El mié, 01-12-2010 a las 19:57 +0100, Thomas Sachau escribió: > Hi, > > i have already written about this some months ago and updated the code in > relation to the comments > especially from vapier. > > Basicly, it does now first set abi-specific vars (like CC, CFLAGS and others > (setup_abi_env function > in bin/auto-multilib.sh contains the full list), then does build the package > as usual. If additional > ABIs are requested, it checks after src_install, if there are possible > ABI-specific files (libs, > headers or, if requested for every ABI, also binaries). If those are found, > the image dir is moved > away and a new run is started, where again at start abic-specific vars are > set and then the complete > src* phases are run. Once all requested ABIs are done, the image dirs are > merged into the final > image dir. The following pkg_* phases are each running for every ABI. > Currently, only different libs and headers are installed by default, binaries > will be the ones from > the default ABI, unless you tell portage to install binaries for all > requested ABIs, in which case a > wrapper will select the ABI-specific binary depending on the environment. > The current implementation uses a USE-dep like way internally to satisfy the > needed dependencies, so > that e.g. 32bit libs on a 64bit platform get their required dependencies > built with 32bit libs > installed. For the rare case, where the crosscompile does fail and there is > only a need for the > binary and no linking against the libs, i have also a var, which disables > this auto-dependency > calculation for specified packages. > > For the user interface, portage shows a USE_EXPANDed var, which contains the > avaidable ABIs, as an > example for "emerge -pv media-libs/jpeg": > > [ebuild R ] media-libs/jpeg-8b USE="-static-libs" MULTILIB_ABI="amd64 > x86" > > Those ABIs can be handled like USE flags, in this case, they are > "multilib_abi_amd64" and > "multilib_abi_x86", so you can use those USE flags to enable/disable specific > possible ABIs either > globally or per package. > > The basic implementation can be used without changing main tree ebuilds or > eclasses, but e.g. for > the replacement of emul-* libs, this will require EAPI-support for > ABI-specific USE-deps for > binary-only packages or packages like wine. > > I would first like to see, if there are any bigger concerns especially with > the implementation and > how it is supposed to work. > > If there are no such concerns or if they have been resolved, i would like to > request some help for > the documentation and PMS-patch related work. > > For install instructions, please have a look at [1], the code can be found in > the multilib branch of > portage git repo at [2]. > > While i did not yet get to the implementation of it, i would also like to > propose something similiar > for languages (like python, ruby or others), so that the basic parts are > inside the PM and we can > drop the different ways of implementation and allow users a much more > fine-grained control on a per > package base (in relation to the current way python eclass based very complex > implementation works). > > [1]: http://github.com/sjnewbury/multilib-overlay/tree/portage-multilib/doc > [2]: > http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=shortlog;h=refs/heads/multilib >
Nice to see progress on this, it's a headache to have to make emul packages grow forever when any application (usually wine) requires it :-S, and this would allow much more flexibility Thanks a lot :-D
signature.asc
Description: This is a digitally signed message part
