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

2016-07-07 Thread Dāvis Mosāns 
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 +++--
 Source/kwsys/SystemTools.hxx.in |  4 +++
 2 files changed, 74 insertions(+), 10 deletions(-)

diff --git a/Source/kwsys/SystemTools.cxx b/Source/kwsys/SystemTools.cxx
index c6e668d..5bcf0d0 100644
--- a/Source/kwsys/SystemTools.cxx
+++ b/Source/kwsys/SystemTools.cxx
@@ -406,6 +406,9 @@ struct SystemToolsPathCaseCmp
 class SystemToolsPathCaseMap:
   public std::map {};
+
+class SystemToolsEnvMap :
+public std::map {};
 #endif
 
 // adds the elements of the env variable path to the arg passed in
@@ -458,7 +461,23 @@ void SystemTools::GetPath(std::vector& path, 
const char* env)
 
 const char* SystemTools::GetEnv(const char* key)
 {
-  return getenv(key);
+  const char *v = 0;
+#if defined(_WIN32)
+  std::string env;
+  if (SystemTools::GetEnv(key, env)) {
+const std::string skey = key;
+SystemToolsEnvMap::iterator i = EnvMap->find(skey);
+if (i != EnvMap->end()) {
+  i->second = env;
+} else {
+  i = EnvMap->insert(SystemToolsEnvMap::value_type(skey, env)).first;
+}
+v = i->second.c_str();
+  }
+#else
+  v = getenv(key);
+#endif
+  return v;
 }
 
 const char* SystemTools::GetEnv(const std::string& key)
@@ -468,16 +487,21 @@ const char* SystemTools::GetEnv(const std::string& key)
 
 bool SystemTools::GetEnv(const char* key, std::string& result)
 {
+#if defined(_WIN32)
+  const std::wstring wkey = Encoding::ToWide(key);
+  const wchar_t* wv = _wgetenv(wkey.c_str());
+  if (wv) {
+result = Encoding::ToNarrow(wv);
+return true;
+  }
+#else
   const char* v = getenv(key);
-  if(v)
-{
+  if (v) {
 result = v;
 return true;
-}
-  else
-{
-return false;
-}
+  }
+#endif
+  return false;
 }
 
 bool SystemTools::GetEnv(const std::string& key, std::string& result)
@@ -485,6 +509,22 @@ bool SystemTools::GetEnv(const std::string& key, 
std::string& result)
   return SystemTools::GetEnv(key.c_str(), result);
 }
 
+bool SystemTools::HasEnv(const char* key)
+{
+#if defined(_WIN32)
+  const std::wstring wkey = Encoding::ToWide(key);
+  const wchar_t* v = _wgetenv(wkey.c_str());
+#else
+  const char* v = getenv(key);
+#endif
+  return v != 0;
+}
+
+bool SystemTools::HasEnv(const std::string& key)
+{
+  return SystemTools::HasEnv(key.c_str());
+}
+
 //
 
 #if defined(__CYGWIN__) || defined(__GLIBC__)
@@ -533,13 +573,25 @@ static int kwsysUnPutEnv(const std::string& env)
 # ifdef KWSYS_PUTENV_EMPTY
   buf[len] = '=';
   buf[len+1] = 0;
-  if(putenv(buf) < 0)
+#if defined(_WIN32)
+  const std::wstring wbuf = Encoding::ToWide(buf);
+  const int r = _wputenv(wbuf.c_str());
+#else
+  const int r = putenv(buf);
+#endif
+  if(r < 0)
 {
 err = errno;
 }
 # else
   buf[len] = 0;
-  if(putenv(buf) < 0 && errno != EINVAL)
+#if defined(_WIN32)
+  const std::wstring wbuf = Encoding::ToWide(buf);
+  const int r = _wputenv(wbuf.c_str());
+#else
+  const int r = putenv(buf);
+#endif
+  if(r < 0 && errno != EINVAL)
 {
 err = errno;
 }
@@ -679,7 +731,12 @@ public:
 static_cast(oldEnv);
 char* newEnv = strdup(env);
 this->insert(newEnv);
+#if defined(_WIN32)
+const std::wstring wEnv = Encoding::ToWide(newEnv);
+return _wputenv(wEnv.c_str()) == 0;
+#else
 return putenv(newEnv) == 0;
