make all vs make bootstrap

[Paolo Bonzini]

> Will make quickstrap do the same as "make all"?

No, there's no "make quickstrap" at all!  Citing from the "Top-Level 
Bootstrap" wiki page:

Toplevel bootstrap is able to bootstrap a compiler with separate 
reconfigurations and rebuilds of libiberty/libcpp/gcc in all the three 
stages. It is actually possible to bootstrap a whole toolchain, so that 
the final executable is built entirely with the assembler, binutils and 
linker that are in a combined tree.

When configuring in a native environment, make will do more or less what 
make bubblestrap used to do: start from stage1, rebuild everything that 
had to be rebuilt, configure stage2 if it has not been configured yet, 
build stage2, and the same for stage3. "Rebuilding" is not limited to 
GCC: libiberty, libcpp, and other dependencies of GCC are all configured 
and compiled three times. It is the same as rebuilding a whole tree from 
scratch three times, each time using the previous build as the result.

It supports all the bells and whistles like bubblestraps and restageN, 
which help during development. make restrap (taking a non-bootstrap 
build and using it as stage1) is not supported. make restageN is called 
make all-stageN, and there is also make all-stageN-gcc to rebuild gcc 
only. There is no equivalent to quickstrap, even though it can be added 
if there's demand.

Lean bootstraps are also supported, but they are enabled with 
--enable-bootstrap=lean rather than with special targets.

make profiledbootstrap works; it will build profile-optimized 
assemblers, binutils and linkers when run in a combined tree.

For a while, old-style bootstrap will still be available with 
./configure --disable-bootstrap; make bootstrap (non intuitive maybe, 
but in the long term, it would only be one more historic wart if the 
flag was called --{enable,disable}-toplevel-bootstrap).

> I *really* don't want to have to remember new configure options when
> this used to be a simple makefile target.

I'm sorry, there's no alternative.  The two bootstrap/non-bootstrap 
logics are very different.  If they could live together in the gcc 
directory, and most of the time working, it was only at the price of 
comparison failures when you were doing something a bit more weird than 
what is supported.

It's probably a matter of having different working patterns.  Mine is 
that if bootstrap breaks seriously (e.g. with wrong code), I make a .i 
of the failure, move it to prev-gcc, and work from there.  With the old 
bootstrapping logic I made the .i of the failure, typed "make restage1", 
and worked from there.  The number of steps is the same.

I agree that the "prev-gcc" naming is sub-ideal, but Daniel seems 
confident that it can be fixed after his toplevel libgcc work goes in. 
If that's true, we can actually do *entirely without* the unstage/stage 
mess and simply have build directories that are called "stage1-gcc", 
"stage2-gcc", "stage3-gcc".  This will make things even easier.

But please, let me recall that the first CFT for toplevel bootstrap 
(when everything was working except parallel builds, and bootstrapping 
combined trees) is from September 2004.

Paolo