Hash: SHA256

On 05/05/14 01:42 PM, Michał Górny wrote:
> Dnia 2014-05-05, o godz. 09:23:56 Ian Stakenvicius <a...@gentoo.org>
> 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?

Nope, this makes sense now.  I have a sneaky suspicion that my memory
had some cross-talk between multilib_for_best_abi and
multilib_build_binaries, too...  if multilib_for_best_abi was always
based on multilib_is_native_abi, then I expect it will be fine to
deprecate it.

Version: GnuPG v2.0.22 (GNU/Linux)


Reply via email to