Subject: Re: make: Dir_FindFile still broken
To: Christos Zoulas <>
From: Simon J. Gerraty <>
List: tech-toolchain
Date: 11/13/2002 23:29:06
On Wed, 13 Nov 2002 23:07:31 -0500, Christos Zoulas writes:
>| >way is to parse the /../ and collapse them. Again this is ucky and
>| >does not work in all cases.
>| And would defeat the purpose of putting a relative path in .PATH.
>No, it would not; it would only collapse /../ inside the path string; not
>leading ones. The problem is again that without a stat, due to symbolic
>links, it would reference different files.

Yes agreed that this is not the way to go.

>| The only other thing I can think of is a new magic token .ASIS or something
>| Then you could have:
>| but I think the path is a prefix of name and stat check is reasonable.
>| The ugly bit is the goto - but the alternative is an extra stat(2) which
>| I'd like to avoid.  Ie. we'd have:
>The .ASIS is too much magic. I think we need to rethink and simplify the
>logic instead of making it more complicated.

When using 'dot' we avoid putting ./ at the start of files, if we gave
that same treatment to '.' then my problem would be solvable by simply


weird but yes it works.  But right now it breaks makefiles that
generate .c files as we get the missmatch of foo.c and ./foo.c

Again if assigning to .CURDIR reset the 'dot' path in .PATH, my
problem would probably also go away (my sets .CURDIR to a
relative PATH - to avoid having to re-write all Makefiles that
use .PATH: ${.CURDIR}/../sibling and the cvs merge pain that would
produce).   Perhaps I'll try implementing that, but I still think make
should spot the pathalogical case where .PATH contains a 
relative path as well as .DOTLAST and he's looking for a file that has
that same relative path as a prefix.  Hmm yes adding a check for
dotlast should nail that down?