[cmake-developers] [PATCH v5] For consoles output on Windows use our own std::streambuf

Currently Microsoft's C++ libraries implementation of std::cout/cerr can't output Unicode characters but only ASCII or ANSI if locale is set so we implement and use our own ConsoleBuf which can output Unicode characters to console and it doesn't matter what locale or console's codepage is set. ---

Re: [cmake-developers] [PATCH v4 4/4] For Windows encode process output to internally used encoding

2016-07-21 20:46 GMT+03:00 Brad King <brad.k...@kitware.com>: > On 07/21/2016 01:36 PM, Dāvis Mosāns wrote: >> Anyway I improved this in places where it was easy, but in some places it's >> more complicated... >> >> For example >> >>while ((p = cm

[cmake-developers] [PATCH v6] For Windows encode process output to internally used encoding

Typically Windows applications (eg. MSVC compiler) use current console's codepage for output to pipes so we need to encode that to internally used encoding (KWSYS_ENCODING_DEFAULT_CODEPAGE). --- Source/CMakeLists.txt | 2 + Source/ProcessOutput.hxx.in| 160

[cmake-developers] [PATCH v4] Add MinGW support for FStream

std::basic_filebuf::open(const wchar_t *) isn't part of C++ standard and it's only present for MSVC but it isn't present in libstdc++ (MinGW) so we implement this functionality using GNU libstdc++ stdio_filebuf extension and _wfopen function. --- CMakeLists.txt | 14 +++

[cmake-developers] [PATCH v5 1/2] Refactor FStream (basic_ifstream and basic_ofstream classes)

Use common basic_efilebuf for both to reduce code duplication. --- Source/kwsys/FStream.hxx.in | 164 +--- 1 file changed, 95 insertions(+), 69 deletions(-) diff --git a/Source/kwsys/FStream.hxx.in b/Source/kwsys/FStream.hxx.in index 681e4d8..248b0cb

[cmake-developers] [PATCH v5 2/2] Add MinGW support for FStream

std::basic_filebuf::open(const wchar_t *) isn't part of C++ standard and it's only present for MSVC but it isn't present in libstdc++ (MinGW) so we implement this functionality using GNU libstdc++ stdio_filebuf extension and _wfopen function. --- Source/kwsys/CMakeLists.txt| 5 ++

Re: [cmake-developers] [PATCH v4 fixed 1/4] On Windows use correct encoding for SystemTools::GetEnv

2016-07-08 16:04 GMT+03:00 Brad King <brad.k...@kitware.com>: > On 07/07/2016 06:32 PM, Dāvis Mosāns wrote: >> On Windows getenv (and putenv) uses ANSI codepage so it needs to be encoded >> to internally used encoding (eg. UTF-8). Here we use _wgetenv (and _wputenv)

[cmake-developers] [PATCH v3 5/7] For consoles output on Windows use our own std::streambuf

Currently Microsoft's C++ libraries implementation of std::cout/cerr can't output Unicode characters but only ASCII or ANSI if locale is set so we implement and use our own ConsoleBuf which can output Unicode characters to console and it doesn't matter what locale or console's codepage is set. ---

[cmake-developers] [PATCH v3 1/7] On Windows use correct encoding for SystemTools::GetEnv

On Windows getenv (and putenv) uses ANSI codepage so it needs to be encoded to internally used encoding (eg. UTF-8). Here we use _wgetenv (and _wputenv) instead and encode that. Also add SystemTools::HasEnv function. --- Source/kwsys/SystemTools.cxx| 56

[cmake-developers] [PATCH v3 7/7] Add MinGW support for FStream

std::basic_filebuf::open(const wchar_t *) isn't part of C++ standard and it's only present for MSVC but it's not present in libstdc++ (MinGW) so we implement this functionality using GNU stdio_filebuf extension and _wfopen function. --- Source/kwsys/FStream.hxx.in | 117

[cmake-developers] [PATCH v3 2/7] Deprecate const char* SystemTools::GetEnv function

On Windows this function returns environment variable encoded in ANSI codepage which might not match internally used encoding. --- Source/kwsys/SystemTools.hxx.in | 14 -- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/Source/kwsys/SystemTools.hxx.in

