OK, do up a second patch for the bsd.*.mk files, and we can take a look at
committing it.

I don't think that anyone would disagree with the opinion that the NetBSD
build system is less than perfect. I went through the 1.2 to 1.3 period myself
on a Sun 3/60 (slooooow). The principal problem is that we don't record the
history of the build system or of the toolchain well enough to recapitulate
it (i.e. how we got from "A" to "B"). All we do is galumph along, dropping
snapshots of our progress from time to time (some of which we call "releases").

For someone who wants to catch up to "-current", they are best off installing
the last snapshot, and then keep on doing builds until they've bumped into
and re-solved all of the "oh, you need this new tool version to build that
file now" problems. It's tedious. It would be better if we could record tool
version dependencies in some reasonable manner so as to expose those "oh, you
need the new tool" problems up front. However, we work with what we got now.

Just for the record, I've got PR#4449 open on this general problem. I'm not
expecting a solution any time soon.

My concern is that someone might end up putting together a snapshot with all
the file ownerships or permissions wrong, and woe betide the people who
installed *that*. I find it's best to make sure that the automation gets it
right in the first place, than to depend on manual processes. Among other
things, that reduces the number of things that everyone has to "remember to
do", and thereby reduces the probability of error. Given our record in
documenting things that need to be done, I believe that this is important.

In the long run, I believe that the push for cross-compilation will answer
some of your concerns for separate build space and tools, because it has to.

	Erik E. Fair	fair@clock.org