bug-make
[Top][All Lists]
Advanced

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

[bug #16286] VPATH and directory cache


From: anonymous
Subject: [bug #16286] VPATH and directory cache
Date: Thu, 6 Apr 2006 19:55:07 +0000
User-agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)

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

Well, that VPATH is useless for anything except leaf targets is what I
figured out on my own after some time of inverstigation.

If one has to include the object dirs or whatever all over the place anyway,
using VPATH just for leaf targets makes things not much easier. It has its
(very limited) use anyway.

What bugged me was that the prerequisites of the linking process are partly
prefixed through vpath, and partly not.
So instead of getting a command

 gcc foo1.o foo2.o foo3.o ...

(which of course won't work since the .o files are in obj/*) I end up with a
command

  gcc foo1.o obj/foo2.o obj/foo3.o foo4.o ...

where the object files with prefix and the ones without prefix change with
each call of make (after a clean) and their magnitude (how many of this or
that) with the number of object files. (for the first one I suspected XRays
as random generator, but maybe it's the OS or the amount of free memory or
just coincidence)

So the bug is: either NO non-leaf-target (or rather its prerequisites) is
handled using vpath (which would at least give a predictable result), or ALL
are (which would give an even more pleasant result) but not a mixture of
both, depending on whatever. Since Make does not know which target is a leaf,
the second alternative seems to be easier to do. (before pruning a file, just
verify its existence once and update the entry if necessary)

In its current incarnation, vpath is pretty useless and does not save much
work. Saving to write the path of external source files in a makefile does
not seem to remotely justify the work put into vpath. But that's just my
opinion.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?func=detailitem&item_id=16286>

_______________________________________________
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/





reply via email to

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