help-make
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: How to: organize application files and get GNU make to put theoutpu


From: Paul Smith
Subject: Re: How to: organize application files and get GNU make to put theoutput files into the right place.
Date: Mon, 25 Jan 2010 14:04:25 -0500

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.

> 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 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>

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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]