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:[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
