public inbox for gentoo-mips@lists.gentoo.org
 help / color / mirror / Atom feed
From: Markos Chandras <hwoarang@gentoo.org>
To: "Michał Górny" <mgorny@gentoo.org>, gentoo-mips@lists.gentoo.org
Subject: Re: [gentoo-mips] On MIPS using the same CHOST for all multilib ABIs
Date: Fri, 17 Jan 2014 19:44:07 +0000	[thread overview]
Message-ID: <52D98807.2060201@gentoo.org> (raw)
In-Reply-To: <20140117195154.4b512793@pomiot.lan>

On 01/17/2014 06:51 PM, Michał Górny wrote:
> Dnia 2014-01-17, o godz. 18:20:30
> Markos Chandras <hwoarang@gentoo.org> napisał(a):
> 
>> 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.
> 
> Well, I'd like someone who knows better than I do to explain how much
> does changing non-native CHOST affect. I will try to test it a bit by
> changing CHOST_x86=i686-pc-linux-gnu to i386-* locally but an expert
> opinion would be preferred.
> 
My comment was not on what side-effects changing the CHOST may have, but
it requires time and effort for every MIPS user out there. You also need
to consider that many people have relatively slow MIPS hardware (routers
and stuff) that will take a good couple of days (if not more) to switch
to a new CHOST. But still, not everyone is going to do it and forcing
them is definitely unpleasant.

-- 
Regards,
Markos Chandras


  reply	other threads:[~2014-01-17 19:44 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-28 22:58 [gentoo-mips] On MIPS using the same CHOST for all multilib ABIs Michał Górny
2013-12-28 23:55 ` Markos Chandras
2013-12-29  2:12 ` Mike Frysinger
     [not found]   ` <20131229163354.35b65df5@gentoo.org>
2013-12-29 18:21     ` Mike Frysinger
2013-12-30  9:44       ` Michał Górny
2013-12-29 21:40 ` [gentoo-mips] " Joshua Kinard
2013-12-29 21:48   ` Markos Chandras
2013-12-29 21:48   ` Michał Górny
2013-12-29 21:48     ` Markos Chandras
2013-12-29 21:52       ` Anthony G. Basile
2013-12-29 22:04         ` Michał Górny
2013-12-29 23:56           ` Mike Frysinger
2013-12-30  7:51             ` Mike Frysinger
2013-12-30  8:17               ` sébastien bertoletto
2013-12-29 22:13         ` Markos Chandras
2013-12-29 22:19           ` Anthony G. Basile
2013-12-29 22:33             ` Markos Chandras
2013-12-29 23:47               ` Anthony G. Basile
2014-01-16 20:01 ` [gentoo-mips] " Michał Górny
2014-01-16 21:05   ` Anthony G. Basile
2014-01-16 21:24     ` Michał Górny
2014-01-16 22:29       ` Anthony G. Basile
2014-01-17  4:47         ` Michał Górny
2014-01-17 18:20           ` Markos Chandras
2014-01-17 18:36             ` Matt Turner
2014-01-17 19:38               ` Markos Chandras
2014-01-17 21:57                 ` Matt Turner
2014-01-17 18:51             ` Michał Górny
2014-01-17 19:44               ` Markos Chandras [this message]
2014-01-21 20:52                 ` Markos Chandras
2014-01-22 14:24                 ` Anthony G. Basile
2014-01-22 14:38                   ` Michał Górny
2014-01-22 20:39                     ` Markos Chandras
2014-01-22 21:07                       ` Anthony G. Basile

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=52D98807.2060201@gentoo.org \
    --to=hwoarang@gentoo.org \
    --cc=gentoo-mips@lists.gentoo.org \
    --cc=mgorny@gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox