Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-dev
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-dev@g.o
From: Thomas Sachau <tommy@g.o>
Subject: Re: The Python problem
Date: Mon, 27 Jun 2011 22:57:05 +0200
Dirkjan Ochtman wrote:
> On Mon, Jun 27, 2011 at 15:08, Fabian Groffen <grobian@g.o> wrote:
>> On 27-06-2011 14:28:34 +0200, Dirkjan Ochtman wrote:
>> It would be nice when a similar technique could be implemented only
>> once, in a consistent way.  In a way, multilib-portage can be considered
>> equal to one of the objectives of the python (and ruby) eclass:
>> multiple times compiling and installing for different ABIs.
> 
> Yeah, but it'd be nice not to have to compile subversion three times
> just because we want the python bindings installed in three different
> Python environments.

You wont be able to prevent this with a general solution, only with some specialized solution inside
the build, if you really want and need that.
Currently, if you want python bindings for three different python environments, you will have to
build everything for all three python environments, even if you only need a subset. Moving to a
similar system like ruby, in the long term maybe based on a general PM-implementation, would users
at least allow to select the targets per package and not just global like now.

> On Mon, Jun 27, 2011 at 17:53, Petteri R├Ąty <betelgeuse@g.o> wrote:
>> I like the ruby approach for the reason that it doesn't require users to
>> run update scripts like python-updater.
>
> Sure, but if that means the developers now have to bump every package
> in the tree when a new version of Python comes out, I'm not sure
> that's the best trade-off.

For multilib-portage, packages dont need to define the possible cross-compile targets, they have all
possible options in the USE flag list. Something similar could be done for this case:

Simplified: Define the range of supported python versions in the dependency section and allow the
eclass or PM to sort out the rest (you of course need a bit more, but this should be the only
required dependency/python-version related part).

Attachment:
signature.asc (OpenPGP digital signature)
Replies:
Re: The Python problem
-- Arfrever Frehtes Taifersar Arahesis
References:
The Python problem
-- Dirkjan Ochtman
Re: The Python problem
-- Fabian Groffen
Re: The Python problem
-- Dirkjan Ochtman
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: The Python problem
Next by thread:
Re: The Python problem
Previous by date:
Re: The Python problem
Next by date:
Re: The Python problem


Updated Jun 29, 2012

Summary: Archive of the gentoo-dev mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.