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-8). Here we use _wgetenv instead > and encode that.
Your change to the SystemTools::GetEnv function introduces memory leaks, since you return a pointer to a new[]-ed array. It seems impossible to refactor SystemTools::GetEnv to use _wgetenv and provide interface compatability. You should probably introduce a function that returns std::string and uses GetEnvironmentVariableW internally. > Also 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). > > Next, when we're outputing to console need to use wide functions. > > This change allows that compilers such as MSVC on Windows can be > installed in non-ASCII path and will work correctly for all > console's codepages which supports that path's characters. Sounds useful. I cannot really comment on this. Cheers, Daniel -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
