[Buildroot] [PATCH 1/1] package/transmission: fix gtk support
Peter Korsgaard
peter at korsgaard.com
Fri Sep 1 23:18:52 UTC 2017
>>>>> "Arnout" == Arnout Vandecappelle <arnout at 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
More information about the buildroot
mailing list