Re: Re*: [PATCH/RFC] Change t0204-gettext-reencode-sanity.sh to pass under Mac OSX

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Torsten Bögershausen <tboegi@xxxxxx> writes:

> On 03/11/2012 08:22 PM, Junio C Hamano wrote:
> ...
>>   * Is USE_GETTEXT_SCHEME=gnu the right thing for Mac OS X?  It may
>>     make this test pass, but does it not break other things?  Does
>>     Mac OS X come with a working gettext.sh to help i18n of shell
>>     scripts?  Does it also give eval_gettext?
> When I remember it right, the following comes from the Fink
> installation on my machine:
> which gettext
> /sw/bin/gettext
>
> which gettext.sh
> /sw/bin/gettext.sh
>
> None of the machines here (Mac OS X, Ubuntu 10.04.4 LTS, OpenSuse 12.1)
> has a eval_gettext

No, we do not expect a standalone eval_gettext program.  If you
dot-source gettext.sh, some systems give you the eval_gettext shell
function, while there are other systems that don't.  Gnu systems
that ship with /usr/bin/gettext.sh do give you eval_gettext while
Solaris is known not to. I do not know what your system does, and
that was what the question was about.  What does this say there?

	$ (. gettext.sh; eval_gettext frotz; echo $?)

>>   * If so, Mac OS X users shouldn't have to say that from the command
>>     line of "make". Do we need a Makefile update?
> Good question.
> I couldn't find any setup of USE_GETTEXT_SCHEME in Makefile
> (except when NO_GETTEXT is set), do I need to run configure?
> So far the Makefile worked for all my systems here.

You shouldn't have to muck with autoconf around here. It is one of
the design goals of our Makefile to work out of the box on major
platforms as long as the prerequisites like POSIX compliant tools
and use of GNU make are met. An optional configure support comes
into the picture only once we know what we want to have in the
Makefile to be tweaked.

Also, as you noticed, even though we mention USE_GETTEXT_SCHEME in
the Makefile, no platforms with explicit support needs to tweak it;
if git-sh-i18n.sh can figure out what to do without having to rely
on any tweak in the Makefile, we would prefer to keep it that way.

What is curious about your system is that git-sh-i18n.sh should have
figured out that you want INTERNAL_GETTEXT_SH_SCHEME to be gnu by
itself, without any need for "make USE_GETTEXT_SCHEME=gnu", with
these lines:

                ...
        elif type gettext.sh >/dev/null 2>&1
        then
                # GNU libintl's gettext.sh
                GIT_INTERNAL_GETTEXT_SH_SCHEME=gnu
        elif test ...

as long as you have /sw/bin/gettext.sh on your PATH, that is.

So I am not sure what's broken.

>>   * If not, what is the appropriate value for USE_GETTEXT_SCHEME on=
>>     Mac OS X?  If the answer is not "fallthrough", do we need a
>>     Makefile update?
> My guess is that "gettext_without_eval_gettext" would be right
> (if we have Fink installed)

Are you sure that after dot-sourcing /sw/bin/gettext.sh, you do not
have eval_gettext?  If you do, then I think it can be set to gnu.

Ævar, I am wondering if the auto-detection part of git-sh-i18n
should read more like this to make sure when we declare gnu we know
eval_gettext is available.  What do you think?

 git-sh-i18n.sh |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/git-sh-i18n.sh b/git-sh-i18n.sh
index d5fae99..a17688b 100644
--- a/git-sh-i18n.sh
+++ b/git-sh-i18n.sh
@@ -27,7 +27,7 @@ then
 elif test -n "$GIT_GETTEXT_POISON"
 then
 	GIT_INTERNAL_GETTEXT_SH_SCHEME=poison
-elif type gettext.sh >/dev/null 2>&1
+elif (. gettext.sh && eval_gettext frotz) >/dev/null 2>&1
 then
 	# GNU libintl's gettext.sh
 	GIT_INTERNAL_GETTEXT_SH_SCHEME=gnu
--
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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]