[Top][All Lists]

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

[bug #16286] VPATH and directory cache

From: Paul D. Smith
Subject: [bug #16286] VPATH and directory cache
Date: Thu, 6 Apr 2006 16:33:04 -0400
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20060124 Firefox/

Follow-up Comment #3, bug #16286 (project make):

All of the behavior you see, as far as I can tell, is expected.  The
documentation of vpath shows that if the target needs to be rebuilt then the
vpath-qualified pathname is thrown away and the target is rebuilt locally
(which means that when this target is listed as a prerequisite it will also
be referred to locally).  If the target is not rebuilt then the vpath path
will be preserved, obviously.

Also, any time you have a make rule that builds ANY target that is not the
one make thinks it will build (which is the value of $@, exactly) then your
makefile is incorrect, and you cannot (or, at least, should not) expect valid
behavior from make.  Your makefile is a contract with make that tells the make
program "if you want to build target A, then run these commands and it will be
built".  If your rules don't build target A but instead something else such as
../A or $(OBJDIR)/A, then you have a bug in your makefile and make won't work

All of the behavior you're seeing is explained in my webpages referenced
earlier.  If a .o is found in the local directory then vpath searching is not
performed, and you will just get that filename with no vpath prefix.  If the
.o is not found locally but is found by vpath, but it is out of date and
needs to be rebuilt, then again you will get that filename with no vpath
prefix.  If the .o is found via vpath and doesn't need to be rebuilt, then
and ONLY then will you get the vpath pathname.

You can modify the latter behavior with GPATH (see the manual) which will
keep make from throwing away the vpath prefix for targets that need to be

In fact, the current behavior of VPATH is not at all useless.  It  is used in
two ways, very commonly.  There is only one set of source code, but you can
have a huge number of targets built from that code: different platforms,
different compiler options, etc.  So VPATH can be used as it is with
autoconf/automake: you create a separate directory, then run the build in
that directory with a reference back to the source code.  This allows your
makefiles to be much simpler to write, since you just write it to create all
the objects in the current directory and the source is found via VPATH. 
Otherwise you'd have to be very careful to prefix every target name with an
"object directory" pathname so it wouldn't write to the source directory.

The other common use of VPATH is where you have a "master workspace" which is
pre-compiled.  Then all the people working from that baseline make a local
workspace which doesn't have any source in it.  They only check out into
their local workspace the files that they want to work on (or maybe they use
a link farm or whatever).  When they run make it will look locally, then in
the master workspace (via vpath).  If the file exists locally, it's used.  If
it exists in VPATH and it doesn't need to be rebuilt, then the master
workspace copy is used.  If it exists in VPATH and _does_ need to be rebuilt,
then it's rebuilt into the local workspace (with no vpath) not the master
copy.  This is exactly how VPATH works.


Reply to this item at:


  Message sent via/by Savannah

reply via email to

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