public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
* [gentoo-dev] Eclasses for BLAS and Lapack
@ 2017-12-04  9:45 Dominik Schmidt
  2017-12-04 10:05 ` Benda Xu
  0 siblings, 1 reply; 2+ messages in thread
From: Dominik Schmidt @ 2017-12-04  9:45 UTC (permalink / raw
  To: gentoo-dev

Hi there

Gentoo does not yet have a (proper) way of selecting a BLAS or Lapack implementation at compile time.
Hence I wrote two eclasses, which can be found in my fork of the science overlay:

* https://github.com/Doeme/sci/blob/blas_lapack_eclass/eclass/blas.eclass
* https://github.com/Doeme/sci/blob/blas_lapack_eclass/eclass/lapack.eclass

They introduce blas_* and lapack_* USE flags. Ebuilds can specify BLAS_COMPAT and LAPACK_COMPAT, deciding what USE flags get added to IUSE and what (conditional) dependencies to DEPEND and RDEPEND.
pkgconfig is used to enforce the USE flag selected implementation during compilation.

But they do _not_ enforce library consistency at dynamic link time, e.g.
when Program A (dynamically) links to BLAS B1 and to Library C, which in turn links to BLAS B2, then executing A will result in symbol clashes and either B1 or B2 will overwrite the others symbols.

Dynamic linking consistency has been implemented at some point with a BLAS_USEDEP approach similar to python, i.e. ebuild A propagates a USE constraint to its dependencies via foo-bar/baz[blas_$impl?,blas_$impl2?,...], but there are issues with this. For example, packages might not depend on BLAS themselves but on two libraries which do depend on BLAS. There we would be unable to enforce a consistent implementation down the dependency graph.
Also, the complexity for writing ebuilds with this approach explodes, since you have to look up for every package whether they depend on BLAS and, if so, add the ${BLAS_USEDEP} to their USE constraints (and do the same for LAPACK).

The current eselect-mechanism would have to be left in place, since we probably want to provide a global default for non-portage built software.

Additional discussion on the sci-overlay GitHub issue: https://github.com/gentoo/sci/issues/805
The corresponding bugreport: https://bugs.gentoo.org/632624

Any commentary and improvements would be greatly appreciated.
In fact, I do have a question at this point: I'm not sure whether to enforce a particular EAPI or not, and if so, which one.

Thank you for your attention,
Doeme


^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [gentoo-dev] Eclasses for BLAS and Lapack
  2017-12-04  9:45 [gentoo-dev] Eclasses for BLAS and Lapack Dominik Schmidt
@ 2017-12-04 10:05 ` Benda Xu
  0 siblings, 0 replies; 2+ messages in thread
From: Benda Xu @ 2017-12-04 10:05 UTC (permalink / raw
  To: gentoo-dev

Dear Fellows, and thanks Dominik,

Dominik Schmidt <schmidom@student.ethz.ch> writes:

> Gentoo does not yet have a (proper) way of selecting a BLAS or Lapack
> implementation at compile time.  Hence I wrote two eclasses, which can
> be found in my fork of the science overlay:
>
> * https://github.com/Doeme/sci/blob/blas_lapack_eclass/eclass/blas.eclass
> * https://github.com/Doeme/sci/blob/blas_lapack_eclass/eclass/lapack.eclass
>
> [...]

The Science Team is very interested in this approach as it solves a
fundamental problem of BLAS[1] selection in Gentoo.  After the review,
we plan to land the 2 eclass-es into Gentoo main repository and start
ebuilds migration.

Your comments on the implementation are crucial to realize that.

Thanks!
Benda

1. Basic Linear Algebra Subprograms


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2017-12-04 10:06 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-12-04  9:45 [gentoo-dev] Eclasses for BLAS and Lapack Dominik Schmidt
2017-12-04 10:05 ` Benda Xu

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox