[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) $< $@
clean:
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
subdir
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?
Britton
- how vpath should behave,
Britton Kerin <=