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

[Paolo Bonzini]

>I *suppose* you could include other parts of the toolchain in the "bootstrap",
>but I think the advantages of doing so are pretty small.
>  
>
What about libraries used by GCC?  From the user point of view it is a 
bad bug that you cannot bootstrap a 64-bit compiler starting from a 
32-bit one (because stage2 does not find a 64-bit libiberty to use).

>I would never use "../configure --disable-bootstrap && make bootstrap", but I
>most certainly *would* use "../configure --disable-bootstrap; cd gcc; make
>bootstrap" and would be *very* annoyed if it stoped working.
>  
>
Except that the two are synonyms.

>In a previous message, you suggested having two trees, one with and one
>without --disable-bootstrap, but that means doing *two* sets of compilations.
>I have a fast enough machine and enough disk space that it's not *too*
>painful (though it is a nuisance and takes time), but you have to be
>conscious of the GCC developers who have slow machines (or people doing
>builds on slow targets!) and ensure that whatever "improvements" are done,
>that they still have some mechanism to do things the old way.
>  
>
Since then, I've catered for the needs of people that saw their workflow 
broken and reported that.  Now (with patches posted but not yet 
reviewed), you can comfortably work with a single tree, use most of the 
commands that you used to have, and still have the advantage of broader 
coverage of the compiler and no binary compatibility problems between 
GCC and the host compiler.  Except "cd gcc; make bootstrap" because the 
two methods *cannot* live together in the same tree.

Paolo