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

[kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)]

    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?