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. For example, if you know some packages have to be built with the same blas implementation to work properly together, you can do USE deps which is not possible with eselect and I am sure this is not the only case. -- Gilles Dartiguelongue <e...@gentoo.org> Gentoo
