Date: Sat, 29 Aug 1998 00:01:36 -0600 From: Warner Losh <imp@village.org> To: committers@freebsd.org Subject: Re: make.conf Message-ID: <199808290601.AAA11483@harmony.village.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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199808290601.AAA11483>