[Top][All Lists]

[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: Ted Byers
Subject: Re: How to: organize application files and get GNU make to put theoutput files into the right place.
Date: Mon, 25 Jan 2010 15:17:18 -0500

Thanks Paul

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

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)

       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.

For the "much more flexible environment that allows you to build multiple output types from the same set of source" system, can you point me to a document or tutorial that shows how to do this?



reply via email to

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