While the no-op C patch series is cooking I thought I'd send an RFC
for the no-op shellscript infrastructure. So here (as threatened in
<AANLkTinUtqJJHNyS9CxrC=VnS87v=GH=pOw9yr4r=pii@xxxxxxxxxxxxxx>[1]) is
the infrastructure needed to gettextize the shell script programs.
To quote my previous E-Mail[1] here are the things that are DONE and
still need to be done.
Open issues:
* Write documentation for git-sh-i18n.sh and git-sh-i18n--envsubst
like we have for git-sh-setup (already in WIP form).
It now has documentation. So this isn't a problem anymore.
* git-sh-i18n--envsubst is still too fat:
$ ldd -r git-sh-i18n--envsubst
linux-vdso.so.1 => (0x00007fffc60fd000)
libz.so.1 => /usr/lib/libz.so.1 (0x00007f25cff9e000)
libcrypto.so.0.9.8 => /usr/lib/libcrypto.so.0.9.8
(0x00007f25cfbfd000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00007f25cf9e0000)
libc.so.6 => /lib/libc.so.6 (0x00007f25cf67f000)
libdl.so.2 => /lib/libdl.so.2 (0x00007f25cf47b000)
/lib64/ld-linux-x86-64.so.2 (0x00007f25d01c0000)
It only needs to link to libc, but I didn't find out when I last
checked how to convince the Makefile to only link against
that. Help welcome :)
This is still an issue. It needs to link to libgit for xmalloc() and
friends, but it doesn't need libz, libcrypto etc.
* Deal with the changes in 92c62a3f4f93432c0c82e3031a9e64e03ba290f7:
$ git --no-pager grep -A1 abomination *.sh
git-pull.sh: # XXX: This is an abomination
git-pull.sh- require_clean_work_tree "pull with
rebase" "Please commit or stash them."
The changes Ramkumar Ramachandra made in 92c62a3f4f, while good,
are hard to square with i18n.
I think I'll just leave those bits untranslated for now and deal
with them later, since I'm trying to keep this minimal.
This is not part of this RFC series, but I still haven't dealt with it
in my branch.
And then there's the issue that unlike the C patches these will not be
a no-op that'll be optimized away by the compiler. We'll be calling an
external program for displaying messages. While this is a trivial cost
on Unix (especially in the context we're using it, i.e. not in tight
loops) it's more expensive on Windows.
I don't see any way to deal with that short of implementing some
pre-processor, but I think the cost is worth it, but others might
disagree of course.
This is still a problem I think. Although there's been some work on
this on the MinGW front from what I can gleam from the mailing list.
1. http://www.spinics.net/lists/git/msg151971.html
Ãvar ArnfjÃrà Bjarmason (2):
git-sh-i18n--envsubst: our own envsubst(1) for eval_gettext()
git-sh-i18n.sh: add no-op gettext() and eval_gettext() wrappers
.gitignore | 3 +
Documentation/git-sh-i18n--envsubst.txt | 36 +++
Documentation/git-sh-i18n.txt | 57 ++++
Makefile | 2 +
git-sh-i18n.sh | 17 ++
sh-i18n--envsubst.c | 444 +++++++++++++++++++++++++++++++
6 files changed, 559 insertions(+), 0 deletions(-)
create mode 100644 Documentation/git-sh-i18n--envsubst.txt
create mode 100644 Documentation/git-sh-i18n.txt
create mode 100644 git-sh-i18n.sh
create mode 100644 sh-i18n--envsubst.c
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html