This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]