Hi Ada coders and lovers,
As x86 (32-bit for i686->) is not primary architecture anymore [2] and we
have at least one bug which blocks gprbuild [1] (and as the result
almost whole stack) I start to think about dropping i686 from the list
of GNAT_arches since F26 onward.
Any ideas/objections?
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1444614
[2] https://fedoraproject.org/wiki/Architectures
--
Pavel
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.
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).
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?
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:
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 :)
Minor issue is GtkAda3 bug [2].
[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