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
