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

[Michał Górny]

On Sun, 24 Feb 2013 18:58:08 +0200
Samuli Suominen <ssuominen@g.o> wrote:

> On 24/02/13 17:53, Michał Górny wrote:
> >> 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:
>  >
>  > - 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.
>
> It's that "Plus" part that is my problem with autotools-multilib.eclass
> currently, it adds EXPORT_FUNCTIONS of src_prepare() from
> autotools-utils.eclass which is irrelevant to the autotools-multilib.eclass
> adds just another eclass/phase function to worry about for inherit order

I understand your concern but I see no way around it. The alternative
solution exports src_prepare() as well to copy the sources -- so it's
even more to worry about than the no-op-by-default.

> > - 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.
>
> but lacks a way to pass arguments to prune_libtool_files, like --all,
> since prune_libtool_files isn't that smart it gets it right everytime
> i propably prefer to stick to manually calling it with or without --all
> and well, this is not related to the multilib conversion so it shouldn't
> be executed anyway

I can add the ability to pass arguments. So far, hasn't considered it
necessary since the single run doesn't really hurt anything noticeably.

> > - adding libtool args for shared/static libs if IUSE=static-libs --
> >    which I wanted to remove but people considered it useful.
>
> if it's not related to the multilib conversion, it shouldn't be executed...

It's not about multilib conversion solely.

Multilib conversion requires out-of-source build support. Out-of-source
build support is established using autotools-utils. The logical
conversion order is to:

1) convert the ebuild to autotools-utils, make sure that out-of-source
builds work,

2) convert the ebuild to autotools-multilib.

Some of my conversions actually follow that split, providing two
patches instead of one.

-- 
Best regards,
Michał Górny