Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 8 Mar 2001 21:23:01 -0800
From:      Marcel Moolenaar <marcel@p1000180.nsr.hp.com>
To:        Warner Losh <imp@village.org>
Cc:        Kris Kennaway <kris@obsecurity.org>, "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net>, "Matthew D. Fuller" <fullermd@futuresouth.com>, arch@FreeBSD.ORG
Subject:   Re: Breaking up make.conf
Message-ID:  <20010308212301.A879@dhcp08.muffin.org>
In-Reply-To: <200103090430.f294Ucs04824@billy-club.village.org>; from imp@village.org on Thu, Mar 08, 2001 at 09:30:38PM -0700
References:  <20010308201422.A94052@mollari.cthul.hu> <200103090241.SAA27525@gndrsh.dnsmgr.net> <200103090349.f293nGs04577@billy-club.village.org> <20010308201422.A94052@mollari.cthul.hu> <200103090430.f294Ucs04824@billy-club.village.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Mar 08, 2001 at 09:30:38PM -0700, Warner Losh wrote:
> I really do want to see a generic mechanism in place.  I don't want to
> see another set of hacks just for FreeBSD.  If we have a generic
> mechanism in place, we can document it and other projects can use or
> not use it as they see fit.

A generic solution for the make.conf problem can be the introduction
of a variable I suddenly call MODE. This MODE variable, when set on
the commandline triggers the inclusion of bsd.mode.${MODE}. Where to
read this file from, can be a combination of system-wide, hardcoded
defaults and the use of a variable I suddenly call MODEPATH.

This mode file contains defaults for certain variables and thus
controls how the software is built, whether this is world or something
else is not important.

For the ports collection, we can have MODE default to ports. Release
builds can have MODE default to release. Kernel and module builds can
have MODE default to kernel.

To allow a flexible mechanism of overriding modes, so that this
scheme can be used in the widest possible scenarios, all mode files
found by MODEPATH are read. This works nicely if mode files use the
conditional assignment by convention. For example, If I have
	MODEPATH=~/modes /etc/modes
and build my software like
	make MODE=foo
then ~/modes/bsd.mode.foo will be included before /etc/modes/bsd.mode.foo
(if it exists) and thus allows per user tweaking of system defaults.

In the various Makefile.inc files, we can append to MODEPATH so that
we can have /usr/src (assuming that's the root of the FreeBSD tree)
part of the MODEPATH. This allows per source tree tweaking of the system
default (assuming that system drectories are appended to MODEPATH last).

This scheme has the nice property of having a simple way to further
enhance parallelism by making MODE part of the name of the object
directory. Of course it should be possible to also set MACHINE_ARCH in
the mode files as well, so that we can define a cross-build as:
	make MODE=alpha buildworld
instead of
	make MACHINE_ARCH=alpha buildworld.

I suggest we do not traverse source trees down to the root, to
search for a make.conf or something equivalent. It's too unstable
from an algorithmic point of view and may cause significant build
overhead.

Just my $0.02...

-- 
Marcel Moolenaar
  mail: marcel@cup.hp.com / marcel@FreeBSD.org
  tel:  (408) 447-4222

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010308212301.A879>