Gentoo Archives: gentoo-dev

From: Arfrever Frehtes Taifersar Arahesis <Arfrever@g.o>
To: Gentoo Development <gentoo-dev@l.g.o>
Subject: Re: [gentoo-dev] Support for multiple ABIs (for Python modules etc.)
Date: Fri, 07 Aug 2009 05:27:17
Message-Id: 200908070729.08558.Arfrever@gentoo.org
In Reply to: Re: [gentoo-dev] Support for multiple ABIs (for Python modules etc.) by Ciaran McCreesh
1 2009-08-01 20:10:49 Ciaran McCreesh napisaƂ(a):
2 > On Sat, 25 Jul 2009 12:28:44 +0200
3 > Arfrever Frehtes Taifersar Arahesis <Arfrever@g.o> wrote:
4 > > I would like to present the plan of support for multiple ABIs. It
5 > > should be sufficient for Python modules and might be also appropriate
6 > > for some other ABI types (e.g. for Ruby modules).
7 >
8 > How do you plan to handle the intersection of ABIs? What if you have to
9 > build or depend upon a Python module for both 32 and 64 bit ABIs, and
10 > for both 2.5 and 2.6? What if you have a package that provides both
11 > Ruby and Python code, where the two ABIs are independent rather than a
12 > product?
13
14 The proposition already handles these cases. Please describe in more details what you don't
15 understand.
16
17 > > 4.1. Implicitly specified ABI dependencies. During calculation of
18 > > dependencies of given package, Portage will verify if all
19 > > dependencies, which use given ABI type, have been built with enabled
20 > > support for these ABIs, which are enabled for given package.
21 >
22 > How do you say "I need only a single ABI for this, even though it looks
23 > like I need every ABI I'm built with"? For example, if your Python
24 > module, being built for 2.5 and 2.6, runs (but does not use in a
25 > library sense) a Python program that comes as part of a Python package
26 > that is buildable with multiple ABIs?
27
28 In such case a Python package, which is a dependency of another Python package, shouldn't
29 be marked as supporting multiple Python ABIs. But anyway I suggest the following syntax:
30 category/package_name{python[*]}
31
32 > > 4.2. Explicitly specified ABI dependencies. {,P,R}DEPEND variables
33 > > will support specifying ABI dependencies in explicit way.
34 > > {,P,R}DEPEND variables will also support ABI conditionals. I suggest
35 > > using {ABI_type[comma-delimited values]} syntax, but it can be
36 > > changed.
37 >
38 > I think we're trying to avoid introducing new special characters if we
39 > can get away with using existing ones. You can overload [] and existing
40 > conditionals if you're careful.
41
42 The syntax suggested by me looks better for this purpose.
43
44 > Having said that, you can probably do everything you described slightly
45 > less elegantly just using things that're already in EAPI 3.
46
47 Not everything.
48
49 --
50 Arfrever Frehtes Taifersar Arahesis

Attachments

File name MIME type
signature.asc application/pgp-signature