From owner-freebsd-current Mon Sep 25 12:07:56 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA19520 for current-outgoing; Mon, 25 Sep 1995 12:07:56 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA19515 for ; Mon, 25 Sep 1995 12:07:54 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA05622; Mon, 25 Sep 1995 12:03:31 -0700 From: Terry Lambert Message-Id: <199509251903.MAA05622@phaeton.artisoft.com> Subject: Re: kernel versions and config's rm -rf To: bde@zeta.org.au (Bruce Evans) Date: Mon, 25 Sep 1995 12:03:30 -0700 (MST) Cc: fenner@parc.xerox.com, terry@lambert.org, current@FreeBSD.ORG In-Reply-To: <199509250642.QAA00867@godzilla.zeta.org.au> from "Bruce Evans" at Sep 25, 95 04:42:25 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1466 Sender: owner-current@FreeBSD.ORG Precedence: bulk > >Yes, please. This keeps the breakage in the dependency graph (which > >will hopefully some day be fixed) sperate from the config, which > >removes far more than it really has too, but does so because the > >dependecy graph breakage is hidden from it. > > Arrgh. The dependencies are all contained in .depend and Makefile. > `make clean' doesn't remove the former so you have to do it. `config' > touches the latter (even when it shouldn't) so you don't have to remove > it. The following steps are sufficient: > > cd /sys/compile/FOOKERNEL > make clean ^^^^^^^^^^ > rm -f .depend ^^^^^^^^^^^^^ > cd /sys/i386/conf > # in case config is still broken: > export NO_CONFIG_CLOBBER='config clobbering is braindamaged' > config ... "^" marks the steps which I believe are workarounds to gaps in the dependency processing. > >I'm wondering at the existance of compile time optioning in the first > >place. Really, it exists because the device driver and other subsystems > >don't have explicit registration mechanisms that don't depend on static > >data. > > No, it exists because static configuration is easier to implement and > has less bloat. Why wasn't it use for IP forwarding and TCP/IP RFC 1323 and RFC 1644 compliance configuration, then? Pick one pardigm and apply it globally, please. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.