Re: committed: merge with libada-branch

[Arnaud Charlet <charlet at ACT-Europe dot FR>]

> 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.

At some point it would probably be nice to move these files, so this is a
medium term goal, that I don't see as critical nor blocking anything.

I am ready to discuss specific issues if people believe this is a blocking
item.

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).

All the people that have spent the effort of getting a little bit familiar
with the GNAT sources have had no trouble with the naming scheme, so I am
not willing to spend *my time* to make a change that is unlikely to make
any difference for those 'complaining people', and will create a real
incompatiblity and trouble for all those people that are familiar with
the current scheme and spent the effort to get familiar with it.

Now, there may be good reasons in the long run to do a few of these renaming,
so I am not withdrawing this proposal, it is just that currently, the
advantages are very low compared to the disadvantages.

Generally speaking, I take suggestions concerning specifically Ada files with
much more interest from people that are somewhat familiar with them, than from
people that know very little about them, even less when those people
have clearly expressed their non-interest in getting familiar with them.

Of course, there's a learning curve at the beginning, and people willing
to make the effort to learn are in a special category and deserve some
attention in my view.

It's just a matter of fairness and equity.

> What are your future plans for this directory?

I am planning to organize and help making things happen around this
new directory. So in particular, if people are willing to help in
adding some of the mentioned features (such as support for
--enable-shared=gnat, support for multilibs, etc...), I'll be glad to
work with them to make this happen.

As I said previousely, I don't have a sufficient understanding of the gcc
configure/make infrastructure to make these changes myself.
On the other hand, I have a pretty good knowledge of the Ada Makefile
and the Ada front-end in general to give some advice and help
organizing and synchronizing the work.

Arno