From owner-freebsd-arch Thu Mar 8 19:58: 3 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id D248937B718; Thu, 8 Mar 2001 19:57:58 -0800 (PST) (envelope-from imp@billy-club.village.org) Received: from billy-club.village.org (billy-club.village.org [10.0.0.3]) by rover.village.org (8.11.2/8.11.0) with ESMTP id f293vtX44788; Thu, 8 Mar 2001 20:57:55 -0700 (MST) (envelope-from imp@billy-club.village.org) Received: from billy-club.village.org (localhost [127.0.0.1]) by billy-club.village.org (8.11.2/8.8.3) with ESMTP id f293sss04615; Thu, 8 Mar 2001 20:54:54 -0700 (MST) Message-Id: <200103090354.f293sss04615@billy-club.village.org> To: John Baldwin Subject: Re: Breaking up make.conf Cc: "Rodney W. Grimes" , arch@FreeBSD.ORG, kris@obsecurity.org (Kris Kennaway) In-reply-to: Your message of "Thu, 08 Mar 2001 19:37:09 PST." References: Date: Thu, 08 Mar 2001 20:54:54 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message John Baldwin writes: : What if I want to use /etc/release.conf for clean release builds and : /etc/currentworld.conf for current, etc.? If it's a tweakable variable name in : /etc/make.conf (or overridable on the command line to make buildworld of : course) then the ../Makefile.inc hack will allow me to stick this file anywhere : with any name, rather than forcing it to be in the path of the source tree. That's why I like the idea of having a etc/make.conf in the tree and have it use that file. This file wouldn't be checked into CVS, but would be the user's responsibility to add to the tree in some fashion. Given the patches I posted, they have the nice property that if the user fails to do this, /etc/make.conf is picked up instead. That would allow you to easily manage these things. It would also allow you to have multiple -current and stable trees checked out under one root and use the same config file or different config files for them without having to remember to set special variables. As a side effect, we can reduce the name space polution problem that we have with bsd.own.mk and bsd.cpu.mk being included from /usr/share/mk/sys.mk. They have bugged me (and others) for a long time. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message