[bug #67195] surprising behavior with prerequisite search via vpath

Follow-up Comment #3, bug #67195 (group make):


> 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.

Do you think '../include/file.x' is a prerequisite or a target?
'../include/file.x' is both a prerequisite and a target.


> 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.

There is prerequisite 'file.x' and make finds 'file.x' as
'../lib/include/file.x' through directory search.
Whether '../include/file.x' is specified as a target on the command line or
not, the behavior of make is the same.
In either case, make uses directory search to find
'../include/file.x' as '../lib/include/../include/file.x'
and
'file.x' as '../lib/include/file.x'.


> But now I wonder if this "search for relative paths" is done simply by
> concatenating the elements of the vpath with the prerequisite.

It is concatenating on the filesystems which use /. It is slightly more
complex on the filesystems which use other delimiters.


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?67195>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/

-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQQk97aszIMMAvLLwm6qLAuaBUf3TgUCaEoEeQAKCRCqLAuaBUf3
TnISAP9tFor1o8CeAnxplZWjGlpoyiCvcJMhlDUyiR4P6OuFfwEAmzedJrrIgplS
+mHoeBhWY2cxnHj6R/V2wE2l3aQWjQg=
=XonS
-----END PGP SIGNATURE-----