Subject: make: Dir_FindFile still broken
To: None <tech-toolchain@netbsd.org>
From: Simon Gerraty <sjg@juniper.net>
List: tech-toolchain
Date: 11/12/2002 10:27:41
Rev 1.27 of dir.c apparently introduced a bug, that rev 1.32 attempts
to fix, but for me at least it is still broken.

With rev 1.26, if I have

.PATH: ${RELCURDIR} .DOTLAST

and RELCURDIR is say, ../../../src/bin/cat when make looks for cat.c
it will find ../../../src/bin/cat/cat.c - so you get relative paths in
debug symbols etc.  When make looks for ../../../src/bin/cat/cat.c it
will also be found as that path.  

As of 1.32 though when make looks for ../../../src/bin/cat/cat.c
it is found as ../../../src/bin/cat/../../../src/bin/cat/cat.c

Add to the mix the fact that I use automatic dependency updates
(CFLAGS includes -MD and .depend is updated from the *.d files after
each successful build), this is a problem as the
../../../src/bin/cat/'s accumulate.

I'm still looking at the diffs for rev 1.32 and 1.27 to spot what to
do about it.

I found that making .PATH: contain

.PATH: . ${RELCURDIR} .DOTLAST

solves the above, but then breaks the case were we avoid adding ./
when finding a file in 'dot' since (I guess) we now have a '.' in the
path which is not 'dot' ;-)

Which leads me to suspect the question posed in Dir_FindFile

/* XXX - should we look in `dot' subdirs here? */

should be answered 'yes'?

--sjg