Pavel Zhukov wrote:
I have drafts of gnat_util and ASIS
packages ready but don't see usecases for them so far.
ASIS should for example allow us to package Adacontrol (checking coding
style and design patterns), and maybe Adabrowse (generating API
documentation from commented source code). I don't know that we have a
pressing need for those tools, but it would be nice to be able to offer
them to Fedora users.
As you know the main missed part is Gnat Programming Studio and
users
want it! I'm working on it right know but metfew issues there I'd
like to discuss (seek for help/advice).
It would be great to finally have GPS in Fedora!
GPS requires gnatcoll with libgpr support enabled. libgpr is
provided
by gprbuild and I've managed to build it [1]. However I'm not 100%
sure if we can ship additional directories like %{_includedir}/gpr and
%{_libdir}/gpr in addition to %{}/gprbuild. I've not found such kind
of restriction in Packaging Guidelines through.
I don't see a problem. Having subdirectories in %{_includedir} and
%{_libdir} is quite normal. There is no %{_includedir}/gprbuild or
%{_libdir}/gprbuild, is there?
Gnatcoll itself... As you can see there're two versions of the
package
on
libre.adacore.com. First one is "normal" one which is released with
gnat and called gnatcoll-gpl-%{version} and we have it in Fedora for a
while. Second one is "special" version for GPS and called
gnatcoll-gps.
I've seen similar things in the past. A special GTKada-for-GPS for
example, and I think there was an XMLada-for-AWS at one point. I've
never seen any explanation of what problems will happen if one doesn't
use those special versions.
They also provide a long list of third-party libraries and probably
expect people to link to those specific versions of all those libraries.
It fits with Adacore's habits of bundling and static linking, but it
doesn't fit well in a dynamically linked distribution like Fedora.
One day there will be both XMLada-for-AWS, XMLada-for-GPRbuild and a
released XMLada with a version number, and which one do we package then?
So I can imaging few possible solutions:
1) Use gnatcoll-gps sources in gnatcoll RPM. Disadvantage is having
approx. 5 months "older" codebase which was not actually "released".
But who cares :) 2) Add second SOURCE to the rpm and gnatcoll-gps
subpackage which provides BR for GPS and single gnatcoll-gps.so
library to link with. Requires patching of build system and I don't
like this part. But advantage is to have gnatcoll which was actually
released in distribution. So should be more stable in theory (sigh).
3) Ship gnatcoll-gps sources in gps-gnatcoll-* rpms as BR and runtime
libraries. Has same disadvantages as (2) and even more as I don't like
the idea to ship gnatcoll in gps package...
4) Do not package gps at all :)
I'm afraid I don't understand what you mean in option 3.
What I would do:
1: First try to link GPS 2016 to Gnatcoll 2016, and if it seems to work,
then ship that and ignore gnatcoll-gps.
2: If it breaks, then I'd look into patching either GPS or Gnatcoll.
3: If patching is infeasible, then maybe I'd try bundling gnatcoll-gps
in the GPS source package and linking it statically so that there is no
gnatcoll-gps.so that anything else could abuse. That would at least
keep the ugliness contained.
4: Your option 1.
5: Your option 2.
But honestly, before I got that far I expect that I'd run out of steam
and go straight to your option 4. :-)
Björn