Well =)

This will be killer feature in gentoo =P
Also what about more complex arhes than ia32? like mips of ppc?

PS also with this feature seems amd64 and x86 can be merged in one
arch (like it was done in kernel) since its only abis of ia32

2010/12/1 Thomas Sachau <to...@gentoo.org>:
> 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
>
>



-- 
Best Regards,
Alexey 'Alexxy' Shvetsov
Petersburg Nuclear Physics Institute, Russia
Department of Molecular and Radiation Biophysics
Gentoo Team Ru
Gentoo Linux Dev
mailto:alexx...@gmail.com
mailto:ale...@gentoo.org
mailto:ale...@omrb.pnpi.spb.ru

Reply via email to