buildroot/package/gettext/Config.in, branch 2017.11.2

toolchain: drop BR2_NEEDS_GETTEXT{,_IF_LOCALE}

2017-07-04T23:37:35+00:00

Now that all packages have been migrated to the new gettext logic, we can remove the BR2_NEEDS_GETTEXT and BR2_NEEDS_GETTEXT_IF_LOCALE variables. Signed-off-by: Thomas Petazzoni Reviewed-by: Arnout Vandecappelle (Essensium/Mind)

Revert "gettext: build libintl unconditionally for uClibc/musl"

2017-07-04T23:25:59+00:00

This reverts commit 431d00abc1ffd0db287f0392e45229a53db7a187, which in fact doesn't work for static linking situations, as can be seen in: http://autobuild.buildroot.net/results/a6a4039f23a6fbd2bdb5938bcef097a7310452cc/ Signed-off-by: Thomas Petazzoni

gettext: build libintl unconditionally for uClibc/musl

2017-07-04T22:13:24+00:00

Only the initial patches of the gettext series have been applied, and a bisectability problem has arised: when BR2_SYSTEM_ENABLE_NLS is disabled, which is the default, gettext no longer builds libintl. However, since packages have not yet been updated to the new gettext logic, they still try to link against libintl, because they rely on BR2_NEEDS_GETTEXT/BR2_NEEDS_GETTEXT_IF_LOCALE, which are true. So, as a temporary measure, we adjust the gettext package so that it unconditionally builds libintl for uClibc/musl, even when NLS is disabled. This commit will be reverted once all packages have been fixed. Fixes: http://autobuild.buildroot.net/results/a4cf71c34dcc5c750ea87a16014c2cb2d28cdebd/ (elfutils) http://autobuild.buildroot.net/results/cb9ae18295b21b3f9399be6edd82273add375656/ (linux-pam) http://autobuild.buildroot.net/results/4225e5dfb6bcf590d9c1068112472ee82bc87d6b/ (alsa-utils) Signed-off-by: Thomas Petazzoni

system: introduce BR2_SYSTEM_ENABLE_NLS

2017-07-04T17:09:55+00:00

Until now, the option BR2_ENABLE_LOCALE was more-or-less controlling whether NLS support was enabled in packages. More precisely, if BR2_ENABLE_LOCALE=y, we were not doing anything (so some packages could have NLS support enabled, some not). And only when BR2_ENABLE_LOCALE was disabled we were explicitly passing --disable-nls to packages. This doesn't make much sense, and there is no reason to tie NLS support to locale support. You may want locale support, but not necessarily NLS support. Therefore, this commit introduces BR2_SYSTEM_ENABLE_NLS, which allows to enable/disable NLS support globally. When this option is enabled, we pass --enable-nls to packages, otherwise we pass --disable-nls. In addition, when this option is enabled and the C library doesn't provide a full-blown implementation of gettext, we select the gettext package, which will provide the full blown implementation. It is worth mentioning that this commit has a visible impact for users: - Prior to this commit, as soon as BR2_ENABLE_LOCALE=y, packages *could* provide NLS support. It was up to each package to decide whether they wanted to provide NLS support or not (we were not passing --enable-nls nor --disable-nls). - After this commit, it's BR2_SYSTEM_ENABLE_NLS that controls whether NLS is enabled or disabled, and this option is disabled by default. Bottom line: with the default of BR2_SYSTEM_ENABLE_NLS disabled, some packages may lose NLS support that they used to provide. But we believe it's a reasonable default behavior for Buildroot, where generally NLS support is not necessary. Signed-off-by: Thomas Petazzoni Reviewed-by: Arnout Vandecappelle (Essensium/Mind) Signed-off-by: Thomas Petazzoni

gettext: force build libintl if needed

2017-07-04T17:09:51+00:00

This commit introduces a hidden option BR2_PACKAGE_GETTEXT_PROVIDES_INTL that is used by gettext.mk to force the build of libintl if the toolchain doesn't provide a full gettext implementation. For now, this hidden option is not selected by anything, but a follow-up commit will introduce BR2_ENABLE_NLS, which will make use of it. Signed-off-by: Thomas Petazzoni Reviewed-by: Arnout Vandecappelle (Essensium/Mind) Signed-off-by: Thomas Petazzoni

