Because the whole point of this process is to remove all the bootstrap
logic from the gcc subdirectory, which is exactly where it doesn't
belong. This will let us take major steps forward in our build process
How does *removing* something take major steps forward? The "whole
bootstrap logic" you are talking about is 30 lines, if that.
If we want a better process (and I certainly agree we do with respect to
libraries), indeed adding a top-level bootstrap process is appropriate. By
why delete what's there and works fine? "If it ain't broke, don't fix it!"
is very prudent engineering and very much applies here.
I feel very strongly that:
(1) If all I want to do is a bootstrap, I should be able to do that bootstrap
without having to reconfigure, maintain separate directories, rebuild files
I've already built, or any other such kludge.
(2) It should be straightforward to write a build script that works with all
versions of GCC.
It's important to keep in mind that many of us, especially those supporting
customers that use GCC, have to maintain many build directories, for multiple
targets and versions of GCC. Having vastly different procedures to use in
different directories is a real pain. At a minimum, there needs to be some
compatibility mode to support the older procedures.
