[oe] [RFC] Allow to limit generated binary locales to predefined list

Paul Sokolovsky pmiscml at gmail.com
Sun Mar 11 19:33:32 UTC 2007


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 at gmail.com





More information about the Openembedded-devel mailing list