From owner-freebsd-current  Wed Nov 29 12:23:46 1995
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id MAA16801
          for current-outgoing; Wed, 29 Nov 1995 12:23:46 -0800
Received: from rocky.sri.MT.net (rocky.sri.MT.net [204.182.243.10])
          by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA16793
          for <current@freebsd.org>; Wed, 29 Nov 1995 12:23:40 -0800
Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id NAA21025; Wed, 29 Nov 1995 13:25:49 -0700
Date: Wed, 29 Nov 1995 13:25:49 -0700
From: Nate Williams <nate@rocky.sri.MT.net>
Message-Id: <199511292025.NAA21025@rocky.sri.MT.net>
To: "Garrett A. Wollman" <wollman@lcs.mit.edu>
Cc: current@freebsd.org
Subject: Re: cvs commit: src/usr.sbin/config Makefile main.c 
In-Reply-To: <9511291846.AA06551@halloran-eldar.lcs.mit.edu>
References: <199511291708.KAA20314@rocky.sri.MT.net>
	<199511291834.KAA08699@freefall.freebsd.org>
	<9511291846.AA06551@halloran-eldar.lcs.mit.edu>
Sender: owner-current@freebsd.org
Precedence: bulk

Garrett A. Wollman writes:
> [PLEASE watch your Cc lines!]
> 
> <<On Wed, 29 Nov 1995 10:34:40 -0800, "Justin T. Gibbs" <gibbs@freefall.freebsd.org> said:
> 
> > Why not make option lines add an entry to a common header file.  Only
> > modules that export an option need to include the "option" header.
> > We could have a separate keyword "define" that gives the current behavior
> > so you can still do it the old quick way for debugging.  I think that
> > a make depend would have much more value if this was done.
> 
> That just brings you back to the same old problem of everything
> getting recompiled when you change the FOOBAR_GRONKULATOR option from
> 0 to 1 even though only two files depend on the setting of that
> particular option.
> 
> Now, if you wanted to suggest that every such option have a /separate/
> header file generated for it, then I might be open to it.

If we do this, we might as well change the way options are done.  By
using separate files, we are effectively making the configuration done
in the same manne as devices are done in config, so adding a new
'option' would require modifying config.

While I normally don't like the statements of "config should die, kill
config" I think it needs to be destroyed before we can do dependencies
on options better.



Nate