gettext: allow building when BR2_NEEDS_GETTEXT is not selected

2014-08-18T08:35:56+00:00

Until now, we thought that gettext was only needed for the target for uClibc toolchains, to provide the gettext functions that are normally provided directly by glibc. However, the gettext runtime actually does more than providing the equivalent of those C library functions: it also provides certain command line tools, like 'gettext' to get translated strings from the shell. This tool is for example used by certain ecryptfs-utils scripts to get translated strings. It is therefore necessary to be able to build the gettext package even for glibc toolchains. Signed-off-by: Thomas Petazzoni Signed-off-by: Peter Korsgaard

gettext: remove support for gettext-tools on target

2014-06-09T13:43:09+00:00

This commit removes the BR2_PACKAGE_GETTEXT_TOOLS option, which could be used to install gettext tools on the target. This is not needed, because Buildroot is not designed to provide a full development environment on the target, and gettext translation files should be processed on the build machine, using the host gettext tools. Remove this option will allow to optimize the build time of gettext on the target, by only building the gettext runtime libraries. Signed-off-by: Thomas Petazzoni Tested-by: Andrew Ruder Reviewed-by: "Yann E. MORIN"

Config.in files: use if/endif instead of 'depends on' for main symbol

2013-12-25T11:21:39+00:00

In the Config.in file of package foo, it often happens that there are other symbols besides BR2_PACKAGE_FOO. Typically, these symbols only make sense when foo itself is enabled. There are two ways to express this: with depends on BR2_PACKAGE_FOO in each extra symbol, or with if BR2_PACKAGE_FOO ... endif around the entire set of extra symbols. The if/endif approach avoids the repetition of 'depends on' statements on multiple symbols, so this is clearly preferred. But even when there is only one extra symbol, if/endif is a more logical choice: - it is future-proof for when extra symbols are added - it allows to have just one strategy instead of two (less confusion) This patch modifies the Config.in files accordingly. Signed-off-by: Thomas De Schampheleire Signed-off-by: Thomas Petazzoni

Config.in files: add missing dependencies to toolchain option comments

2013-11-10T22:59:57+00:00

When a package A depends on config option B and toolchain option C, then the comment that is given when C is not fulfilled should also depend on B. For example: config BR2_PACKAGE_A depends on BR2_B depends on BR2_LARGEFILE depends on BR2_WCHAR comment "A needs a toolchain w/ largefile, wchar" depends on !BR2_LARGEFILE || !BR2_WCHAR This comment should actually be: comment "A needs a toolchain w/ largefile, wchar" depends on BR2_B depends on !BR2_LARGEFILE || !BR2_WCHAR or if possible (typically when B is a package config option declared in that same Config.in file): if BR2_B comment "A needs a toolchain w/ largefile, wchar" depends on !BR2_LARGEFILE || !BR2_WCHAR [other config options depending on B] endif Otherwise, the comment would be visible even though the other dependencies are not met. This patch adds such missing dependencies, and changes existing such dependencies from depends on BR2_BASE_DEP && !BR2_TOOLCHAIN_USES_GLIBC to depends on BR2_BASE_DEP depends on !BR2_TOOLCHAIN_USES_GLIBC so that (positive) base dependencies are separate from the (negative) toolchain dependencies. This strategy makes it easier to write such comments (because one can simply copy the base dependency from the actual package config option), but also avoids complex and long boolean expressions. Signed-off-by: Thomas De Schampheleire Acked-by: Arnout Vandecappelle (Essensium/Mind) (untested) Signed-off-by: Peter Korsgaard

Config.in files: unify comments of toolchain option dependencies

2013-10-14T20:45:57+00:00

This patch lines up the comments in Config.in files that clarify which toolchain options the package depends on. Signed-off-by: Thomas De Schampheleire Signed-off-by: Peter Korsgaard