[Buildroot] [RFC] Handling gettext

[Buildroot] [RFC] Handling gettext

[Yann E. MORIN]

Hello All!

Currently, defining dependency upon gettext is a bit convoluted:

  config BR2_PACKAGE_FOO
    select BR2_PACKAGE_GETTEXT if BR2_NEEDS_GETTEXT
    select BR2_PACKAGE_LIBINTL if BR2_NEEDS_GETTEXT_IF_LOCALE

I think that packages should not have to do that in this way, because
I believe they should not have to deal with that complexity.

What I mean is, for example, should the gettext issue gains some complexity,
of is simplified, of we decide to always use a library instead of the libc's
gettext, it would mean updating all packages.

Also, it breaks my script about the _AVAILABLE sutff.

What I suggest is the following:

0) Rename the current options:

  BR2_NEEDS_GETTEXT            -->  BR2_NEEDS_EXTERNAL_GETTEXT

1) Add blind options that do the conditional selects:

  config BR2_NEEDS_GETTEXT
    bool
    select BR2_PACKAGE_GETTEXT if BR2_NEEDS_EXTERNAL_GETTEXT

  config BR2_NEEDS_LIBINTL
    bool
    select BR2_PACKAGE_LIBINTL if BR2_NEEDS_EXTERNAL_GETTEXT

2) simplify packages by selecting appropriate options:

  config BR2_PACKAGE_FOO
    select BR2_NEEDS_GETTEXT
    select BR2_NEEDS_LIBINTL

3) Ditto for the _IF_LOCALE variants.

4) A similar approach (that I haven't yet thought about) for the .mk file.
   Maybe something along the lines of:

  In package's .mk file:
  FOO_DEPENDENCIES += $(needs_gettext)

  In one of the infrastructure .mk files:
  needs_gettext = $(if $(BR2_NEEDS_EXTERNAL_GETTEXT),gettext)

Comments?

I was initially a bit puzzled when reading the doc, and really wondered
*why* I needed to do that in my package (remember, the huge QEMU stack
in the coming). I had to read the docs twice before I really saw where we
were going with these.

And no, updating the doc (my original issue) is not what I suggest. In
fact, the doc is pretty clear what to do and why. It's just that, in my
poor convoluted mind, I expected something much simpler than that. ;-)

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.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [RFC] Handling gettext

[Thomas Petazzoni]

Hello,

Le Fri, 31 Aug 2012 01:50:54 +0200,
"Yann E. MORIN" <yann.morin.1998@free.fr> a ?crit :

> Also, it breaks my script about the _AVAILABLE sutff.
> 
> What I suggest is the following:

Have you looked at
http://lists.busybox.net/pipermail/buildroot/2012-July/055871.html ?

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] [RFC] Handling gettext

[Yann E. MORIN]

Thomas, All,

On Friday 31 August 2012 09:25:02 Thomas Petazzoni wrote:
> Le Fri, 31 Aug 2012 01:50:54 +0200,
> "Yann E. MORIN" <yann.morin.1998@free.fr> a ?crit :
> 
> > Also, it breaks my script about the _AVAILABLE sutff.
> > 
> > What I suggest is the following:
> 
> Have you looked at
> http://lists.busybox.net/pipermail/buildroot/2012-July/055871.html ?

Well, I missed it, but nonetheless, I think my proposal can be added on-top
of that patchset.

Tonight is too late, but tomorrow I'll have a look at, and review this
patchset.

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.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [RFC] Handling gettext

[Arnout Vandecappelle]

On 08/31/12 23:58, Yann E. MORIN wrote:
> Thomas, All,
>
> On Friday 31 August 2012 09:25:02 Thomas Petazzoni wrote:
>> >  Le Fri, 31 Aug 2012 01:50:54 +0200,
>> >  "Yann E. MORIN"<yann.morin.1998@free.fr>  a ?crit :
>> >
>>> >  >  Also, it breaks my script about the _AVAILABLE sutff.
>>> >  >
>>> >  >  What I suggest is the following:
>> >
>> >  Have you looked at
>> >  http://lists.busybox.net/pipermail/buildroot/2012-July/055871.html  ?
> Well, I missed it, but nonetheless, I think my proposal can be added on-top
> of that patchset.

  I agree.  And this proposal is another great cleanup idea from Yann!

  Regards,
  Arnout
-- 
Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 +32-16-286540
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] [RFC] Handling gettext

[Samuel Martin]

Hi all,

2012/8/31 Yann E. MORIN <yann.morin.1998@free.fr>:
> Thomas, All,
>
> On Friday 31 August 2012 09:25:02 Thomas Petazzoni wrote:
>> Le Fri, 31 Aug 2012 01:50:54 +0200,
>> "Yann E. MORIN" <yann.morin.1998@free.fr> a ?crit :
>>
>> > Also, it breaks my script about the _AVAILABLE sutff.
>> >
>> > What I suggest is the following:
>>
>> Have you looked at
>> http://lists.busybox.net/pipermail/buildroot/2012-July/055871.html ?
>
> Well, I missed it, but nonetheless, I think my proposal can be added on-top
> of that patchset.
I don't think these patchsets are incompatible.
BTW, this cleanup would make things a lot easier for me when working
on the gettext refactoring.


Cheers,

-- 
Sam

[Buildroot] [RFC] Handling gettext

[Samuel Martin]

Hi Yann, all,

2012/8/31 Yann E. MORIN <yann.morin.1998@free.fr>:
> Hello All!
>
> Currently, defining dependency upon gettext is a bit convoluted:
>
>   config BR2_PACKAGE_FOO
>     select BR2_PACKAGE_GETTEXT if BR2_NEEDS_GETTEXT
>     select BR2_PACKAGE_LIBINTL if BR2_NEEDS_GETTEXT_IF_LOCALE
>
> I think that packages should not have to do that in this way, because
> I believe they should not have to deal with that complexity.
>
> What I mean is, for example, should the gettext issue gains some complexity,
> of is simplified, of we decide to always use a library instead of the libc's
> gettext, it would mean updating all packages.
>
> Also, it breaks my script about the _AVAILABLE sutff.
>
> What I suggest is the following:
>
> 0) Rename the current options:
>
>   BR2_NEEDS_GETTEXT            -->  BR2_NEEDS_EXTERNAL_GETTEXT
>
> 1) Add blind options that do the conditional selects:
>
>   config BR2_NEEDS_GETTEXT
>     bool
>     select BR2_PACKAGE_GETTEXT if BR2_NEEDS_EXTERNAL_GETTEXT
>
>   config BR2_NEEDS_LIBINTL
>     bool
>     select BR2_PACKAGE_LIBINTL if BR2_NEEDS_EXTERNAL_GETTEXT
>
> 2) simplify packages by selecting appropriate options:
>
>   config BR2_PACKAGE_FOO
>     select BR2_NEEDS_GETTEXT
>     select BR2_NEEDS_LIBINTL
I do like having such explicit things in BR:)

However, IIRC,  gettext comes if needed with i18n/l10n option from the
toolchain menu.
I may miss something obvious, but I don't get what is the behavior of
this when the i18n/l10n support is disabled. :-|

I mean, in the case package foo requires i18n/l10n support:  how do
you express the package foo dependency on the i18n/l10n support?
Is it through the *_AVAILABLE infra you're working on too?


Cheers,

-- 
Sam