Bootstrap, to me talks about the whole toolchain and all the library
that it uses.
I suppose it *can*, but that's not what term usually means.
Wouldn't you bootstrap an assembler written in assembly language?
Of course. But that's not relevant to this since we don't write the
compiler in assembly language.
Even if the compiler is written in C, part of compiling itself is
doing an assembly -> machine language translation, which can be
stressed by bootstrapping the assembler as well. This is not
mandatory (of course) but possible with the new method.
I *suppose* you could include other parts of the toolchain in the "bootstrap",
but I think the advantages of doing so are pretty small.
I've interpreted it as "I don't bootstrap while debugging, so I'm using
--disable-bootstrap to debug". Not as "I'm using ../configure
--disable-bootstrap && make bootstrap".
I haven't tried doing builds since the change, but I certainly view doing the
normal (what you would probably consider "limited") bootstrap as part of my
debugging procedure.
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.
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.
As long as --disable-bootstrap keeps all the old stuff alive, I have no
problem. Like a lot of other people in this thread, I'll just keep using
it. That of course, means the new mechanism won't get much testing.
