Skip to contentSkip to conversation

multchoice menu with kconfig

Buildroot Stefan Fröberg 2 participants 11 messages Feb 18, 2013

lore
Share & tools
lore
#0 lore raw

Hello all

Could someone show me how to make a multi-choice menu with kconfig language with the ability to select
several menu entries and then storing those values as a space separated string variable.

Let's say I have the following locales:

af
ak
ar
as
ast
etc .... bazillion other locale values

and I would like to be able to select as many of those locales I want. Let's say I select locales "ak" and "ast" and then store them in a variable like BR2_PACKAGE_FOO_LOCALES so that it would look like

BR2_PACKAGE_FOO_LOCALES = "ak ast"

how to do that in the least amount of typing ?

Regards
Stefan

#1 lore raw
Quoted 14 lines · Stefan Fr?berg

Could someone show me how to make a multi-choice menu with kconfig language with the ability to select
several menu entries and then storing those values as a space separated string variable.

Let's say I have the following locales:

af
ak
ar
as
ast
etc .... bazillion other locale values

Quoted 7 lines

and I would like to be able to select as many of those locales I want. Let's say I select locales "ak" and "ast" and then store them in a variable like BR2_PACKAGE_FOO_LOCALES so that it would look like

BR2_PACKAGE_FOO_LOCALES = "ak ast"

how to do that in the least amount of typing ?

I don't think that's possible. You have no other option than to make a
bunch of bool options, and convert them to strings in the .mk file.

Config.in:
config BR2_PACKAGE_FOO_LOCALE_AF
bool "af"

config BR2_PACKAGE_FOO_LOCALE_AK
bool "ak"

foo.mk:
FOO_LOCALE += $(if $(BR2_PACKAGE_FOO_LOCALE_AF),af) FOO_LOCALE += $(if $(BR2_PACKAGE_FOO_LOCALE_AK),ak)

Obviously you could write a script to generate all this. But I doubt we
want to have it in the first place. In particular for locales, the BR2_ENABLE_LOCALE_WHITELIST fits our needs. And having a list of locales as a string isn't too user-unfriendly.

If this is for the iso-codes package: the locales stuff is already
covered by the generic options. I don't know what Thomas was going on about, because most of the 14MB gets removed again in the finalize step...

The only thing that perhaps could be made optional is the installation
of the xml files.

Regards,
Arnout

Signature · 6 lines
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
#2 lore raw

Hi Arnout !

18.2.2013 17:33, Arnout Vandecappelle kirjoitti:

Quoted 30 lines · Stefan Fr?berg
Quoted 14 lines

Could someone show me how to make a multi-choice menu with kconfig language with the ability to select
several menu entries and then storing those values as a space separated string variable.

Let's say I have the following locales:

af
ak
ar
as
ast
etc .... bazillion other locale values

Quoted 7 lines

and I would like to be able to select as many of those locales I want. Let's say I select locales "ak" and "ast" and then store them in a variable like BR2_PACKAGE_FOO_LOCALES so that it would look like

BR2_PACKAGE_FOO_LOCALES = "ak ast"

how to do that in the least amount of typing ?

I don't think that's possible. You have no other option than to make
a bunch of bool options, and convert them to strings in the .mk file.

Config.in:
config BR2_PACKAGE_FOO_LOCALE_AF
bool "af"

Quoted 7 lines

config BR2_PACKAGE_FOO_LOCALE_AK
bool "ak"

foo.mk:
FOO_LOCALE += $(if $(BR2_PACKAGE_FOO_LOCALE_AF),af) FOO_LOCALE += $(if $(BR2_PACKAGE_FOO_LOCALE_AK),ak)

Damn...

Quoted 11 lines

Obviously you could write a script to generate all this. But I doubt
we want to have it in the first place. In particular for locales, the BR2_ENABLE_LOCALE_WHITELIST fits our needs. And having a list of locales as a string isn't too user-unfriendly.

If this is for the iso-codes package: the locales stuff is already
covered by the generic options. I don't know what Thomas was going on about, because most of the 14MB gets removed again in the finalize step...

Yes. I was exactly going to use that for iso-codes package. In gentoo ebuild file for iso-codes they have something like this:

local linguas_bak=${LINGUAS}
local mylinguas=""

for norm in iso_15924 iso_3166 iso_3166_2 iso_4217 iso_639 iso_639_3; do

     einfo "Preparing ${norm}"
    
     mylinguas=""
     LINGUAS=${linguas_bak}
     strip-linguas -i "${S}/${norm}"
    
     for loc in ${LINGUAS}; do
         mylinguas="${mylinguas} ${loc}.po"
         done
    
         if [ -n "${mylinguas}" ]; then
             sed -e "s:pofiles =.*:pofiles = ${mylinguas}:" \
             -e "s:mofiles =.*:mofiles = ${mylinguas//.po/.mo}:" \
             -i "${S}/${norm}/Makefile.am" "${S}/${norm}/Makefile.in" \
             || die "sed in ${norm} folder failed"
         fi

