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 |