> >> This [.h files instead of -D options] sounds neat, but how could
> >> this work?  config would need to know about every define ever used
> >> anywhere, [...]
> > The config grammar could be changed to understand an "option" keyword
> > which tells it to emit an "option_<option>.h" file.  These "option"
> > directives could be placed in [...]
> 
> This is fine for "major" options, like COMPAT_10.  It rapidly becomes a
> maintenance nightmare when it comes to things like RASTERCONS_SMALLFONT
> or REAL_CLISTS or MAPPED_MBUFS or ALLOCPRINT or TRIPLE or
> AUDIO_C_HANDLER or COUNT_SW_LEFTOVERS or FPU_SHL1_BY_ADD or
> PMAP_PTESYNC or EXTREME_DEBUG or EXTREME_EXTREME_DEBUG (I kid you not)
> or VMFAULT_TRACE or ....

Or, you can go the other way, and say: put all of them in one .h file.

Sure, if you change your config file at all, everything gets
recompiled.  However,

	(1) that shouldn't happen very often,

	(2) that's what you have to do now to be 'completely safe'
	    anyway, and

	(3) it's a lot easier to remember to include one header in
	    every source file than it is to include only the 'right'
	    ones (where the set of 'right ones' can change as you
	    add and delete #ifdefs in the file).

Using one file would make life a lot easier on config, would make the
plethora of option files more manageable (there could be only one!
8-), and would prevent stupid errors.

Why optimize for the "reconfig the kernel" case, when that shouldn't
happen very often?  (If it _does_ happen very often, it's probably
being done by someone experienced enough to know whether or not they
have to 'make depend'...)


cgd