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örn.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 [1] http://fedoraproject.org/wiki/Packaging:Guidelines#Beware_of_Rpath -- packaging mailing list packaging@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/packaging
