Follow-up Comment #2, bug #67195 (group make): Your reply confirms what I suspected, namely that make indeed searches for the relative path '../include/file.x' instead of just the file 'file.x'. I think this is wrong but one may perhaps have a different opinion.
Furthermore, if we remove (or ignore) the 'all' target and directly specify
'../include/file.x' as a goal:
> make ../include/file.x
then this results in:
make: '../lib/include/../include/file.x' is up to date.
This demonstrates that searching in the vpath is done not only for
prerequisites but also for targets which IMHO is wrong as well.
Note that the rule '../include/%.x: %.x' matches the goal, and the
prerequisite should thus be the plain 'file.x', which would then be found in
the vpath, which in turn results in the behavior I expected.
If you still think this behavior is correct, then I would request that the
documentation be made clearer. In particular, when it talks about "searching
for prerequisites", it should state explicitly that
1) If a "prerequisite" is a relative path, what is searched for is not the
file itself; instead the prerequisite is interpreted as being relative to all
the directories listed in the vpath.
2) If a vpath directive is in effect, then searching is performed for goals as
well.
BTW, thanks for listing possible work-arounds. I do have one for our actual
use case (part of a large and complex build system) and it works by converting
the top level directory ("..") to an absolute path. But now I wonder if this
"search for relative paths" is done simply by concatenating the elements of
the vpath with the prerequisite. If this is so, then even using absolute paths
would not reliably avoid this issue in all cases...
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?67195>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
