1 |
Pacho Ramos schrieb: |
2 |
> El mar, 25-09-2012 a las 10:21 -0300, Alexis Ballier escribió: |
3 |
>> On Sun, 23 Sep 2012 16:49:13 +0200 |
4 |
>> Thomas Sachau <tommy@g.o> wrote: |
5 |
>> |
6 |
>>> It is not hard by itself to inherit an eclass. There is just the |
7 |
>>> limitation, that occurs with an eclass, e.g.: |
8 |
>>> |
9 |
>>> -the one from mgorny only does it for autotools based ebuilds only and |
10 |
>>> even there only for libraries, headers and binaries are not done. |
11 |
>>> While one may create the same for cmake based ones, those are still |
12 |
>>> only for a subset of packages, since not all do use autotools/cmake |
13 |
>>> or are satisfied with a libs only solution |
14 |
>>> -the multilib-native eclass does extend it way more, but still has its |
15 |
>>> limitations, e.g. what happens with a new target ABI (like x32 on the |
16 |
>>> amd64 profile) or how are dependencies handled? |
17 |
>>> |
18 |
>>> multilib-portage is the answer to those limitations, since it does |
19 |
>>> work for any target with multilib cross-compile support, can handle |
20 |
>>> things like the dependencies internally and can even work on not |
21 |
>>> prepared/modified ebuilds. |
22 |
>>> |
23 |
>>> So before i invest even more time in getting this official, we should |
24 |
>>> better get to some conclusion, if we either go the route with eclass |
25 |
>>> based multilib cross-compile support with its limitations or if we |
26 |
>>> move this up to the package manager level. |
27 |
>>> |
28 |
>> |
29 |
>> Can't we get something in between ? |
30 |
>> |
31 |
>> Unless I'm mistaken, portage-multilib has its limitations also: |
32 |
>> |
33 |
>> - I have package foo and package bar, both depending on ffmpeg and |
34 |
>> canditates for a multilib build. However, package foo does not link to |
35 |
>> ffmpeg but simply spawns the 'ffmpeg' binary to process some files, |
36 |
>> package bar links to libavcodec. You need ffmpeg[multilib] for a |
37 |
>> multilib build of bar but not for foo. How do you distinguish between |
38 |
>> the two ? |
39 |
|
40 |
I dont really understand your question here. So do you: |
41 |
|
42 |
- simply have 2 64bit apps wanting to use ffmpeg? |
43 |
- have 2 32bit binary packages wanting to use ffmpeg? |
44 |
- want to build foo and bar on a 64bit platform for a 32bit platform? |
45 |
- want a 64bit or a 32bit version of ffmpeg or both? |
46 |
- if you want a 32bit version of ffmpeg, do you only want 32bit libs or |
47 |
also a 32bit binary? |
48 |
|
49 |
>> - When an out-of-tree build is possible, it is more efficient to do it |
50 |
>> that way while multilib-portage will probably run the full src_* |
51 |
>> phases twice. mgorny's eclass is a solution to this for |
52 |
>> autotools-utils based ebuilds. I have added basic support for this in |
53 |
>> freebsd-lib some time ago also. |
54 |
|
55 |
Isnt "out-of-tree build" just building in a seperate location, so in the |
56 |
end doing one unpack instead of 2, while everything else still needs to |
57 |
be done for each target? |
58 |
|
59 |
>> |
60 |
>> |
61 |
>> |
62 |
>> However, it is clear that USE=multilib is limited too. What we probably |
63 |
>> need, as I read in the draft you posted some time ago, is a |
64 |
>> MULTILIB_ABI use-expand. Keep a list of all the MULTILIB_ABIs in an |
65 |
>> eclass, add them to IUSE of multilib-enabled packages and then you can |
66 |
>> use the USE-deps. When a new ABI gets added, add it to the list in the |
67 |
>> eclass and be done. You already have PM support for this :) |
68 |
|
69 |
Please keep in mind, that the USE flags are different, depending on your |
70 |
arch. E.g. on amd64, you may additionally have x86 and x32, while on |
71 |
ppc64, you may have ppc64 and ppc. You dont want the later on amd64 nor |
72 |
the first on ppc. So how do you want to add different (use-expanded) USE |
73 |
flags based on the arch the user is running? |
74 |
|
75 |
>> |
76 |
>> You can leverage the generic multilib building code you have to an |
77 |
>> eclass, so that you don't need to spec it; spec-ing it has its problems |
78 |
>> too: what happens if next year pkg-config is deprecated and now we |
79 |
>> shall all use foo-config ? your spec adjusts PKG_CONFIG_PATH but not |
80 |
>> FOO_CONFIG_PATH. You probably need a small EAPI change to be able to |
81 |
>> implement sanely a generic solution into an eclass though. |
82 |
>> |
83 |
>> My question to you would be: what are we missing from current EAPIs to |
84 |
>> be able to perfectly support multilib builds ? |
85 |
|
86 |
While the variable export, the build for each target and the merge of |
87 |
the results should also be possible inside an eclass, the dependency and |
88 |
USE flag parts seems more tricky. |
89 |
|
90 |
And additionally, with support of this in (multilib-)portage (not |
91 |
depending on EAPI, but enabled via FEATURES), i already get all of this |
92 |
without having to wait for a new EAPI/eclass and ebuilds moving to it. |
93 |
|
94 |
|
95 |
> What finally occurred with this? What would be the problem of opting by |
96 |
> this "mixed" solution (eclass for some packages and PM features |
97 |
> requiring newer eapi for others)? |
98 |
|
99 |
I guess nothing new. Nobody yet provided an eclass providing the full |
100 |
support for everything i have in multilib-portage and i did not create |
101 |
the requested PMS-diff yet. |
102 |
|
103 |
|
104 |
-- |
105 |
|
106 |
Thomas Sachau |
107 |
Gentoo Linux Developer |