From owner-freebsd-hackers  Sun Nov 12 18:15:37 1995
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id SAA26703
          for hackers-outgoing; Sun, 12 Nov 1995 18:15:37 -0800
Received: from linus.demon.co.uk (linus.demon.co.uk [158.152.10.220])
          by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA26669
          for <hackers@freebsd.org>; Sun, 12 Nov 1995 18:15:10 -0800
Received: (from mark@localhost) by linus.demon.co.uk (8.7.1/8.7.1) id CAA02290; Mon, 13 Nov 1995 02:16:28 GMT
Date: Mon, 13 Nov 1995 02:16:28 GMT
From: Mark Valentine <mark@linus.demon.co.uk>
Message-Id: <199511130216.CAA02290@linus.demon.co.uk>
In-Reply-To: Richard Wackerbarth's message of Nov 12,  6:39pm
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: rkw@dataplex.net (Richard Wackerbarth)
Subject: Re: LKM's still wont compile in -current
Cc: hackers@freebsd.org
Sender: owner-hackers@freebsd.org
Precedence: bulk

> From: rkw@dataplex.net (Richard Wackerbarth)
> Date: Sun 12 Nov, 1995
> Subject: Re: LKM's still wont compile in -current

> I think that you are skirting the fact that there are three separate
> environments.
> 1) The host environment.
> 2) The bootstrap environment.
> 3) The target environment.
> 
> The host environment just "is". I'm not allowed to change it.

Amen!

> The bootstrap environment has the customized tools to build the target.
> In many cases, these tools are the generic tools available from the host
> environment. In those cases, they are specified by a configuration link of
> some sort.
> However, I can override any of them by providing the source code that will
> run in the host environment. For example, I might have a revised version of
> a compiler or make that has a feature that I am using in building the
> target.

OK, I've been treating the bootstrap environment as simply a set of tools
which exist in the host environment (e.g. ``CC=/usr/bin/cc'' for the common
case, ``CC=/usr/local/bin/gcc -V 2.7.0'' or ``CC=gcc -b sparc'' for other
interesting cases).

However, even in the common case, you still want to treat the bootstrap
tools specially (e.g. to end up with a target compiler compiled by itself,
which make world already does in its own brutal way; the standard FSF build
method does this without clobbering the host environment).

So, I agree that we need to firm out a build model which embodies this
distinction (more concrete examples will help this process, since talking
in abstractions won't make the problems clear to a wider audience who
don't have the brain cycles to spare in following all of this).

> And the target is the target. When building the target, we don't step on
> anything in either the host or bootstrap environments. However, we do
> associate with each target the bootstrap environment that knows how to
> build the target.

As in src/make.conf, perhaps...

> Right now, make world tries to pile all three of these environments on top
> of each other. I "sortta" works only because in most cases, the host,
> bootstrap, and target environments are the same.

The "sortta" is probably generous, since building an -experimental system on
a -stable or -current host must be awfully common...

I think that if we fix this, we'll make it easier for people without lots
of kit to play with to join in the development effort (all you should need
is enough disk space on your "working" system for a target build and a
separate boot partition containing a minimal target installation for testing;
or a spare 386 with 4MB^H^H^H5MB RAM and a small disk...).

		Mark.