Date: Tue, 1 Sep 1998 09:29:52 +0200 From: Eivind Eklund <eivind@yes.no> To: =?iso-8859-1?Q?Dag-Erling_Coidan_Sm=F8rgrav?= <dag-erli@ifi.uio.no> Cc: committers@FreeBSD.ORG Subject: Re: make.conf Message-ID: <19980901092952.54287@follo.net> In-Reply-To: =?iso-8859-1?Q?=3Cxzpr9xwpx75=2Efsf=40grjottunagard=2Eifi=2Euio=2Eno=3E?= =?iso-8859-1?Q?=3B_from_Dag-Erling_Coidan_Sm=F8rgrav__on_Tue=2C_Sep_01?= =?iso-8859-1?Q?=2C_1998_at_01=3A07=3A26AM_%2B0200?= References: <1018.904492666@time.cdrom.com> <xzpr9xwpx75.fsf@grjottunagard.ifi.uio.no>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Sep 01, 1998 at 01:07:26AM +0200, Dag-Erling Coidan Smørgrav wrote: > "Jordan K. Hubbard" <jkh@time.cdrom.com> writes: > > If /etc/make.conf is split at all then it should be split into: > > > > /usr/src/conf.mk - configuration frobs exclusively for /usr/src > > > > /usr/ports/conf.mk - configuration frobs exclusively for /usr/ports. > > > > /usr/share/mk/conf.mk - stuff truly global to any invocation of Bmake > > e.g. variables you want both src and ports > > (and so on) to get as a base set before > > potentially laying their own on top. > > No. If I don't have a full source tree installed, but check out part > of the tree (say, 'cvs co ls') from my local copy of the repository, I > won't be able to compile it. If you have to put them i separate > directories, I'd suggest /etc/make/ ostl. ... in which case I won't be able to compile my two checked out source trees with different options in parallel. Doh. This entire issue need somebody to sit down and see what can be done to create a full solution. My preference is for this to work as 'build configuration system' instead of a straight way of setting options. This means that config.file.name will have to be parsed by soem sort of script, and split into a set of option files, just like config(8) does it today. Compiles that need the options must include the files; if the targets are out of date WRT the options, these must be recompiled. This implies the need for something like 'makedepend' for parsing all of this, unless we want to add explict dependencies for all the configuration files. This sucks, but IMO it sucks less than the alternatives. IMO, any scheme that is implemented today should reflect the above model as at least a possibility. Of course, if somebody decide to sit down and do this (and rkw@dataplex.net has offered to do so), then there'd be extra glory to be gained by integrating it so the kernel can be compiled by much of the same mechanism, avoiding having two similar tools. Eivind.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980901092952.54287>