1 |
On Sun, 24 Feb 2013 16:12:18 +0100 |
2 |
Pacho Ramos <pacho@g.o> wrote: |
3 |
|
4 |
> El dom, 24-02-2013 a las 15:57 +0100, Michał Górny escribió: |
5 |
> [...] |
6 |
> > > d) the previous point will also allow to convert go-mono.eclass packages |
7 |
> > > without introducing yet another eclass for that |
8 |
> > |
9 |
> > So you're introducing a hacky eclass just because you're too lazy to |
10 |
> > convert go-mono packages properly and too impatient to let others do |
11 |
> > the work properly for you? |
12 |
> |
13 |
> Would be nice to know what autotools-utils.eclass is doing differently |
14 |
> that is showing this problem with go-mono.eclass packages :/ |
15 |
|
16 |
I already told that I'm going to look at this but I have too much work |
17 |
to do right now so it's going to take a longer while. |
18 |
|
19 |
> Only one question, what is the reason for us having base.eclass and |
20 |
> autotools-utils.eclass? |
21 |
|
22 |
I think that base.eclass is silently intended for removal at some point |
23 |
in the future. While we're here, we should probably mark it deprecated. |
24 |
|
25 |
autotools-utils does a bit more -- especially by using out-of-source |
26 |
builds. The major reason to use autotools-utils so far was to support |
27 |
those builds. |
28 |
|
29 |
Believe me or not, the day I took over the maintenance of it I seen |
30 |
the opportunity to use out-of-source builds for multilib. Today, both |
31 |
python-r1 & multilib-build were specifically designed to allow using |
32 |
out-of-source builds with minimal effort. |
33 |
|
34 |
> I still try to use plain ebuilds without |
35 |
> inheritting autotools-utils.eclass as I usually don't need it, probably |
36 |
> others do the same and refuse to have to inherit it only for multilib |
37 |
> support :/ How do you plan to solve this problem? |
38 |
|
39 |
You generally have two options on doing multilib builds: either using |
40 |
out-of-source builds or in-source builds. If you decide on the latter, |
41 |
you unnecessarily waste users' time and disk space to create two more |
42 |
copies of sources. I don't think we should go this way. |
43 |
|
44 |
If you decide on out-of-source builds, you basically need proper |
45 |
src_{configure,compile,test,install} and that's what autotools-utils |
46 |
does. Plus: |
47 |
|
48 |
- prune_libtool_files in src_install() which most people want to do |
49 |
anyway, so that doesn't hurt -- and the pkg-config dep is going to |
50 |
be removed, by the patch I sent already. |
51 |
|
52 |
- patch applying and autoreconf in src_prepare() -- which are |
53 |
completely optional, you are free to write your own src_prepare(). |
54 |
If you wanted to apply patches by hand, you'd need to write |
55 |
src_prepare() anyway. |
56 |
|
57 |
- adding libtool args for shared/static libs if IUSE=static-libs -- |
58 |
which I wanted to remove but people considered it useful. |
59 |
|
60 |
> I would also like to hear why that people refuses to use |
61 |
> autotools-utils.eclass... because I don't have a strong opinion on this |
62 |
> topic |
63 |
|
64 |
Well, the major argument was similar to yours -- why we should use |
65 |
an eclass if default PMS functions work. But in the multilib case, they |
66 |
do not work by design anymore. |
67 |
|
68 |
-- |
69 |
Best regards, |
70 |
Michał Górny |