Re: Status and rationale for toplevel bootstrap (was Re: Example of debugging GCC with toplevel bootstrap)

[Paolo Bonzini <paolo dot bonzini at lu dot unisi dot ch>]

Richard Kenner wrote:

>    If you configure with --enable-languages=c,ada (which I guess is a good 
>    option for you), a toplevel "make" does everything you need -- nothing 
>    less, nothing more.
>
> No, I want to configure with all the languages since I want to build them
> all (and have to, in order to do a full "make check").  We're talking
> about limiting what's built during each testing step, not limiting what
> *can* be built.
>  
Okay.  Things start to take a shape.  Then it seems to me that you are 
just relying on a peculiarity of the Ada build system, that is the fact 
that you can work entirely from within the GCC directory.  This is true 
nowadays even though it's been *years* since GCC won't run except within 
the Cygnus tree (aka toplevel).  For every other language, this point 
would have been moot because they never had anything like 
"gnatlib_and_tools".

What you want is making the GNAT RTS and tools after fixing the bug and 
bootstrapping the compiler, and before testing everything, just as a 
quick smoke test.  What you need to do then, is to run from the toplevel 
"make stage3-bubble; make -C gcc gnatlib_and_tools".

If "make stage1-bubble" is the equivalent of "make" within the gcc 
directory, then "make stage3-bubble" is the equivalent of "make 
bootstrap" within the gcc directory.  Plus, of course, there are 
"stage2-bubble" and "stage4-bubble" in case you find them useful.

> Because doing more than just building the GNAT RTS and tools will greatly
> slow down my developement cycle.  Sure, when I'm ready for a final test,
> I need to build everything, but not normally.
>  
However, with libada enabled, "make all-target-libada all-gnattools" 
from the toplevel would be exactly the same as "make gnatlib_and_tools" 
from the gcc directory.  A bit more verbose, I grant you this.

> Secondly, from my perspective, what I saw was a proposal to *enhance*
> bootstrapping.
From the original proposal, submitted September 2004: "For a while, 
old-style bootstrap will still be available with ./configure 
--disable-bootstrap; make bootstrap (non intuitive maybe, but in the 
long term, it would only be one more historic wart if the flag was 
called --{enable,disable}-toplevel-bootstrap)."

> What I *didn't* see was a discussion where things were being proposed to be
> *removed*.
*Moved*, not removed.  Moved from the gcc directory to the toplevel.

> But why is this a "show-stopper"?  Why can't the target just be added back?
>  
For now, everything is compatible with --disable-bootstrap.  I can 
imagine that when we start relying on the advantages of toplevel 
bootstrap, things would not be so easy.  But I am confident that things 
will be sorted out before that.

Paolo