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
