RE: Gmake Enhancement

[Jim Belton]

Hi all:

I wrote:
> > I've been considering making an enhancement to gmake to support 
> > bmake's '.include "file"' semantics.  In bmake, when you 
> > include a .mk file, its included files are searched for in its 
> > own directory as well as in the path.  This allows us to get 
> > around having to define TOP or TOPDIR in all of our Makefiles 
> > (which we currently have to do with gmake on GNU/Linux).
> > 
> > Would you be interested in taking this enhancement back?

Paul wrote:
> When you say "in the path", do you mean the $PATH environment 
> variable?
> I don't like that idea; $PATH is for finding executable 
> programs, not makefiles.

Nope.  I meant the list of all the paths that make looks in for 
.mk files.  This would include standard places, if any, 
directories specified on the command line with -I and the 
directory that make is run from.

> If you mean a different environment variable, is it 
> sufficient to set MAKEFLAGS variable to have the appropriate 
> -I options?

Nope, because, as you point out below, it does not become 
effective in time.

> There are two idea I have offhand; one is to change make so 
> that modifications to the MAKEFLAGS etc. variables are 
> interpreted immediately when they are made, rather than only 
> before and after all makefiles have been read in.  If that 
> happened then you could add something like this to your makefiles:
> 
>       MAKEFLAGS += -I/include/dir

This would work.  What side effects might this have on things 
other than the include path list?

> The other alternative is to modify make to search for 
> included makefiles with VPATH/vpath.  When I first heard 
> about this I didn't like it because that's not what 
> VPATH/vpath is for and I don't like conflating uses like 
> that.  But then I realized that make already searches 
> VPATH/vpath for makefiles, in order to see if they need to be rebuilt.
> So then I thought maybe that's a valid use case.

One of our senior engineers actually thought that VPATH was 
intended to do exactly this, and was surprised when it didn't
work.  What side effects on existing VPATH functionality could 
this have?

It seems like adding the ".include" directive would be safer.  The
naming is somewhat intuitive, since .include is just like include,
but searches in the "." (of the current .mk file) as well as 
everywhere else.  I think I could add this without breaking 
anything.

Regards,
Jim.