Re: [cmake-developers] CMake unicode support

2013-10-11 Thread Brad King
On 10/11/2013 12:05 AM, clin...@elemtech.com wrote:
 I've started some work towards supporting Unicode in CMake so I could get 
 better support for building/testing our internationalized applications.
 https://github.com/clintonstimpson/CMake/commit/f08ca2ff65f434b2bc404000765a836880f78f0e

Wow, thanks for working on this.

 There are plenty of changes in KWSys so the patch probably needs to be split 
 up.

Let's start with the KWSys pieces because that will try out use
of the APIs everywhere quickly and before merging.

Thanks,
-Brad
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers


Re: [cmake-developers] CMake unicode support

2013-10-11 Thread David Cole
Wow! Impressive...

Good luck getting this into CMake; I'd love to see UNICODE support through and 
through.


:-)
David C.

--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

[cmake-developers] CMake unicode support

2013-10-10 Thread clinton
Hi All, 

I've started some work towards supporting Unicode in CMake so I could get 
better support for building/testing our internationalized applications. 
https://github.com/clintonstimpson/CMake/commit/f08ca2ff65f434b2bc404000765a836880f78f0e
 

It keeps char* / std::string throughout the code where utf-8 is assumed on 
Windows and the current encoding on other platforms (usually utf-8). 
Conversions to wchar_t are done on demand when calling Windows apis. In other 
words, its mainly just a change to move towards unicode aware apis on Windows. 
It calls the wide version of Windows apis explicitly, so it does not matter 
whether one is compiling with -DUNICODE/-D_UNICODE or not. I assumed Win9x 
support is no longer needed, so there was no attempt to enable calling the old 
ANSI version of the apis. 

I haven't gotten as far as I hoped because of unicode limitations in Visual 
Studio. For example, custom commands in visual studio executed with cmd.exe has 
problems with encoding. When I reported this to Microsoft, they said it works 
better on Windows 8, but I don't have that right now. I was able to make my own 
utf-8 .bat files and call cmd.exe (with appropriate settings) myself and it 
worked just fine. Somehow, its different when Visual Studio does the same for 
custom commands. 

Any feedback or patches would be appreciated. For instance, std::ifstream/std:: 
ofstream/fopen need to be done special, and maybe some of you would prefer to 
have a wrapper for that. 

There are plenty of changes in KWSys so the patch probably needs to be split 
up. 

Although probably not an entire solution, it gets us part of the way there. I 
think this scope of changes can be merged in and further work done later which 
can include others. Overall, these changes don't really change the programs 
behavior except that some things which have already been working on other 
platforms start to work on Windows. 

Clint 
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers