1 |
On Mon, 24 Sep 2012 22:47:33 +0200 |
2 |
Michał Górny <mgorny@g.o> wrote: |
3 |
|
4 |
> On Mon, 24 Sep 2012 16:16:53 -0300 |
5 |
> Alexis Ballier <aballier@g.o> wrote: |
6 |
> |
7 |
> > On Mon, 24 Sep 2012 20:12:40 +0200 |
8 |
> > Michał Górny <mgorny@g.o> wrote: |
9 |
> > |
10 |
> > > > > > > > > > to some extent, can't you do the same by unpacking |
11 |
> > > > > > > > > > twice to different $S and calling |
12 |
> > > > > > > > > > src_prepare/compile/install instead of their |
13 |
> > > > > > > > > > autotools-utils counterpart with tweaked $S so that |
14 |
> > > > > > > > > > it works with almost every ebuild ? |
15 |
> > |
16 |
> > [...] |
17 |
> > |
18 |
> > > Ebuilds don't offer me anything if I have to rewrite phase |
19 |
> > > functions anyway... |
20 |
> > |
21 |
> > what, in the above quote, makes you think you need to rewrite |
22 |
> > anything ? |
23 |
> |
24 |
> 1. If ebuild has phase functions, they override the eclass. |
25 |
> 2. If eclass exports phase functions, they have no way of calling |
26 |
> 'previous' eclass phase functions. |
27 |
> |
28 |
|
29 |
you dont need this, the PM has already done the work for you: call |
30 |
directly the relevant function. |
31 |
|
32 |
src_multilib_compile() { |
33 |
forall ABIS; do |
34 |
prepare ABI variables |
35 |
src_compile |
36 |
done |
37 |
} |
38 |
|
39 |
then, in a future EAPI, let the PM call src_multilib_compile instead |
40 |
of src_compile if multilib is requested. |
41 |
|
42 |
this needs very minimal PM/EAPI support, leaves the multilib code |
43 |
into eclasses, leaves multilib opt-in so that noarch or packages not |
44 |
installing a lib dont need to care, and also leaves room for cleaner |
45 |
more specific eclasses like yours |