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

[Samuli Suominen]

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

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

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

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

src_prepare() seems to be adequate from PMS for the multilib conversion