This shows pretty clearly that you haven't looked at it - the
basic bootstrap targets are about 10% of gcc/Makefile.in, which is
rather more than 30 lines.
You're right that I hadn't looked recently and it has indeed grown.
Certainly more than 30 lines, but not quite 10%: I count 375 out of 4615,
which is 8%. However, large blocks of that are duplicate, for example each
of the stage[123] versions, so that's not completely a fair number.
The GCC build process is ridiculously rich and has a ridiculous number
of vaguely "user-tunable" knobs, e.g. about six ways to specify what
assembler the compiler is going to use. The more complicated your
needs, the less likely they are to continue to work.
Unfortunately, the people who have the most complicated needs (not me)
are the ones who have the strongest requirement that they continue working.
I always use the system assembler, so I don't know *any* of the ways to
specify what assembler to use, but if there are indeed six, you can be sure
that at least one person out there is using each of them.
It's been my experience among GCC users working on large projects that build
scripts tend to be treated like "black magic", written by somebody who knew
the stuff and is long gone. If one of those six methods no longer works,
that script will break and they won't have the foggiest idea how to fix it.
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.
./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.
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?
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.
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.
