RE: Gmake Enhancement

[Paul Smith]

On Fri, 2007-10-05 at 14:53 -0700, Jim Belton 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).
> 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.

Ah, I understand the difference you intend.  In addition to the current
locations, which include the current directory, you also intend to
search the directory the included makefile exists in.

> > 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?

It's not clear, exactly.  Probably none since that variable will be
reinterpreted once all the makefiles are read anyway.

> > 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?

Again, probably none; there's an off chance that a makefile that
previously wasn't found at all would now be found via VPATH.

> 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.

Yes, but I'm not that excited about adding yet another keyword, with
only slightly different semantics, to the make syntax.


If all your makefiles live in one central location, then you could set a
variable based on the location of the first one (by looking in
MAKEFILE_LIST) and use that for the rest.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <address@hidden>          Find some GNU make tips at:
 http://www.gnu.org                      http://make.mad-scientist.us
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist