make all vs make bootstrap
In previous versions of GCC before yesterday, "make all" used to do a normal build but now I am getting a full bootstrap which is not what I wanted as I was just testing objective-C and libobjc changes and nothing else. Is this is deliberate change or just a mistake? Thanks, Andrew Pinski
Re: make all vs make bootstrap
Andrew Pinski wrote: > Is this is deliberate change or just a mistake? I'm pretty sure is deliberate and --disable-bootstrap is the config you need. Paolo.
Re: make all vs make bootstrap
Andrew Pinski <[EMAIL PROTECTED]> wrote: > In previous versions of GCC before yesterday, "make all" used to do a > normal build > but now I am getting a full bootstrap which is not what I wanted as I > was just testing > objective-C and libobjc changes and nothing else. > > Is this is deliberate change or just a mistake? http://gcc.gnu.org/ml/gcc/2005-12/msg00357.html Use "make quickstrap" or --disable-bootstrap. -- Giovanni Bajo
Re: make all vs make bootstrap
On Thu, 2005-12-15 at 19:01 +0100, Giovanni Bajo wrote: > Andrew Pinski <[EMAIL PROTECTED]> wrote: > > > In previous versions of GCC before yesterday, "make all" used to do a > > normal build > > but now I am getting a full bootstrap which is not what I wanted as I > > was just testing > > objective-C and libobjc changes and nothing else. > > > > Is this is deliberate change or just a mistake? > > > http://gcc.gnu.org/ml/gcc/2005-12/msg00357.html > > Use "make quickstrap" or --disable-bootstrap. Will make quickstrap do the same as "make all"? I *really* don't want to have to remember new configure options when this used to be a simple makefile target.
Re: make all vs make bootstrap
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
Re: make all vs make bootstrap
What about bubblestrap? (See also http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25438) -- Cheers, /ChJ
Re: make all vs make bootstrap
Christian Joensson wrote: What about bubblestrap? (See also http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25438) A "make" from a toplevel is equivalent to the old "make bubblestrap" or "make -C bubblestrap". In practice "make" just does the right thing, compiling all that is needed to not have comparison failures. Paolo
Re: make all vs make bootstrap
Paolo Bonzini <[EMAIL PROTECTED]> wrote: >> What about bubblestrap? >> >> (See also http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25438) >> >> > A "make" from a toplevel is equivalent to the old "make bubblestrap" > or "make -C bubblestrap". In practice "make" just does the right > thing, compiling all that is needed to not have comparison failures. I would also note that using "make" in the cp/ directory at least used to build cc1plus with the system compiler, without -Werror and with a different set of warnings. There have been many cases where a patch tested by C++ rules (which is *not* a full bootstrap, but just "build compiler, build libjava, check c++") resulted in a bootstrap failure because of a variable not initialized or something. The correct solution used to be (guess what!) "make bubblestrap" to build the compiler. Now, it's simply the default :) Giovanni Bajo
Re: make all vs make bootstrap
Hi Paolo > 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. I see that gcc/doc/makefile.texi is now out of date. Can you update it so that we have a reference for the new targets? Thanks, Ben
