[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: |
Sat, 6 Oct 2007 00:39:39 -0700 |
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
> >
>