Richard Kenner wrote:
If you configure with --enable-languages=c,ada (which I guess is a good
option for you), a toplevel "make" does everything you need -- nothing
less, nothing more.
No, I want to configure with all the languages since I want to build them
all (and have to, in order to do a full "make check"). We're talking
about limiting what's built during each testing step, not limiting what
*can* be built.
Okay. Things start to take a shape. Then it seems to me that you are
just relying on a peculiarity of the Ada build system, that is the fact
that you can work entirely from within the GCC directory. This is true
nowadays even though it's been *years* since GCC won't run except within
the Cygnus tree (aka toplevel). For every other language, this point
would have been moot because they never had anything like
"gnatlib_and_tools".
What you want is making the GNAT RTS and tools after fixing the bug and
bootstrapping the compiler, and before testing everything, just as a
quick smoke test. What you need to do then, is to run from the toplevel
"make stage3-bubble; make -C gcc gnatlib_and_tools".
If "make stage1-bubble" is the equivalent of "make" within the gcc
directory, then "make stage3-bubble" is the equivalent of "make
bootstrap" within the gcc directory. Plus, of course, there are
"stage2-bubble" and "stage4-bubble" in case you find them useful.
Because doing more than just building the GNAT RTS and tools will greatly
slow down my developement cycle. Sure, when I'm ready for a final test,
I need to build everything, but not normally.
However, with libada enabled, "make all-target-libada all-gnattools"
from the toplevel would be exactly the same as "make gnatlib_and_tools"
from the gcc directory. A bit more verbose, I grant you this.
Secondly, from my perspective, what I saw was a proposal to *enhance*
bootstrapping.
From the original proposal, submitted September 2004: "For a while,
old-style bootstrap will still be available with ./configure
--disable-bootstrap; make bootstrap (non intuitive maybe, but in the
long term, it would only be one more historic wart if the flag was
called --{enable,disable}-toplevel-bootstrap)."
What I *didn't* see was a discussion where things were being proposed to be
*removed*.
*Moved*, not removed. Moved from the gcc directory to the toplevel.
But why is this a "show-stopper"? Why can't the target just be added back?
For now, everything is compatible with --disable-bootstrap. I can
imagine that when we start relying on the advantages of toplevel
bootstrap, things would not be so easy. But I am confident that things
will be sorted out before that.
Paolo
