Subject: Re: More config changes, for ro source tree and disjoint build trees
To: None <tech-kern@NetBSD.ORG>
From: der Mouse <mouse@Holo.Rodents.Montreal.QC.CA>
List: tech-kern
Date: 08/13/1996 20:53:18
>> 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 ....

I've often wished for every preprocessor definition, typedef, etc, to
be tagged so as to identify what file it came from (or better, what the
whole include file chain was when it was found); then, optionally, the
compiler could list any files that were #included but that the program
would have come out exactly the same without (sort of a -Wunused for
include files).  If this sort of thing were done, it would be
relatively easy to extend it to make the compiler produce a list of all
the .o files that might, potentially, change if a given define were to
appear, disappear, or change.  (Of course, this list would include
scads of options that _aren't_ defined; this list might even be useful
under some circumstances.)

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu
		    01 EE 31 F6 BB 0C 34 36  00 F3 7C 5A C1 A0 67 1D