1 |
On Sun, 23 Sep 2012 16:49:13 +0200 |
2 |
Thomas Sachau <tommy@g.o> wrote: |
3 |
|
4 |
> It is not hard by itself to inherit an eclass. There is just the |
5 |
> limitation, that occurs with an eclass, e.g.: |
6 |
> |
7 |
> -the one from mgorny only does it for autotools based ebuilds only and |
8 |
> even there only for libraries, headers and binaries are not done. |
9 |
> While one may create the same for cmake based ones, those are still |
10 |
> only for a subset of packages, since not all do use autotools/cmake |
11 |
> or are satisfied with a libs only solution |
12 |
> -the multilib-native eclass does extend it way more, but still has its |
13 |
> limitations, e.g. what happens with a new target ABI (like x32 on the |
14 |
> amd64 profile) or how are dependencies handled? |
15 |
> |
16 |
> multilib-portage is the answer to those limitations, since it does |
17 |
> work for any target with multilib cross-compile support, can handle |
18 |
> things like the dependencies internally and can even work on not |
19 |
> prepared/modified ebuilds. |
20 |
> |
21 |
> So before i invest even more time in getting this official, we should |
22 |
> better get to some conclusion, if we either go the route with eclass |
23 |
> based multilib cross-compile support with its limitations or if we |
24 |
> move this up to the package manager level. |
25 |
> |
26 |
|
27 |
Can't we get something in between ? |
28 |
|
29 |
Unless I'm mistaken, portage-multilib has its limitations also: |
30 |
|
31 |
- I have package foo and package bar, both depending on ffmpeg and |
32 |
canditates for a multilib build. However, package foo does not link to |
33 |
ffmpeg but simply spawns the 'ffmpeg' binary to process some files, |
34 |
package bar links to libavcodec. You need ffmpeg[multilib] for a |
35 |
multilib build of bar but not for foo. How do you distinguish between |
36 |
the two ? |
37 |
|
38 |
- When an out-of-tree build is possible, it is more efficient to do it |
39 |
that way while multilib-portage will probably run the full src_* |
40 |
phases twice. mgorny's eclass is a solution to this for |
41 |
autotools-utils based ebuilds. I have added basic support for this in |
42 |
freebsd-lib some time ago also. |
43 |
|
44 |
|
45 |
|
46 |
However, it is clear that USE=multilib is limited too. What we probably |
47 |
need, as I read in the draft you posted some time ago, is a |
48 |
MULTILIB_ABI use-expand. Keep a list of all the MULTILIB_ABIs in an |
49 |
eclass, add them to IUSE of multilib-enabled packages and then you can |
50 |
use the USE-deps. When a new ABI gets added, add it to the list in the |
51 |
eclass and be done. You already have PM support for this :) |
52 |
|
53 |
You can leverage the generic multilib building code you have to an |
54 |
eclass, so that you don't need to spec it; spec-ing it has its problems |
55 |
too: what happens if next year pkg-config is deprecated and now we |
56 |
shall all use foo-config ? your spec adjusts PKG_CONFIG_PATH but not |
57 |
FOO_CONFIG_PATH. You probably need a small EAPI change to be able to |
58 |
implement sanely a generic solution into an eclass though. |
59 |
|
60 |
My question to you would be: what are we missing from current EAPIs to |
61 |
be able to perfectly support multilib builds ? |
62 |
|
63 |
A. |