committed: merge with libada-branch

[Laurent GUERBY]

On Tue, 2004-02-10 at 20:56, Zack Weinberg wrote:
> Laurent GUERBY <laurent@guerby.net> writes:
> > I hope this will make it easier for GCC people to build
> > and test Ada when the backend is changed :).
> It's a step in the right direction; there's still a long way to go.

IIRC, having one more step to do was the argument people were
using, what are the others? Now you just have to add ada
to configure enable and have a working GNAT around and
it just works like other languages, at least for some major native
targets.

> Well, /a priori/ it seems to me that moving the sources will allow the
> build system to be made simpler and easier to understand.  It's also a
> golden opportunity - since you are renaming them all anyway - to
> switch to a more comprehensible naming scheme (you can't build GCC on
> a filesystem limited to 8.3 names anyway - so using krunched names
> doesn't gain anything anymore - and how about config/OSNAME/foobar.adb
> instead of XYfoobar.adb?)

In my experience people knowing Ada have little trouble finding
their way in the krunched names, the Ada standard package list
is finite and not that big. Plus with any reasonable GNAT IDE
you can jump from a "with" to the runtime source in one
click/keystroke irrespectiv of the naming convention used.

Also, I prefer the current way of handling OS specific stuff
(concentrated in a section of the Makefile with GNU make extensions)
than dozen of directories and lots of files with the same name and
different content.

But that's more taste than real functionality even if GNU make
handling is in theory more flexible than static repartition in multiple
directories.

> I know very little about the way multilibs work.  It may or may not be
> feasible to do something that doesn't involve moving the source code.
> I am pretty sure moving the source code will make it easier, though.

I hope that someone who knows will help us.

> There are cleanups to the gcc subdirectory build infrastructure, such
> as eliminating the lang/Makefile.in facility, that are blocked by the
> current structure of the Ada sources.

It looks like most of the existing ada/Makefile.in is related
to the specifics building the library and tools and we should be able
to move that to libada, orthogonal to renaming I'd say.

> There is brief documentation of how to specify a set of multilibs in
> the GCC internals manual, but I don't know of any documentation
> anywhere of how to write a multilib-enabled language runtime Makefile.
> 
> The set of multilibs is determined entirely by the target
> architecture.  Building a cross compiler to just about any
> embedded target (mips-elf for example) will involve multilibs.

Are multilib used to build shared and non shared libraries?

Laurent