2009-08-01 20:10:49 Ciaran McCreesh napisaĆ(a): > On Sat, 25 Jul 2009 12:28:44 +0200 > Arfrever Frehtes Taifersar Arahesis <arfre...@gentoo.org> wrote: > > I would like to present the plan of support for multiple ABIs. It > > should be sufficient for Python modules and might be also appropriate > > for some other ABI types (e.g. for Ruby modules). > > How do you plan to handle the intersection of ABIs? What if you have to > build or depend upon a Python module for both 32 and 64 bit ABIs, and > for both 2.5 and 2.6? What if you have a package that provides both > Ruby and Python code, where the two ABIs are independent rather than a > product?
The proposition already handles these cases. Please describe in more details what you don't understand. > > 4.1. Implicitly specified ABI dependencies. During calculation of > > dependencies of given package, Portage will verify if all > > dependencies, which use given ABI type, have been built with enabled > > support for these ABIs, which are enabled for given package. > > How do you say "I need only a single ABI for this, even though it looks > like I need every ABI I'm built with"? For example, if your Python > module, being built for 2.5 and 2.6, runs (but does not use in a > library sense) a Python program that comes as part of a Python package > that is buildable with multiple ABIs? In such case a Python package, which is a dependency of another Python package, shouldn't be marked as supporting multiple Python ABIs. But anyway I suggest the following syntax: category/package_name{python[*]} > > 4.2. Explicitly specified ABI dependencies. {,P,R}DEPEND variables > > will support specifying ABI dependencies in explicit way. > > {,P,R}DEPEND variables will also support ABI conditionals. I suggest > > using {ABI_type[comma-delimited values]} syntax, but it can be > > changed. > > I think we're trying to avoid introducing new special characters if we > can get away with using existing ones. You can overload [] and existing > conditionals if you're careful. The syntax suggested by me looks better for this purpose. > Having said that, you can probably do everything you described slightly > less elegantly just using things that're already in EAPI 3. Not everything. -- Arfrever Frehtes Taifersar Arahesis
signature.asc
Description: This is a digitally signed message part.