Subject: Re: FYI: more options defop'ted: DDB, network protocols, COMPAT_*
To: Greg A. Woods <>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
List: current-users
Date: 07/05/1998 14:53:28
On Sun, 5 Jul 1998 17:30:46 -0400 (EDT),
(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...