[Top][All Lists]

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

Re: Target-specific CPPFLAGS for autodependencies

From: Greg Chicares
Subject: Re: Target-specific CPPFLAGS for autodependencies
Date: Wed, 10 May 2006 22:08:08 +0000
User-agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)

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

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.

reply via email to

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