This *will* stop working,
Then I'm confused: I thought the whole point of --disable-bootstrap is
to keep the old mechanism instead of getting the new one.
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 *wierd* to me.
What it used to be "make" and "make bootstrap" are (and will be)
"./configure --disable-bootstrap && make" and "./configure && make".
Rerunning configure is a pain! It's never just "./configure", but
has the source directory plus any options. Keeping track of exactly what
configure command was last done in each directory is a mess and error-prone.
Why is such a step being put into the normal workflow? I fail to see
how that helps anything.
Paolo posted mails explaining complex workflows like debugging a
stage1/2 miscompilation, and how that can be done with the new
system. What is that *you* think you can't do anymore with the new
system?
Building a debugging compiler and then doing a bootstrap (the normal case)
without having to rerun configure.
Perhaps I'm confused. Here's what I thought was going on (and what I'd
*like* to see going on):
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?
