bug-gettext
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug-gettext] Bug#671257: gettext: msgfmt output format prevents mul


From: Vladimir 'φ-coder/phcoder' Serbinenko
Subject: Re: [bug-gettext] Bug#671257: gettext: msgfmt output format prevents multiarch migration (fwd)
Date: Thu, 03 May 2012 12:29:56 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.3) Gecko/20120329 Icedove/10.0.3

On 03.05.2012 11:59, Bruno Haible wrote:
> Paul Martin wrote:
>> On Thu, May 03, 2012 at 12:18:48AM +0200, Bruno Haible wrote:
>>
>>> I don't know where you got this history from. AFAIK, GNU 'msgfmt' always
>>> created .mo files in native endianness since the beginning (1995),
>>> up until 2005-08-26, when the option --endianness was introduced.
>> This option is not documented in:
>>
>>  * "msgfmt --help" output
>>  * its manpage
>>  * its Texinfo format manual
>>
>> Please document it.
> OK, you have a reasonable use-case, so I'm documenting it. Patch attached.
>
> There was an earlier request to document this option also in 2008:
>   <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=468209>
>   "All I want is for the manpage of msgfmt to explain that --endianness
>    {big|little} *is* supported, *why* it is supported and why it is
>    important for certain situations."
> but I understood the rationale as being runtime optimization of a few CPU
> cycles, and that was IMO not a good enough reason to document this option.
That's pretty annoying in all actually. In GRUB we don't load full index
at language load and load it only on-demand. In this scenario there is
no performance benefit since the check which endianness is currently in
use outweights the benefit of not swapping. I thought that msgfmt always
creates little-endian file and so we support only little-endian ones.
I'll adjust our build-system to use --endian=little but this doesn't
solve all problems since we also load mo file for bison-runtime in
experimental branch and so experimental and future versions will have to
deal with presence of both formats, getting performance hit and making
the code uglier.

-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko


Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]