Since we're on the topic, I'd like to make a few suggestions about the
build process (from my earlier mach days).

First, can we flush "make depend".  The alternative is to have gcc
invoked with -MD.  This causes a <foo>.d file containing the
dependencies generated as the <foo>.c is compiled.  Then as "make"
finishes up, it runs a program, "md", to integrate this <foo>.d file
into .depend or an explicit dependency file.  The Makefile includes
the dependency file and thereby is always up to date.

Now I confess that in the current scheme, I just don't bother to do
"make depend" and if I am really worried I just delete the build area
and rebuild.  As computers get faster still, this stupid alternative
becomes more feasible.  But I'd like people to consider the fool proof
-MD approach.

Another disturbing problem of the kernel Makefile is the large number
of "-D" that appear.  What is disturbing is that any file compiled can
depend on such a define and if you change the defined value, you don't
have any automatic way to tell what files to recompile.  In mach, -D
defines were essentially not used.  Config would put each define into
its own .h file.  This means that all source files must explicitly
include the .h's which set defines that they care about.  But it also
means that if the define is changed, the header file is changed, and
the dependency process takes over to regenerate the .o files that need
to be changed.

Lastly, if we are seriously working on a process to allow config to
specify where the source and obj areas are.  The next logical, though
harder step, is to use the "path" mechanism of "make" to have
collections of sources shadow each other, so that the only sources you
need to have in your personal kernel tree, are the sources you change,
The other sources are pulled from the official source area and the
obj's get installed wherever you desire.