[cmake-developers] CTest update broken with non-ASCII filenames

Nils Gladitz nilsgladitz at gmail.com
Thu Apr 9 15:08:20 EDT 2015


On 09.04.2015 20:39, Rolf Eike Beer wrote:
> Am Donnerstag, 9. April 2015, 10:30:35 schrieb Brad King:
>> On 04/09/2015 10:28 AM, Nils Gladitz wrote:
>>>> What was the original problem you were trying to fix?
>>> You pointed out test failures on "nibble.ngladitz" which I then tried to
>>> fix:
>>>
>>> https://open.cdash.org/testDetails.php?test=316350872&build=3711574
>> Right, I forgot about that, thanks.  So, this was exposed by
>> using the zh_HK locale.
> Just guessing: C will be "ASCII", i.e. "every 8 bit character gets mangled"
> (or at least everything not being able to be displayed in a 256 byte
> codepage). So a fix could be to use something like en_US.UTF-8, if that is
> available on the system, which sadly may not always be the case.

I merged "c-locale-messages" which tries to preserve LC_CTYPE (which 
affects filename encodings) in the presence of LC_ALL and sets 
LC_MESSAGES to C (which affects output messages).
This does seem to fix both cases for me.

Forcing UTF-8 might not be the correct way to go since people might be 
using other encoding beyond ASCII and UTF-8.
It has been a while but I think I used to run linux distros with e.g. 
something similar to "en_US.ISO-8859-1".
Haven't seen anything like that since but I am not really that familiar 
with what other system use ... also aren't locale names themselves 
platform specific?

I implemented this outside of CTest hoping this might be something that 
could be reused elsewhere as well.
Since running external processes with english ASCII messages is a common 
pattern I was thinking it could be added to e.g. execute_process() with 
a new e.g. "C_LOCALE_MESSAGES" flag?

Nils


More information about the cmake-developers mailing list