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