On Mon, Jan 25, 2010 at 2:04 PM, Paul Smith
<address@hidden> wrote:
On Mon, 2010-01-25 at 13:14 -0500, Ted Byers wrote:
> One last question. Right now, I have:
>
> CPPFLAGS = -Wall -pedantic -I ../include
>
> I haven't set a variable for linking, so I suppose I am using whatever
> default value there may be (if there is one).
Note that this is technically not quite correct. The "CPP" in CPPFLAGS
means "C preprocessor", not "C++". In make, the prefix for variables
related to C++ is "CXX", not "CPP".
In short, you should only be putting preprocessor flags into CPPFLAGS;
that is -I, -D, and similar.
Compiler flags like -Wall, -pedantic, etc. should go into CFLAGS (for C
code) or CXXFLAGS (for C++ code). Linker-specific flags go into LDFLAGS
variable.
OK. Thanks. I wasn't aware of this.
> What would be the procedure to extend the CPPFLAGS (and whatever the
> corresponding link variable) so that if I invoke it in one way, the
> executable has all the debug info and no optimization, and if invoked
> in another way, without debug info and full optimization? Ideally, if
> I specify either 'make debug' or 'make production', all the code,
> whether for a library or for the executable, would be compiled with
> either the debug info and no optimization or no debug info and full
> optimization. Is there a standard way to do this?
Not sure what you mean by "standard"; if you mean by "generally
available in GNU make", one option is to use target-specific variables
(see the manual for details). Do something like this:
By "standard" I meant only commonly accepted, or commonly used, practice.
# By default, enable both optimization and debug
OPTFLAGS = -g -O2
CFLAGS += $(OPTFLAGS)
CXXFLAGS += $(OPTFLAGS)
debug: OPTFLAGS = -g
debug: all
production: OPTFLAGS = -O2
production: all
all: <whatever>
Thanks. This will be useful as a start.
But here's a question about order of execution. Above you show the contents of OPTFLAGS being added to whatever is in CFLAGS and CXXFLAGS. When is that executed when make is invoked with either debug or production? Before the target specific values are defined or after?
And a point of clarification. We don't want to mix debug and non-debug binaries. So, I have clean and realclean targets defined that remove intermediate binaries or all binaries. Therefore, I need to ask, is there a well defined order in which targets that have been specified are made? For example, is realclean guaranteed to be done before all if I specify:
debug: realclean all
Or is it just a matter of chance whether or not the above would have realclean done before all or after? Of course, if realclean is done after all, then nothing useful ends up being done.
However, there are really a lot of disadvantages to this once you decide
you want a flexible build system. If all you'll ever do is run "make
debug" or "make production" and build the entire thing, no problem. But
what if you want to build just part of the code, with "make someapp"
directly? Etc. Also this means you'll have both the debug and
optimized versions written to the same output file, so you can't build
both in the same location. Etc. If you want to solve these kinds of
problems you're looking at a much more flexible environment that allows
you to build multiple output types from the same set of source.
So the implication is that I'd do something similar to what MS VC++ does (different locations for debug and release versions of a given project). I can live with that for the time being.