On Wed, 13 Nov 2002 23:29:39 -0500 (Eastern Standard Time), Todd Vierling write
>sjg:  Do note that NetBSD's own mkdep process removes leading paths to ".c"
>files, specifically because we want .depend to contain filenames *before*
>.PATH-transformation.  Perhaps your -MD-based .depend setup should mimic

But how can an external tool know what make saw before .PATH
translation?  Removing paths before .c files seems (initially at
least) as dangerous as anything else.  The code added to make in dir.c
v1.32 is presumably catering for Makefiles saying foo.o: subdir/foo.c?

>this behavior so that it produces .depend entries in the format bsd.*.mk
>expects, rather than however (gmake?) expects from gcc?  Or, on the other
>hand, is there a reason you absolutely need .DOTLAST?

Yes. Because without it the original entry for .CURDIR is used (first
it seems) and so we find cat.c as an absolute path - which is exactly
what I want to avoid.  My goal is to minimize the pain of debugging a
binary on a machine other than the build host - possibly with the
build tree mounted via some other path.  Using relative paths in all
the debug symbols seems to help quite a bit.

As I said, if the initial .PATH entry for .CURDIR were manipulatable -
such that I could change it to a relative path, I would likely not
need .DOTLAST or the specific ${RELCURDIR} entry in .PATH and since
make would be using the magic 'dot' entry it would automatically do
exactly what I'm trying to do with this patch - at least in 
DirLookupSubdir().

I'm trying to get back to the behaviour I got from dir.c v1.26 without
breaking what ever other features/fixes have been added since.

Thanks
--sjg