[Top][All Lists]

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

how vpath should behave

From: Britton Kerin
Subject: how vpath should behave
Date: Wed, 19 May 2021 15:09:43 -0800

It looks to me like when vpath evolved from VPATH a few things could
have been better:

1.  It should just set the path, not add to a list of paths anymore.
The original behavior was needed for VPATH but since vpath works
per-pattern (or even per-target) it's pointless and potentially
confusing: the user should know where stuff is supposed to be and
finding it somewhere else is a likely source of confusion, especially
since this is likely to to get used in a context where users are
migrating away from a setup where everything is kept in one dir.

2.  vpath seems schizo about where the path changes it implies are
honored.  My previous email shows one such place, here's another:

$ cat Makefile
OBJS = objdir/foo.o

FC = cp # Fake Compile
FL = cp # Fake Link

vpath %.o objdir

$(OBJS): %.o: %.c
        $(FC) $< objdir/$@

foo: foo.o
        $(FL) $< $@

        rm -f *.o
        rm -f objdir/*.o
        rm -f foo
$ make foo.o
make: *** No rule to make target 'objdir/foo.c', needed by
'objdir/foo.o'.  Stop.

If the OBJS = objdir/foo.o line is changed to just OBJS = foo.o then
foo.o can be built as expected with make foo.o and a subsequent
rebuild will understand it to already exist (because
it's found in objdir).  static patterns seem unaware of vpath.

I've never used vpath before so maybe I don't understand it's purpose
correctly, but it seems that it's intended to avoid making user write
e.g. $(OBJDIR)/some_target everywhere or write
functions that do it or eval or whatever when all that's really meant
is "we're working in a subdir now".

vpath should just automatically prefix it's path onto every target or
prereq that matches it's pattern (and it's pattern arg should be a
list of patterns).  This should happen in all the appropriate places
(e.g. static pattern targets part, $< $@ etc.  The interface with the
should just be handled by the presence (or not) of a matching vpath
for the targets involved (so e.g. binary foo doesn't have a matching
vpath but foo.o does so $(FL) $< $@ works as expected).

Of course this would be too dangerous a change for vpath itself but a
new directive cpath or something could be introduced.  Thoughts?


reply via email to

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