done

And that ${LINGUAS} variable in Gentoo is just a space separated list of locales that user wants to support.

So that buildroot BR2_ENABLE_LOCALE_WHITELIST variable seems to do the exactly same thing as gentoo's ${LINGUAS} variable ?
Just put the locales you want to keep and everything else is removed at the final step of finishing rootfs ?

It would be perfect :-)

Quoted 6 lines

The only thing that perhaps could be made optional is the
installation of the xml files.

Regards,
Arnout

Regards
Stefan

#3 lore raw
Quoted 6 lines · Stefan Fr?berg

So that buildroot BR2_ENABLE_LOCALE_WHITELIST variable seems to do the exactly same thing as gentoo's ${LINGUAS} variable ?
Just put the locales you want to keep and everything else is removed at the final step of finishing rootfs ?

It would be perfect

Yep. Check out the target-purgelocales goal in the top-level Makefile.

It's not enabled by default, though. You need to have
BR2_ENABLE_LOCALE_PURGE set.

Regards,
Arnout

Signature · 6 lines
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
#4 lore raw

18.2.2013 17:58, Arnout Vandecappelle kirjoitti:

Quoted 8 lines · Stefan Fr?berg
Quoted 6 lines

So that buildroot BR2_ENABLE_LOCALE_WHITELIST variable seems to do the exactly same thing as gentoo's ${LINGUAS} variable ?
Just put the locales you want to keep and everything else is removed at the final step of finishing rootfs ?

It would be perfect

Quoted 8 lines

Yep. Check out the target-purgelocales goal in the top-level Makefile.

It's not enabled by default, though. You need to have
BR2_ENABLE_LOCALE_PURGE set.

Regards,
Arnout

Thanks!

I also noticed that you had submitted host-gettext patch yesterday.

And because this iso-codes package does not seem to have nothing but punch .po files
and not link against anything then changing that ISO_CODES_DEPENDENCIES to host-gettext should be good.

Thanks again !

Regards
Stefan

#5 lore raw
Quoted 4 lines · Stefan Fr?berg

And because this iso-codes package does not seem to have nothing but punch .po files
and not link against anything then changing that ISO_CODES_DEPENDENCIES to host-gettext should be good.

Err... But iso-codes doesn't need host-gettext, does it? It probably
doesn't make much sense without locale support in the toolchain, but otherwise I see no dependencies except python (which is already a buildroot dependency).

Regards,
Arnout

Signature · 6 lines
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
#6 lore raw

18.2.2013 18:08, Arnout Vandecappelle kirjoitti:

Quoted 11 lines · Stefan Fr?berg
Quoted 4 lines

And because this iso-codes package does not seem to have nothing but punch .po files
and not link against anything then changing that ISO_CODES_DEPENDENCIES to host-gettext should be good.

Err... But iso-codes doesn't need host-gettext, does it? It probably
doesn't make much sense without locale support in the toolchain, but otherwise I see no dependencies except python (which is already a buildroot dependency).

But don't you need at least host gettext stuff to process those .po files ?

I should now tell at this point that besides giving -lintl linker flags and giving --disable-nls to configure scripts
I absolutely have no idea how gettext works. :D

Im confused now.
So no dependencies at all ????? Or gettext dependencies with locale checking ?????? (Like Thomas said in his post)

Regards
Stefan

#7 lore raw
Quoted 14 lines · Stefan Fr?berg

18.2.2013 18:08, Arnout Vandecappelle kirjoitti:

Quoted 11 lines
Quoted 11 lines · Stefan Fr?berg
Quoted 4 lines
Quoted 4 lines

And because this iso-codes package does not seem to have nothing but punch .po files
and not link against anything then changing that ISO_CODES_DEPENDENCIES to host-gettext should be good.

Err... But iso-codes doesn't need host-gettext, does it? It probably
doesn't make much sense without locale support in the toolchain, but otherwise I see no dependencies except python (which is already a buildroot dependency).

But don't you need at least host gettext stuff to process those .po files ?

Quoted 7 lines

I should now tell at this point that besides giving -lintl linker flags and giving --disable-nls to configure scripts
I absolutely have no idea how gettext works. :D

Im confused now.
So no dependencies at all ????? Or gettext dependencies with locale checking ?????? (Like Thomas said in his post)

Sorry, correction: it does need host-gettext, but the gettext package
(or rather, msgfmt) is one of our global dependencies.

