The top level bootstrap model is to rebuild all the useful bits of the
entire tree as a group; and repeat that as many times as necessary to
be able to compare them.
Please define "useful". I'm very concerned if we're doing more builds
than before and don't have a way to restrict the builds to what we
were doing previously since it slows down the development process,
especially for those people still on slower machines.
A bootstrap has a very precise purpose: you want to ensure that when
you install a new compiler, you won't lose the ability to recompile it.
So we ensure that everything that *has* to be compiled in order to build
the compiler is. As we extend that to ancilary pieces we're rapidly
getting into a process of diminishing returns and when I hear that we're
making it *easy* to keep adding pieces, I worry even more about bootstrap
speeds in the future.
We can bootstrap the assembler in a combined tree. The first stage's
gcc will invoke a stage1 assembler, the second stage's gcc will invoke
a stage2 assembler. This doesn't have any fundamental benefits except
for thoroughness; it's an even better sanity check.
Sure, but I think it should be viewed as an *additional* check, much like
we currently have two tests: bootstrap and "make check". So we'd have
three: a "simple" bootstrap, a complete bootstrap, and "make check". The
latter two would be a requirement for check-ins, but the former would exist
to be used as part of the "rough" testing process.
Eventually I expect we'll have at least one frontend written in C++.
We'll be able to build that frontend using a bootstrapped copy of
libstdc++.
Sure, but I don't see what the major gain of such a thing would be over
the current set of tests for libstdc++. Aren't those tests much more
exhaustive a test than the usage of libstdc++ by such a front-end?
Personally, I think this layout (which I did not pick) is superior.
It makes it far more difficult to accidentally mix stages.
I'm not sure I understand the logic of that conclusion, though I agree
that the order in which the directories are named isn't a critical issue
so long as the current *functionality* isn't lost.
We could change that decision, and move all the files around instead.
That wouldn't change the need to hand off to the top level in order to
do bootstraps though; the routines in gcc would be just for
convenience. A bootstrap would need to build top level versions of
helper tools and libraries.
Right, but it would avoid the need to rename directories and, as I said, I
think that's a problem waiting to happen.
