committed: merge with libada-branch

[Zack Weinberg]

Laurent GUERBY <laurent@guerby.net> writes:

> On Tue, 2004-02-10 at 22:15, Zack Weinberg wrote:
>> 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.
>
> If you know the Ada package name (from textbook and no IDE around), the
> gnatkr tool will give you the crunched name:
>
> $ gnatkr ada.text_io
> a-textio
>
> If you're in a file, the package name is at the top and end of the file.

It should be emphasized that I don't do this very often, and so I have
not been motivated to invest time in learning an Ada IDE or anything
else that could help.  I am willing to take suggestions, however.
If you know of a readily-available (ideally in the form of a Debian
package) utility that does for Ada sources what cscope(1) does for C,
I'm interested.

It should also be emphasized that the threshold for me getting
frustrated and giving up is very, very low.  If it takes me five
seconds to find thing one, and then that refers to thing two, which
takes me another five seconds to find, and then that refers to thing
three - forget about it.  (By contrast, I can chase a chain of
references in the C sources as fast as I can type.)

My usual problem with krunched names is that I know a package name,
and I'm looking at the giant directory listing, and I have to work
out which file to look at, or else I have to grep the entire directory
for the appropriate string.  Either one takes about five seconds; see
above.  Same with symbols, except there the only option is to grep.

>> 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.
>
> For now the table is in ada/Makefile.in, it's not simple to classify
> the OS/file correspondance, sometimes one file is used for half of
> the OSes, sometimes only for one OS, so it will not be simple to
> come with a set of meaningful prefixes.

Hmm.  That suggests to me an organization based on properties, rather
than OS names.  For example, consider System.Parameters: you could
have an organization like

 .../runtime/system/parameters/ default.ads
                                default.adb
                                hp.ads
                                linux.adb
                                openvms-restricted.ads
                                openvms.ads
                                os2.adb
                                rtems.adb
                                solaris.adb
                                vxworks-ae.ads
                                vxworks.ads

and the appropriate files would get symlinked or copied to
.../runtime/system/parameters.ad[sb] when the library was configured.

Ada.Numerics.Aux would be similar:

 .../runtime/ada/numerics/aux/ default.ads
                               i386-80bit-libm.ads
                               i386-80bit-hw.ads
                               i386-80bit-hw.adb
                               vxworks.ads

(NB ada/Makefile.in makes reference to 4vnumaux.ads, which does not
exist; conversely 4onumaux.ads exists but is not referenced.)

I'll add that the Makefile logic for deciding what
LIBGNAT_TARGET_PAIRS etc to choose is, to me, completely
incomprehensible; I would be much more comfortable with an approach
similar to config.gcc, invoked from configure and using shell cases on
canonical system names.

zw