On Fri, 1 Jun 2001, Todd Vierling wrote:

# Date: Fri, 1 Jun 2001 14:27:51 -0400 (Eastern Daylight Time)
# From: Todd Vierling <tv@wasabisystems.com>
# Reply-To: tech-toolchain@netbsd.org
# To: current-users@netbsd.org
# Cc: tech-toolchain@netbsd.org
# Subject: WARNING: -current toplevel build process changing!
#
# In just a little bit I'll be committing changes to the toplevel "src"
# build process.  The new build system will create a directory to hold
# build-time tools, such as gcc, binutils, bmake, and so forth.  These are
# used BOTH for cross-compiling and native compiling, so as to ensure that
# proper versions of the tools are used for the source tree being compiled.
# The tools will only be recompiled when needed.

I have some questions.

1.  How long has "tech-toolchain" been in existence as a mailing channel?

2.  Where, outside of tech-toolchain, has this been discussed?  I'd think
	that a change of this magnitude would have been better presented
	to current-users from the outset, seeing as it affects everyone.

3.  What if you want to have immediate available support to compile across
    more than two platforms, switchable via an envar and/or mk.conf?

4.  Why not mk.conf?

5.  What is there about bmake that "make" doesn't cover?

6.  Has there been a discussion and/or a guinea-pig marathon regarding this,
    or is it just going to get shoehorned in?

I know that the majority of geekdom sucks at communication on projects.
I know this because I work with them every day, and I'm not an exception.
The problem is that within the scope of NetBSD, this can't be the standard
Modus Operandi.  In my opinion, anyway.  It's a technical issue -- it should
have been discussed first.

# To set where these tools are installed, set TOOLDIR in the environment (NOT
# /etc/mk.conf).  TOOLDIR will default to "src/tools/local" if not explicitly
# set.  The layout is similar to /usr/local (with "bin", "lib", etc.
# subdirectories).

Once these tools are built, what happens to the ones who live in the main
tree?  Do we then have to REbuild the tools to be installed in ${DESTDIR:-/}
even if they're for the same architecture?  This strikes me as a loss.

# The existing toplevel targets (make build, make obj, make clean[dir], etc.)
# will still work; there will just be a Makefile shim that bootstraps bmake
# where needed.
#
# On most platforms, the build tools will consist of only bmake at this time,
# so any automated builds should continue to work fine if your "src" is
# writable.  This will expand to a full set of build tools, suitable for
# cross-compiling even on non-NetBSD hosts, in the near future.  In
# particular, i386 will also switch to the new gcc and binutils this weekend.

What if src is read-only and you're making use of objdirs to generate
your build?  Or are we using the case where

    /usr/obj/dir/prog -> /usr/src/dir/prog/obj.$ARCH

...and not the other way around?  (side comment:  Should this be fixed?!?)

# If you have any problems with the new toplevel build process, please let me
# know (or post to tech-toolchain).  All this will also be documented in a bit
# more detail in "README.tools" in the top level.

				--*greywolf;
--
NetBSD, Net Improvement.