> People have suggested in the past to put every -DFOO flag in a
> foo.h file that contains '#define FOO 1' and let the compiler to its thing.
> This of course is a maintainance nightmare and will slow down compilation
> a lot.

Which is better: speed, or correctness?  To my mind, speed is
worthless without correctness, and the current mechanism, though
faster, is incorrect.


I would actually suggest one "options.h", rather than lots of little
foo.h files, which would then be included in every .c file in the
kernel.

in what way is it a "maintainence nightmare"?  I don't think that it
causes any serious problems, other than a few extra recompilations.


Looking at it another way:

how often to you change your kernel config file?  i.e. how often would
it hurt to recompile the world, if you have dependencies made?

similarly: how often do you change <sys/types.h> or <sys/param.h>?  I
know that when i do that, and i actually care whether the entire world
is recompiled, i remove the .depend file and remove and make the .o's
i want, individually.

It seems to me that the default: normal build, with dependencies,
should produce a correct kernel, even if that means recompiling a few
extra .o's to get it.


What is the cost of doing it each way?  Is it better to keep new
end-users from running into this problem repeatedly, or to give
developers very slightly quicker (on average) compilations?

I'd say that the former is more important.  It also make sure that
seasoned developers don't get accidentally burned by the same problem.



chris