El dom, 24-02-2013 a las 16:53 +0100, Michał Górny escribió: > On Sun, 24 Feb 2013 16:12:18 +0100 > Pacho Ramos <pa...@gentoo.org> wrote: > > > El dom, 24-02-2013 a las 15:57 +0100, Michał Górny escribió: > > [...] > > > > d) the previous point will also allow to convert go-mono.eclass packages > > > > without introducing yet another eclass for that > > > > > > So you're introducing a hacky eclass just because you're too lazy to > > > convert go-mono packages properly and too impatient to let others do > > > the work properly for you? > > > > Would be nice to know what autotools-utils.eclass is doing differently > > that is showing this problem with go-mono.eclass packages :/ > > I already told that I'm going to look at this but I have too much work > to do right now so it's going to take a longer while. >
In that case, sorry, I probably missed it for some reason :S
> > Only one question, what is the reason for us having base.eclass and
> > autotools-utils.eclass?
>
> I think that base.eclass is silently intended for removal at some point
> in the future. While we're here, we should probably mark it deprecated.
>
I agree, I though it was marked as deprecated time ago, but last time I
read it it appeared to be still "active"
[...]
> You generally have two options on doing multilib builds: either using
> out-of-source builds or in-source builds. If you decide on the latter,
> you unnecessarily waste users' time and disk space to create two more
> copies of sources. I don't think we should go this way.
>
> If you decide on out-of-source builds, you basically need proper
> src_{configure,compile,test,install} and that's what autotools-utils
> does. Plus:
>
> - prune_libtool_files in src_install() which most people want to do
> anyway, so that doesn't hurt -- and the pkg-config dep is going to
> be removed, by the patch I sent already.
>
> - patch applying and autoreconf in src_prepare() -- which are
> completely optional, you are free to write your own src_prepare().
> If you wanted to apply patches by hand, you'd need to write
> src_prepare() anyway.
>
> - adding libtool args for shared/static libs if IUSE=static-libs --
> which I wanted to remove but people considered it useful.
>
> > I would also like to hear why that people refuses to use
> > autotools-utils.eclass... because I don't have a strong opinion on this
> > topic
>
> Well, the major argument was similar to yours -- why we should use
> an eclass if default PMS functions work. But in the multilib case, they
> do not work by design anymore.
>
OK, thanks for the info
signature.asc
Description: This is a digitally signed message part
