| 1 |
On 29/11/12 09:48, Gilles Dartiguelongue wrote: |
| 2 |
> Le jeudi 29 novembre 2012 à 08:52 +0100, justin a écrit : |
| 3 |
>> Currently we have an eselect module to switch between different |
| 4 |
>> implementations by setting /usr/lib/lib[blas,lapack].so to the selected |
| 5 |
>> implementation. |
| 6 |
>> |
| 7 |
>> This has two drawbacks, which some of you might already of hit: |
| 8 |
>> 1. They seem to be not completely API/ABI compatible (I don't which one |
| 9 |
>> is correct here. And please don't be nitpicking on this point). So |
| 10 |
>> switching would mean recompilation of all packages linked against it |
| 11 |
>> before, otherwise you might get runtime errors. This takes time and |
| 12 |
>> triggers point 2. |
| 13 |
>> |
| 14 |
>> 2. As andy showed we should stick with specific implementations for |
| 15 |
>> specific tasks. The current way flattens this out to be optimal for some |
| 16 |
>> and suboptimal for others. |
| 17 |
>> |
| 18 |
>> Now, there has been a lot of effort around Andy and Sebastien to solve |
| 19 |
>> this problem. The solution is simple: don't install any libblas.so or |
| 20 |
>> liblapack.so in libdir, but instead make the pkg-config module |
| 21 |
>> eselectable and force packages to used pkg-config. Nearly (I think its |
| 22 |
>> 100%) of the packages in the tree already use pkg-config to detect |
| 23 |
>> blas/lapack. |
| 24 |
> |
| 25 |
> I think I understand the problem now. You should not patch/generate .pc |
| 26 |
> files but install them to an implementation specific subdirectory. |
| 27 |
> |
| 28 |
|
| 29 |
If I get you correctly you are assuming that we have pkgconfig files for |
| 30 |
all implementations coming from upstreams. That's not correct, we have |
| 31 |
nearly none. So we need to generate them our own. And yes this need to |
| 32 |
be sent upstream. |
| 33 |
|
| 34 |
That's the reason for the eclass. |
| 35 |
|
| 36 |
> That way, you just have to append that path to PKGCONFIG_PATH when |
| 37 |
> configuring your package using blas and you should be able to |
| 38 |
> transparently select which implementation to get without further |
| 39 |
> patching of either upstream or downstream packages. |
| 40 |
> |
| 41 |
|
| 42 |
This would mean that the pkg maintainer decides the implementation. But |
| 43 |
we leave this choice to the user which works fine. And we have a working |
| 44 |
eselect based solution. |
| 45 |
|
| 46 |
justin |
Archives