[cmake-developers] [PATCH v3 6/7] Use Windows version of Directory::Load for MinGW too

Otherwise it would use POSIX functions which works only for ASCII paths. --- Source/kwsys/Directory.cxx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Source/kwsys/Directory.cxx b/Source/kwsys/Directory.cxx index c549792..659c559 100644 --- a/Source/kwsys/Directory.cxx +++

[cmake-developers] [PATCH v3 3/7] Use SystemTools::GetEnv and HasEnv functions

--- Source/CPack/cmCPackGenerator.cxx | 8 +++--- Source/CTest/cmCTestCoverageHandler.cxx | 12 - Source/CTest/cmCTestCurl.cxx| 27 ++-- Source/CTest/cmCTestMultiProcessHandler.cxx | 8 +++--- Source/cmBuildCommand.cxx | 25

[cmake-developers] [PATCH v3 4/7] For Windows encode process output to internally used encoding

Typically Windows applications (eg. MSVC compiler) use current console's codepage for output to pipes so we need to encode that to internally used encoding (KWSYS_ENCODING_DEFAULT_CODEPAGE). --- Source/kwsys/CMakeLists.txt | 2 ++ Source/kwsys/ProcessWin32.c | 25 - 2

Re: [cmake-developers] [PATCH v3 5/7] For consoles output on Windows use our own std::streambuf

t would output internal encoding which is unreadable for non-ASCII because console expects different codepage. As for encoding used for files it doesn't matter because we use same one for both writing and reading. It would matter if other applications would want to read it. And because it's set as

Re: [cmake-developers] [PATCH v3 7/7] Add MinGW support for FStream

2016-07-07 3:51 GMT+03:00 Mike Gelfand <mike...@mikedld.com>: > On 07/07/2016 03:33 AM, Dāvis Mosāns wrote: >> 2016-07-07 1:22 GMT+03:00 Mike Gelfand <mike...@mikedld.com>: >>>> @@ -92,19 +159,26 @@ namespace @KWSYS_NAMESPACE@ >>>> [snip] >>

[cmake-developers] [PATCH v4] For consoles output on Windows use our own std::streambuf

Currently Microsoft's C++ libraries implementation of std::cout/cerr can't output Unicode characters but only ASCII or ANSI if locale is set so we implement and use our own ConsoleBuf which can output Unicode characters to console and it doesn't matter what locale or console's codepage is set. ---

[cmake-developers] [PATCH v4 1/4] On Windows use correct encoding for SystemTools::GetEnv

On Windows getenv (and putenv) uses ANSI codepage so it needs to be encoded to internally used encoding (eg. UTF-8). Here we use _wgetenv (and _wputenv) instead and encode that. Also add SystemTools::HasEnv function. --- Source/kwsys/SystemTools.cxx| 78

[cmake-developers] [PATCH v4 4/4] For Windows encode process output to internally used encoding

Typically Windows applications (eg. MSVC compiler) use current console's codepage for output to pipes so we need to encode that to internally used encoding (KWSYS_ENCODING_DEFAULT_CODEPAGE). --- Source/cmExecProgramCommand.cxx| 1 + Source/cmExecuteProcessCommand.cxx | 1 +

[cmake-developers] [PATCH v4 3/4] Use SystemTools::GetEnv and HasEnv functions

--- Source/CPack/cmCPackGenerator.cxx | 8 +++--- Source/CTest/cmCTestCoverageHandler.cxx | 12 - Source/CTest/cmCTestCurl.cxx| 27 ++-- Source/CTest/cmCTestMultiProcessHandler.cxx | 8 +++--- Source/cmBuildCommand.cxx | 25

[cmake-developers] [PATCH v4 fixed 1/4] On Windows use correct encoding for SystemTools::GetEnv

On Windows getenv (and putenv) uses ANSI codepage so it needs to be encoded to internally used encoding (eg. UTF-8). Here we use _wgetenv (and _wputenv) instead and encode that. Also add SystemTools::HasEnv function. --- Source/kwsys/SystemTools.cxx| 80

[cmake-developers] [PATCH v4 2/4] Deprecate const char* SystemTools::GetEnv function