host-gettext is only needed for the autoconf macros (because we don't
use the system's autoconf, only our own version).

Regards,
Arnout

Signature · 6 lines
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
#8 lore raw

18.2.2013 18:23, Arnout Vandecappelle kirjoitti:

Quoted 21 lines · Stefan Fr?berg
Quoted 20 lines

18.2.2013 18:08, Arnout Vandecappelle kirjoitti:

Quoted 4 lines
Quoted 4 lines · Stefan Fr?berg
Quoted 3 lines
Quoted 3 lines

And because this iso-codes package does not seem to have nothing but punch .po files
and not link against anything then changing that

Quoted 8 lines
Quoted 8 lines

ISO_CODES_DEPENDENCIES

Quoted 1 line
Quoted 1 line

to host-gettext should be good.

Err... But iso-codes doesn't need host-gettext, does it? It probably
doesn't make much sense without locale support in the toolchain, but otherwise I see no dependencies except python (which is already a buildroot dependency).

But don't you need at least host gettext stuff to process those .po files ?

I should now tell at this point that besides giving -lintl linker flags and giving --disable-nls to configure scripts
I absolutely have no idea how gettext works. :D

Quoted 7 lines
Quoted 3 lines

Im confused now.
So no dependencies at all ????? Or gettext dependencies with locale checking ?????? (Like Thomas said in his post)

Sorry, correction: it does need host-gettext, but the gettext package
(or rather, msgfmt) is one of our global dependencies.

Ah, I see.
So if it's only that msgfmt that is needed and it is already there then I can remove ISO_CODES_DEPENDENCIES completely?

Quoted 6 lines

host-gettext is only needed for the autoconf macros (because we don't
use the system's autoconf, only our own version).

Regards,
Arnout

Speaking of autoconf (or actually autoreconf):

I have a prelink package ready here and I had to do PRELINK_AUTORECONF = YES what happens is that it complains about
missing ./ABOUT-NLS and ./config.rpath .
I tried to give PRELINK_AUTORECONF_OPTS = --install --force so that it would create those missing files but it did not change anything.

The only thing that worked was doing the following horrible looking stuff:

define PRELINK_POST_PATCH_FIXUP

    (cd $(@D); \
    autopoint)

endef

PRELINK_POST_PATCH_HOOKS += PRELINK_POST_PATCH_FIXUP

Im still using 2012.08 version of buildroot so could that be the reason that buildroots autoreconf does not create those two missing files ?

Regards
Stefan

#9 lore raw

[Buildroot] autopoint [was: Re: multchoice menu with kconfig]

Quoted 11 lines · Stefan Fr?berg

Speaking of autoconf (or actually autoreconf):

I have a prelink package ready here and I had to do PRELINK_AUTORECONF = YES what happens is that it complains about
missing ./ABOUT-NLS and ./config.rpath .
I tried to give PRELINK_AUTORECONF_OPTS = --install --force so that it would create those missing files but it did not change anything.

The only thing that worked was doing the following horrible looking stuff:

define PRELINK_POST_PATCH_FIXUP

Quoted 8 lines
     (cd $(@D); \
     autopoint)

endef

PRELINK_POST_PATCH_HOOKS += PRELINK_POST_PATCH_FIXUP

Im still using 2012.08 version of buildroot so could that be the reason that buildroots autoreconf does not create those two missing files ?

Packages that require autopoint can't be reconfigured by buildroot -
I'm not sure why. The autopoint program is not one of our dependencies, so we can't rely on autopoint being present.

However, now that there is a host-gettext package, we could probably
add the possibility to add autopoint support to autoreconf.

Just touching ABOUT-NLS and config.rpath may also work, though.

Regards,
Arnout

Signature · 6 lines
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
#10 lore raw

[Buildroot] autopoint [was: Re: multchoice menu with kconfig]

18.2.2013 23:36, Arnout Vandecappelle kirjoitti:

Quoted 22 lines · Stefan Fr?berg
Quoted 12 lines

Speaking of autoconf (or actually autoreconf):

I have a prelink package ready here and I had to do PRELINK_AUTORECONF = YES what happens is that it complains about
missing ./ABOUT-NLS and ./config.rpath .
I tried to give PRELINK_AUTORECONF_OPTS = --install --force so that it would create those missing files but it did not change anything.

The only thing that worked was doing the following horrible looking stuff:

define PRELINK_POST_PATCH_FIXUP

Quoted 8 lines
     (cd $(@D); \
     autopoint)

endef

PRELINK_POST_PATCH_HOOKS += PRELINK_POST_PATCH_FIXUP

Im still using 2012.08 version of buildroot so could that be the reason that buildroots autoreconf does not create those two missing files ?

Quoted 9 lines

Packages that require autopoint can't be reconfigured by buildroot -
I'm not sure why. The autopoint program is not one of our dependencies, so we can't rely on autopoint being present.

However, now that there is a host-gettext package, we could probably
add the possibility to add autopoint support to autoreconf.

Just touching ABOUT-NLS and config.rpath may also work, though.

Yes, touch works too.
I will wait untill host-gettext with autopoint is committed to latest git before submitting prelink

Regards
Stefan

Quoted 4 lines

Regards,
Arnout