committed: merge with libada-branch

[Zack Weinberg]

Arnaud Charlet <charlet@ACT-Europe.FR> writes:

>> So, what this gives us is a wrapper Makefile in libada/ that invokes
>> gcc/Makefile to do all the work.  None of the code is moved.  This is
>> a step forward, but the multilibs logic is very fragile, and I doubt
>> it can be made to work without physically moving all of the libada
>> source code into the libada directory (I could be wrong about this).
>
> I don't see (currently) any gain in moving the files to libada.
> As already pointed out, the current support for gnatlib already deals with
> creating a separate directory for the gnat rts, so this should not affect the
> multilibs logic.

My worry is that the multilib logic won't even be able to handle that.
It is insanely fragile.  (Specifically, I do not think it can handle
any recursive make invocation that transfers control to a sibling
directory.)

Nathanael Nerode is probably the best person to ask about how it
works, and I certainly may be wrong about this.

> As for renaming files, etc... we have no current plans to do this.
> So far, only some people that are not willing to invest a little
> effort into looking at the Ada run time have complained about the
> naming scheme (no criticism here, just an observation).

My primary interest in this entire issue is because I want global
consistency, and to the extent that you and the other Ada maintainers
are willing to work toward global consistency I'm willing to meet
you somewhere in the middle, including familiarizing myself with the
current structure of the library.  But note that global consistency
most definitely does mean that the library sources move out of the gcc
subdirectory, since all other languages do that.

zw