From owner-cvs-all Fri Aug 28 23:27:23 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA19879 for cvs-all-outgoing; Fri, 28 Aug 1998 23:27:23 -0700 (PDT) (envelope-from owner-cvs-all) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA19843 for ; Fri, 28 Aug 1998 23:27:09 -0700 (PDT) (envelope-from dillon@backplane.com) Received: (dillon@localhost) by apollo.backplane.com (8.8.8/8.6.5) id XAA22084; Fri, 28 Aug 1998 23:24:59 -0700 (PDT) Date: Fri, 28 Aug 1998 23:24:59 -0700 (PDT) From: Matthew Dillon Message-Id: <199808290624.XAA22084@apollo.backplane.com> To: Warner Losh Cc: committers@FreeBSD.ORG Subject: Re: make.conf 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}? I think some variables are seriously global... not just for /usr/src and /usr/ports, but potentially for everything. For example, the location of certain binaries, or whether you want man pages to be compressed or not, whether your system is tightly integrated with kerberos, whether you want compiled programs to be optimized in a specific way for the platform (aka -m486, etc...), whether you are USA_RESIDENT, etc... Other variables aren't quite as global, but cover a large enough code base that the convenience factor is just too big to ignore. For example, some of the ports-specific globals: NOPORTSDOCS, FORCE_PKG_REGISTER. Other variables cover a program class but don't really apply to all programs. e.g. NNTP_ONLY, which can conceivably effect a class of news-related clients. Still worth the convenience factor. Maybe. Others can't be considered global by any stretch of the imagination: TOP_TABLE_SIZE, SUP, etc... I think the thing with make.conf is that, basically, it's just too convenient a place to put make configuration variables. Usually you don't have too many, and you really don't want to spread them around half a dozen different files. Hence, make.conf. The key to making it work is to make the variables verbose enough as to greatly diminish the chance of a conflict occuring. :Warner : -Matt Matthew Dillon Engineering, HiWay Technologies, Inc. & BEST Internet Communications (Please include original email in any response)