I would like to propose two additions to the Ada guidelines. The Trac ticket is here:
https://fedorahosted.org/fpc/ticket/374
Comfignat is a new build system built around the GNAT tools and designed to make packaging easy. The RPM macro Comfignat_make handles building a Comfignat-using package with the right configuration for Fedora. This macro needs to be mentioned in the Ada guidelines. I propose this change:
https://fedoraproject.org/w/index.php?title=User:Rombobeorn/Ada_Guidelines_C...
A macro named GNAT_add_rpath can be defined in spec files to allow a runpath to be added, for example in test suites or auxiliary programs that aren't installed but run during the build. This should also be explained in the Ada guidelines. I propose this addition:
https://fedoraproject.org/w/index.php?title=User:Rombobeorn/Ada_Guidelines_C...
Here's the complete proposed new version of the Ada guidelines:
https://fedoraproject.org/wiki/User:Rombobeorn/Ada_Guidelines_Changes_2
Björn Persson
On Thursday, December 05, 2013 11:12:41 PM Björn Persson wrote:
I would like to propose two additions to the Ada guidelines. The Trac ticket is here:
https://fedorahosted.org/fpc/ticket/374
Comfignat is a new build system built around the GNAT tools and designed to make packaging easy. The RPM macro Comfignat_make handles building a Comfignat-using package with the right configuration for Fedora. This macro needs to be mentioned in the Ada guidelines. I propose this change:
https://fedoraproject.org/w/index.php?title=User:Rombobeorn/Ada_Guidelines_C hanges_2&diff=361215&oldid=361212
Is comfignat packaged in Fedora? Is anyone going to use it?
A macro named GNAT_add_rpath can be defined in spec files to allow a runpath to be added, for example in test suites or auxiliary programs that aren't installed but run during the build. This should also be explained in the Ada guidelines. I propose this addition:
Is it really needed? We can use LD_LIBRARY_PATH in the %check section to make it. For example matreshka works fine with it.
https://fedoraproject.org/w/index.php?title=User:Rombobeorn/Ada_Guidelines_C hanges_2&diff=361216&oldid=361215
Here's the complete proposed new version of the Ada guidelines:
https://fedoraproject.org/wiki/User:Rombobeorn/Ada_Guidelines_Changes_2
Björn Persson
Pavel Zhukov wrote:
On Thursday, December 05, 2013 11:12:41 PM Björn Persson wrote:
Comfignat is a new build system built around the GNAT tools and designed to make packaging easy. The RPM macro Comfignat_make handles building a Comfignat-using package with the right configuration for Fedora. This macro needs to be mentioned in the Ada guidelines.
Is comfignat packaged in Fedora?
Comfignat consists of a generic makefile foundation and a template of an abstract GNAT project that will be bundled with the source packages that use it. The files need to be in the source tree so that Make will find them, so there's no point in packaging Comfignat.
Comfignat is here by the way, for anyone who is interested: https://www.rombobj%C3%B6rn.se/Comfignat/
Is anyone going to use it?
I've been helping Tero Koskinen to remake Ahven's build system around Comfignat, and he says he'll make a new release soon. I want to package Ahven to be able to run the test suites of Anet, Alog and the Trusted Key Manager. Anet is already packaged but without a %check section.
I also use Comfignat in some projects of my own that will hopefully be ready to be packaged some day.
A macro named GNAT_add_rpath can be defined in spec files to allow a runpath to be added, for example in test suites or auxiliary programs that aren't installed but run during the build. This should also be explained in the Ada guidelines.
Is it really needed? We can use LD_LIBRARY_PATH in the %check section to make it. For example matreshka works fine with it.
You can do it that way if it works for you. The GNAT_add_rpath mechanism is there if you need it. Setting LD_LIBRARY_PATH to "%{buildroot}/%{_libdir}" is reasonably clean. templates_parser.spec does «LD_LIBRARY_PATH="`pwd`/.build/native/release/relocatable/lib/" make doc». In that case the spec file must know the internal structure of the build directory just to work around a problem that Gnatmake_optflags has introduced, which is a bit messy. GNAT_add_rpath would be a cleaner solution there.
Björn Persson
On Sunday, December 08, 2013 06:36:17 PM Björn Persson wrote:
Pavel Zhukov wrote:
On Thursday, December 05, 2013 11:12:41 PM Björn Persson wrote:
Comfignat is a new build system built around the GNAT tools and designed to make packaging easy. The RPM macro Comfignat_make handles building a Comfignat-using package with the right configuration for Fedora. This macro needs to be mentioned in the Ada guidelines.
Is comfignat packaged in Fedora?
Comfignat consists of a generic makefile foundation and a template of an abstract GNAT project that will be bundled with the source packages that use it. The files need to be in the source tree so that Make will find them, so there's no point in packaging Comfignat.
Comfignat is here by the way, for anyone who is interested: https://www.rombobj%C3%B6rn.se/Comfignat/
Is anyone going to use it?
I've been helping Tero Koskinen to remake Ahven's build system around Comfignat, and he says he'll make a new release soon. I want to package Ahven to be able to run the test suites of Anet, Alog and the Trusted Key Manager. Anet is already packaged but without a %check section.
I also use Comfignat in some projects of my own that will hopefully be ready to be packaged some day.
Bjorn, I can understand your point here but comfignat is just one more project It can invoked (using fedora-gnat-project-common) some macroses but I'd not like to change Guidelines. In that case we'll introduce %{awsmake} %{awsmake_install}, %{matreshkamake} %{mynicepackagemake} macroses soon (and yes. matreshka uses its own nice configuration syste). Gnatmake and gprbuild is the standard and should be documented comfignat is not (yet).
A macro named GNAT_add_rpath can be defined in spec files to allow a runpath to be added, for example in test suites or auxiliary programs that aren't installed but run during the build. This should also be explained in the Ada guidelines.
Is it really needed? We can use LD_LIBRARY_PATH in the %check section to make it. For example matreshka works fine with it.
You can do it that way if it works for you. The GNAT_add_rpath mechanism is there if you need it. Setting LD_LIBRARY_PATH to "%{buildroot}/%{_libdir}" is reasonably clean. templates_parser.spec does «LD_LIBRARY_PATH="`pwd`/.build/native/release/relocatable/lib/" make doc». In that case the spec file must know the internal structure of the build directory just to work around a problem that Gnatmake_optflags
The maintainer must know the structure of the build directory anyway.
has introduced, which is a bit messy. GNAT_add_rpath would be a cleaner solution there.
It's not a problem that Gnatmake_optflags has introduced. It's the policy [1] In you case maintainer must use chrpath to remove Rpath in $install section and this is last resort[1].
Björn Persson
Pavel Zhukov wrote:
Bjorn, I can understand your point here but comfignat is just one more project It can invoked (using fedora-gnat-project-common) some macroses but I'd not like to change Guidelines. In that case we'll introduce %{awsmake} %{awsmake_install}, %{matreshkamake} %{mynicepackagemake} macroses soon (and yes. matreshka uses its own nice configuration syste). Gnatmake and gprbuild is the standard and should be documented comfignat is not (yet).
I'm not sure I understand what you're trying to say here. Do you mean that it's okay to use Comfignat_make but it should be undocumented? That's actually forbidden by the current policy which says that either Gnatmake_optflags or GPRbuild_optflags must be used. Or do you mean that you want Comfignat_make to remain forbidden?
Yes, Matreshka has its own build system and AWS has its own. Every Ada package has its own custom build system (except for those that have no build system at all and leave it to the users to compile the source code as they see fit). Each one has its own names for options variables and directory variables, and most are inflexible and have to be hacked to support Fedora's packaging standards. This slows us packagers down and leads to packaging bugs – like the missing optflags in Matreshka that you just fixed. I've had to wrestle a lot with GTKada's build system even though it uses Autoconf. I'm trying to improve the situation by establishing some conventions and a build system foundation that helps developers follow the conventions.
It's true that Comfignat isn't popular yet. It's only been four months since I released the first version. So how many Comfignat-using packages do you think there should be before it's worthy of a macro?
templates_parser.spec does «LD_LIBRARY_PATH="`pwd`/.build/native/release/relocatable/lib/" make doc». In that case the spec file must know the internal structure of the build directory just to work around a problem that Gnatmake_optflags
The maintainer must know the structure of the build directory anyway.
Information hiding is important to keep software maintainable. The code in one module should only use the APIs of other modules and not depend on their internals, even though the programmer often knows the internals of all the modules.
Now, makefiles don't usually have very well-defined APIs, but we can try not to make it worse.
In you case maintainer must use chrpath to remove Rpath in $install section and this is last resort[1].
The example programs in Templates Parser's manual are never installed. They are compiled and run during the build, and their output is included in the manual along with the input and the source code, but the compiled programs exist only in the build directory. There's no need to use chrpath on them. It's the same with test suites. It's not a problem if they have runpaths because they aren't included in the built packages.
Björn Persson
-
Björn Persson -
Pavel Zhukov