On 7 January 2012 22:44, Bo Ørsted Andresen <[email protected]> wrote: > I suppose an exlib could use something like: > > myexparam multibuild_options="multibuild_c: 32 64" > MYOPTIONS="( $(exparam multibuild_options) )"
Again, I'm not sure if it makes sense to make it as generic as that - other things than C will probably add the options in their own language-specific exlib anyway, and they'll need to have their own rules for declaring which versions of the language the package is compatible with. I'm starting to think we should maybe have an exlib specifically for C multilib. > The reason we haven't done it before is because adding options in an > exlib can't be overridden in special cases. I.e. without an exparam. > > And also adding the options to MYOPTIONS wasn't any harder than > requiring an extra exlib. I suppose that changes if it starts adding > restrictions to the options. I'm a bit unhappy with duplicating the list of ABIs in every library exheres. MIPS has 3, and for x86 there's http://en.wikipedia.org/wiki/X32_ABI (an exquisitely stupid name, but it seems like a good idea in principle), so if we want to support those in future we'd need to edit every exheres the way it is now. > We originally decided against this because we really wanted people to > add support for out-of-tree builds instead by discouraging multiunpack. That's fair enough if it really is possible to do out-of-tree builds, but for some packages that isn't feasible. > If we don't set LD in the profiles because of this, it means users also > can't sensibly specify LD on their own. Packages handle it > inconsistently. By setting it we hit those kinds of issues consistently > and override it (usually with LD="${CC}") where needed. That's a fair point. > We originally wanted to test having Paludis add those (?) dependencies > to everything automagically. With (?) it would apply only to packages > that have multibuild options. > > If we're never going to do that it makes sense to convert to (-) though. > But some of the current (?) dependencies really haven't been > multibuildified nor should they be, so whoever converts it would need to > fix those properly. Have we decided that we're definitely not doing the automatic adding? I think I'd be in favour of not doing it, specifically because it requires relaxing the dep checking in this way. _______________________________________________ Exherbo-dev mailing list [email protected] http://lists.exherbo.org/mailman/listinfo/exherbo-dev
