5:15 p.m.
Orion Poplawski wrote:
I'm thinking perhaps it is time to come up with a standard for
how ada
libraries are installed. I don't know much about ada, but I package plplot
which has an ada interface. ada uses a couple different types of files:
adb, ads, ali, and perhaps .gpr and .lgpr for gnat.
I have made a few Ada packages and have been trying to come up with some
workable practices. The details are still subject to change but I'll try to
write down how I currently do things.
To make usage of Ada libraries smooth for programmers I have based my
packaging on Gnat project files (.gpr files). Every Ada library should have a
project file describing how to compile programs against the library. In order
to work correctly in a multilib system, the project file should include
common.gpr from the package fedora-gnat-project-common, and use the variable
Common.Lib in place of "lib" or "lib64" in paths.
The file common.gpr is one of the things that are subject to change. I have
started thinking that maybe I should define some more complete paths there and
rename it to "locations.gpr" or something.
fedora-gnat-project-common also contains some RPM macros that should be used
in spec files.
Example location from GtkAda-devel:
/usr/include/gtkada/gtkada-types.adb
/usr/include/gtkada/gtkada-types.ads
/usr/lib/gnat/gtkada.gpr
/usr/lib/gnat/gtkada/gtkada.lgpr
/usr/lib/gtkada/relocatable/gtkada.ali
/usr/lib/gtkada/static/gtkada.ali
/usr/lib/libgtkada.so
I don't know about the difference between relocatable and static.
The GTKada build system has a rather unusual idea of putting shared and static
libraries in separate subdirectories, with copies of the same .ali files in
both subdirectories. The RPM spec fixes it up a bit by moving the shared
libraries to %{_libdir} so that the linker can find them.
In Fedora we shouldn't really package the static libraries. I'm sporadically
working on a big patch to the GTKada build system that will provide a clean
way of disabling the static libraries and putting the shared ones in the right
place. It will also allow putting the .ali files directly in %{_libdir}/gtkada.
So this may be simple, but perhaps:
%{_includedir}/<name>/
%{_libdir}/<name>/
is sufficient.
That's what I've been doing. Source code needed for compiling against the
library (.ads and some .adb files) in %{_includedir}/<name>, linking
information (.ali files) in %{_libdir}/<name>, and of course the library files
themselves in %{_libdir}. I'll just add one thing: Gnat project files should go
in %{_GNAT_project_dir}. That macro expands to /usr/lib/gnat, even on 64-bit
systems, because that's where Gnat looks for project files.
I think all that's technically required is that Gnat can find the project file
and that the linker can find the library. Things should then work as long as
the project file points correctly to the other files. None the less I want all
files to be in standard locations so that humans can find them without too much
trouble.
plplot-ada-devel currently puts files in:
/usr/lib/ada/adalib/plplotadad/plplot.ali
/usr/share/ada/adainclude/plplotadad/plplot.adb
/usr/share/ada/adainclude/plplotadad/plplot.ads
Not sure where they got that directory structure from.
That looks reminiscent of a draft document that was called "GNU Ada
Environment Specification". I never understood the purpose of that directory
structure, but the Ada packages in Debian conform to it. Before I started
packaging for Fedora I was going to review the specification and see if I could
figure out what the advantage was, but all the links to it that I could find
were broken.
Since the GNU Ada Environment Specification seemed to be defunct, and GTKada –
the only Ada library that I could find in Fedora at the time – didn't follow
it, I decided to use a directory structure as close as possible to what is
used for other compiled languages in Fedora.
plplot does not produce .gpr or .lgpr files. Not sure if this should
be
enforced or how they are produced.
As I wrote above, I want to require .gpr files. You'll need to write one by
hand if upstream doesn't provide one, but it's really not too hard to do. You
can look at pragmarc.gpr from PragmARC-devel for an example of what it will
look like for an uncomplicated library.
Lists of source files like GTKada's .lgpr files can be useful when compiling a
project, but I can't see that they do any good for an installed library. Nor
do I think that the ".lgpr" suffix is a widespread convention.
Björn Persson