public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Gilles Dartiguelongue <eva@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] RFC: new eclass - pkgconfig.eclass
Date: Thu, 29 Nov 2012 17:54:58 +0100	[thread overview]
Message-ID: <1354208098.15387.49.camel@gilles.gandi.net> (raw)
In-Reply-To: <50B725B4.6090603@gentoo.org>

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 <eva@gentoo.org>
Gentoo



  reply	other threads:[~2012-11-29 16:55 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-28 21:49 [gentoo-dev] RFC: new eclass - pkgconfig.eclass Justin
2012-11-28 22:16 ` hasufell
2012-11-29  2:51   ` Chí-Thanh Christopher Nguyễn
2012-11-28 22:21 ` Michał Górny
2012-11-29  1:26   ` Richard Yao
2012-11-29  1:47     ` [gentoo-dev] " Duncan
2012-11-29 13:35     ` [gentoo-dev] " Ian Stakenvicius
2012-11-28 23:00 ` Christoph Junghans
2012-11-29  1:14 ` Mike Frysinger
2012-11-29  7:52   ` justin
2012-11-29  8:48     ` Gilles Dartiguelongue
2012-11-29  9:07       ` justin
2012-11-29 16:54         ` Gilles Dartiguelongue [this message]
2012-11-29 17:00           ` justin
2012-11-29  8:52     ` Michał Górny
2012-11-29  9:29       ` justin
2012-11-29  7:20 ` Rémi Cardona
2012-11-29 13:16 ` hasufell
2012-11-29 14:56   ` justin
2012-11-29 15:51     ` [gentoo-dev] blas .pc files (was RFC: new eclass - pkgconfig.eclass) Ian Stakenvicius
2012-11-29 16:09       ` justin
2012-11-29 16:27         ` hasufell
2012-11-29 16:44         ` Ian Stakenvicius
2012-11-29 20:11         ` Ralph Sennhauser
2012-11-29 20:45           ` Justin
2012-11-29 16:23     ` [gentoo-dev] RFC: new eclass - pkgconfig.eclass hasufell
2012-11-29 16:57       ` justin
2012-11-30  4:37   ` [gentoo-dev] " Duncan
2012-11-30  7:36     ` Justin
2012-12-01 20:35     ` Mike Frysinger
2012-11-29 17:04 ` [gentoo-dev] " justin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1354208098.15387.49.camel@gilles.gandi.net \
    --to=eva@gentoo.org \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox