This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: committed: merge with libada-branch


Laurent GUERBY <laurent@guerby.net> writes:

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

I'd rather not discuss that in this thread.

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

My concern is for people (such as myself) who are *not* familiar with
Ada.  I have occasion to look in there maybe once a month and every
time I have to work out from first principles how the krunching scheme
works.

As for organization of OS specific stuff, the only real suggestion I
have is that the file names have some obvious relation to the system
they're intended for, rather than being arbitrary codes.  Directory
partitioning was just the first thing that came to mind.

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

Yes, I agree this should be possible.

zw


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]