From owner-freebsd-current@FreeBSD.ORG Fri Mar 17 18:09:46 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 290DB16A420; Fri, 17 Mar 2006 18:09:46 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 94DEC43D72; Fri, 17 Mar 2006 18:09:45 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id k2HI759g046263; Fri, 17 Mar 2006 11:07:05 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Fri, 17 Mar 2006 11:07:05 -0700 (MST) Message-Id: <20060317.110705.41678962.imp@bsdimp.com> To: ru@FreeBSD.org From: Warner Losh In-Reply-To: <20060317165638.GA1172@ip.net.ua> References: <20060317165638.GA1172@ip.net.ua> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Fri, 17 Mar 2006 11:07:05 -0700 (MST) Cc: current@FreeBSD.org Subject: Re: [HEADS UP] New world/kernel build options are imminent X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2006 18:09:46 -0000 > The new model borrows internal part of implementation from NetBSD > and user API part from FreeBSD ports. There were several goals: > > - The new naming scheme should be uniform, easy to remember. > - There should be a full list of options, with clear defaults > and dependencies, in one central place. > - API should be stable and detective of user/developer errors. > - make(1) environment should be clean outside world/kernel. - Possible to change the default in the base system in a stable way. The change from NO_HESIOD TO YES_HESIOD wasn't a big deal to most of our users, but the desire to have someone say "I want to build HESIOD, reguardless of the default" wasn't possible in the old system. The other item that's desirable is to have per-tree defaults for these w/o needing to redefine the system make file. That isn't dependent on these changes, but is a highly desirable thing. I've some patches that implement that in a brute-force kind of way. Warner