[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    Re: [gentoo-dev] blas .pc files (was RFC: new eclass - pkgconfig.eclass)
From:       Justin <jlec () gentoo ! org>
Date:       2012-11-29 20:45:43
Message-ID: 50B7C977.7000605 () gentoo ! org
[Download RAW message or body]


On 29.11.2012 21:11, Ralph Sennhauser wrote:
> On Thu, 29 Nov 2012 17:09:34 +0100
> justin <jlec@gentoo.org> wrote:
> 
>> On 29/11/12 16:51, Ian Stakenvicius wrote:
> [...]
>>> ..ok remind me again what the .pc files provide you?  this is so
>>> that you can have slotted blas providers and various packages can
>>> choose their preferred one instead of having to use the eselected
>>> one?  or...
>>>
>>
>> Not exactly.
>> The user can choose for each package newly by eselecting the wanted
>> implementation. This is the user side. From the pm side we ensure that
>> the choice is really respected by linking against package specific
>> names [1] instead of the generic ones e.g. libblas.so. And this can be
>> achieved in an easy way by using pkg-config.
>>
>> justin
>>
>> 1)
>>  # eselect blas set atlas-threads
>>  # pkg-config --libs blas
>> -lptf77blas -lm -latlas -lpthread
>>
>> # eselect blas set reference
>> # pkg-config --libs blas
>> -lrefblas
>>
> 
> This immediately bears the following questions:
> 
> * How do you ensure the linked against implementation doesn't get
> depcleaned? revdep-rebuild maybe?

portage handles this fine.

> 
> * How do you let users configure the implementation to be used on a per
> package basis? Interrupt an emerge world to set the appropriate
> implementation for the next few packages?
> 

The Standard user will get reference implementation and has no problem.
Setting individual implementation on per package basis needs to be
considered as they-know-what-they-are-doing. Otherwise you don't know
which implementation to choose .


["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]