Re: Target-specific CPPFLAGS for autodependencies

[Greg Chicares]

On 2006-5-10 19:59 UTC, David Greene wrote:
> I use target-specific variable definitions for things like CFLAGS
> and CPPFLAGS.

That does seem much nicer than an if...else if...else cascade.

> Unfortunately, GNU make's ability to automatically make makefiles
> can't take advantage of this:
> 
> prog: CPPFLAGS = -I/my/include/dir
> prog: file1.o file2.o
> 
> %.d: %.c
>       $(CC) -MM $(CPPFLAGS) $< > $@
> 
> include file1.d file2.d
> 
> Since the rule that makes file.d and file2.d is not invoked
> as a dependency of prog, CPPFLAGS is not set to the correct
> value.

Here's the only way I know; I'd be glad to learn a better way.

Split it into two makefiles. In the first, write
> prog: CPPFLAGS = -I/my/include/dir
> prog: file1.o file2.o
and so on for other targets than 'prog'; and add a '%: force'
make-everything rule that invokes $(MAKE) and passes all the
variables you've set target-specifically.

In the second one, the submakefile, each thing you passed is
now just a normal variable. Everything except target-specific
definitions goes in this submakefile--all the "real work", e.g.
> %.d: %.c
>       $(CC) -MM $(CPPFLAGS) $< > $@
>
> include file1.d file2.d
along with your '%.o: *.c' rules.

Sorry I haven't the time right now to write a validated sample,
but I have used this technique in production and it works.

Probably you've seen the "recursive make considered harmful"
paper, which says it's a bad thing to delegate the "real work"
to a submakefile that doesn't have full information about what
you're actually building. I've used this where targets really
are independent--say, multiple builds of the same system using
different compilers--so that problem doesn't arise; in such a
case, the only information that's masked from the submakefile
is where the variable definitions came from, but that's what
we want them not to know. In different circumstances, this
method could be inappropriate.