>: Note that the one upshot of moving all objdir handling to <bsd.obj.mk> does
>: have one noticeable impact:  pre-evaluating variables (using := or !=), or
>: dependency rules, containing an explicit ${.OBJDIR} before including
>: <bsd.obj.mk>, will probably evaluate to the wrong thing.  However, typically
>: an explicit ${.OBJDIR} is not needed, and I am running a full-text grep on
>: the source tree to find the locations where this can be fixed in our tree.

Well this will certainly hose me.
I use bmake at work and play fancy games with .CURDIR and .OBJDIR
in sys.mk, so if .OBJDIR were to be changed later that would all break.

>Now, since make actually chdir()s to the .OBJDIR, in most cases an explicit
>reference to ${.OBJDIR} is unnecessary, and from what I've seen of the
>currently-running grep so far, almost all cases can have the explicit
>reference nuked.

You can't simply nuke all references to .OBJDIR.  Granted most of them are 
plain wrong (not talking about netbsd's tree - I've not checked it recently)
but there are cases where its use is important.

The games I mentioned above involve resetting .CURDIR to a relative path
from .OBJDIR, and setting .OBJDIR=., these ensure that all .h's etc
are found via relative paths - ensuring that there are no absolute paths
buried in debug symbols in .o's etc.  The original values of .CURDIR and 
.OBJDIR are saved for the occasions where an absolute path is necessary.

Thanks
--sjg