| 1 |
On 29/11/12 16:51, Ian Stakenvicius wrote: |
| 2 |
> On 29/11/12 09:56 AM, justin wrote: |
| 3 |
> |
| 4 |
>> Standard autotools based packages always use |
| 5 |
> |
| 6 |
>> --with-blas= |
| 7 |
> |
| 8 |
>> so it is pretty simple for us to make it to |
| 9 |
> |
| 10 |
>> --with-blas="$(pkg-config --libs blas)" |
| 11 |
> |
| 12 |
>> same thing goes for cmake and |
| 13 |
> |
| 14 |
>> -DBLAS_LIBRARIES="$(pkg-config --libs blas)" |
| 15 |
> |
| 16 |
>> This game has been played since ever, because blas/lapack are |
| 17 |
>> bundled in more then 80% of the packages using it. So we are used |
| 18 |
>> to patch them to use system libs. So why not making our lives |
| 19 |
>> easier by having a pkg-config option? |
| 20 |
> |
| 21 |
>> justin |
| 22 |
> |
| 23 |
> |
| 24 |
> ..ok remind me again what the .pc files provide you? this is so that |
| 25 |
> you can have slotted blas providers and various packages can choose |
| 26 |
> their preferred one instead of having to use the eselected one? or... |
| 27 |
> |
| 28 |
> |
| 29 |
> |
| 30 |
> |
| 31 |
> |
| 32 |
|
| 33 |
Not exactly. |
| 34 |
The user can choose for each package newly by eselecting the wanted |
| 35 |
implementation. This is the user side. From the pm side we ensure that |
| 36 |
the choice is really respected by linking against package specific names |
| 37 |
[1] instead of the generic ones e.g. libblas.so. And this can be |
| 38 |
achieved in an easy way by using pkg-config. |
| 39 |
|
| 40 |
justin |
| 41 |
|
| 42 |
1) |
| 43 |
# eselect blas set atlas-threads |
| 44 |
# pkg-config --libs blas |
| 45 |
-lptf77blas -lm -latlas -lpthread |
| 46 |
|
| 47 |
# eselect blas set reference |
| 48 |
# pkg-config --libs blas |
| 49 |
-lrefblas |
Archives