Re: [CT-NG 1.11.1] eglibc internationalization support

["Yann E. MORIN" <yann dot morin dot 1998 at anciens dot enib dot fr>]

Benoit, All,

On Thursday 09 June 2011 15:42:07 BenoÃt THÃBAUDEAU wrote:
> Does somebody have suggestions/comments/preferences or need more
> time to answer, or should I propose a patch first, then discuss?

The real reason we need localedef is to build locales, right? So
maybe we'd better add an option:
  [ ] Build and install locales

And then build localedef and locales. I mean, rather that list it in the
add-ons list.

Below are a few quotes of your original patch:

> +# This function builds and installs the C library locales
> +do_eglibc_localedef() {

Rename to 'do_libc_locales' and add the same function in the common
glibc/eglibc script.

Then, instead of calling do_eglibc_localedef conditionnaly on CT_LIBC ==
eglibc, you can call it always. Then, once we know how to build locales
for glibc, infrastructure is there.

> + Â ÂCT_DoStep INFO "Installing C library locales"
> +
> + Â Âmkdir -p "${CT_BUILD_DIR}/build-libc/localedef"
> + Â Âcd "${CT_BUILD_DIR}/build-libc/localedef"

Although localedef is part of the C library, its build procedure is really
completely decorelated. Can't we build localedef in its own build dir:
    mkdir -p "${CT_BUILD_DIR}/build-localedef"
    cd "${CT_BUILD_DIR}/build-localedef"

Or, is it required that it be built as a sub-dir of eglibc? Where are the
locales definitions stored? Is that what --with-glibc= is for?

> + Â ÂCT_DoExecLog CFG Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â\
> + Â Â"${src_dir}/configure" Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â\
> +    Â--prefix=/usr                        \
> + Â Â Â Â--cache-file="$(pwd)/config.cache" Â Â Â Â Â Â Â Â Â Â Â Â Â\
> + Â Â Â Â--with-glibc="${libc_src_dir}"
> +

Indeed, we do want to build localedef natively. It runs on the host.
Correct?

Also, configure accepts --with-pkgversion and --with-bugurl, so we could
add them as well if they are usefull, or add a comment stating they are
not used for locales.

Would it be worth having the localedef binary on the target, in case there
is a need to build the locales on-the-fly there?

> + Â Â# Set the localedef option for the target's uint32_t alignment in
> bytes
> + Â Âlocaledef_opts+=(--uint32-align=4)

Even on 64-bit archs?

> @@ -19,6 +20,11 @@ do_libc_start_files() {
> + Â Âcase "$(do_libc_add_ons_list ,)" in
> + Â Â Â Â"") extra_config+=("--enable-add-ons=no");;
> + Â Â Â Â*) Âextra_config+=("--enable-add-ons=$(do_libc_add_ons_list ,)");;
> + Â Âesac
> +

...and...

> @@ -185,7 +191,7 @@ do_libc() {
> Â Â Âcase "$(do_libc_add_ons_list ,)" in
> - Â Â Â Â"") ;;
> + Â Â Â Â"") extra_config+=("--enable-add-ons=no");;
> Â Â Â Â Â*) Âextra_config+=("--enable-add-ons=$(do_libc_add_ons_list ,)");;
> Â Â Âesac

... -> Could you make those two hunks (and related) into a separate
patch, please?

> > I have briefly looked at glibc's and eglibc's Makefiles. Both have a
> > localedata/install-locales target, but apparently only for native
> > builds
> > since they use the built localedef. A host localedef is required in
> > order
> > to install the locales, hence eglibc's localedef add-on.
> > Unfortunately,
> > there doesn't seem to be such an add-on for glibc.

Sad...

> > The options for eglibc are:
> > 1) Use the localedef add-on.
> > 2) Use a pre-installed host version of localedef.

1) as you did. We'll be needing it on hosts that do not have it ( yes,
there are guys using uClibc-based desktops out there... ;-) )

> > The options for glibc are:
> > 1) Use eglibc's localedef add-on if it works, but it's probably
> > better to
> >    avoid mixing packages.

That's not an option, indeed.

> > 2) Use a pre-installed host version of localedef.
> > 3) Do not support installing target locales, which would be a shame.

3) is better in the short term. We can see later if we can devise a plan
to build them.

> > I think 2) would be the best for both since it would avoid
> > eglibc/glibc
> > branches. The host localedef would be detected by CT-NG's configure.

The issue is about people who are building on hosts that may not have
have a localedef, for example uClibc-based desktops, on maybe MacOS.

> > Do you think the installation of locales should be mandatory, or a
> > config
> > option?

Config option, default n.

> > Do you think that the list of locales to install should be a
> > configuration,
> > or that all locales should be installed?

All locales. It would be up to the rootfs build system to choose what
locales to install. So maybe we could add a script that accepts a list
of locales, a destination rootfs, and copies required locales, and
handling patterns, a bit like:
  tuple-locales --dest-dir /some/place/rootfs 'en_US*' fr_FR.UTF8

Optionally, it should be possible to pass a file that lists such patterns:
  tuple-locales -d /some/place/rootfs -f my-locales-patterns

It may even makes sense to add this option to populate.
I can take care of that at a later stage...

> > Tools like BuildRoot have an option to purge the target locales
> > installed
> > from a toolchain, so too many config options concerning locales is
> > perhaps
> > useless for CT-NG.

Yes, indeed, it should be the role of such a build system to install
needed locales.

Sorry for the time it took for me to answer... Plus, I'm off for the WE
starting tomorrow morning early, although I may have a bit of time to
read emails at some point...

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

--
For unsubscribe information see http://sourceware.org/lists.html#faq