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

["Michał Górny" <mgorny@gentoo.org>]

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

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.

> 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.

autotools-utils does a bit more -- especially by using out-of-source
builds. The major reason to use autotools-utils so far was to support
those builds.

Believe me or not, the day I took over the maintenance of it I seen
the opportunity to use out-of-source builds for multilib. Today, both
python-r1 & multilib-build were specifically designed to allow using
out-of-source builds with minimal effort.

> I still try to use plain ebuilds without
> inheritting autotools-utils.eclass as I usually don't need it, probably
> others do the same and refuse to have to inherit it only for multilib
> support :/ How do you plan to solve this problem?

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.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]