The same project is assembled on different versions of the OS with different flags.
What is this flag?
First OS:
-g++ -c -pipe -g -D_REENTRANT -Wall -W -Wno-unknown-pragmas -DQT_WEBKIT -D_TESTR ...
Other OS:
+g++ -c -pipe -g -D_REENTRANT -Wall -W -Wno-unknown-pragmas -D_TESTR
The -D option is a preprocessor option and is documented in section 3.13 Preprocessor Options of the GCC Manual. (You can also always just run gcc --help or g++ --help to get help for the options.)
The -D<name>[=<value>] option #defines the macro <name> to have the value <value> (or 1 if the value <value> is not provided).
So, in your case, it defines the three macros _REENTRANT, QT_WEBKIT, and D_TESTR to the value 1, in other words, it is exactly equivalent to having
#define _REENTRANT 1
#define QT_WEBKIT 1
#define D_TESTR 1
prepended to the file being compiled.
Related
In the old Makefile there is an include part:
SHELL=/bin/sh
CORE_SRC=\
./Core/allocator.cpp \
./Core/etc... \
CORE_OBJS=$(CORE_SRC:.cpp=.o)
INCLUDE=\
`pkg-config --cflags glib-2.0 libpng` \
`sdl-config --cflags` \
`freetype-config --cflags` \
`./python-config-linux.sh --cflags` \
-I./TopLayer -I./etc...
CC=g++-4.4
CFLAGS=-O3 -pipe -Wall -fPIC -D__STDC_CONSTANT_MACROS
CORE_LFLAGS=\
-fPIC \
-Wl,-rpath,./libs
CORE_LDLIBS=\
`pkg-config --libs glib-2.0 libpng` \
`sdl-config --libs` -lz -ljpeg \
`freetype-config --libs` \
`curl-config --libs` \
-L./$(LIBSDIR) \
-letc...
GAME_LFLAGS=\
-shared -pthread -fPIC \
-Wl,-rpath,../libs
GAME_LDLIBS=\
-lm \
`python-config-linux.sh --libs`
target_name: $(CORE_OBJS) $(CORE_NAME)
target_name: override CFLAGS += -DAV_OUTPUT
$(CORE_NAME): $(CORE_OBJS)
$(CC) $(CORE_LFLAGS) $(CORE_OBJS) $(CORE_LDLIBS) -o $#
.c.o:
$(CC) $(CFLAGS) $(INCLUDE) -c $< -o $*.o
.cpp.o:
$(CC) $(CFLAGS) $(INCLUDE) -c $< -o $#
The execution of those configs is:
$pkg-config --cflags glib-2.0 libpng
-> -I/usr/include/glib-2.0 -I/usr/lib/i386-linux-gnu/glib-2.0/include -I/usr/include/libpng12
$sdl-config --cflags
-> -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT
$freetype-config --cflags
-> -I/usr/include/freetype2
$./python-config-linux.sh --cflags
-> -I/python-2.7.10/include/python2.7 -I/python-2.7.10/include/python2.7 -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
I don't understand and a bit confused about Cmake - should I use target_include_dirictories() or find_packages()?
Should target_include_dirictories() be used also with --cflags and libs like glib-2.0 libpng for pkg-config?
*Updated makefile. Removed unnecessary targets etc.
You will need both find_package() and target_link_libraries().
target_include_directories() is almost always obsolete when using libraries found through find_package. Docs.
Example
Example tested on macOS HighSierra with CMake 3.12.
project(Example)
cmake_minimum_required(VERSION 3.10)
find_package(PNG REQUIRED)
add_executable(prog main.c) # main.c from: http://zarb.org/~gc/html/libpng.html
target_link_libraries(prog PNG)
# On Ubuntu 14.04 + CMake 3.2 use the older syntax (FindPNG.cmake is too old) from the next line:
# target_link_libraries(prog ${PNG_LIBRARIES})
I'm building a GHC from source again (7.8 on ARM, as there's no binary version of that), and noticed it does this at some point:
"inplace/bin/ghc-stage1" -static -optc-DTHREADED_RTS -optc-DDEBUG -H32m \
-O -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header \
-Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS \
-package-name rts -dcmm-lint -i -irts -irts/dist/build \
-irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen \
-O2 -O0 -c rts/StgMiscClosures.cmm -o rts/dist/build/StgMiscClosures.thr_debug_o
Well, that's -O, -O2 and -O0 in a single command!
What is the reason for this, and which flag takes precedence anyway in such a case?
processArgs processes command-line arguments left-to-right (see process in CmdLineParser.processArgs. Furthermore, the semantics of the -O flags is such that each of them turns on/off a certain subset of individual optimizations (see updOptLevel). So in your example -O0 "wins" since it overwrites the effects of -O and -O2.
I am kinda rookie in makefile field but trying to write makefile that would go in two modes: normal mode make outputing executable file called say bingo depending on some files and a mode make debug outputing executable file called bingo.debug that shall be compiled with debug option. I'm trying to use target variable with the following result:
PROGRAM = bingo
SUFIX = .debug
CC = gcc
CFLAGS = -Wall -O2
DEBUG = -g -D DEBUG
all: $(PROGRAM)
debug: CFLAGS += $(DEBUG)
debug: PROGRAM += $(SUFIX)
debug: all
file1.o: file1.c file1.h
$(CC) -c $(CFLAGS) -o $# $<
file2.o: file2.c file2.h
$(CC) -c $(CFLAGS) -o $# $<
$(PROGRAM).o: $(PROGRAM).c
$(CC) -c $(CFLAGS) -o $# $<
$(PROGRAM): file1.o file2.o ($PROGRAM).o
$(CC) -o $# $^
.PHONY: all clean
clean:
rm -rf $(PROGRAM) *.o
It looks like make debug correctly compiles the file with debug flags but it does not change the file name (i.e. both modes outputs the same bingo file). Any help much appriciated!
You cannot use target-specific variables in targets. The documentation is very clear that they are available only in recipes.
In general it's problematic to do things this way, because make has no idea which objects were built with debug and which weren't. If you forget to do a complete clean and/or run make the wrong way then you'll get a mix of different object files: some compiled with debug and some not.
Instead, you should put your debug object files in a different directory from your non-debug object files so you don't have to worry about that.
It's quite easy to get clang++ to use GCC's libstdc++ (-stdlib=stdc++), but how can I do the converse? On OS X Mavericks, the c++ system library is libc++, which means that basically libstdc++ cannot be used (if you mix with other c++ libraries such as boost that have been compiled with libc++). So, roughly, that means G++ is not usable... Unless I can ask it to use libc++ rather than libstdc++.
Thanks.
The script I use (EDIT)
I'm using the following script, g++-libc++, to run g++ on top of libc++, on Mac OS X with MacPorts (hence the -mp names.
#! /bin/sh
clangxx=clang++-mp-3.5
gxx=g++-mp-4.9
libcxx_includes=$($clangxx -print-search-dirs |
perl -ne 's{^libraries: =(.*)}{$1/../../../} && print')
exec $gxx -std=c++11 \
-isystem ${libcxx_includes}/include/c++/v1 \
-nostdinc++ -nodefaultlibs \
-lc -lc++ -lc++abi -lgcc_s.10.5 \
-Wl,-no_compact_unwind \
"$#"
Something like:
g++ -std=c++0x -nostdinc++ -nodefaultlibs -lc -isystem <path_to>/include/c++/v1 -lc++ -lc++abi -lgcc_s.10.5
I am asked to write a Makefile which needs to selects between two compilers, and each of these compilers should support 3 build versions (debug, release, test).
There are a lot of variables that change based on input (compiler, compiler options, output directory, include directories etc). My first option was to go through target-specific variables and configure variables according to target. Do you think this is good idea?
I am not extremely familiar with those kind of variables. It seems to me that if I do something like this:
release: variable1=value1 #release is target
release: variable2=value2
release:
# some compilation rule
Only the variable1 will be configured. Am I right about this?
Update
Thank you for your reply. I am trying to deal with compiler selection issue through additional variable which would be configured according to target. But, here is the problem. I have the following lines:
release: CFLAGS = -DCORE_SW_VERSION='"$(CORE_SW_VERSION)"' -Wall
release: CFLAGS += -fgnu89-inline -mno-volatile-cache $(INCLUDE)
release: TARGET=release
After this lines, I do some ifeq sequence in which I decide which compiler to use (according to TARGET variable value).
And CFLAGS is configured properly, but the TARGET variable is empty. This leads me to conclusion that you can configure only one target-specific variable. Am I right? If not, I am not aware what I am doing wrong. Could you please help me?
Target-specific variables are defined only when building that target and any prerequisites of that target. You can't use target-specific variables arbitrarily throughout the makefile (as it sounds like you're trying to do with ifeq). For that, you may want to look at $(MAKECMDGOALS). I don't believe there is any limit on the number of target-specific variables, certainly not a limit of one.
Needing either target-specific variables or $(MAKECMDGOALS) may be a warning that you're trying to do coerce make into doing something it wasn't meant to do.
It's not clear to me whether you want to build three versions (debug/test/release with a single compiler for each one), or six versions. Assuming three, here is a unix-y Makefile to build with different compilers and CFLAGS depending on the target. However, note that this could just as easily be coded with RELEASE_CFLAGS, RELEASE_CC, DEBUG_CFLAGS, etc... variables.
all: release debug test
release: CC=gcc
release: CFLAGS=
debug: CC=gcc
debug: CFLAGS=-g
test: CC=cc
test: CFLAGS=-Wall
.PHONY: release debug test
release: release/exe
debug: debug/exe
test: test/exe
OBJECTS := test.o
release/%.o: %.c
$(CC) $(CLFAGS) -c -o $# $<
debug/%.o: %.c
$(CC) $(CLFAGS) -c -o $# $<
test/%.o: %.c
$(CC) $(CLFAGS) -c -o $# $<
release/exe: $(OBJECTS:%=release/%)
$(CC) $(CFLAGS) -o $# $^
debug/exe: $(OBJECTS:%=debug/%)
$(CC) $(CFLAGS) -o $# $^
test/exe: $(OBJECTS:%=test/%)
$(CC) $(CFLAGS) -o $# $^