On Sun, 27 Jan 2013 14:40:35 +0100 Thomas Sachau <to...@gentoo.org> wrote:
> Michał Górny schrieb: > > Hello, > > > > Following all the suggestions from Alexis Ballier, I have reworked > > the code to remove multiple points of failure. I have also rebased it > > on the common multilib-build eclass concept, and updated amd64 > > no-multilib & x86 profiles as well. > > > > Key points: > > > > 1. The list of available flags and corresponding ABIs is now stored > > in a single variable. Adding a new ABI is as simple as adding > > a value to that variable (+ profiles). > > > > 2. All ABIs are validated against $(get_all_abis) list. This guarantees > > that we check only the flags proper for the arch. > > > > 3. The USE_EXPAND is visible only on amd64 multilib profile. However, > > it is also available on non-multilib amd64 & x86, with all flags > > masked except for the default one which is force-enabled. > > > > The last point means that x86 binary packages (skype) can have > > dependencies as simple as: > > > > dev-libs/libfoo[abi_x86_32] > > > > which would be valid both for amd64 multilib & x86. > > > > > > > > Lets see, if i understand your plan right, without reading all your diffs: > > 1. you currently support amd64/multilib and show same flags on > amd64/no-multilib and x86 to avoid duplicating the dependency list? If > yes, will this be extended to general support for all multilib arches, > only on request for specific arches or not at all? Yes and no. I do force the flags to enabled but they are hidden from the end-user using USE_EXPAND. I don't mind supporting any arch which likes to enable multilib. It's mostly about adding the flags to proper profiles and to the list in the eclass. But I'd rather rely on arch teams to decide on how to proceed with the particular arches. > 2. How do you handle other abi-specific files like headers or binaries > and cases like binaries with abi-specific content? Is it possible to > preserve them for all requested abis or to preserve them for an > non-default abi? The idea is that all non-libdir stuff shall be handled properly by ebuilds. The eclass is meant to support the most common and simplest case, proper and efficient handling of deviations can't be controlled centrally. -- Best regards, Michał Górny
signature.asc
Description: PGP signature
