On 29/11/12 02:14, Mike Frysinger wrote: > On Wednesday 28 November 2012 16:49:14 Justin wrote: >> Problem: >> Some packages aren't lucky and their buildsystem doesn't create >> pkg-config files out of the box. >> >> Solution: >> Create them by hand. > > i agree this is a problem. but i think the only real place to fix this is in > the upstream package. otherwise, the .pc file is largely unused and kind of > pointless. other people have already enumerated more detailed responses, so > i'll just leave it at this. > -mike >
Hi, I will respond here, but this also is addressed to all the other negative responses. Let me explain the reason we (sci team) are using manually created .pc files. And as a side note I totally agree with the statement that pc file creation should be upstreams business. Back to the problem. We are mainly using this approach to allow multiple installations of packages providing BLAS and LAPACK implementations, and its derivative. Why this? There is a reference implementation, a closed source intel implementation, optimized versions for speed, a gnu version and so on, from which the user should be able to choose. Still why we need a switchable system? I would like to point [1] you to some great GSOC work from andy which he also present in Praque [2]. He clearly showed, that different implementations are good for different puposes. Therefore we need to have different implementations installed in parallel. Currently we have an eselect module to switch between different implementations by setting /usr/lib/lib[blas,lapack].so to the selected implementation. This has two drawbacks, which some of you might already of hit: 1. They seem to be not completely API/ABI compatible (I don't which one is correct here. And please don't be nitpicking on this point). So switching would mean recompilation of all packages linked against it before, otherwise you might get runtime errors. This takes time and triggers point 2. 2. As andy showed we should stick with specific implementations for specific tasks. The current way flattens this out to be optimal for some and suboptimal for others. Now, there has been a lot of effort around Andy and Sebastien to solve this problem. The solution is simple: don't install any libblas.so or liblapack.so in libdir, but instead make the pkg-config module eselectable and force packages to used pkg-config. Nearly (I think its 100%) of the packages in the tree already use pkg-config to detect blas/lapack. The only remaining problem is on the implementation side. As you can imagine, this effort is nothing in which the upstreams are really interested in. Therefore most of our .pc files are created inside the ebuild. Eventually they will find their way back upstream, but currently this is something gentoo specific, it's about choices. The eclass should just be a reduction of redundant code. And of course its not meant to be a replacement to upstream work on packages with sane buildsystems. Its just a last resort for corner cases like our lapack/blas stuff, which do not have any reasonable option. I hope this clears my intention and makes it reasonable to have this eclass, justin 1) https://github.com/andyspiros/numbench/wiki http://andyspiros.wordpress.com/category/google-summer-of-code/ 2) http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo/xml/htdocs/proj/en/miniconf/presentations/miniconf-2012-numbench-spiros.pdf
signature.asc
Description: OpenPGP digital signature
