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.
>But I don't *want* to use the libada mechanism: I need to use the present
>mechanism where the Ada library and tools are built within the gcc/
>directory. It's indeed nice to have the libada mechanism as an option
>when a full build is done, but it's not what's wanted during a
>development cycle.
Why?
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.
And more importantly, if there are showstopper problems why wasn't
this discussed at lengths like we are (appropriately) doing for
toplevel bootstrap?
First of all, it's natural for people to not pay attention to things until
it's right up against them: look at the cvs->svn transition as an example.
Secondly, from my perspective, what I saw was a proposal to *enhance*
bootstrapping. I never thought this "top-level bootstrap" was particularly
useful, but we have lots of features in the compiler that specific
individuals don't see as useful, so that's hardly a reason to comment on it.
What I *didn't* see was a discussion where things were being proposed to be
*removed*. Perhaps it was there and I didn't see it, but normally when
somebody is proposing something that breaks backwards compatibility, I'd
expect to see large upper-case subjects warning about it and if they were
there, I missed them.
But why is this a "show-stopper"? Why can't the target just be added back?
