cross (or native) compilers meant to be run on a host different from
the build environment can now be built by setting the HOST make
variable on the command line or in config.mak. this requires (for
building the target libraries) a cross toolchain for the same TARGET,
but that can run on the build system, to be present already in the
PATH. future enhancements may make it possible to automatically build
and use the needed toolchain.
leaving HOST blank produces a toolchain that runs on the build system
(host==build in gcc jargon), the same as before with NATIVE unset.
the NATIVE make variable is now obsolete but still supported; it
simply causes HOST to be set equal to TARGET (thus producing a native
toolchain for the target).
builds are now placed in build/$(HOST)/$(TARGET) when HOST is set, and
build/local/$(TARGET) when it's not, so that builds for the same
target but different host do not clobber each other.
default OUTPUT directory when HOST is set is now output-$(HOST). as
usual, multiple targets can safely go in the same output directory,
but toolchains for different hosts should not.
based on patch by Michael Forney, but using a plain variable without
without the need for $(call ...). I used a different name for the
variable so that it won't break if anyone has an HTTP_GET variable for
use with the original patch in their config.mak.
this is useful for preparing to automate multiple builds using shared
source trees. otherwise concurrent builds could clash attempting to
extract the same source trees.
this feature is still experimental and requires manually setting a
LINUX_ARCH make variable matching the target. automatic mapping will
be added later. if LINUX_ARCH is not set, header installation is
skipped.
this allows sharing a sources directory between multiple checkouts or
independent toolchain-using projects.
also, during distclean, only remove the in-tree sources directory, not
a custom/external one. this is a safety measure in case the SOURCES
variable is set to something stupid like blank, root directory, or
some large shared directory.
this makes it easy to rebuild components simply by removing the source
or build directory with rm -rf; no separate action on the steps files
is needed.
some dependencies are also changed to order-only so that
update/rebuild of one component does not force unnecessary rebuild of
another.
new convenience pseudo-targets are also added.
old versions of gcc, such as 4.2.1 which I'm in the process of adding
support for, have broken configure scripts that do not accept
variables on the command line and instead interpret them as the target
name. the easiest solution is just passing these in the environment.
previously the stage0 gcc was installed to the output location during
the build, then replaced later by the final gcc. this violates the
principles of make and simply wastes time. the stage0 gcc is usable
in-place without installing it, so we can simply do that instead.
Patrick Oppenlander
Rich Felker
Michael Forney
Szabolcs Nagy