Re: Ada guidelines changes for Comfignat and runpaths

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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





[Index of Archives]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite Forum]     [KDE Users]

  Powered by Linux