Pacho Ramos schrieb: > El dom, 23-09-2012 a las 13:52 +0200, Thomas Sachau escribió: >> Pacho Ramos schrieb: >>> El dom, 23-09-2012 a las 11:56 +0200, Michał Górny escribió: >>>> On Sun, 23 Sep 2012 11:07:30 +0200 >>>> Thomas Sachau <to...@gentoo.org> wrote: >>>> >>>>> Matt Turner schrieb: >>>>>> On Sat, Sep 22, 2012 at 2:24 PM, Michał Górny <mgo...@gentoo.org> wrote: >>>>>>> It is a simple eclass using autotools out-of-source builds to build >>>>>>> packages for multiple ABIs when multilib is supported. >>>>>> >>>>>> Thanks a lot, Michał! This looks good to me. >>>>>> >>>>>>> Use case: xorg packages, ask Matt. >>>>>> >>>>>> So the idea is that users want up-to-date 32-bit drivers for games and >>>>>> WINE. The emul- packages aren't a very good solution for a number of >>>>>> reasons. >>>>>> >>>>>> I'd like to add multilib USE flags to Mesa and thus its dependencies. >>>>>> I realized that almost everything in x11-libs/ could be converted very >>>>>> easily, which would allow us to get rid of emul-linux-x86-xlibs in >>>>>> addition to emul-linux-x86-opengl. >>>>>> >>>>>> >>>>> >>>>> This looks like a shortened duplication of a subset of multilib-portage >>>>> features. While this wont hurt multilib-portage (since it does exclude >>>>> most actions on ebuilds with USE=multilib), it will mean a rewrite for >>>>> many ebuilds, which then again need another rewrite (or more likely >>>>> revert), when multilib-portage is accepted in a future EAPI. >>>> >>>> s/when/if/ >>>> >>>>> So i would prefer some help/support with multilib-portage to get it >>>>> accepted sooner, instead of this additional workaround for a subset of >>>>> packages. >>>> >>>> I prefer the simpler solution. >>>> >>>>> P.S.: I know, that users, who want up-to-date 32bit drivers for games >>>>> and wine do use multilib-portage, so we already have a working solution >>>>> for this issue. >>>> >>>> They will no longer have to do that. >>>> >>> >>> I would prefer if eclass way could be extended to packages not using >>> autotools too, otherwise, we will still need emul packages for, for >>> example, qt libs. If that would be possible via eclass, maybe >>> multilib-portage wouldn't be needed but, if not, we will still need it >>> and, then, would be nice if this inclussion for autotools packages >>> wouldn't cause more problems to get the "strong" solution land in the >>> "near" future :/ >>> >>> The simpler solution (eclass) looks fine to me, but it would need to be >>> extended to more packages than autotools based ones to let it replace >>> portage-multilib/emul packages >>> >> >> you mean something like this one? >> >> https://github.com/sjnewbury/multilib-overlay/blob/80c9fd20cfd05481ac19edcadd56ad5e578a8930/eclass/multilib-native.eclass >> >> That was the original eclass allowing cross-compile support, but >> required ebuilds to inherit it. multilib-portage is based on this, but >> does not require to modify the ebuilds themselves. >> > > Yes, that is what I meant... but I don't find hard to modify ebuilds to > inherit it :/ >
It is not hard by itself to inherit an eclass. There is just the limitation, that occurs with an eclass, e.g.: -the one from mgorny only does it for autotools based ebuilds only and even there only for libraries, headers and binaries are not done. While one may create the same for cmake based ones, those are still only for a subset of packages, since not all do use autotools/cmake or are satisfied with a libs only solution -the multilib-native eclass does extend it way more, but still has its limitations, e.g. what happens with a new target ABI (like x32 on the amd64 profile) or how are dependencies handled? multilib-portage is the answer to those limitations, since it does work for any target with multilib cross-compile support, can handle things like the dependencies internally and can even work on not prepared/modified ebuilds. So before i invest even more time in getting this official, we should better get to some conclusion, if we either go the route with eclass based multilib cross-compile support with its limitations or if we move this up to the package manager level. -- Thomas Sachau Gentoo Linux Developer
signature.asc
Description: OpenPGP digital signature
