Gentoo Archives: gentoo-dev

From: Pacho Ramos <pacho@g.o>
To: "Michał Górny" <mgorny@g.o>
Cc: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] New eclass: autotools-multilib-minimal
Date: Sun, 24 Feb 2013 16:21:30
Message-Id: 1361722869.20067.65.camel@belkin4
In Reply to: Re: [gentoo-dev] New eclass: autotools-multilib-minimal by "Michał Górny"
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

Attachments

File name MIME type
signature.asc application/pgp-signature