| Message ID | 20190212215520.7422-1-vadim4j@gmail.com |
|---|---|
| Headers | show |
| Series | Add gettext-tiny package | expand |
Hello, On Tue, 12 Feb 2019 23:55:18 +0200 Vadim Kochan <vadim4j@gmail.com> wrote: > Add lightweight alternative for the GNU gettext package - gettext-tiny. > The sources are used from sabotage-linux project. Some files are used > from the original gettext gnu like po/*, gettextize and some m4 files. > > The original gettext package is renamed to gettext-gnu because now gettext is > a virtual package and gettext-gnu and gettext-tiny became as gettext providers. > > The main purpose of gettext-tiny is to be used only for the host if NLS > is not enabled. I finally took some time to play around with this. The first thing is that I didn't like a lot the download of lots of gettext-gnu files from gettext-tiny. I've played a bit with this, and ended up trying to use the gettext-gnu tarball instead. See: https://github.com/tpetazzoni/buildroot/tree/gettext-tiny https://github.com/tpetazzoni/buildroot/commit/22936b22944f49646c8732fb2742a526d0a556e2#diff-e5eacf305a325109262748204673e7b5R19 for the details. It also avoids the need to patch to get config.rpath, because config.rpath is available in the gettext-gnu tarball. I also reworked how the virtual package was handled, but I then understood that I had mistaken that only the host package was really a virtual package with two implementation: the target gettext package has only one implementation: gettext-gnu. However, the ecryptfs-utils case has shown that it is possible for a package to need a gettext implementation even if BR2_SYSTEM_ENABLE_NLS is disabled. So from there, we have two solutions: - Patch ecryptfs-utils itself so that it doesn't use gettext when --disable-nls is used. Perhaps this is the right thing to do. In this case, we could indeed mandate that the target gettext package is only available when BR2_SYSTEM_ENABLE_NLS=y, and therefore indeed have the gettext virtual package always point to gettext-gnu. - Alternatively, support gettext-tiny as a target package, which would provide both libintl and the gettext program (the latter to please ecryptfs-utils). I was initially worried that some packages that don't understand --disable-nls might try to link with libintl, and that we would therefore need a target gettext package even if BR2_SYSTEM_ENABLE_NLS. However, libintl is only a replacement library for the gettext functions that don't exist in uclibc/musl, but do exist in glibc. Because in glibc they are part of the C library itself, I don't think any package is ever going to link explicitly with libintl. It's only Buildroot that ensures -lintl is passed to the LIBS/LDFLAGS when needed. So I believe we're good. So, perhaps the good solution is option (1) above ? Thomas
Hi Thomas! On Sat, Mar 09, 2019 at 11:37:42PM +0100, Thomas Petazzoni wrote: > Hello, > > On Tue, 12 Feb 2019 23:55:18 +0200 > Vadim Kochan <vadim4j@gmail.com> wrote: > > > Add lightweight alternative for the GNU gettext package - gettext-tiny. > > The sources are used from sabotage-linux project. Some files are used > > from the original gettext gnu like po/*, gettextize and some m4 files. > > > > The original gettext package is renamed to gettext-gnu because now gettext is > > a virtual package and gettext-gnu and gettext-tiny became as gettext providers. > > > > The main purpose of gettext-tiny is to be used only for the host if NLS > > is not enabled. > > I finally took some time to play around with this. The first thing is > that I didn't like a lot the download of lots of gettext-gnu files from > gettext-tiny. I've played a bit with this, and ended up trying to use > the gettext-gnu tarball instead. See: > > https://github.com/tpetazzoni/buildroot/tree/gettext-tiny > https://github.com/tpetazzoni/buildroot/commit/22936b22944f49646c8732fb2742a526d0a556e2#diff-e5eacf305a325109262748204673e7b5R19 > > for the details. It also avoids the need to patch to get config.rpath, > because config.rpath is available in the gettext-gnu tarball. > > I also reworked how the virtual package was handled, but I then > understood that I had mistaken that only the host package was really a > virtual package with two implementation: the target gettext package has > only one implementation: gettext-gnu. > > However, the ecryptfs-utils case has shown that it is possible for a > package to need a gettext implementation even if BR2_SYSTEM_ENABLE_NLS > is disabled. So from there, we have two solutions: > > - Patch ecryptfs-utils itself so that it doesn't use gettext when > --disable-nls is used. Perhaps this is the right thing to do. In > this case, we could indeed mandate that the target gettext package > is only available when BR2_SYSTEM_ENABLE_NLS=y, and therefore indeed > have the gettext virtual package always point to gettext-gnu. > > - Alternatively, support gettext-tiny as a target package, which would > provide both libintl and the gettext program (the latter to please > ecryptfs-utils). > > I was initially worried that some packages that don't understand > --disable-nls might try to link with libintl, and that we would > therefore need a target gettext package even if BR2_SYSTEM_ENABLE_NLS. > However, libintl is only a replacement library for the gettext > functions that don't exist in uclibc/musl, but do exist in glibc. > Because in glibc they are part of the C library itself, I don't think > any package is ever going to link explicitly with libintl. It's only > Buildroot that ensures -lintl is passed to the LIBS/LDFLAGS when > needed. So I believe we're good. > > So, perhaps the good solution is option (1) above ? Many thanks for your feedback! Using the gnu gettext's tar is really better idea! Regarding ecryptfs-utils - yes, I think the patch might be really easy, something like this: ... function trans { if command -v gettext &> /dev/null; then gettext @ else echo @ fi } ... and replace gettext -> trans in scripts. Regards, Vadim Kochan
Hello Vadim, On Sun, 10 Mar 2019 02:20:05 +0200 Vadim Kochan <vadim4j@gmail.com> wrote: > Many thanks for your feedback! Using the gnu gettext's tar is really better > idea! Regarding ecryptfs-utils - yes, I think the patch might be really easy, > something like this: > > ... > function trans { > if command -v gettext &> /dev/null; then > gettext @ > else > echo @ > fi > } > ... > > and replace gettext -> trans in scripts. Sounds good! Will you work on this ? So, we agree that for the target gettext, only gettext-gnu will be a provider when BR2_SYSTEM_ENABLE_NLS=y. When BR2_SYSTEM_ENABLE_NLS is disabled, we don't have any target gettext package. Correct ? If so, then I'll rework my branch to take this into account. Thanks, Thomas
Vadim, All, On 2019-03-10 10:11 +0100, Thomas Petazzoni spake thusly: > On Sun, 10 Mar 2019 02:20:05 +0200 > Vadim Kochan <vadim4j@gmail.com> wrote: > > > Many thanks for your feedback! Using the gnu gettext's tar is really better > > idea! Regarding ecryptfs-utils - yes, I think the patch might be really easy, > > something like this: > > > > ... > > function trans { > > if command -v gettext &> /dev/null; then 'command' is not a POSIX builtin; it's a bashism, so there is no guarantee it is available: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html So, maybe: if which gettext >/dev/null; then gettext "${@}" else echo "${@}" fi Alternatively, I believe it would be relatively trivial to provide a fake gettext rwapper: #!/bin/sh while [ ${#} -ne 0 ]; do case "${1}" in (-h) echo "no help"; exit 0;; (-V) echo "0.0.0"; exit 0;; (-d|--domain) shift 2;; (-d*|--domain=*) shift 1;; (-e|-E|-n) shift 1;; (-s) shift 1;; # Ignore? (*) break;; esac done case ${#} in (0) ;; (1) echo "${1}";; # No TEXTDOMAIN? (*) shift; echo "${@}";; # Ignore TEXTDOMAIN? esac Regards, Yann E. MORIN. > > gettext @ > > else > > echo @ > > fi > > } > > ... > > > > and replace gettext -> trans in scripts. > > Sounds good! Will you work on this ? > > So, we agree that for the target gettext, only gettext-gnu will be a > provider when BR2_SYSTEM_ENABLE_NLS=y. When BR2_SYSTEM_ENABLE_NLS is > disabled, we don't have any target gettext package. Correct ? If so, > then I'll rework my branch to take this into account. > > Thanks, > > Thomas > -- > Thomas Petazzoni, CTO, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com
Hi Yann, Thomas, All On Sun, Mar 10, 2019 at 11:18:52AM +0100, Yann E. MORIN wrote: > Vadim, All, > > On 2019-03-10 10:11 +0100, Thomas Petazzoni spake thusly: > > On Sun, 10 Mar 2019 02:20:05 +0200 > > Vadim Kochan <vadim4j@gmail.com> wrote: > > > > > Many thanks for your feedback! Using the gnu gettext's tar is really better > > > idea! Regarding ecryptfs-utils - yes, I think the patch might be really easy, > > > something like this: > > > > > > ... > > > function trans { > > > if command -v gettext &> /dev/null; then > > 'command' is not a POSIX builtin; it's a bashism, so there is no > guarantee it is available: > > http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html > > So, maybe: > > if which gettext >/dev/null; then > gettext "${@}" > else > echo "${@}" > fi > > Alternatively, I believe it would be relatively trivial to provide a > fake gettext rwapper: > > #!/bin/sh > > while [ ${#} -ne 0 ]; do > case "${1}" in > (-h) echo "no help"; exit 0;; > (-V) echo "0.0.0"; exit 0;; > (-d|--domain) shift 2;; > (-d*|--domain=*) shift 1;; > (-e|-E|-n) shift 1;; > (-s) shift 1;; # Ignore? > (*) break;; > esac > done > case ${#} in > (0) ;; > (1) echo "${1}";; # No TEXTDOMAIN? > (*) shift; echo "${@}";; # Ignore TEXTDOMAIN? > esac > > Regards, > Yann E. MORIN. Yann, thanks for this! > > > > gettext @ > > > else > > > echo @ > > > fi > > > } > > > ... > > > > > > and replace gettext -> trans in scripts. > > > > Sounds good! Will you work on this ? > > > > So, we agree that for the target gettext, only gettext-gnu will be a > > provider when BR2_SYSTEM_ENABLE_NLS=y. When BR2_SYSTEM_ENABLE_NLS is > > disabled, we don't have any target gettext package. Correct ? If so, > > then I'll rework my branch to take this into account. > > > > Thanks, > > > > Thomas But, it looks like that there should be no problem if NLS is disabled (host-gettext is provided by gettext-tiny) and gettext (target) (provided by gettext-gnu) are enabled in the same time (of course 1 small fix is required in latest gettext-tiny series v3): in file package/gettext/Config.in > config BR2_PACKAGE_GETTEXT > bool "gettext" > select BR2_PACKAGE_HAS_GETTEXT *remove -> depends on BR2_SYSTEM_ENABLE_NLS remove dependens on NLS to select gettext-gnu for the target. So, both host-gettext-tiny and gettext-gnu should coexist as they provides different instances, right ? If this is ok, then of course ecryptfs-utils needs support the gettext-less version, but it might be done later out of this scope ? Regards, Vadim Kochan
On Sun, 10 Mar 2019 11:18:52 +0100 "Yann E. MORIN" <yann.morin.1998@free.fr> wrote: > Alternatively, I believe it would be relatively trivial to provide a > fake gettext rwapper: Well, that was the whole point of the discussion in my initial reply to Vadim's v3. Do we want to create a gettext-tiny target variant, which would install a fake gettext wrapper, or do we say "if NLS is disabled, there is no gettext support on the target". See my reply to Vadim v3 cover letter. Best regards, Thomas
Hello, On Mon, 11 Mar 2019 01:05:32 +0200 Vadim Kochan <vadim4j@gmail.com> wrote: > But, it looks like that there should be no problem if NLS is disabled > (host-gettext is provided by gettext-tiny) and gettext (target) > (provided by gettext-gnu) are enabled in the same time (of course 1 > small fix is required in latest gettext-tiny series v3): > > in file package/gettext/Config.in > > > config BR2_PACKAGE_GETTEXT > > bool "gettext" > > select BR2_PACKAGE_HAS_GETTEXT > *remove -> depends on BR2_SYSTEM_ENABLE_NLS > > remove dependens on NLS to select gettext-gnu for the target. > > So, both host-gettext-tiny and gettext-gnu should coexist as they > provides different instances, right ? > > If this is ok, then of course ecryptfs-utils needs support the gettext-less > version, but it might be done later out of this scope ? I don't really like to do this. It's a lot better if we can avoid gettext-gnu entirely if NLS is disabled. So I'd prefer if we could stick to one of the two options I proposed in my reply to your v3: Option 1: we fix ecryptfs-utils to not unconditionally use gettext. Option 2: we improve gettext-tiny so that it provides a fake gettext implementation, and we allow gettext-tiny as a gettext implementation for the target. Best regards, Thomas
Hi Thomas, Yann, All On Mon, Mar 11, 2019 at 09:02:35AM +0100, Thomas Petazzoni wrote: > Hello, > > On Mon, 11 Mar 2019 01:05:32 +0200 > Vadim Kochan <vadim4j@gmail.com> wrote: > > > But, it looks like that there should be no problem if NLS is disabled > > (host-gettext is provided by gettext-tiny) and gettext (target) > > (provided by gettext-gnu) are enabled in the same time (of course 1 > > small fix is required in latest gettext-tiny series v3): > > > > in file package/gettext/Config.in > > > > > config BR2_PACKAGE_GETTEXT > > > bool "gettext" > > > select BR2_PACKAGE_HAS_GETTEXT > > *remove -> depends on BR2_SYSTEM_ENABLE_NLS > > > > remove dependens on NLS to select gettext-gnu for the target. > > > > So, both host-gettext-tiny and gettext-gnu should coexist as they > > provides different instances, right ? > > > > If this is ok, then of course ecryptfs-utils needs support the gettext-less > > version, but it might be done later out of this scope ? > > I don't really like to do this. It's a lot better if we can avoid > gettext-gnu entirely if NLS is disabled. So I'd prefer if we could > stick to one of the two options I proposed in my reply to your v3: > > Option 1: we fix ecryptfs-utils to not unconditionally use gettext. > > Option 2: we improve gettext-tiny so that it provides a fake gettext > implementation, and we allow gettext-tiny as a gettext implementation > for the target. > Regarding ecryptfs-utils, looks like it is easy just to use function with "gettext" name and if gettext exists (by "which") then use the full path which is returned by "which", otherwise I think it is OK to use just "echo" or Yann's wrapper. Here is a sample script: ----------8<---------------- #! /bin/sh GETTEXT_PROG="" gettext() { if [ -z "${GETTEXT_PROG}" ]; then GETTEXT_PROG=$(which gettext) if [ $? != 0 ]; then GETTEXT_PROG=echo fi fi ${GETTEXT_PROG} "$@" } gettext "XXXXXXXXXXXX" gettext "ZZZZZZZZZZZZ" gettext "CCCCCCCCCCCC" -------->8------------------ Of course copy-n-pasting it to even few ecryptfs-utils's scripts looks not good, the better way if each script will source some 'common' one which has this gettext function. Otherwise, the better if gettext-tiny installs one for target because it may work w/o changing ecryptfs-utils, and it will work for other packages which may use gettext tool. So I will start with ecryptfs-utils. Regards, Vadim Kochan
Add lightweight alternative for the GNU gettext package - gettext-tiny. The sources are used from sabotage-linux project. Some files are used from the original gettext gnu like po/*, gettextize and some m4 files. The original gettext package is renamed to gettext-gnu because now gettext is a virtual package and gettext-gnu and gettext-tiny became as gettext providers. The main purpose of gettext-tiny is to be used only for the host if NLS is not enabled. There was issue with using gettext-tiny for "wine" because it requires libgettextpo for wrc tool to be able translate Windows's resource files to *.pot, but this option might be disabled if NLS is disabled (done in patch 0001. v3: 1) Rebased on master. 2) Drop wine related patch which is already applied. v2: 1) Add patch to disable gettext option for "wine" if NLS is disabled. 2) Fix build issue with libuio by adding config.rpath by separate package patch: 0002-Add-config.rpath-from-gettext-gnu-distro-0.19.8.1.patch 3) Use gettext-tiny only as for HOST alternative and if NLS is disabled. There is no option to manually select gettext-gnu or gettext-tiny which is controlled by gettext virtual package. 4) Drop "files" folder with copied files from original gettext gnu, but download them from: https://git.savannah.gnu.org/cgit/gettext.git Thanks to Yann E. Morin for help with this. 5) gettextize is preprocessed from the original gettextize.in 6) Use only host-generic-package for gettext-tiny, hence remove "target" related stuff. Vadim Kochan (2): package/gettext: Turn into virtual package package/gettext-tiny: Add new package DEVELOPERS | 1 + .../0001-error_print_progname.patch | 0 .../0002-Update-after-gnulib-changed.patch | 0 .../gettext.hash => gettext-gnu/gettext-gnu.hash} | 0 package/gettext-gnu/gettext-gnu.mk | 103 +++ ...-format-not-a-string-literal-error-for-gc.patch | 55 ++ ...ig.rpath-from-gettext-gnu-distro-0.19.8.1.patch | 709 +++++++++++++++++++++ package/gettext-tiny/gettext-tiny.hash | 14 + package/gettext-tiny/gettext-tiny.mk | 104 +++ package/gettext/Config.in | 27 +- package/gettext/gettext.mk | 96 +-- 11 files changed, 1010 insertions(+), 99 deletions(-) rename package/{gettext => gettext-gnu}/0001-error_print_progname.patch (100%) rename package/{gettext => gettext-gnu}/0002-Update-after-gnulib-changed.patch (100%) rename package/{gettext/gettext.hash => gettext-gnu/gettext-gnu.hash} (100%) create mode 100644 package/gettext-gnu/gettext-gnu.mk create mode 100644 package/gettext-tiny/0001-libintl-Fix-format-not-a-string-literal-error-for-gc.patch create mode 100644 package/gettext-tiny/0002-Add-config.rpath-from-gettext-gnu-distro-0.19.8.1.patch create mode 100644 package/gettext-tiny/gettext-tiny.hash create mode 100644 package/gettext-tiny/gettext-tiny.mk