Re: [gentoo-dev] New eclass: autotools-multilib-minimal

[Pacho Ramos <pacho@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 2673 bytes --]

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 <pacho@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


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]