+#endif
 }
   bool UnPut(const char* env)
 {
@@ -5371,6 +5428,7 @@ static unsigned int SystemToolsManagerCount;
 SystemToolsTranslationMap *SystemTools::TranslationMap;
 #ifdef _WIN32
 SystemToolsPathCaseMap *SystemTools::PathCaseMap;
+SystemToolsEnvMap *SystemTools::EnvMap;
 #endif
 #ifdef __CYGWIN__
 SystemToolsTranslationMap *SystemTools::Cyg2Win32Map;
@@ -5421,6 +5479,7 @@ void SystemTools::ClassInitialize()
   SystemTools::TranslationMap = new SystemToolsTranslationMap;
 #ifdef _WIN32
   SystemTools::PathCaseMap = new SystemToolsPathCaseMap;
+  SystemTools::EnvMap = new SystemToolsEnvMap;
 #endif
 #ifdef __CYGWIN__
   SystemTools::Cyg2Win32Map = new SystemToolsTranslationMap;
@@ -5480,6 +5539,7 @@ void SystemTools::ClassFinalize()
   delete SystemTools::TranslationMap;
 #ifdef _WIN32
   delete SystemTools::PathCaseMap;
+  delete SystemTools::EnvMap;
 #endif
 #ifdef __CYGWIN__
   delete SystemTools::Cyg2Win32Map;
diff --git a/Source/kwsys/SystemTools.hxx.in b/Source/kwsys/SystemTools.hxx.in
index bba5a5c..8f01e75 100644
--- a/Source/kwsys/SystemTools.hxx.in
+++ b/Source/kwsys/SystemTools.hxx.in
@@ -53,6 +53,7 @@ namespace @KWSYS_NAMESPACE@
 
 class SystemToolsTranslationMap;
 class SystemToolsPathCaseMap;
+class SystemToolsEnvMap;
 
 /** \class SystemToolsManager
  *

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

2016-07-07 Thread Dāvis Mosāns 
---
 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
@@ -26,6 +26,16 @@
 # include  // For access permissions for use with access()
 #endif
 
+#if __cplusplus >= 201402L
+# define DEPRECATED [[deprecated]]
+#elif defined(__GNUC__)
+# define DEPRECATED __attribute__ ((deprecated))
+#elif defined(_MSC_VER)
+# define DEPRECATED __declspec(deprecated)
+#else
+# define DEPRECATED
+#endif
+
 // Required for va_list
 #include 
 // Required for FILE*
@@ -840,8 +850,8 @@ public:
   /**
* Read an environment variable
*/
-  static const char* GetEnv(const char* key);
-  static const char* GetEnv(const std::string& key);
+  DEPRECATED static const char* GetEnv(const char* key);
+  DEPRECATED static const char* GetEnv(const std::string& key);
   static bool GetEnv(const char* key, std::string& result);
   static bool GetEnv(const std::string& key, std::string& result);
   static bool HasEnv(const char* key);
-- 
2.9.0

-- 

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

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

2016-07-07 Thread Dāvis Mosāns 
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 +
 Source/cmProcessTools.cxx  |  2 ++
 Source/cmSystemTools.cxx   |  3 +++
 Source/kwsys/CMakeLists.txt|  2 ++
 Source/kwsys/Process.h.in  | 13 +
 Source/kwsys/ProcessUNIX.c |  6 ++
 Source/kwsys/ProcessWin32.c| 33 -
 Source/kwsys/SystemInformation.cxx |  1 +
 9 files changed, 61 insertions(+), 1 deletion(-)

diff --git a/Source/cmExecProgramCommand.cxx b/Source/cmExecProgramCommand.cxx
index 58bbc31..92b89fc 100644
--- a/Source/cmExecProgramCommand.cxx
+++ b/Source/cmExecProgramCommand.cxx
@@ -220,6 +220,7 @@ bool cmExecProgramCommand::RunCommand(const char* command, 
std::string& output,
   char* data;
   int p;
   while ((p = cmsysProcess_WaitForData(cp, , , CM_NULLPTR), p)) {
+cmsysProcess_DecodeTextOutput(cp, , );
 if (p == cmsysProcess_Pipe_STDOUT || p == cmsysProcess_Pipe_STDERR) {
   if (verbose) {
 cmSystemTools::Stdout(data, length);
diff --git a/Source/cmExecuteProcessCommand.cxx 
b/Source/cmExecuteProcessCommand.cxx
index d97b25f..b13fb2e 100644
--- a/Source/cmExecuteProcessCommand.cxx
+++ b/Source/cmExecuteProcessCommand.cxx
@@ -229,6 +229,7 @@ bool 
cmExecuteProcessCommand::InitialPass(std::vector const& args,
   char* data;
   int p;
   while ((p = cmsysProcess_WaitForData(cp, , , CM_NULLPTR), p)) {
+cmsysProcess_DecodeTextOutput(cp, , );
 // Put the output in the right place.
 if (p == cmsysProcess_Pipe_STDOUT && !output_quiet) {
   if (output_variable.empty()) {
diff --git a/Source/cmProcessTools.cxx b/Source/cmProcessTools.cxx
index 34b8df2..8ab8070 100644
--- a/Source/cmProcessTools.cxx
+++ b/Source/cmProcessTools.cxx
@@ -23,10 +23,12 @@ void cmProcessTools::RunProcess(struct cmsysProcess_s* cp, 
OutputParser* out,
   while ((out || err) &&
  (p = cmsysProcess_WaitForData(cp, , , CM_NULLPTR), p)) {
 if (out && p == cmsysProcess_Pipe_STDOUT) {
+  cmsysProcess_DecodeTextOutput(cp, , );
   if (!out->Process(data, length)) {
 out = CM_NULLPTR;
   }
 } else if (err && p == cmsysProcess_Pipe_STDERR) {
+  cmsysProcess_DecodeTextOutput(cp, , );
   if (!err->Process(data, length)) {
 err = CM_NULLPTR;
   }
diff --git a/Source/cmSystemTools.cxx b/Source/cmSystemTools.cxx
index 9740ef7..aeb5471 100644
--- a/Source/cmSystemTools.cxx
+++ b/Source/cmSystemTools.cxx
@@ -616,6 +616,7 @@ bool 
cmSystemTools::RunSingleCommand(std::vector const& command,
   (captureStdOut || captureStdErr || outputflag != OUTPUT_NONE)) {
 while ((pipe = cmsysProcess_WaitForData(cp, , , CM_NULLPTR)) >
0) {
+  cmsysProcess_DecodeTextOutput(cp, , );
   // Translate NULL characters in the output into valid text.
   // Visual Studio 7 puts these characters in the output of its
   // build process.
@@ -1689,11 +1690,13 @@ int cmSystemTools::WaitForLine(cmsysProcess* process, 
std::string& line,
   return pipe;
 } else if (pipe == cmsysProcess_Pipe_STDOUT) {
   // Append to the stdout buffer.
+  cmsysProcess_DecodeTextOutput(process, , );
   std::vector::size_type size = out.size();
   out.insert(out.end(), data, data + length);
   outiter = out.begin() + size;
 } else if (pipe == cmsysProcess_Pipe_STDERR) {
   // Append to the stderr buffer.
+  cmsysProcess_DecodeTextOutput(process, , );
   std::vector::size_type size = err.size();
   err.insert(err.end(), data, data + length);
   erriter = err.begin() + size;
diff --git a/Source/kwsys/CMakeLists.txt b/Source/kwsys/CMakeLists.txt
index 39b03b3..65203c0 100644
--- a/Source/kwsys/CMakeLists.txt
+++ b/Source/kwsys/CMakeLists.txt
@@ -708,6 +708,8 @@ IF(KWSYS_USE_Process)
   IF(NOT UNIX)
 # Use the Windows implementation.
 SET(KWSYS_C_SRCS ${KWSYS_C_SRCS} ProcessWin32.c)
+SET_PROPERTY(SOURCE ProcessWin32.c APPEND PROPERTY COMPILE_DEFINITIONS
+  KWSYS_ENCODING_DEFAULT_CODEPAGE=${KWSYS_ENCODING_DEFAULT_CODEPAGE})
   ELSE()
 # Use the UNIX implementation.
 SET(KWSYS_C_SRCS ${KWSYS_C_SRCS} ProcessUNIX.c)
diff --git a/Source/kwsys/Process.h.in b/Source/kwsys/Process.h.in
index 96563a2..0c79b47 100644
--- a/Source/kwsys/Process.h.in
+++ b/Source/kwsys/Process.h.in
@@ -67,6 +67,7 @@
 # define kwsysProcess_Execute   kwsys_ns(Process_Execute)
 # define kwsysProcess_Disownkwsys_ns(Process_Disown)
 # define kwsysProcess_WaitForData   kwsys_ns(Process_WaitForData)
+# define kwsysProcess_DecodeTextOutput  
kwsys_ns(Process_DecodeTextOutput)
 # define kwsysProcess_Pipes_e   kwsys_ns(Process_Pipes_e)
 # define kwsysProcess_Pipe_None

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

2016-07-07 Thread Dāvis Mosāns 
---
 Source/CPack/cmCPackGenerator.cxx   |  8 +++---
 Source/CTest/cmCTestCoverageHandler.cxx | 12 -
 Source/CTest/cmCTestCurl.cxx| 27 ++--
 Source/CTest/cmCTestMultiProcessHandler.cxx |  8 +++---
 Source/cmBuildCommand.cxx   | 25 +--
 Source/cmCLocaleEnvironmentScope.cxx|  5 ++--
 Source/cmCTest.cxx  | 11 +
 Source/cmCommandArgumentParserHelper.cxx|  8 +++---
 Source/cmConditionEvaluator.cxx |  2 +-
 Source/cmExportCommand.cxx  |  5 ++--
 Source/cmExtraEclipseCDT4Generator.cxx  |  9 ---
 Source/cmFileCommand.cxx| 11 +
 Source/cmFindPackageCommand.cxx |  4 +--
 Source/cmGlobalVisualStudio7Generator.cxx   |  6 ++---
 Source/cmMakefile.cxx   |  5 +++-
 Source/cmNinjaTargetGenerator.cxx   |  2 +-
 Source/cmQtAutoGenerators.cxx   |  2 +-
 Source/cmSetCommand.cxx |  7 +++---
 Source/cmState.cxx  |  5 ++--
 Source/cmSystemTools.cxx|  6 ++---
 Source/cmTimestamp.cxx  |  7 +++---
 Source/cmUtils.hxx  | 26 
 Source/cmake.cxx| 21 +---
 Source/cmcmd.cxx| 16 +---
 Source/kwsys/SystemInformation.cxx  | 20 +++
 Source/kwsys/SystemTools.cxx| 38 +++--
 Source/kwsys/testSystemTools.cxx|  9 ---
 27 files changed, 156 insertions(+), 149 deletions(-)
 create mode 100644 Source/cmUtils.hxx

diff --git a/Source/CPack/cmCPackGenerator.cxx 
b/Source/CPack/cmCPackGenerator.cxx
index df8bb0f..76609e1 100644
--- a/Source/CPack/cmCPackGenerator.cxx
+++ b/Source/CPack/cmCPackGenerator.cxx
@@ -1074,11 +1074,11 @@ const char* cmCPackGenerator::GetInstallPath()
 return this->InstallPath.c_str();
   }
 #if defined(_WIN32) && !defined(__CYGWIN__)
-  const char* prgfiles = cmsys::SystemTools::GetEnv("ProgramFiles");
-  const char* sysDrive = cmsys::SystemTools::GetEnv("SystemDrive");
-  if (prgfiles) {
+  std::string prgfiles;
+  std::string sysDrive;
+  if (cmsys::SystemTools::GetEnv("ProgramFiles", prgfiles)) {
 this->InstallPath = prgfiles;
-  } else if (sysDrive) {
+  } else if (cmsys::SystemTools::GetEnv("SystemDrive", sysDrive)) {
 this->InstallPath = sysDrive;
 this->InstallPath += "/Program Files";
   } else {
diff --git a/Source/CTest/cmCTestCoverageHandler.cxx 
b/Source/CTest/cmCTestCoverageHandler.cxx
index 7102533..9410a52 100644
--- a/Source/CTest/cmCTestCoverageHandler.cxx
+++ b/Source/CTest/cmCTestCoverageHandler.cxx
@@ -727,10 +727,7 @@ int cmCTestCoverageHandler::HandleCoberturaCoverage(
   // if it doesn't exist or is empty, assume the
   // binary directory is used.
   std::string coverageXMLFile;
-  const char* covDir = cmSystemTools::GetEnv("COBERTURADIR");
-  if (covDir && strlen(covDir) != 0) {
-coverageXMLFile = std::string(covDir);
-  } else {
+  if (!cmSystemTools::GetEnv("COBERTURADIR", coverageXMLFile) || 
coverageXMLFile.empty()) {
 coverageXMLFile = this->CTest->GetBinaryDir();
   }
   // build the find file string with the directory from above
@@ -791,7 +788,8 @@ struct cmCTestCoverageHandlerLocale
 {
   cmCTestCoverageHandlerLocale()
   {
-if (const char* l = cmSystemTools::GetEnv("LC_ALL")) {
+std::string l;
+if (cmSystemTools::GetEnv("LC_ALL", l)) {
   lc_all = l;
 }
 if (lc_all != "C") {
@@ -2121,8 +2119,8 @@ int cmCTestCoverageHandler::RunBullseyeSourceSummary(
 int cmCTestCoverageHandler::HandleBullseyeCoverage(
   cmCTestCoverageHandlerContainer* cont)
 {
-  const char* covfile = cmSystemTools::GetEnv("COVFILE");
-  if (!covfile || strlen(covfile) == 0) {
+  std::string covfile;
+  if (!cmSystemTools::GetEnv("COVFILE", covfile) || covfile.empty()) {
 cmCTestOptionalLog(this->CTest, HANDLER_VERBOSE_OUTPUT,
" COVFILE environment variable not found, not running "
" bullseye\n",
diff --git a/Source/CTest/cmCTestCurl.cxx b/Source/CTest/cmCTestCurl.cxx
index 6b8e5b5..b335e32 100644
--- a/Source/CTest/cmCTestCurl.cxx
+++ b/Source/CTest/cmCTestCurl.cxx
@@ -219,16 +219,18 @@ bool cmCTestCurl::HttpRequest(std::string const& url,
 
 void cmCTestCurl::SetProxyType()
 {
-  if (cmSystemTools::GetEnv("HTTP_PROXY")) {
-this->HTTPProxy = cmSystemTools::GetEnv("HTTP_PROXY");
-if (cmSystemTools::GetEnv("HTTP_PROXY_PORT")) {
+  this->HTTPProxy = "";
+  // this is the default
+  this->HTTPProxyType = CURLPROXY_HTTP;
+  this->HTTPProxyAuth = "";
+  if (cmSystemTools::GetEnv("HTTP_PROXY", this->HTTPProxy)) {
+std::string port;
+if (cmSystemTools::GetEnv("HTTP_PROXY_PORT", port)) {
   this->HTTPProxy += ":";
-  this->HTTPProxy += cmSystemTools::GetEnv("HTTP_PROXY_PORT");
+

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

2016-07-07 Thread Dāvis Mosāns 
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 +++--
 Source/kwsys/SystemTools.hxx.in |  4 +++
 2 files changed, 72 insertions(+), 10 deletions(-)

diff --git a/Source/kwsys/SystemTools.cxx b/Source/kwsys/SystemTools.cxx
index c6e668d..fc1d756 100644
--- a/Source/kwsys/SystemTools.cxx
+++ b/Source/kwsys/SystemTools.cxx
@@ -406,6 +406,9 @@ struct SystemToolsPathCaseCmp
 class SystemToolsPathCaseMap:
   public std::map {};
+
+class SystemToolsEnvMap :
+public std::map {};
 #endif
 
 // adds the elements of the env variable path to the arg passed in
@@ -458,7 +461,21 @@ void SystemTools::GetPath(std::vector& path, 
const char* env)
 
 const char* SystemTools::GetEnv(const char* key)
 {
-  return getenv(key);
+  const char *v;
+#if defined(_WIN32)
+  const std::string env = SystemTools::GetEnv(key);
+  const std::string skey = key;
+  SystemToolsEnvMap::iterator i = EnvMap->find(skey);
+  if (i != EnvMap->end()) {
+i->second = env;
+  } else {
+i = EnvMap->insert(SystemToolsEnvMap::value_type(skey, env)).first;
+  }
+  v = i->second.c_str();
+#else
+  v = getenv(key);
+#endif
+  return v;
 }
 
 const char* SystemTools::GetEnv(const std::string& key)
@@ -468,16 +485,21 @@ const char* SystemTools::GetEnv(const std::string& key)
 
 bool SystemTools::GetEnv(const char* key, std::string& result)
 {
+#if defined(_WIN32)
+  const std::wstring wkey = Encoding::ToWide(key);
+  const wchar_t* wv = _wgetenv(wkey.c_str());
+  if (wv) {
+result = Encoding::ToNarrow(wv);
+return true;
+  }
+#else
   const char* v = getenv(key);
-  if(v)
-{
+  if (v) {
 result = v;
 return true;
-}
-  else
-{
-return false;
-}
+  }
+#endif
+  return false;
 }
 
 bool SystemTools::GetEnv(const std::string& key, std::string& result)
@@ -485,6 +507,22 @@ bool SystemTools::GetEnv(const std::string& key, 
std::string& result)
   return SystemTools::GetEnv(key.c_str(), result);
 }
 
+bool SystemTools::HasEnv(const char* key)
+{
+#if defined(_WIN32)
+  const std::wstring wkey = Encoding::ToWide(key);
+  const wchar_t* v = _wgetenv(wkey.c_str());
+#else
+  const char* v = getenv(key);
+#endif
+  return v != 0;
+}
+
+bool SystemTools::HasEnv(const std::string& key)
+{
+  return SystemTools::HasEnv(key.c_str());
+}
+
 //
 
 #if defined(__CYGWIN__) || defined(__GLIBC__)
@@ -533,13 +571,25 @@ static int kwsysUnPutEnv(const std::string& env)
 # ifdef KWSYS_PUTENV_EMPTY
   buf[len] = '=';
   buf[len+1] = 0;
-  if(putenv(buf) < 0)
+#if defined(_WIN32)
+  const std::wstring wbuf = Encoding::ToWide(buf);
+  const int r = _wputenv(wbuf.c_str());
+#else
+  const int r = putenv(buf);
+#endif
+  if(r < 0)
 {
 err = errno;
 }
 # else
   buf[len] = 0;
-  if(putenv(buf) < 0 && errno != EINVAL)
+#if defined(_WIN32)
+  const std::wstring wbuf = Encoding::ToWide(buf);
+  const int r = _wputenv(wbuf.c_str());
+#else
+  const int r = putenv(buf);
+#endif
+  if(r < 0 && errno != EINVAL)
 {
 err = errno;
 }
@@ -679,7 +729,12 @@ public:
 static_cast(oldEnv);
 char* newEnv = strdup(env);
 this->insert(newEnv);
+#if defined(_WIN32)
+const std::wstring wEnv = Encoding::ToWide(newEnv);
+return _wputenv(wEnv.c_str()) == 0;
+#else
 return putenv(newEnv) == 0;
+#endif
 }
   bool UnPut(const char* env)
 {
@@ -5371,6 +5426,7 @@ static unsigned int SystemToolsManagerCount;
 SystemToolsTranslationMap *SystemTools::TranslationMap;
 #ifdef _WIN32
 SystemToolsPathCaseMap *SystemTools::PathCaseMap;
+SystemToolsEnvMap *SystemTools::EnvMap;
 #endif
 #ifdef __CYGWIN__
 SystemToolsTranslationMap *SystemTools::Cyg2Win32Map;
@@ -5421,6 +5477,7 @@ void SystemTools::ClassInitialize()
   SystemTools::TranslationMap = new SystemToolsTranslationMap;
 #ifdef _WIN32
   SystemTools::PathCaseMap = new SystemToolsPathCaseMap;
+  SystemTools::EnvMap = new SystemToolsEnvMap;
 #endif
 #ifdef __CYGWIN__
   SystemTools::Cyg2Win32Map = new SystemToolsTranslationMap;
@@ -5480,6 +5537,7 @@ void SystemTools::ClassFinalize()
   delete SystemTools::TranslationMap;
 #ifdef _WIN32
   delete SystemTools::PathCaseMap;
+  delete SystemTools::EnvMap;
 #endif
 #ifdef __CYGWIN__
   delete SystemTools::Cyg2Win32Map;
diff --git a/Source/kwsys/SystemTools.hxx.in b/Source/kwsys/SystemTools.hxx.in
index bba5a5c..8f01e75 100644
--- a/Source/kwsys/SystemTools.hxx.in
+++ b/Source/kwsys/SystemTools.hxx.in
@@ -53,6 +53,7 @@ namespace @KWSYS_NAMESPACE@
 
 class SystemToolsTranslationMap;
 class SystemToolsPathCaseMap;
+class SystemToolsEnvMap;
 
 /** \class SystemToolsManager
  * \brief Use to make sure

[cmake-developers] [ANNOUNCE] CMake 3.6.0 available for download

2016-07-07 Thread Robert Maynard 
I am proud to announce that CMake 3.6.0 is now available for download at:
  https://cmake.org/download/

Documentation is available at:
  https://cmake.org/cmake/help/v3.6

Release notes appear below and are also published at
  https://cmake.org/cmake/help/v3.6/release/3.6.html

Some of the more significant features of CMake 3.6 are:

* The "Visual Studio 14 2015" generator learned to support the
  Clang/C2 toolsets, e.g. with the "-T v140_clang_3_7" option. This
  feature is experimental.

* The "list()" command gained a "FILTER" sub-command to filter list
  elements by regular expression.

* A "CMAKE_TRY_COMPILE_TARGET_TYPE" variable was added to optionally
  tell the "try_compile()" command to build a static library instead
  of an executable.  This is useful for cross-compiling toolchains
  that cannot link binaries without custom flags or scripts.

* A "_CLANG_TIDY" target property and supporting
  "CMAKE__CLANG_TIDY" variable were introduced to tell the
  Makefile Generators and the "Ninja" generator to run "clang-tidy"
  along with the compiler for "C" and "CXX" languages.

* The "ExternalProject" module leared the "GIT_SHALLOW 1" option to
  perform a shallow clone of a Git repository.

* The "ExternalProject" module learned to initialize Git submodules
  recursively and also to initialize new submodules on updates.  Use
  the "GIT_SUBMODULES" option to restrict which submodules are
  initalized and updated.

* The "InstallRequiredSystemLibraries" module learned a new
  "CMAKE_INSTALL_UCRT_LIBRARIES" option to enable app-local deployment
  of the Windows Universal CRT libraries with Visual Studio 2015.

* The "Compile Features" functionality is now aware of features
  supported by Intel C++ compilers versions 12.1 through 16.0 on UNIX
  platforms.

Deprecated and Removed Features
===

* The "CMakeForceCompiler" module and its macros are now deprecated.
  See module documentation for an explanation.

* The "Visual Studio 7 .NET 2003" generator is now deprecated and
  will be removed in a future version of CMake.

* The "Visual Studio 7" generator (for VS .NET 2002) has been
  removed. It had been deprecated since CMake 3.3.

* The "Visual Studio 6" generator has been removed. It had been
  deprecated since CMake 3.3.



CMake 3.6 Release Notes
***

Changes made since CMake 3.5 include the following.


New Features



Generators
--

* The "Ninja" generator learned to produce phony targets of the form
  "sub/dir/all" to drive the build of a subdirectory. This is
  equivalent to "cd sub/dir; make all" with Makefile Generators.

* The "Ninja" generator now includes system header files in build
  dependencies to ensure correct re-builds when system packages are
  updated.

* The "Visual Studio 14 2015" generator learned to support the
  Clang/C2 toolsets, e.g. with the "-T v140_clang_3_7" option. This
  feature is experimental.


Commands


* The "add_custom_command()" and "add_custom_target()" commands
  learned how to use the "CROSSCOMPILING_EMULATOR" executable target
  property.

* The "install()" command learned a new "EXCLUDE_FROM_ALL" option to
  leave installation rules out of the default installation.

* The "list()" command gained a "FILTER" sub-command to filter list
  elements by regular expression.

* The "string(TIMESTAMP)" and "file(TIMESTAMP)" commands gained
  support for the "%s" placeholder.  This is the number of seconds
  since the UNIX Epoch.


Variables
-

* A "CMAKE_DEPENDS_IN_PROJECT_ONLY" variable was introduced to tell
  Makefile Generators to limit dependency scanning only to files in
  the project source and build trees.

* A new "CMAKE_HOST_SOLARIS" variable was introduced to indicate
  when CMake is running on an Oracle Solaris host.

* A "CMAKE__STANDARD_INCLUDE_DIRECTORIES" variable was added
  for use by toolchain files to specify system include directories to
  be appended to all compiler command lines.

* The "CMAKE__STANDARD_LIBRARIES" variable is now documented.
  It is intended for use by toolchain files to specify system
  libraries to be added to all linker command lines.

* A "CMAKE_NINJA_OUTPUT_PATH_PREFIX" variable was introduced to tell
  the "Ninja" generator to configure the generated "build.ninja" file
  for use as a "subninja".

* A "CMAKE_TRY_COMPILE_PLATFORM_VARIABLES" variable was added for
  use by toolchain files to specify platform-specific variables that
  must be propagated by the "try_compile()" command into test
  projects.

* A "CMAKE_TRY_COMPILE_TARGET_TYPE" variable was added to optionally
  tell the "try_compile()" command to build a static library instead
  of an executable.  This is useful for cross-compiling toolchains
  that cannot link binaries without custom flags or scripts.


Properties
--

* A "DEPLOYMENT_REMOTE_DIRECTORY" target property was introduced to
  tell the "Visual Studio 9 2008" and "Visual Studio 8 2005"
  generators to generate

Re: [cmake-developers] cmake -E capabilities

2016-07-07 Thread Tobias Hunger 
Hello,

On Tue, Jul 5, 2016 at 1:48 AM, Stephen Kelly ,
me, Stephen Kelly wrote:
>>> Such a feature would also work with cmake projects if the user chooses to
>>> use the XCode generator on mac or VS generator on Windows (or if someday
>>> we have a multi-config Ninja generator or so).
>>
>> How is a multi-config ninja generator better than just having to build
>> directories next to each other, each with one configuration? You might
>> save a bit of disk space (probably not a lot). Will you save a significant
>> amount of processing time?
>>
>> The one benefit I can think of is switching between configurations will
>> probably be a lot faster. But that is nothing that is done so often that
>> it warrants optimizing for IMHO.
>
> What I have in mind is not optimization. As you say, if this is not needed
> at this point for IDE integration, then we can drop the idea.

I still do not get why this feature exists at all. What is the benefit
of having it? Is it just because xcode supports it, so cmake should
to?

>> Either the clients do not care or they need to know which configurations
>> those are going to be.
>
> This can be retrieved by reading the STRINGS property of the
> CMAKE_BUILD_TYPE cache variable.

Oh, that sounds interesting. I'll need to investigate this:-)

Best Regards,
Tobias
-- 

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

Re: [cmake-developers] cmake -E capabilities

2016-07-07 Thread Tobias Hunger 
Sorry for the late reply... we had a beta release and a new patch
level release out this week and I had to fix some bugs in both:-)

On Sun, Jul 3, 2016 at 1:30 PM, Stephen Kelly  wrote:
>> "KDevelop3",
>
>  This generator should probably be removed/hidden by now. It has
> confused users of more-recent KDevelop versions.

Yes, that should be hidden. I'll add that in the next update.

>> What do you think? What else should we report here?
>
> It looks like a good start. The intention of the output is to satisfy needs
> that consumers like you have, and I guess it does have what you need.

Obviously, or I would not propose it:-)

The hope is to get feedback from other potential users. But so far no
luck on that front:-/

>> Compared to the bug report mentioned above the fields "multiconfig" and
>> "recursive" are missing. I could not figure out how to get that
>> information:-/
>
> When I made the example in the issue tracker, 'recursive' meant 'you can cd
> to a directory and run the CMAKE_MAKE_PROGRAM there'. At the time, it was
> possible to do that when using the Makefiles generator, but not the Ninja
> generator.
>
> I think that capability has since been added for the Ninja generator, but I
> don't know if it is possible with the Xcode and VS generators.
>
> Would that be a useful thing to expose here in your view?

I think that information would be useful at some point. But it is not
needed before a project is opened.

>> I would also welcome some code review on the patch.
>
> 1) For consistency you should change
>
>  GetRegisteredGenerators
>
> to
>
>  this->GetRegisteredGenerators
>
> whether that is a preferred style is orthogonal to the fact that it's
> consistently used in cmake code.

Oh, sorry. I still find that horrible to read, so I only sprinkle
this-> over the code shortly before sending it in to review.

> 2) CMake has to build with toolchains which do not provide
> std::unordered_map. See uses of CMake_HAVE_CXX_UNORDERED_MAP for existing
> code which uses either std::unordered_map or std::unordered_map. (Yes there
> is room for improvement there, but such improvement is orthogonal to your
> branch).

Oh, too bad.

> 3) Similarly, CMake has to build with compilers which do not support
> cxx_range_for or cxx_auto_type. For the cmServer implementation that may or
> may not be the case, but within the cmake class, that's the way it is.

I'll fix that.

> 4) It seems that the
>
>  this->Generators
>
> member of the cmake class has the names of all generators (without 'extra'
> generators). It seems unfortunate to not use that container and instead
> parse the names out of the names from the GetRegisteredGenerators call by
> splitting on the ' - '. It leads to hard coded magic expressions like
> 'separator + 3', so it should be avoided if possible.

Yes, that is ugly.

> Is there another way of determining the extra generators supported by a
> given generator and avoiding parsing a string which we just generated? Can
>
>   const std::vector& supportedGlobalGenerators =
> extraGenerator->GetSupportedGlobalGenerators();
>
> be used somehow? Can you first loop over this->Generators to get the
> 'normal' generators, then loop over the extra generators, call that method
> to match things up and output the result?

Doesn't this require me to instanciate the generators? Won't that  be
potentially expensive?

> Or would it make sense to refactor the container members in the cmake class
> themselves to make this information more easily available for this use-case?
>
> 5) You use the term 'appendix' for the version, but 'suffix' is the more-
> commonly used name for that concept.

I'll change that.

Best Regards,
Tobias
-- 

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

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

2016-07-07 Thread Brad King 
On 07/06/2016 12:07 PM, Ruslan Baratov wrote:
> Attaching rebased patch.

Thanks, applied with some re-wording:

 ExternalProject: Use default file name if extracting from URL fails
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=af7da934

-Brad

-- 

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

Re: [cmake-developers] [CpackIFW] Fix bug in cpack_ifw_configure_... commands

2016-07-07 Thread Konstantin Podsvirov 
15:44, 7 jul 2016 г., Brad King :On 07/07/2016 07:43 AM, Konstantin Podsvirov wrote: Can you also merge topic 'cpack-ifw-list-variable' to release branch?Does it fix a 3.6 regression or a bug in a 3.6 new feature?No.Fixes to long-standing bugs are not eligible to be backportedto the release.It's long-standing bug from 3.1 release.Ok. I will wait.Thanks,-Brad--Regards,Konstantin Podsvirov 
-- 

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

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

2016-07-07 Thread Brad King 
On 07/06/2016 03:12 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 internally used
> encoding (KWSYS_ENCODING_DEFAULT_CODEPAGE).

We can't do that here.  KWSys Process is a low-level process execution
API and can make no assumptions about the kind of output that comes
from the child.  It might be text or binary, and so cannot be transformed
at this layer in any way.

Higher-level clients within CMake will have to be taught to do the conversion
in cases that the output is expected to be text.  While at it, there was
some discussion a few months ago about newline conversion that needs the
same treatment.

Thanks,
-Brad

-- 

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

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

2016-07-07 Thread Brad King 
On 07/06/2016 03:12 PM, Dāvis Mosāns wrote:
> On Windows this function returns environment variable encoded
> in ANSI codepage which might not match internally used encoding.
[snip]
> -  static const char* GetEnv(const char* key);
> -  static const char* GetEnv(const std::string& key);
> +  DEPRECATED static const char* GetEnv(const char* key);
> +  DEPRECATED static const char* GetEnv(const std::string& key);

Please also revise these to return the properly converted string
and use a static std::map internally to manage the storage.  I'd
like the two overloads to at least return consistent values.  The
need for the internal map is a good justification for adding the
deprecation mark.

Thanks,
-Brad
-- 

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

Re: [cmake-developers] [CpackIFW] Fix bug in cpack_ifw_configure_... commands

2016-07-07 Thread Brad King 
On 07/07/2016 07:43 AM, Konstantin Podsvirov wrote:
> Can you also merge topic 'cpack-ifw-list-variable' to release branch?

Does it fix a 3.6 regression or a bug in a 3.6 new feature?
Fixes to long-standing bugs are not eligible to be backported
to the release.

Thanks,
-Brad
-- 

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

[cmake-developers] [CpackIFW] Fix bug in cpack_ifw_configure_... commands

2016-07-07 Thread Konstantin Podsvirov 
Hello, Brad!Can you also merge topic 'cpack-ifw-list-variable' to release branch?It's fix processing of LICENSES arguments of cpack_ifw_configure... commands where license display_name contain spaces.
-- 

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