Maxim Reznik reznikmm@gmail.com writes:
2017-04-21 11:16 GMT+03:00 Pavel Zhukov pzhukov@redhat.com:
Hi Bjorn ( and other Ada and Fedora lovers :-) ) ,
Finally I've sorted out job related issues and can dedicate more time on Fedora packaging activities. I have drafts of gnat_util and ASIS packages ready but don't see usecases for them so far.
That's cool! ASIS is used in development version of Matreshka to build a2js - an ada to javascript translator. It's in early beta state but could be interesting to somebody.
You can use copr repo to test it. # dnf copr enable landgraf/ada-testing-repo # yum install asis-devel Again they're in very draft stage and not ready for review. But fedora compilcation flags are used so ABI should remain stable I hope.
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).
That's really cool!
Main issues: 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. Do gprbuild-libgpr and gprbuild-libgpr-devel sound good?
I guess libgpr and libgpr-devel could be even better. It seems this is a separate piece of software, even if gprbuild is the only user of it now and this packaged inside of gprbuild tar.gz.
The problem is we will have to build two packages (gprbuild and libgpr) from the same sources so build it twice and ship parts of them in different RPMs. If it's part of gprbuild it will have gprbuild- name. But it's possible to use "Provides: libgpr" to make things more clear.
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. The reason of having this is release time of GPS and Gnatcoll development model. So I can imaging few possible solutions:
- Use gnatcoll-gps sources in gnatcoll RPM. Disadvantage is having
approx. 5 months "older" codebase which was not actually "released". But who cares :)
I prefer this approach.
- 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 :)
You can also consider to build GPS 17 instead of GPS GPL 2016, due to GPS are on github now: https://github.com/AdaCore/gps/tree/17 https://github.com/AdaCore/gnatcoll/tree/17
(I haven't tried by myself however) or wait for gps gpl 2017 (branching is expected next month).
iirc It requires gnatcoll-xref which is not available in gnatcoll-2016 and requires modern version of GtkAda (>=17.0) which is not available in Fedora so far. Gnatcoll from the master requires some newer features of gnat (I don't remember which exactly) so I'm wondering if it's even doable in F26 lifecycle.
Minor issue is GtkAda3 bug [2].
And one more issue is gtkada.gpr doesn't contain version in it. Gnatcoll configure expects to see Version := "2016"; there.
[1] https://copr.fedorainfracloud.org/coprs/landgraf/ada-testing-repo/ [2] https://bugzilla.redhat.com/show_bug.cgi?id=1442661
Thank you for ideas/suggestions in advance and have a nice weekend!
-- Pavel _______________________________________________ Ada mailing list -- ada@lists.fedoraproject.org To unsubscribe send an email to ada-leave@lists.fedoraproject.org