[ On Sun, July 5, 1998 at 14:53:28 (-0700), Jonathan Stone wrote: ]
> Subject: Re: FYI:  more options defop'ted: DDB, network protocols, COMPAT_*
>
> Greg, I dont understand. you were the one who suggested it was
> unecessary to rerun ``make depend'' after each config run.

I only asked if it were necessary to run "make depend" after a config
run that changed only automatically generated opt_*.h files.

> >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.

Ok, then how is that wrong?  There must be some hidden magic I'm missing
if I'm wrong.  If config only changes the content of one or more opt_*.h
files, and otherwise essentially leaves the contents of the Makefile
alone (i.e.  specifically does not add any more *.o's, i.e. require any
new source files to be included in the build), then the existing .depend
file should contain *all* of the dependencies.  No?  The same thing
should apply if the new config run only changes the IDENT value in
Makefile too.

(In fact I'd like to consider it a design bug if the above were not
true.  Such a mistake should only happen if someone has #ifdef'ed a
#include somewhere, and that should not be done for the kernel.)

> 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:).

Ah, now I think I see the problem.  I've been trying to use the term
"defopt'ed" to mean "a new 'defopt' entry has been added to the
conf/files file which has the form of 'defopt file OPTION'" (i.e. the
new options that cause an opt_*.h file to be generated) since that's the
sense I've had of everyone else's use of it w.r.t. this new addition of
opt_*.h files to eliminate compile flags from the command line.

Speaking of defining terms of reference, why is it that the contents of
the 4.4-Lite2's /usr/src/share/doc/smm/02.config/ are not found anywhere
in NetBSD tree?  Is it only because nobody's yet found the time to merge
the 4.4-Lite2 documentation?  Or did someone remove it from the
share/doc directory and then forget to add it to /usr/src/usr.sbin/config?
Of course that document will need updating to reflect recent changes in
config(8), but without anything to update....   ;-)

(there's lots of other documentation on the reference CD that doesn't
seem to be in NetBSD too)

> It's a documentation bug. Serious? As documentation bugs go, maybe.

Documentation that tells one how to use the source code, particularly
that which describes how to configure and build the code, is as critical
as the code itself, at least for the non-default case (i.e. when someone
wants to build a non-standard kernel -- a kernel which uses different
options than the standard kernel -- then knowing what the options are
and what they do is extremely critical).  ;-)

> But now you're talking about adding options and defopt's to the source
> code.

No, no -- I'm only talking about changing options in a config(8) input
file and then using the same build directory.  That's what I expect to
be the common case for non-kernel developers.  I.e. tuning and such.

Kernel developers who are adding/changing the implementation of options
will have to be much smarter.   ;-)

-- 
							Greg A. Woods

+1 416 443-1734      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>