Re: What happend to bootstrap-lean? (was: What happened to bubblestrap?)

[Daniel Jacobowitz <drow at false dot org>]

On Sun, Dec 18, 2005 at 01:25:36PM -0500, Richard Kenner wrote:
>     The answer to both of these questions is the same.  Toplevel bootstrap
>     deliberately - as a design decision, and in my opinion, a very good
>     one - puts every stage in its own directory.  
> 
> Of course: we've always had each stage living in a different directory.
> You're not going to get any disagreement there.  My question was why you have
> to go *up*.  Unless you're rebuilding a library outside the gcc/ directory,
> all the stages can be in subdirectories of that directory.

No, that's not at all what we do today.  We build everything in gcc/
and shuffle the files off to other directories depending on the current
stage.  In the revised model, the stages are completely independent;
the directories have nothing in common.

>     For other directories, however, we don't want to have to work it out.
>     It lets the bootstrap mechanism be more modularly independent of the
>     components being bootstrapped.
> 
> Here you've lost me completely.  When you say "bootstrap", I interpret that
> as meaning using X to build another copy of X from sources enough times so
> that you can compare successive versions and expect them to be the same.  But
> what else is there in the gcc tree that can be used to build itself?  So
> what's to be made "independent"?

No!  This is the old model of bootstrap: rebuild gcc a bunch of times
with itself.  The top level bootstrap model is to rebuild all the useful
bits of the entire tree as a group; and repeat that as many times as
necessary to be able to compare them.

We bootstrap everything used in the build process.  Some example
consequences of this:

We used to have some workarounds in the libcpp-to-gcc interface to work
around the fact that we built libcpp once, with the system compiler,
and then linked it to each stage of the bootstrap.  Darwin had a system
compiler that disagreed with the FSF GCC on the size of _Bool, I
believe.  Now we build the stage1 libcpp with the system compiler,
build the stage1 gcc with the system compiler, link them together,
and go on to build the stage2 libcpp with the stage1 gcc.

We can bootstrap the assembler in a combined tree.  The first stage's
gcc will invoke a stage1 assembler, the second stage's gcc will invoke
a stage2 assembler.  This doesn't have any fundamental benefits except
for thoroughness; it's an even better sanity check.

Eventually I expect we'll have at least one frontend written in C++. 
We'll be able to build that frontend using a bootstrapped copy of
libstdc++.

> What's wrong with the present obj/gcc/stage1 and obj/gcc/stage2?  As I said,
> I think renaming directories is going to cause no end of problems (having
> directories be renamed under people is just one example).  What's the
> benefit?  Before we made "make bootstrap" restart in the beginning, the
> Makefile was able to keep track internally of what it was up to.  More
> recently, we used a file that stays where we are.  What's so wrong with that
> approach that justifies renaming directories?  Can't those two states
> (current and previous) just be variables in the Makefile that it imports
> from some status file?

It was an implementation decision to use obj/stage1-gcc instead of
obj/gcc/stage1, so that (A) we didn't have to move every individual
file around, and (B) we knew, robustly, that each stage's build would
be completely separate from the previous stage's (no way to leave stray
files behind, since the directory is created from scratch).

Personally, I think this layout (which I did not pick) is superior.
It makes it far more difficult to accidentally mix stages.

We could change that decision, and move all the files around instead. 
That wouldn't change the need to hand off to the top level in order to
do bootstraps though; the routines in gcc would be just for
convenience.  A bootstrap would need to build top level versions of
helper tools and libraries.

-- 
Daniel Jacobowitz
CodeSourcery, LLC