Björn Persson <Bjorn(a)xn--rombobjrn-67a.se> writes:
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.
I thought only one user uses Adacontrol based on the name of
the project
:-) But they don't use Fedora nor RPMs
> 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?
I meant to have second directories there. But yeah
seems like it's not a problem.
> 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.
The problem is gnatcoll is ~5 months ahead of GPS and
the moment of
release. Basically we have to either revert many patches in gnatcoll or
backport similar number to gps. And end up with something in
between. Supporting of this will be painful.
Hopefully 2017's release will be better...
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.
It's basically
option [3] in your response below but without static
library in gps package but with another dynamic one in gnatcoll
package like %{_libdir}/gnatcoll/relocatable/gnatcoll-gps.so{.%{version}}
which provided by gnatcoll-gps{-devel} packages the only user of this
library is gps.
xmlada looks good because it much more stable and backward compatible
than gnatcoll.
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]
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.
I don't like the idea to put gnatoll/xmlada builds
in gps src.rpm. Don't
know why... Will try to play with it in Copr. Hopefully by that time AdaCore
will release 2017 which will break^W fix everything!
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. :-)
I prefer option 4 as well because I'm not
big fun of GPS and Python
tracebacks. But I've received questions like "Is there IDE for Ada
in Fedora?" few times and answer "There is emacs/vim with ada-mode/ada
plugin)" didn't work very well. It's better to have than not to have :-)
Björn
_______________________________________________
Ada mailing list -- ada(a)lists.fedoraproject.org
To unsubscribe send an email to ada-leave(a)lists.fedoraproject.org
--
Pavel