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.

justin

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to