[Buildroot] multchoice menu with kconfig

[Buildroot] multchoice menu with kconfig

[Stefan Fröberg]

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

[Buildroot] multchoice menu with kconfig

[Arnout Vandecappelle]

On 18/02/13 14:49, Stefan Fr?berg wrote:
> 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 ?

  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

-- 
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

[Buildroot] multchoice menu with kconfig

[Stefan Fröberg]

Hi Arnout !

18.2.2013 17:33, Arnout Vandecappelle kirjoitti:
> On 18/02/13 14:49, Stefan Fr?berg wrote:
>> 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 ?
>
>  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)
>

Damn...

>
>  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 :-)

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

Regards
Stefan

[Buildroot] multchoice menu with kconfig

[Arnout Vandecappelle]

On 18/02/13 16:45, Stefan Fr?berg wrote:
> 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

-- 
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

[Buildroot] multchoice menu with kconfig

[Stefan Fröberg]

18.2.2013 17:58, Arnout Vandecappelle kirjoitti:
> On 18/02/13 16:45, Stefan Fr?berg wrote:
>> 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
>

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

[Buildroot] multchoice menu with kconfig

[Arnout Vandecappelle]

On 18/02/13 17:01, Stefan Fr?berg wrote:
> 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

-- 
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

[Buildroot] multchoice menu with kconfig

[Stefan Fröberg]

18.2.2013 18:08, Arnout Vandecappelle kirjoitti:
> On 18/02/13 17:01, Stefan Fr?berg wrote:
>> 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

[Buildroot] multchoice menu with kconfig

[Arnout Vandecappelle]

On 18/02/13 17:16, Stefan Fr?berg wrote:
> 18.2.2013 18:08, Arnout Vandecappelle kirjoitti:
>> >On 18/02/13 17:01, Stefan Fr?berg wrote:
>>> >>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)

  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

-- 
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

[Buildroot] multchoice menu with kconfig

[Stefan Fröberg]

18.2.2013 18:23, Arnout Vandecappelle kirjoitti:
> On 18/02/13 17:16, Stefan Fr?berg wrote:
>> 18.2.2013 18:08, Arnout Vandecappelle kirjoitti:
>>> >On 18/02/13 17:01, Stefan Fr?berg wrote:
>>>> >>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)
>
>  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?

>  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

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

[Arnout Vandecappelle]

On 18/02/13 17:32, Stefan Fr?berg wrote:
> 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 ?

  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


-- 
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

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

[Stefan Fröberg]

18.2.2013 23:36, Arnout Vandecappelle kirjoitti:
> On 18/02/13 17:32, Stefan Fr?berg wrote:
>> 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 ?
>
>  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


>  Regards,
>  Arnout
>
>