1 |
Hi, |
2 |
|
3 |
i have already written about this some months ago and updated the code in relation to the comments |
4 |
especially from vapier. |
5 |
|
6 |
Basicly, it does now first set abi-specific vars (like CC, CFLAGS and others (setup_abi_env function |
7 |
in bin/auto-multilib.sh contains the full list), then does build the package as usual. If additional |
8 |
ABIs are requested, it checks after src_install, if there are possible ABI-specific files (libs, |
9 |
headers or, if requested for every ABI, also binaries). If those are found, the image dir is moved |
10 |
away and a new run is started, where again at start abic-specific vars are set and then the complete |
11 |
src* phases are run. Once all requested ABIs are done, the image dirs are merged into the final |
12 |
image dir. The following pkg_* phases are each running for every ABI. |
13 |
Currently, only different libs and headers are installed by default, binaries will be the ones from |
14 |
the default ABI, unless you tell portage to install binaries for all requested ABIs, in which case a |
15 |
wrapper will select the ABI-specific binary depending on the environment. |
16 |
The current implementation uses a USE-dep like way internally to satisfy the needed dependencies, so |
17 |
that e.g. 32bit libs on a 64bit platform get their required dependencies built with 32bit libs |
18 |
installed. For the rare case, where the crosscompile does fail and there is only a need for the |
19 |
binary and no linking against the libs, i have also a var, which disables this auto-dependency |
20 |
calculation for specified packages. |
21 |
|
22 |
For the user interface, portage shows a USE_EXPANDed var, which contains the avaidable ABIs, as an |
23 |
example for "emerge -pv media-libs/jpeg": |
24 |
|
25 |
[ebuild R ] media-libs/jpeg-8b USE="-static-libs" MULTILIB_ABI="amd64 x86" |
26 |
|
27 |
Those ABIs can be handled like USE flags, in this case, they are "multilib_abi_amd64" and |
28 |
"multilib_abi_x86", so you can use those USE flags to enable/disable specific possible ABIs either |
29 |
globally or per package. |
30 |
|
31 |
The basic implementation can be used without changing main tree ebuilds or eclasses, but e.g. for |
32 |
the replacement of emul-* libs, this will require EAPI-support for ABI-specific USE-deps for |
33 |
binary-only packages or packages like wine. |
34 |
|
35 |
I would first like to see, if there are any bigger concerns especially with the implementation and |
36 |
how it is supposed to work. |
37 |
|
38 |
If there are no such concerns or if they have been resolved, i would like to request some help for |
39 |
the documentation and PMS-patch related work. |
40 |
|
41 |
For install instructions, please have a look at [1], the code can be found in the multilib branch of |
42 |
portage git repo at [2]. |
43 |
|
44 |
While i did not yet get to the implementation of it, i would also like to propose something similiar |
45 |
for languages (like python, ruby or others), so that the basic parts are inside the PM and we can |
46 |
drop the different ways of implementation and allow users a much more fine-grained control on a per |
47 |
package base (in relation to the current way python eclass based very complex implementation works). |
48 |
|
49 |
[1]: http://github.com/sjnewbury/multilib-overlay/tree/portage-multilib/doc |
50 |
[2]: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=shortlog;h=refs/heads/multilib |
51 |
|
52 |
-- |
53 |
Thomas Sachau |
54 |
|
55 |
Gentoo Linux Developer |