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

2016-07-07 3:51 GMT+03:00 Mike Gelfand : > On 07/07/2016 03:33 AM, Dāvis Mosāns wrote: >> 2016-07-07 1:22 GMT+03:00 Mike Gelfand : @@ -92,19 +159,26 @@ namespace @KWSYS_NAMESPACE@ [snip] private: internal_buffer_type* buf_;

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

2016-07-07 1:36 GMT+03:00 Mike Gelfand : > On 07/07/2016 12:42 AM, clin...@elemtech.com wrote: >> From what I remember, WriteConsoleW doesn't support redirection to a >> file or pipe. I don't see an alternative in the patch for the case >> where stdout is not attached to the

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

On 07/07/2016 03:33 AM, Dāvis Mosāns wrote: > 2016-07-07 1:22 GMT+03:00 Mike Gelfand : >>> @@ -92,19 +159,26 @@ namespace @KWSYS_NAMESPACE@ >>> [snip] >>>private: >>> internal_buffer_type* buf_; >>> +#if !defined(_MSC_VER) >>> +FILE *file_ = 0; >>> +#endif >>> };

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

On 07/07/2016 12:42 AM, clin...@elemtech.com wrote: > From what I remember, WriteConsoleW doesn't support redirection to a > file or pipe. I don't see an alternative in the patch for the case > where stdout is not attached to the console. The SO thread I pointed at actually contained a check for

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

On 07/06/2016 10:12 PM, Dāvis Mosāns wrote: > --- a/Source/kwsys/FStream.hxx.in > +++ b/Source/kwsys/FStream.hxx.in > @@ -14,33 +14,76 @@ > > #include <@KWSYS_NAMESPACE@/Encoding.hxx> > #include > +#if defined(_WIN32) && !defined(_MSC_VER) > +#include > +#endif > > namespace

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

From what I remember, WriteConsoleW doesn't support redirection to a file or pipe.  I don't see an alternative in the patch for the case where stdout is not attached to the console. Clint -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at:

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

On 07/06/2016 10:12 PM, Dāvis Mosāns wrote: > --- a/Source/kwsys/SystemInformation.cxx > +++ b/Source/kwsys/SystemInformation.cxx > @@ -219,6 +219,8 @@ typedef struct rlimit ResourceLimitType; > # define USE_CPUID 0 > #endif > > +#include > + > #if USE_CPUID > > #define

[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

[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 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 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 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

Re: [cmake-developers] ExternalProject default downloaded file name

On 07/05/2016 05:14 PM, Ruslan Baratov wrote: > if it will work in most cases then why not? Most users will not > even notice this. Okay. The changes for the new pattern are now in `master` and are worthwhile regardless of having a default filename fallback because they help extract a more

Re: [cmake-developers] Green Hills MULTI Generator Recommendations

> I am interested in using CMake with Green Hills MULTI Great! > 2. Is there a way in a toolchain file or on the command line to specify the > directory where CMake should look for the compiler executables? Take a look at