Re: [gentoo-dev] [PATCHES] multilib-build.eclass: getting 'long' ABI value & deprecating multilib_for_best_abi()

[Michał Górny]

Dnia 2014-05-05, o godz. 09:23:56
Ian Stakenvicius <axs@g.o> napisał(a):

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 05/05/14 04:29 AM, Michał Górny wrote:
>
> > 3. deprecates multilib_for_best_abi() since having two separate
> > concepts of 'best ABI' and 'default ABI' is confusing, and mostly
> > doesn't serve any real purpose.
> >
> > For improved consistency, we would like people to use
> > multilib-minimal and multilib_is_native_abi() tests if necessary.
> >
> >
> > I will submit the patches in replies to this mail.
> >
>
> multilib_for_best_abi was introduced to deprecate
> multilib_is_native_abi though, aren't we going backwards?

Honestly, I don't remember why it was introduced. I just checked
the commit message and relevant mails, and it's all quite laconic.
It was introduced as part of multibuild_for_best_variant(), and that
benefited mostly distutils-r1 for its *_all() phases.

I think multilib_for_best_abi() was mostly intended to help getting
autotools-multilib to work properly. Now it is built on top of
multilib-minimal, and people are encouraged to redefine the multilib_*
phases rather than try to hack on top of 'autotools-utils_src_compile'
and stuff. This makes most of multilib_for_best_abi() irrelevant.

So, I don't think we are really going backwards here. We've changed
direction over the past year. We've seen what caught better and I'm
mostly trying to make things simpler. As part of that, I'd like to
remove redundant APIs and focus on supporting one best-supported
interface for multilib. At the point, multilib-minimal seems to be
the way forward.

Do you agree with me on this? Do you have another ideas?

-- 
Best regards,
Michał Górny