Toolifying nbmake properly?

[Valery Ushakov <uwe%stderr.spb.ru@localhost>]

Surprisingly, we don't properly build nbmake as a tool.

$TOOLDIR/bin/nbmake still defaults to host's mk files, which might
result in surprising and silent failures.  E.g. I've just spent quite
a bit of time trying to figure out why /usr/include/arm was missing
from the comp.tgz of my arm build.

distrib/sets/sets.subr has arch_to_cpu() function that uses make to
get MACHINE_CPU.  Slighly reformatted for clarity:

    MAKEFLAGS= MAKEVERBOSE= MACHINE_ARCH=${1} \
    ${MAKE} -B -f- all <<EOMAKE
.include <bsd.own.mk>
all:
	@echo \${MACHINE_CPU}
EOMAKE


Turns out that this usually works only by accident.  I was building on
a Linux host that also has Linux bmake package installed.  bmake
package is a port of NetBSD make and it comes with vintage mk files.
And it's those vintage mk files that are used by the make invocation
above!  Too bad the expression to compute MACHINE_CPU in those mk
files doesn't know anything about evbearmv7hf-el

I haven't tried it, but the same failure should probably happen when
building on NetBSD-6.  Its bsd.own.mk does't yet know about evbarm
either.

We rely on the make wrapper to provide -m syspath to all invocations
of nbmake in the build, but we provide it via MAKEFLAGS that has to be
sanitized from the environment in the invocation above.

If we consider things in mk files like e.g. that MACHINE_CPU
definition in bsd.own.mk to be "part" of make, we really should
install them in $TOOLDIR/share/mk and arrange for nbmake to use them
by default.

If we only consider nbmake, the program, to be the tool, we should
arrange for such bsd.*.mk lookups like MACHINE_CPU above to use the
right mk files.  Ideally we should be able to poisoning the
environment so that accessing host's mk files by accident is trapped.

-uwe