Re: [RFC] Allow to limit generated binary locales to predefined list

[Paul Sokolovsky <pmiscml@gmail.com>]

Hello Jan,

Sunday, March 11, 2007, 5:56:28 PM, you wrote:

>> I finally took time to clean it up and make list configurable via OE
>> variable, and submit it: http://bugs.openembedded.org/show_bug.cgi?id=1966
> Cool!

>> GLIBC_GENERATE_LOCALES = "en_GB,UTF-8 de_DE,UTF-8"
>>
>>  Format is <locale>,<encoding> pairs separated by space. Format is
>> actually based on "SUPPORTED" file generated/provided with GLIBC. For
>> development purposes, encoding can be just "UTF-8", and for Angstrom,
>> only en_GB locales is required now. Previous default from OZ/Familiar
>> was "en_GB,UTF-8 de_DE,UTF-8 fr_FR,UTF-8".

> Any special reason to use a comma between the locale and the encoding,
> instead of a dot? Not only does the list (at first glance) now look
> comma-seperated, almost everywhere a '.' (dot) is used to glue the
> encoding to the locale...

  My intention was to do as little (pre/post)processing/interpretation
for GLIBC's SUPPORTED file as possible. Looking at what it has:

aa_DJ.UTF-8 UTF-8
aa_DJ ISO-8859-1

  It's clear why dot couldn't be used - it already appears in
SUPPORT's syntax. So, again, I don't try to interpret it in any way,
just provide means to specify expressions of that syntax using OE variable,
using simple substitution of newlines with spaces, and spaces with
commas.

  Colon or semicolon would be other obvious choices.

> Maybe we could even take this one step further and use IMAGE_LINGUAS
> and introduce an IMAGE_ENCODINGS and combine these together to get a
> list of binary locales to generate?

  Yes, that would be natural extension of that idea. But my patch
doesn't go that far, just offering way to constrain *GLIBC*'s locate
generation.

> Jan.



-- 
Best regards,
 Paul                            mailto:pmiscml@gmail.com