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:[EMAIL PROTECTED] > Sent: Friday, October 05, 2007 9:38 PM > To: Jim Belton > Cc: bug-make@gnu.org > 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 <[EMAIL PROTECTED]> 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 > _______________________________________________ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
