This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
My Build Scheme (was Re: Installation proposal)
- From: Nathanael Nerode <neroden at doctormoo dot dyndns dot org>
- To: mark at codesourcery dot com, gcc at gcc dot gnu dot org
- Date: Wed, 3 Jul 2002 18:39:46 -0400
- Subject: My Build Scheme (was Re: Installation proposal)
The installation proposal you make in
http://gcc.gnu.org/ml/gcc/2002-02/msg01663.html
is ok, I guess. Unfortunately I think it's highly likely to introduce
unexpected bugs. It will also make the later implementation of my
preferred scheme *harder*. I prefer the "horrendously complicated"
scheme of changing all the Makefiles: Per Bothner's
build system improvement scheme from back in February.
Which I was planning to implement as soon as I finished
autoconfiscation, hopefully started in time for 3.3.
One other issue:
The *name* of the subdirectory. "install" is questionable, although
it's better than the previous suggestion of "build". I advise
"recently_built"
"built"
But if we want to do a REALLY good, elegant, proper job,
we need something with the *host* for the appropriate tool encoded in
it. The *target* for the tool is traditionally encoded into the tool
file name. Putting it in a directory corresponding to the host it needs to
run on would avoid much confusion. :-)
My favorite strategy for total build improvement is actually this:
------------------------------------------------------------------
* Always use build_subdir, not just when build!=host.
* Introduce host_subdir (=host_alias) for host files. This solves the
"building in place" problem entirely, without any ened for phony
makefiles or other such cruft.
* Have an "install" or "recently_built" subdir in each of build_subdir,
host_subdir, and target_subdir, and build (installable) files which run
on the appropriate machine into the appropriate "recently_built" dir.
Note that if build=host, build_subdir=host_subdir, and a bunch of
simplifications happen all by themselves.
Similarly if host=target. Similarly if build=target; crossbacks can
start to behave properly.
Special case configure code for "if build=host, look for recently built,
otherwise don't", becomes unnecessary; we always look for recently built
*in the appropriate directory*, and if build!=host it just won't be
there.
I believe there's room for improved GCC bootstrapping in here too,
though I haven't quite worked it out (I'm thinking, set build_subdir to
"stage1", host_subdir to "stage2", and target_subdir to "stage3"), and I
think it allows some of the benefits of bootstraps to be moved smoothly
to cross-compiles.
And we get all the advantages of all previous schemes, except that
there's quite a lot of changeover work.
This is what I think would be the correct thing to do.
Just throwing it out there....
--Nathanael