Re: [gentoo-dev] RFC: new eclass - pkgconfig.eclass

[justin]

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