RE: Gmake Enhancement

[Jim Belton]

Paul:

I don't think VPATH would help me enough.  I would still need to write:

VPATH=../..
include makedefs/makedefs.mk

This isn't much better than:

TOPDIR=../..
include $(TOPDIR)/makedefs/makedefs.mk

which is what we have today.  What I really want to write is:

include ../../makedefs/makedefs.mk

and have the included makedefs.mk be able to pull in other files
relative to its path.  I think I've found a solution.  Inside the
makedefs.mk file, I can write:

TOPDIR=$(dir $(patsubst %/,%,$(dir $(lastword $(MAKEFILE_LIST)))))

It would be really nice to have a builtin variable for this, so I could
write:

TOPDIR=$(dir $(.INCDIR))

or something like that.

Anyway, looks like I have what I need.  If you like the .INCDIR idea,
let me know.  I may decide to hack it into gmake, if you're interested.

Cheers,
Jim.

> > -----Original Message-----
> > From: Paul Smith [mailto:address@hidden
> > Sent: Friday, October 05, 2007 9:38 PM
> > To: Jim Belton
> > Cc: address@hidden
> > Subject: RE: Gmake Enhancement
> > 
> > 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
> > 
>