From owner-cvs-all Fri Aug 28 23:03:33 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA17186 for cvs-all-outgoing; Fri, 28 Aug 1998 23:03:33 -0700 (PDT) (envelope-from owner-cvs-all) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id XAA17179 for ; Fri, 28 Aug 1998 23:03:23 -0700 (PDT) (envelope-from imp@village.org) Received: from harmony [10.0.0.6] by rover.village.org with esmtp (Exim 1.71 #1) id 0zCe5V-0004Hx-00; Sat, 29 Aug 1998 00:02:13 -0600 Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.1/8.8.3) with ESMTP id AAA11483 for ; Sat, 29 Aug 1998 00:01:37 -0600 (MDT) Message-Id: <199808290601.AAA11483@harmony.village.org> Subject: Re: make.conf To: committers@freebsd.org In-reply-to: Your message of "Fri, 28 Aug 1998 22:47:21 PDT." <199808290547.WAA21954@apollo.backplane.com> References: <199808290547.WAA21954@apollo.backplane.com> Date: Sat, 29 Aug 1998 00:01:36 -0600 From: Warner Losh Sender: owner-cvs-all@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199808290547.WAA21954@apollo.backplane.com> Matthew Dillon writes: : In my comments below, when I say 'global' I mean that the option could : be meaningful to virtually any utility, port, etc... Does that mean all the programs that might be built on the system, or just all the programs that traditionally have lived in /usr/{src,ports}? The biggest problem with having so many global variables is that they can step on other people's uses of those variables. FTP_PASSIVE_MODE is an ENVIRONMENT variable that has no business being defined in any global makefile, for example, even if all the users on the system need this to run FTP. That is the problem with /etc/make.conf being included in sys.mk. I agree that it should be included by, or caused to be included by, all of /usr/{src,ports}, but I agree with Bruce and others who think that it unnecessarily pollutes the namespace of MAKE macros. In the pseudo proposal that I had in my last message, /usr/src/mk.conf would include /etc/make.conf rather than having /usr/share/mk/sys.mk do it. /usr/src/mk.conf would be included as ../mk.conf from somwhere in the build tree (which would itself include ../mk.conf, etc up to the top level). make(1) would have to be modified to automatically include ../mk.conf, in this scheme. Something about it bugs me, however, and I can't put my finger on it. Again, read for /usr/src where-ever the tree happens to be, as /usr/src wouldn't be hard coded. An alternative to changing make would be to add .include <../mk.conf> to all Makefiles in the source tree, as well as creating mk.conf files in all non-leaf nodes of the tree, which were one liners, except at the top level. Hmmm, the second part of this would need to be done reguardless. I also agree that some way to customize the /etc/make.conf file needs to be upgrade friendly. Warner