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
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.
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.
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).
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 _______________________________________________ Ada mailing list -- ada@lists.fedoraproject.org To unsubscribe send an email to ada-leave@lists.fedoraproject.org
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
Pavel Zhukov wrote:
Maxim Reznik reznikmm@gmail.com writes:
2017-04-21 11:16 GMT+03:00 Pavel Zhukov pzhukov@redhat.com:
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.
You only need to add "-n".
In gcc.spec for example, you can find these lines:
%package gnat
%description gnat
%package -n libgnat
%description -n libgnat
This produces subpackages named "gcc-gnat" and "libgnat". Because of "-n" it's not "gcc-libgnat".
And I agree that "libgpr" would be better than "gprbuild-libgpr".
And one more issue is gtkada.gpr doesn't contain version in it. Gnatcoll configure expects to see Version := "2016"; there.
The current gnatcoll master branch in Dist-Git, with with_gtkada changed to 1, builds fine for me in F25, and with GtkAda3-devel-3.14.2-3.fc27 it builds fine in Rawhide too. Can you provide a test case that fails because the version number isn't there?
Björn
Björn Persson <Bjorn@rombobjörn.se> writes:
Pavel Zhukov wrote:
Maxim Reznik reznikmm@gmail.com writes:
2017-04-21 11:16 GMT+03:00 Pavel Zhukov pzhukov@redhat.com:
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.
You only need to add "-n".
Thank you. Didn't know about that option.
In gcc.spec for example, you can find these lines:
%package gnat
%description gnat
%package -n libgnat
%description -n libgnat
This produces subpackages named "gcc-gnat" and "libgnat". Because of "-n" it's not "gcc-libgnat".
And I agree that "libgpr" would be better than "gprbuild-libgpr".
And one more issue is gtkada.gpr doesn't contain version in it. Gnatcoll configure expects to see Version := "2016"; there.
The current gnatcoll master branch in Dist-Git, with with_gtkada changed to 1, builds fine for me in F25, and with GtkAda3-devel-3.14.2-3.fc27 it builds fine in Rawhide too. Can you provide a test case that fails because the version number isn't there?
Sorry. It's GPS's configure script. Not gnatcoll. https://github.com/AdaCore/gps/blob/master/configure#L4340
Björn
Ada mailing list -- ada@lists.fedoraproject.org To unsubscribe send an email to ada-leave@lists.fedoraproject.org
-- Pavel
Pavel Zhukov pzhukov@redhat.com wrote:
Björn Persson <Bjorn@rombobjörn.se> writes:
Pavel Zhukov wrote:
And one more issue is gtkada.gpr doesn't contain version in it. Gnatcoll configure expects to see Version := "2016"; there.
The current gnatcoll master branch in Dist-Git, with with_gtkada changed to 1, builds fine for me in F25, and with GtkAda3-devel-3.14.2-3.fc27 it builds fine in Rawhide too. Can you provide a test case that fails because the version number isn't there?
Sorry. It's GPS's configure script. Not gnatcoll. https://github.com/AdaCore/gps/blob/master/configure#L4340
Yuck, what a kludge! It matches case-sensitively even though the project file language is case-insensitive, it requires exactly one space on each side of the assignment operator, and if there were a variable named "Conversion" it would match that one too. And while the gpl-2016 branch requires version 2016 or greater, the master branch looks for 17.0 or greater, so the test will be broken if the two numbering schemes are mixed.
I'll give you commit access so you can make the changes you need, as you're the one who can check that it actually works before you push.
Björn
Björn Persson <Bjorn@rombobjörn.se> writes:
Pavel Zhukov wrote:
And one more issue is gtkada.gpr doesn't contain version in it.
While I was upgrading GTKada I added a version number to the project file. Does that work for GPS's configuration script?
Yes it does. Thank you! -- Pavel
Björn
Ada mailing list -- ada@lists.fedoraproject.org To unsubscribe send an email to ada-leave@lists.fedoraproject.org
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:
- 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
Björn Persson <Bjorn@rombobjörn.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:
- 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@lists.fedoraproject.org To unsubscribe send an email to ada-leave@lists.fedoraproject.org
-- Pavel
Pavel Zhukov wrote:
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.
In the 2017 release I don't see that or any other such special library versions, so it looks like that particular problem has gone away, at least for this release.
Björn
ada@lists.stg.fedoraproject.org
-
Björn Persson -
Maxim Reznik -
Pavel Zhukov