[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Problem with GNU Make (3.81, probably newer) with stacking --include
From: |
Paul Smith |
Subject: |
Re: Problem with GNU Make (3.81, probably newer) with stacking --include-dir=... |
Date: |
Wed, 11 Jun 2014 13:45:35 -0400 |
On Tue, 2014-06-10 at 16:01 -0700, Corey Brenner wrote:
> I've run into a situation where I want to control the include dirs in
> a recursive make. I am adding include paths to recursive invocations
> via --include-dir=, when I find one which matches my criteria.
>
> However, GNU Make seems to be holding on to these directories from
> high level invocations to lower ones. The construction of include
> paths, via --include-dir, should be per-invocation,
> and not shared with children, except by providing --include-dir=... on
> the recursive command line.
I don't think you'll find too many people who agree with your assessment
that GNU make's behavior in this situation is wrong. The typical use
for the -I (--include-dir) flag is to provide a general location to
search for included makefiles and most people would expect and intend
that recursive invocations of make would get the same paths as the
initial invocation so they can all include the same makefiles, without
having to specify them to every sub-make.
> Is there a way to suppress this behavior?
The only way I can think of is to modify the MAKEFLAGS variable in your
makefile to remove the flags. In GNU make 4.0, this is pretty simple
because the flag and the option are concatenated into a single argument:
$ echo 'a:;: $(MAKEFLAGS)' | make-4.0 -f- -I/usr/include -I/bin
: -I/usr/include -I/bin
You can easily use $(filter-out ...) for example, to remove all the -I
flags. Unfortunately in older versions of make the option and argument
are left as two separate words:
$ echo 'a:;: $(MAKEFLAGS)' | make-3.81 -f- -I/usr/include -I/bin
: I /usr/include -I /bin
which makes it much more difficult to remove them.