Re: [gentoo-mips] On MIPS using the same CHOST for all multilib ABIs

[Markos Chandras <hwoarang@gentoo.org>]

On 01/17/2014 04:47 AM, Michał Górny wrote:
> Dnia 2014-01-16, o godz. 17:29:43 "Anthony G. Basile"
> <blueness@gentoo.org> napisał(a):
> 
>> On 01/16/2014 04:24 PM, Michał Górny wrote:
>>> Because AC_PATH_TOOL uses CHOST and some random Gentoo
>>> invention.
>> 
>> I got that AC_PATH_TOOL and AC_CHECK_TOOL prefix whatever utility
>> they search for with the canonicalized chost (usually from
>> config.guess), but I still don't see why we need this to avoid
>> hackery?  Can you give me a practial example because right now I
>> just don't see a serious problem.
> 
> libgpg-error installs ${CHOST}-gpg-error-config.
> 
> Now libgcrypt (and possibly other tools) are using AC_PATH_TOOL to
> find it. If we have proper CHOSTs, they find the right
> gpg-error-config and we don't have to put any more effort into
> that. Then libgcrypt installs ${CHOST}-libgcrypt-config.
> 
> Now other tools are using AC_PATH_TOOL to find proper
> libgcrypt-config. If we have proper CHOSTs, it just works and we
> don't have to put any more effort into that.
> 
> Same goes for LLVM & Mesa.
> 
> If we play by the rules nicely, all pieces fit together nicely and
> we don't have to worry. If we don't, we ask the developers to spit
> Gentoo- specific hackery all over the place.
> 
You need to consider that besides changing CHOST to new stages (which
is a lengthy and tiring process), you somehow need to migrate existing
users to the new CHOST (no?) otherwise the multilib eclass (or any
other eclass/package) that depends on CHOST will be broken as soon as
they update their tree and try to install package updates.
This is definitely not a pleasant user experience.

Apologies for the stupid question (still trying to understand how our
multilib works) but if our CHOST are being a problem, how come our
multilib profiles work fine?

-- 
Regards,
Markos Chandras