Subject: Re: FYI: more options defop'ted: DDB, network protocols, COMPAT_*
To: Greg A. Woods <email@example.com>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
Date: 07/05/1998 14:53:28
On Sun, 5 Jul 1998 17:30:46 -0400 (EDT), firstname.lastname@example.org
(Greg A. Woods) writes:
[[ iterated changing of options, config, make]]
Greg, I dont understand. you were the one who suggested it was
unecessary to rerun ``make depend'' after each config run.
>I had been thinking that in the interest of only describing the safest
>build process it might be better that the only options to be mentioned
>as not requiring a fresh "make depend" are those which only affect
>generated (i.e. opt_*.h) files which bill already be listed in .depend
>as dependencies for existing *.o's.
Yes, I think you were, but that's wrong, for the reasons I gave.
>On the other hand if the count is
>really that lop-sided, perhaps it would be better to mention something
>akin to "(must re-run ``make depend'' after changing)" for those that
>are not ``defopt'ed''.
No: if you change an option which adds more .o files to the Makefile,
and do that more than once, you need to rerun ``make depend''. Even
if the option is defopt'ed. For precisely the reasons you agree to:).
>I consider it a fairly serious bug whenever options(4) is not updated
>whenever a kernel option is added, removed, or changed, regardless of
>whether it's one that only affects auto-generated files or not (and
>similarly for any other documentation skew problems introduced by
>changing only the code).
It's a documentation bug. Serious? As documentation bugs go, maybe.
But now you're talking about adding options and defopt's to the source
code. Which has exactly the same effect as turning on a previously
not-turned-on option: your .depend file doesn't know about the
dependencies on the new opt_*.h files. I dont see how that's
I get the feeling we're talking totally past each other...