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/
signature.asc
Description: PGP signature
