qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [Patch 0/2] Fix QEMU configure / make with Turkish (and


From: Stefan Weil
Subject: Re: [Qemu-devel] [Patch 0/2] Fix QEMU configure / make with Turkish (and maybe other) locale
Date: Sun, 25 Mar 2012 21:48:33 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20120317 Iceowl/1.0b1 Icedove/3.0.11

Am 25.03.2012 21:27, schrieb Andreas Färber:
Am 25.03.2012 21:11, schrieb Stefan Weil:
These two patches override the user specific locale settings which
can break QEMU builds. They set the default locale C for configure
and make:

[PATCH v2 1/2] Makefile: Set default locale C
[PATCH 2/2] configure: Set default locale C (fix build for Turkish

A side effect is that all messages which are produced during configure
and make also use the default locale, so for example compiler messages
are no longer localized.

Reading the patches I thought of that issue, too, and don't think a
sledge hammer is the best solution here. The issue reported was tr (a
user-invisible invokation) misbehaving so why not fix just that? That
way user-directed output would still be in the language of the user's
choice.

Andreas

The answer is quite simple: there are lots of places where tr
is already used which would have to be modified (in configure
and several other scripts), and it's not only tr but also
the process which creates the html documentation which depends
on the locale (see commit message of patch 1).

As you see in my patch, I had to override three environment
variables to (hopefully) handle all cases which lead to wrong
results, so adding these overrides to each invocation of tr
or other programs which need it would result in rather long
command lines.

Of course many different solutions are possible. We could also
add a tr wrapper script, but I still prefer my solution because
it is easy and clean (only two locations which set the environment)
and safe (also works for problems which might exist and which we
still don't know, no problem when more scripts and external
programs like tr are added by future modifications).

Regards,
Stefan





reply via email to

[Prev in Thread] Current Thread [Next in Thread]