Re: What happend to bootstrap-lean? (was: What happened to bubblestrap?)

[Daniel Jacobowitz <drow at false dot org>]

On Sun, Dec 18, 2005 at 12:12:17PM -0500, Richard Kenner wrote:
> Backwards compatibility is indeed expensive, but is critical.  All vendors
> do it and we need to as well.  You can be certain that if there were six
> ways of specifying something in VMS on a VAX in 1979, all six will still
> work today on all VMS targets.  There's a reason for that: the users demand
> and expect it.

I am perfectly willing to maintain backwards compatibility for _users_
of GCC.  Most users of GCC don't build GCC, and most builders of GCC
really don't use the full expressiveness of the build system.  I
disagree with the assertion that we need to maintain "compatibility" in
our Makefiles.  Obviously we want to in as much as it is practical;
this isn't.

And don't you think that talking about compatibility expected by our
users is just a little bit disingenuous, when you're talking about
running make inside the gcc subdirectory?  Users don't do that! 
Only developers of GCC do.  It's only useful for incremental builds; a
full build of GCC always starts and ends in the top level.

>     ./configure &&
>     make bootstrap is going to continue working, presumably forever.
> 
> I thought the whole point was that "bootstrap" wasn't a target at the top
> level, but just in the gcc/ directory, so that the above did *not* work.

Huh?  Are you talking about before, or after, the changes?  "bootstrap"
has always been a target at the top level.  It used to be implemented
by building a bunch of other stuff and then forwarding to a bootstrap
target in the gcc subdirectory and then building another bunch of
stuff, but is no longer.

>     Any such build script - we've got plenty of our own here, thanks -
>     grows little widgets over time to handle particular configurations and
>     particular versions of GCC, in my experience.  
> 
> Sure, but the issue is the *size* of the differences.  Are we talking about
> something subtle or a completely different sequence of make targets?

Paolo already answered this question, in a message directly to you:
  http://gcc.gnu.org/ml/gcc/2005-12/msg00490.html

>     But if you insist that you must continue to run 'make' in the gcc
>     subdirectory, you won't get a bootstrap, just a rebuild of the current
>     stage.
> 
> You lost me.  "make" in the gcc subdirectory would always build into that
> directory using the system compiler (i.e., what you'd normally use to build
> the stage1 compiler), not do a bootstrap.  It was "make bootstrap" that would
> continue the bootstrap from the current location.

I was referring to "make $(anything)", i.e. the command /usr/bin/make.

> In my experience, the four most common targets in the gcc subdirectory were:
> 
> 	<empty>, as above
> 	bootstrap, as above
> 	compare, the obvious
> 	unstage1, to undo a "make bootstrap"
> 
> I think those four targets need to keep working because they are also the
> oldest targets.  I certainly agree that it's reasonable to change the way
> that the lesser-used targets are executed, so long as there's a
> clearly-documented mapping.  However, I also don't see why we can't simply
> put that target into gcc/Makefile.in to simply recursively execute the make
> with the equivalent target.  That does not have the maintenance burden you
> suggest above.

Because it would have to recurse to the parent directory, which is then
going to rename your current directory and do bits elsewhere, in other
directories; it's likely to leave you far away from the results of your
make.  Do you really think that'll leave you any less confused?  I'd be
baffled!  I hate it when things rename my $PWD.

-- 
Daniel Jacobowitz
CodeSourcery, LLC