bug-make
[Top][All Lists]
Advanced

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

RE: Gmake Enhancement


From: Jim Belton
Subject: RE: Gmake Enhancement
Date: Fri, 5 Oct 2007 23:25:45 -0700

Paul:

I've never used VPATH before.  Let me go understand it and look at the
code that implements it.  I will also see if I can figure out why the
test harness is borked under FreeBSD for me.  Could be our port of
ActivePerl.

Have a great weekend!
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
> 




reply via email to

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