help-make
[Top][All Lists]
Advanced

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

Re: Automatic macro dependencies


From: Brian Dessent
Subject: Re: Automatic macro dependencies
Date: Tue, 05 Aug 2008 13:20:22 -0700

Harvey Chapman wrote:

> I'd like to be able to define a list of macros like (DEBUG_XX, DEBUG_YY)
> and have make detect that a source file needs to be recompiled because
> of a change in that list. These macros are always used with an "#ifdef"
> or  an "#if defined()" style pre-processing directive.

How is make supposed to know what the value of a macro from a previous
compilation was in order to know that it's changed?  Remember that make
has no special knowledge of C or compilers or anything, aside from a
builtin database of recipes for common file extensions.  But at its core
all make knows is how to express a relationship between a target file
and a list of its of dependent files, optionally with a set of commands
to run to rebuild that target.  It knows nothing of their content or
semantics.

In order to implement this you really need to transform the problem into
one of "what files have changed", i.e. put the definition or
not-definition of the DEBUG_XX and DEBUG_YY macros in a header file that
gets included by every source file.  Then add the header as a dependency
of the source files -- if you use an automatic dependency generation
mechanism you get this for free.  With this setup, enabling or disabling
debug macros means updating this config.h file, and that is something
make knows how to detect and propagate.  Autoconf uses this method
extensively, see AC_CONFIG_HEADERS.

Alternatively, you could do it by encoding CPPFLAGS into the name of the
output object file, so that if CPPFLAGS changes make will see that the
targets do not exist and build them.  This could be done with a lot of
pattern rule magic, but I think it would quickly get ugly for more than
a very simple case of two alternatives.  And it's really just a much
uglier way of doing VPATH builds, i.e. multiple separate build dirs for
one source dir, each with their distinct options.  Also it means that
-DFOO -DBAR is treated as different and distinct from -DBAR -DFOO which
could lead to all kinds of unexpected consequences.

Brian




reply via email to

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