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 -- Thomas Sachau Gentoo Linux Developer
signature.asc
Description: OpenPGP digital signature
