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

[justin]

On 29/11/12 17:54, Gilles Dartiguelongue wrote:
> Le jeudi 29 novembre 2012 à 10:07 +0100, justin a écrit :
>> On 29/11/12 09:48, Gilles Dartiguelongue wrote:
>>> Le jeudi 29 novembre 2012 à 08:52 +0100, justin a écrit :
>>>> 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.
>>>
>>> I think I understand the problem now. You should not patch/generate .pc
>>> files but install them to an implementation specific subdirectory.
>>>
>>
>> If I get you correctly you are assuming that we have pkgconfig files for
>> all implementations coming from upstreams. That's not correct, we have
>> nearly none. So we need to generate them our own. And yes this need to
>> be sent upstream.
>>
>> That's the reason for the eclass.
>>
>>> That way, you just have to append that path to PKGCONFIG_PATH when
>>> configuring your package using blas and you should be able to
>>> transparently select which implementation to get without further
>>> patching of either upstream or downstream packages.
>>>
>>
>> This would mean that the pkg maintainer decides the implementation. But
>> we leave this choice to the user which works fine. And we have a working
>> eselect based solution.
>
> No, this means you can then use USE flags to select it which is package
> manager controlled and usually easier to deal with than eselected stuff.
>

So you mean adding a USE for each implementation to each package which
is using one fo blas/cblas/lapack/clapack/lapacke and all the others
which I forgot?

And in the end, we still would need pc files, because version A of
implementation X could have different library names then version B.