[Buildroot] [PATCH 1/1] package/transmission: fix gtk support

[Peter Korsgaard <peter@korsgaard.com>]

>>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes:

Hi,

 >> Why should we randomly pass --enable-nls to some packages? Why should
 >> this package depends on BR2_SYSTEM_ENABLE_NLS, if it needs NLS support?

 >  Because BR2_SYSTEM_ENABLE_NLS does not really say that NLS *support* is
 > enabled, it says that NLS *installation* is enabled. NLS support is always
 > "enabled" through the stubs in musl/uClibc.

 >  As far as I understand, the configure error is just there because the
 > transmission guys are too lazy to have conditional use of the intl functions. I
 > don't see how there could be a hard requirement on non-stub implementations of
 > the intl functions - except if they start calling internals. So the better
 > solution, actually, would be to patch out this check in configure and instead
 > check for intl and error out if that is not available, independent on the
 > --enable-nls option - just like most packages do, I think.

 >  If you're not actually interested in translations, there is no reason really
 > why you should pull them in just because this package is calling gettext stuff
 > unconditionally.

 >  That said, probably nobody really cares, we're just fixing build failures here.
 > So in the end I don't really mind if we depend on BR2_SYSTEM_ENABLE_NLS as the
 > easy way out. Though then the commit message should at least provide the full
 > story, as a hint for future contributors who want to fix it properly.

Correct. I went with depending on BR2_SYSTEM_ENABLE_NLS, but I added a
comment explaining that we could also explictly pass --enable-nls.

-- 
Bye, Peter Korsgaard