Re: [gentoo-dev] [ANNOUNCE] New eselect modules for blas, cblas, lapack

[Danny van Dyk]

Hi Donnie,

Am Freitag, 26. Mai 2006 05:20 schrieb Donnie Berkholz:
> With great pleasure, I announce the testing release of new eselect
> modules for BLAS, CBLAS and LAPACK implementations. You may say, "But
> we already have 'eselect blas' and 'eselect lapack,' Donnie! What are
> you thinking?" In reply, I would say, "The current eselect modules
> have many limitations."
And rightfully so! :-) Thanks for all your efforts here, it is really 
appreciated.

> One of the main problems with the existing setup is that available
> implementations are hardcoded into the modules rather than being
> autodetected from the system. This just doesn't scale well, and it
> ties upgrades and changes to BLAS/LAPACK/whatever into a required
> update of eselect.
>
> A point of disagreement between Danny van Dyk (Kugelfang) and myself
> is handling systems with multiple libdirs (e.g., AMD64). To
> understand our quandary, you'll first need to understand how the new
> modules work.
>
> My opinion is that if you want to switch implementations, you should
> be warned if any available libdir failed to switch to the
> implementation you selected. The tradition of Unix tools says they
> should be silent when everything works as expected and be loud on
> errors.
Right, emphasis on "error" here.

> Not switching for all libdirs when you explicitly said you wanted to
> switch your whole system is an error, even if the implementation
> isn't currently available for all your libdirs. Anything else will
> require adding hackish special cases to the code and doesn't fit with
> my model of how the modules should work.
See, i don't see the explicity of 'all libdirs' when not specifying any 
libdirs at all. In my eyes, 'eselect blas set acml' doesn't mean: 
'switch to acml in _all libdirs_', but 'switch to acml in _all libdirs 
it is installed to_.
>
> Danny thinks instead that the modules should list all libdirs for
> which the implementation was changed rather than warn about libdirs
> for which it wasn't. This opposes the Unix philosophy. Danny also
> thinks that the modules should silently fail when no implementations
> are available for a certain libdir when the user wants to switch the
> whole system. I disagree and think the modules should warn the user.

>
> In addition, Danny brings up a specific subprofile on amd64 called
> no-symlink, in which lib32, lib, and lib64 are all directories rather
> than symlinks. He says the 'lib' directory is only for
> arch-independent (ABI-independent) files, so we should also add a
> special case for that. Knowing my hatred of special casing, you may
> guess I disagree.
Motivation for this special casing is, that this warning would appear 
any time the user doesn't specify the libdirs, and there is nothing the 
user can do against it. There just is no way to install any 
blas/cblas/lapack implementation to /usr/lib on no-symlink profile.
I'm strongly against warnings that can't be turned off. Futher, this 
would be no additional special case, it can easily be merged with the 
previous special casing: only swithch on libdir that the package is 
installed to.

> The main issue needing resolution is whether to warn on failures to
> switch given libdirs when trying to switch the whole system, or
> whether to say which successfully switched. One way is the Unix
> philosophy, and the other way is ... something else.
:-)

> Without further ado, you may get all the ported BLAS/CBLAS/LAPACK
> implementations as well as the new eselect modules from my overlay
> [1]. They will remain there until more widespread testing is
> completed.
Donnie: RFC: should ACML be modified to install both ABIs? (i.e. x86 and 
amd64). I'd say no, as no packages but glibc/gcc/binutils currently do 
that.

Danny
-- 
Danny van Dyk <kugelfang@g.o>
Gentoo/AMD64 Project, Gentoo Scientific Project
-- 
gentoo-dev@g.o mailing list