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>]

> The point is that 32->64 is a cross-compiler and it's only meaningful to talk
> about "bootstrapping" a native compiler.
>  
It's not 32->64.  It's 64->64, but built with a 32-bit compiler.  
Anyway, I find this discussion secondary now that we reached a point 
from which I can help you.

>     You will always have a bootstrap sequence and a non-bootstrap
>     sequence, but you'll need to reconfigure to switch between the two.
>
> That's *weird* to me.  Why is such a step being put into the normal 
> workflow?  I
> fail to see how that helps anything.

The default is usually the right thing.  And because you have plenty of 
other makefile targets to decide what to do in a more fine-grained way.

Because in practice you will never need it anymore.  You and others 
reported it to be inconvenient, so the pending patches will make the two 
trees "similar enough" that you can work within a "../configure" tree 
only.  They are still different, but this will be irrelevant most of the 
times.

> In the old scheme, a "bootstrap" meant just rebuilding the compiler.
> There seems to be a belief that it would be good if it rebuilt more.
> So the way I thought things were going to be done, if you say "make
> bootstrap" with --disable-bootstrap, it does the old (shorter) method
> and if you say it with --enable-bootstrap, it does the new (longer).  
> If this
> isn't what's implemented, why isn't it?


It is.  But since the old mechanism had some inherent limitations that 
are blocking other improvements, sooner or later if you say "make 
bootstrap" with --disable-bootstrap you will get "No rule to make target 
`bootstrap'", and the same will happen if you say "make bootstrap" 
within the gcc directory.

> Of course I forgot about the upper-level "make" before the "check", but it's not
> needed before "check-ada": for that all I want is "make gnatlib_and_tools",
> but you don't show the equivalent for that.
>  
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.

> But I don't *want* to use the libada mechanism: I need to use the present
> mechanism where the Ada library and tools are built within the gcc/
> directory. It's indeed nice to have the libada mechanism as an option when a
> full build is done, but it's not what's wanted during a development cycle.
>  
Why?  And more importantly, if there are showstopper problems why wasn't 
this discussed at lengths like we are (appropriately) doing for toplevel 
bootstrap?

Paolo