[Top][All Lists]
[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
>