--- Source/kwsys/SystemTools.hxx.in | 14 -- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/Source/kwsys/SystemTools.hxx.in b/Source/kwsys/SystemTools.hxx.in index 8f01e75..f6fc282 100644 --- a/Source/kwsys/SystemTools.hxx.in +++ b/Source/kwsys/SystemTools.hxx.in @@

Re: [cmake-developers] [PATCH v4 4/4] For Windows encode process output to internally used encoding

2016-08-02 20:11 GMT+03:00 Brad King : > > How are we to know the encoding being produced by the child? > There isn't any reliable way to detect it, we just have to know what particular application uses. Also there aren't any standard or API to determine it but generally

[cmake-developers] [PATCH v5] For Windows encode process output to internally used encoding

Typically Windows applications (eg. MSVC compiler) use current console's codepage for output to pipes so we need to encode that to internally used encoding (KWSYS_ENCODING_DEFAULT_CODEPAGE). --- Source/cmExecProgramCommand.cxx| 3 ++ Source/cmExecuteProcessCommand.cxx | 11 -

Re: [cmake-developers] [PATCH v4 4/4] For Windows encode process output to internally used encoding

2016-07-18 17:04 GMT+03:00 Brad King <brad.k...@kitware.com>: > On 07/07/2016 05:54 PM, Dāvis Mosāns wrote: >> Typically Windows applications (eg. MSVC compiler) use current console's >> codepage for output to pipes so we need to encode that to intern

[cmake-developers] [PATCH] Improve encoding handling on Windows

On Windows getenv uses ANSI codepage so it needs to be encoded to internally used encoding (eg. UTF-8). Here we use _wgetenv instead and encode that. Also typically Windows applications (eg. MSVC compiler) use current console's codepage for output to pipes so we need to encode that to internally

Re: [cmake-developers] [PATCH] Improve encoding handling on Windows

2016-07-01 15:25 GMT+03:00 Daniel Pfeifer <dan...@pfeifer-mail.de>: > Hi Dāvis, > > On Fri, Jul 1, 2016 at 4:18 AM, Dāvis Mosāns <davis...@gmail.com> wrote: > > On Windows getenv uses ANSI codepage so it needs to be encoded to > > internally used encoding (eg. UTF

[cmake-developers] [PATCH v2] Improve encoding handling on Windows

On Windows getenv (and putenv) uses ANSI codepage so it needs to be encoded to internally used encoding (eg. UTF-8). Here we use _wgetenv (and _wputenv) instead and encode that. Also typically Windows applications (eg. MSVC compiler) use current console's codepage for output to pipes so we need

Re: [cmake-developers] [PATCH] Improve encoding handling on Windows

2016-07-01 17:41 GMT+03:00 Mike Gelfand : > > Since you already have "bool SystemTools::GetEnv(const char* key, > std::string& result)", another option would be to use it everywhere and > maybe introduce something like "bool SystemTools::HasEnv(const char* > key)" for those

Re: [cmake-developers] [PATCH v2] Improve encoding handling on Windows

2016-07-03 13:04 GMT+03:00 Mike Gelfand : > For std::c(in|out|err) vs. std::wc(in|out|err), here's an implementation > of std::streambuf which we currently use in our projects: > http://stackoverflow.com/a/21728856/583456. You could either try using > it as is or use it as a

[cmake-developers] [PATCH v7] For Windows encode process output to internally used encoding

Typically Windows applications (eg. MSVC compiler) use current console's codepage for output to pipes so we need to encode that to internally used encoding (KWSYS_ENCODING_DEFAULT_CODEPAGE). --- Source/CMakeLists.txt | 6 ++ Source/ProcessOutput.cxx | 141

Re: [cmake-developers] [PATCH v7] For Windows encode process output to internally used encoding

2016-08-17 16:47 GMT+03:00 Brad King : > I squashed in one warning fix: > > Windows: Encode child process output to internally-used encoding > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=12924660 > > However, then I had to revert the change from `next` because it >

Re: [cmake-developers] [Discussion] Add python support for CMakeLists

2017-01-12 11:48 GMT+02:00 Charles Huet : [...] > Lua is the language that should be used, since it is easy to embed on all > the platforms CMake supports. All arguments about language X being better > than language Y do not matter, since all other languages do not answer