>    it seems like having this feature in NetBSD make itself would
>be useful(?).  it isn't clear if it would be better to put it in
>make itself (like i did) or add a new make wrapper script to the
>NetBSD source tree that would do the search.  anyone have any
>helpful thoughts on this?

As I mentioned, I don't think the patch does any great harm, but would 
rather see it in make rather than bmake (my goal in recent years is for
bmake to be little more than an autoconf'd version of netbsd make)
So if Christos and others don't object to it in make - its fine with me.

Again, I can't think of anything better than .../ as the clue to do this.
Though I'm sure someone might.

Lastly, the reason I push the wrapper solution is that it gives you this
search for free, and helps solve other common build problems.
(I've already bored Chuck with this, so this is for everyone else ;-)

The 'mk' wrapper that I use, simply searches up the tree to find a
.sandbox-env file which  marks the top of the sandbox ($SB gets set to that 
location), and also provides a means of controlling the build environment
since 'mk' will source it before it returns to the original directory and
invokes make (actually it invokes cmd=${cmd:-${REAL_MAKE:-/usr/bin/make}})
and there is a plethora of customization hooks provided.

The main compainion to 'mk' is 'mksb' which configures a sandbox (by generating
.sandbox-env and doing a cvs checkout - unless told not to).

We've used this approach at work for some years - and I actually got the ok
to make 'mk' and its companions publicly available - but that was just 
about the time build.sh was introduced so I let it slide.
But I will get around to packaging up mk et al, and posting it for
download or perhaps as a pkgsrc thing.

--sjg