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