> make stage1-bubble STAGE1_LANGUAGES=c,c++,fortran,java 

> Wow, that's awkward.

I understand, but I have a patch to make it easier.
 
Patches for the toplevel take a long time to review, and I cannot handle 
posting too many patches and tracking them. Not even two patches. Currently I 
have a pending patch at http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00473.html 
that I would have liked to be in 4.1 too, so I am not sending out the changes 
that I have in my tree to make this easier.

However, the patch is not very twisty, and reviewing does not require thorough 
knowledge of cross compilation for example.  You are a GWP, so you could help.  
A previous version of the patch is at 
http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00404.html but I've withdrawn it 
because I could make it even more similar to the old scheme.  If you want to 
review the newer version, I'll send it on monday and CC you.
 
Same goes for the documentation updates.
 
> Remind me why it's a good idea to force me to mess with bootstrapping
> at all, when all I want is to build a copy of the compiler that I can
> use for debugging problems?
 
First, because "make stage1-bubble" above only takes as much time as a 
non-bootstrapped build.  Is the command line harder than "make all-gcc; make -C 
gcc cc1plus f951 jc1"?  Maybe, but after the patch I mentioned above it will be 
the same as before toplevel bootstrap.
 
Second, because the toplevel bootstrap did fix bugs.  For example, the 
inability to bootstrap a 64-bit compiler with a 32-bit compiler (because 
libiberty was not built as a 64-bit binary) -- this requires a five line patch 
that was posted by Richard Guenther but has not been reviewed yet, either.  Or 
the binary compatibility problems when the compilation platform had a 4-byte 
bool. From the *user* point of view this is surely a progression.

Third, because nobody said it was a bad idea in the 16 months between the first 
(not the only) call for testing and the definitive enabling of toplevel 
bootstrap.

Fourth, because toplevel bootstrap is a prerequisite for many further cleanups 
and improvements, including moving libgcc to the toplevel and bootstrapping 
libada.

Eric Botcazou wrote:

> Glad to see that a GWP maintainer eventually speaks up. :-)

Well, Kenner is also GWP.  Still, it remains to be seen why the other did not 
speak up.  I am the first person that would like to know it.

> FWIW I personally think this toplevel bootstrap thing is a step backward, now 
> typing "make" triggers such a complex machinery that nobody seems to able to 
> understand what it does.

So the previous system was easy?  IMO it's just that it's been tested for 15 
years.  Personally it took me a lot of time to understand the working of 
bubblestrap, stage*_copy, stage*_build, and so on

The point is that you have to decide in advance if the toplevel will bootstrap. 
 If you use --disable-bootstrap, it will not.  --disable-bootstrap will *not* 
disappear; rather, "../configure --disable-bootstrap && make bootstrap", which 
currently triggers the old-style GCC-only bootstrap, will disappear.

What I usually do, is developing in a --disable-bootstrap tree, and when I'm 
reasonably sure, start a fresh bootstrap (because I have a script that also 
does the comparison with a baseline run, and I let it run overnight).  In more 
complex cases, like debugging a miscompilation or otherwise failing bootstrap, 
I debug in a tree configured for bootstrap.

Paolo

Reply via email to