I'd like to propose a new scheme for doing builds out of a read-only
source tree, and make an argument for why I think it's as convenient
as possible.  I'll talk about the userland build process first, and
then about the kernel build process at the end.

When you actually type "make" and build object files, you have to do
so in a context which contains some information about where the object
files are going to be.  Currently, you type "make" in the source tree
and each source directory has "obj" symlinks pointing to where the
objects are; but if some piece of state in the source tree knows where
the build directory is, there can really only be one build tree, which
is very limiting.

There are two options I can think of for providing information about
the build directory.  One is to set an environment or make variable
giving the build directory, and the other is to type "make" from
within a build tree.

For subtle reasons having to do with the semantics of make, the first
option basically boils down the existing MAKEOBJDIR environment
variable (that is, make has to know what its object directory is
before it reads the Makefile, so a make variable won't work).  So one
possible scheme to do away with obj links is to have the subdir.mk
file modify the MAKEOBJDIR variable during submakes.  The problem with
this scheme is that it makes it difficult for the user to set up the
context once and then do a build from any part of the source tree.

So we're left with the second option: make from within a build tree.
Let me propose how I see this scheme working (I've already implemented
a prototype some time ago, but I seem to have lost it, so the details
may be slightly wrong):

	1. To get things started, you cd into the source tree (or some
	   part of it) and type "make buildtree TREEDIR=/my/dir".

	   This generates a build tree under /my/dir with all of the
	   subdirectories of the current source directory.  Each
	   build directory contains a little stub Makefile, which
	   looks like:

		.CURDIR=<the corresponding source directory>
		TREEDIR=<the build directory>
		.include ${.CURDIR}/Makefile

	2. To actually build the objects, you run "make" in the build
	   directory; doing so in subdirectories is of course fine.

	3. A few Makefiles have to be taught that ${TREEDIR}, not
	   ${.CURDIR}, is the appropriate starting point for running
	   "make" in a directory nearby the current one.
	   /usr/src/usr.sbin/tn3270/tn3270/Makefile is an example.

	4. Sometimes new directories are added to the sourcedirectory.
	   bsd.subdir.mk should probably recognize this and generate
	   build directories on the fly when they're missing.

For kernel builds, I think you just want to modify "config" to:

	1. Use only the last path component of the given argument as
	   the name of the build directory (so kernel configs don't
	   have to be in the conf directory).

	2. Allow an option to specify the name of the "compile" tree
	   instead of ../compile.

	3. Allow users to overwrite the "S=" line in Makefile.i386 (or
	   whatever) with a command line option, so that the source
	   directory is not "../../../..".

This doesn't yield the world's most convenient kernel build system;
you'd wind up typing something like:

	config /my/configs/MYKERNELNAME -b /my/compile -s /sys

You could make this slightly easier to use by having the user run
"config" from his or her own compile tree ("config -s /sys
../conf/MYKERNEL"), but that's a significant departure from how config
currently works.

Comments?  Do people like this?  Do people go "ewww?"  Can people
think of simpler ideas?  The lack of a good system for doing NetBSD
builds out of a read-only source tree has caused some problems here.