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:
>| 
>| .PATH: .ASIS ${RELCURDIR} .DOTLAST
>| 
>| 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
putting:

.PATH: . ${RELCURDIR} .DOTLAST

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 sys.mk 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?  

--sjg