[Cmake-commits] CMake branch, next, updated. v3.3.1-2896-ge81aa1a

[Brad King]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  e81aa1a379fa721c800caef75c74e26e8acb9585 (commit)
   via  6dad4c25b06ae232c766d76747b080373fb2499d (commit)
  from  6f95ab5feffdefbb9d0070c6fb56972dcda9655f (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e81aa1a379fa721c800caef75c74e26e8acb9585
commit e81aa1a379fa721c800caef75c74e26e8acb9585
Merge: 6f95ab5 6dad4c2
Author: Brad King 
AuthorDate: Mon Sep 14 09:21:06 2015 -0400
Commit: Brad King 
CommitDate: Mon Sep 14 09:21:06 2015 -0400

Merge branch 'master' into next


---

Summary of changes:


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, master, updated. v3.3.1-1162-g31117bb

[Brad King]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  31117bb17c4e764bb60b8c9c6847a631cc9ecf3c (commit)
   via  ed258d606b87dacc465dad73b04f1c3e270b627c (commit)
   via  fb45c37160e4f8d839a2c29bce80cae7563cfd3a (commit)
   via  158f7e31dc685859f5a53d88e965382c6361efb1 (commit)
   via  08ce3f486e789275104a390d2d34f36a90c5fd2f (commit)
  from  75ad8d342119be9e71006c2f352755ad9565963b (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=31117bb17c4e764bb60b8c9c6847a631cc9ecf3c
commit 31117bb17c4e764bb60b8c9c6847a631cc9ecf3c
Merge: 75ad8d3 ed258d6
Author: Brad King 
AuthorDate: Mon Sep 14 09:19:59 2015 -0400
Commit: CMake Topic Stage 
CommitDate: Mon Sep 14 09:19:59 2015 -0400

Merge topic 'fix-buildsystem-property-append'

ed258d60 Tests: Cover set_property for buildsystem directory properties
fb45c371 cmState: Only append non-empty values to buildsystem properties.
158f7e31 cmMakefile: Use appropriate parameter name.
08ce3f48 cmTarget: Only append non-empty values to buildsystem properties.


---

Summary of changes:
 Source/cmState.cxx   |9 +++--
 Source/cmTarget.cxx  |   10 +-
 .../RunCMake/set_property/COMPILE_DEFINITIONS-stdout.txt |3 ++-
 Tests/RunCMake/set_property/COMPILE_DEFINITIONS.cmake|1 +
 Tests/RunCMake/set_property/COMPILE_FEATURES-stdout.txt  |2 +-
 Tests/RunCMake/set_property/COMPILE_OPTIONS-stdout.txt   |3 ++-
 Tests/RunCMake/set_property/COMPILE_OPTIONS.cmake|1 +
 Tests/RunCMake/set_property/Common.cmake |   14 ++
 .../RunCMake/set_property/INCLUDE_DIRECTORIES-stdout.txt |3 ++-
 Tests/RunCMake/set_property/INCLUDE_DIRECTORIES.cmake|1 +
 Tests/RunCMake/set_property/LINK_LIBRARIES-stdout.txt|2 +-
 Tests/RunCMake/set_property/USER_PROP-stdout.txt |1 +
 Tests/RunCMake/set_property/USER_PROP.cmake  |1 +
 13 files changed, 39 insertions(+), 12 deletions(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[cmake-developers] [CPackDeb] use of internal md5sum function

[Raffi Enficiaud]

Hi Brad and Domen and others,

Please find attached a patch on CPackDeb
- which calls the internal function for md5sum computation
- which prevents the hash of the symlinks

I believe this fixes the issue (partially or totally)

https://public.kitware.com/Bug/view.php?id=13386

It is based on my previous patch.

Thanks,
Raffi
From 780a58a38d0445d1b4b58363b734a262a07a879e Mon Sep 17 00:00:00 2001
From: Raffi Enficiaud 
Date: Mon, 14 Sep 2015 14:45:12 +0200
Subject: [PATCH] CPackDeb: preventing md5sum on symlinks

- Direct call to cmSystemTools::ComputeFileMD5
- Avoiding hashing symlinks
- Tests
---
 Source/CPack/cmCPackDebGenerator.cxx   | 42 --
 Tests/CPackComponentsDEB/CMakeLists.txt| 20 +++
 ...yResult-components-lintian-dpkgdeb-checks.cmake | 34 ++
 .../CPackComponentsDEB/RunCPackVerifyResult.cmake  | 12 +--
 4 files changed, 86 insertions(+), 22 deletions(-)

diff --git a/Source/CPack/cmCPackDebGenerator.cxx 
b/Source/CPack/cmCPackDebGenerator.cxx
index 981d86d..090c076 100644
--- a/Source/CPack/cmCPackDebGenerator.cxx
+++ b/Source/CPack/cmCPackDebGenerator.cxx
@@ -526,27 +526,31 @@ int cmCPackDebGenerator::createDeb()
packageFiles.begin();
  fileIt != packageFiles.end(); ++ fileIt )
   {
-  std::string cmd = "\"";
-  cmd += cmSystemTools::GetCMakeCommand();
-  cmd += "\" -E md5sum \"";
-  cmd += *fileIt;
-  cmd += "\"";
-
-  std::string output;
-  int retval = -1;
-  int res = cmSystemTools::RunSingleCommand(cmd.c_str(), , ,
-  , toplevel.c_str(), this->GeneratorVerbose, 0);
-  if ( !res || retval )
+
+// hash only regular files
+if(   cmSystemTools::FileIsDirectory(*fileIt)
+   || cmSystemTools::FileIsSymlink(*fileIt))
 {
-cmCPackLogger(cmCPackLog::LOG_ERROR, "Problem running cmake -E md5sum "
-  << cmd << std::endl);
+  continue;
 }
-  // debian md5sums entries are like this:
-  // 014f3604694729f3bf19263bac599765  usr/bin/ccmake
-  // thus strip the full path (with the trailing slash)
-  cmSystemTools::ReplaceString(output,
-   topLevelWithTrailingSlash.c_str(), "");
-  out << output;
+
+char md5sum[33];
+if(!cmSystemTools::ComputeFileMD5(*fileIt, md5sum))
+{
+  cmCPackLogger(cmCPackLog::LOG_ERROR, "Problem computing the md5 of "
+<< *fileIt << std::endl);
+}
+
+md5sum[32] = 0;
+
+std::string output(md5sum);
+output += "  " + *fileIt + "\n";
+// debian md5sums entries are like this:
+// 014f3604694729f3bf19263bac599765  usr/bin/ccmake
+// thus strip the full path (with the trailing slash)
+cmSystemTools::ReplaceString(output,
+ topLevelWithTrailingSlash.c_str(), "");
+out << output;
   }
 // each line contains a eol.
 // Do not end the md5sum file with yet another (invalid)
diff --git a/Tests/CPackComponentsDEB/CMakeLists.txt 
b/Tests/CPackComponentsDEB/CMakeLists.txt
index c25e33a..8ed81ac 100644
--- a/Tests/CPackComponentsDEB/CMakeLists.txt
+++ b/Tests/CPackComponentsDEB/CMakeLists.txt
@@ -93,6 +93,26 @@ if(CHMOD_PROG)
   "${CMAKE_CURRENT_BINARY_DIR}/preinst;${CMAKE_CURRENT_BINARY_DIR}/prerm")
 endif()
 
+# creates a symbolic link and a directory. Those should not be hashed.
+# warning: relocation of the symlink is not supported (symlinks with relative
+# paths)
+execute_process(COMMAND ${CMAKE_COMMAND} -E create_symlink mylibapp symtest)
+install(FILES ${CPackComponentsDEB_BINARY_DIR}/symtest
+DESTINATION bin
+COMPONENT applications)
+
+if(EXISTS "./dirtest")
+  execute_process(COMMAND ${CMAKE_COMMAND} -E remove_directory ./dirtest)
+endif()
+execute_process(COMMAND ${CMAKE_COMMAND} -E make_directory ./dirtest)
+# BUG: apparently cannot add an empty directory
+execute_process(COMMAND ${CMAKE_COMMAND} -E create_symlink ../mylibapp 
./dirtest/symtest)
+# NOTE: we should not add the trailing "/" to dirtest
+install(DIRECTORY ${CPackComponentsDEB_BINARY_DIR}/dirtest
+DESTINATION bin/
+COMPONENT applications)
+
+
 
 # We may use the CPack specific config file in order
 # to tailor CPack behavior on a CPack generator specific way
diff --git 
a/Tests/CPackComponentsDEB/RunCPackVerifyResult-components-lintian-dpkgdeb-checks.cmake
 
b/Tests/CPackComponentsDEB/RunCPackVerifyResult-components-lintian-dpkgdeb-checks.cmake
index 5460b1a..c2b2417 100644
--- 
a/Tests/CPackComponentsDEB/RunCPackVerifyResult-components-lintian-dpkgdeb-checks.cmake
+++ 
b/Tests/CPackComponentsDEB/RunCPackVerifyResult-components-lintian-dpkgdeb-checks.cmake
@@ -42,6 +42,13 @@ if(LINTIAN_EXECUTABLE)
   ERROR_REGEX_STRINGS "${STRINGS_TO_AVOID}")
 
 set(lintian_output_errors_all 

Re: [cmake-developers] [CPackDeb][libarchive] removing use of fakeroot and supporting UID/GID/UNAME etc in libarchive

[Raffi Enficiaud]

Le 14/09/15 11:51, Raffi Enficiaud a écrit :

Hi Brad and Domen and others,

I just realized that the permissions for the extra control files should
be set in a different way than for the md5sum checksum file.

Please find attached the patch correcting this and the corresponding
test that fires the problem.

Best,
Raffi



It's better with the attachment, sorry.

Raffi

>From 45fa572012ae2140a8b81d56c8d4b0b10e30c19f Mon Sep 17 00:00:00 2001
From: Raffi Enficiaud 
Date: Mon, 14 Sep 2015 11:42:33 +0200
Subject: [PATCH] cpackdeb: reset extra file permissions to their original

Adding a note about the file permissions on the extra files.
---
 Modules/CPackDeb.cmake  |  7 ++-
 Source/CPack/cmCPackDebGenerator.cxx|  4 +++-
 Tests/CPackComponentsDEB/CMakeLists.txt | 14 ++
 3 files changed, 23 insertions(+), 2 deletions(-)

diff --git a/Modules/CPackDeb.cmake b/Modules/CPackDeb.cmake
index 970a7d0..0ccfee4 100644
--- a/Modules/CPackDeb.cmake
+++ b/Modules/CPackDeb.cmake
@@ -326,7 +326,12 @@
 #
 #   set(CPACK_DEBIAN_PACKAGE_CONTROL_EXTRA
 #   "${CMAKE_CURRENT_SOURCE_DIR/prerm;${CMAKE_CURRENT_SOURCE_DIR}/postrm")
-
+#
+#  .. note::
+#
+#The original permissions of the files will be used in the final
+#package. In particular, the scripts should have the proper executable
+#flag prior to the generation of the package.
 
 #=
 # Copyright 2007-2009 Kitware, Inc.
diff --git a/Source/CPack/cmCPackDebGenerator.cxx 
b/Source/CPack/cmCPackDebGenerator.cxx
index dc9fca3..981d86d 100644
--- a/Source/CPack/cmCPackDebGenerator.cxx
+++ b/Source/CPack/cmCPackDebGenerator.cxx
@@ -576,7 +576,7 @@ int cmCPackDebGenerator::createDeb()
 control_tar.SetUNAME("root");
 control_tar.SetGNAME("root");
 
-// set md5sum file permissins to RW-R--R-- so that deb lintian
+// set md5sum file permissions to RW-R--R-- so that deb lintian
 // doesn't warn about it
 control_tar.SetPermissions(S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
 
@@ -597,6 +597,8 @@ int cmCPackDebGenerator::createDeb()
   this->GetOption("GEN_CPACK_DEBIAN_PACKAGE_CONTROL_EXTRA");
 if( controlExtra )
   {
+  // permissions are now controlled by the original file permissions
+  control_tar.SetPermissions(-1);
   std::vector controlExtraList;
   cmSystemTools::ExpandListArgument(controlExtra, controlExtraList);
   for(std::vector::iterator i = controlExtraList.begin();
diff --git a/Tests/CPackComponentsDEB/CMakeLists.txt 
b/Tests/CPackComponentsDEB/CMakeLists.txt
index 5c4eeab..c25e33a 100644
--- a/Tests/CPackComponentsDEB/CMakeLists.txt
+++ b/Tests/CPackComponentsDEB/CMakeLists.txt
@@ -80,6 +80,20 @@ set(CPACK_COMPONENT_HEADERS_DESCRIPTION
 # depend on the libraries component.
 set(CPACK_COMPONENT_HEADERS_DEPENDS libraries)
 
+# creates preinst/prerm scripts with specific permissions. Those permissions
+# (especially executable) should be in the final archive
+find_program(CHMOD_PROG chmod)
+if(CHMOD_PROG)
+  file(WRITE ${CMAKE_CURRENT_BINARY_DIR}/preinst "echo default_preinst")
+  file(WRITE ${CMAKE_CURRENT_BINARY_DIR}/prerm "echo default_prerm")
+  execute_process(COMMAND ${CHMOD_PROG} a+x 
${CMAKE_CURRENT_BINARY_DIR}/preinst)
+  execute_process(COMMAND ${CHMOD_PROG} a+x ${CMAKE_CURRENT_BINARY_DIR}/prerm)
+
+  set(CPACK_DEBIAN_APPLICATIONS_PACKAGE_CONTROL_EXTRA
+  "${CMAKE_CURRENT_BINARY_DIR}/preinst;${CMAKE_CURRENT_BINARY_DIR}/prerm")
+endif()
+
+
 # We may use the CPack specific config file in order
 # to tailor CPack behavior on a CPack generator specific way
 # (Behavior would be different for RPM or TGZ or DEB ...)
-- 
1.9.1

-- 

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-commits] CMake branch, master, updated. v3.3.1-1153-g8af3474

[Brad King]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  8af34749fe95e03596db0fd79184e2adf8d8b1fb (commit)
   via  5d6aa3648bb6d8f3be320fc08e16e810a782c054 (commit)
   via  3f4e5e8c3d3926af0a0f05b4c1547cb3fd15 (commit)
  from  f844993c243ae271469d33347402bf3174dff683 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8af34749fe95e03596db0fd79184e2adf8d8b1fb
commit 8af34749fe95e03596db0fd79184e2adf8d8b1fb
Merge: f844993 5d6aa36
Author: Brad King 
AuthorDate: Mon Sep 14 09:19:51 2015 -0400
Commit: CMake Topic Stage 
CommitDate: Mon Sep 14 09:19:51 2015 -0400

Merge topic 'fix-makefile-progress'

5d6aa364 cmLocalGenerator: Always return the end snapshot state of a 
directory.
3f4e5e8c cmState: Return end snapshot for GetBuildsystemDirectoryParent.


---

Summary of changes:
 Source/cmLocalGenerator.cxx |2 +-
 Source/cmState.cxx  |3 ++-
 2 files changed, 3 insertions(+), 2 deletions(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, master, updated. v3.3.1-1164-gf660a68

[Brad King]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  f660a6890cdd8931d5f820f34d59ab9217a6d02b (commit)
   via  fd26a19afc24ac6ce62c4c31ec589c0d296f15de (commit)
  from  31117bb17c4e764bb60b8c9c6847a631cc9ecf3c (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f660a6890cdd8931d5f820f34d59ab9217a6d02b
commit f660a6890cdd8931d5f820f34d59ab9217a6d02b
Merge: 31117bb fd26a19
Author: Brad King 
AuthorDate: Mon Sep 14 09:20:01 2015 -0400
Commit: CMake Topic Stage 
CommitDate: Mon Sep 14 09:20:01 2015 -0400

Merge topic 'FindHDF5-updates'

fd26a19a FindHDF5: Add NAMES_PER_DIR and introduce HDF5_PREFER_PARALLEL


---

Summary of changes:
 Help/release/dev/FindHDF5-updates.rst |6 ++
 Modules/FindHDF5.cmake|   28 
 2 files changed, 30 insertions(+), 4 deletions(-)
 create mode 100644 Help/release/dev/FindHDF5-updates.rst


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, next, updated. v3.3.1-2894-g6f95ab5

[Brad King]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  6f95ab5feffdefbb9d0070c6fb56972dcda9655f (commit)
   via  f660a6890cdd8931d5f820f34d59ab9217a6d02b (commit)
   via  31117bb17c4e764bb60b8c9c6847a631cc9ecf3c (commit)
   via  75ad8d342119be9e71006c2f352755ad9565963b (commit)
   via  e32604d67be88dda63601eec5bfe734657b0d2ac (commit)
   via  8af34749fe95e03596db0fd79184e2adf8d8b1fb (commit)
   via  f844993c243ae271469d33347402bf3174dff683 (commit)
   via  e52aa5619cc2cbc30adb80d9008986c03c9b9637 (commit)
   via  2e11afd2f72c6f2e5d69831a8f960a61dd2b28ec (commit)
  from  993e178cfd3fab54f089fe28a03257a41409d7ba (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6f95ab5feffdefbb9d0070c6fb56972dcda9655f
commit 6f95ab5feffdefbb9d0070c6fb56972dcda9655f
Merge: 993e178 f660a68
Author: Brad King 
AuthorDate: Mon Sep 14 09:20:14 2015 -0400
Commit: Brad King 
CommitDate: Mon Sep 14 09:20:14 2015 -0400

Merge branch 'master' into next


---

Summary of changes:
 Source/CMakeVersion.cmake |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, master, updated. v3.3.1-1166-g6dad4c2

[Brad King]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  6dad4c25b06ae232c766d76747b080373fb2499d (commit)
   via  db7f069a4b33f3e8b45142b67289e51c142c90b4 (commit)
  from  f660a6890cdd8931d5f820f34d59ab9217a6d02b (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6dad4c25b06ae232c766d76747b080373fb2499d
commit 6dad4c25b06ae232c766d76747b080373fb2499d
Merge: f660a68 db7f069
Author: Brad King 
AuthorDate: Mon Sep 14 09:21:00 2015 -0400
Commit: CMake Topic Stage 
CommitDate: Mon Sep 14 09:21:00 2015 -0400

Merge topic 'fix_64bit_autodef'

db7f069a Windows: Fix 64-bit DLL module definition file generation on VS 
2015


---

Summary of changes:
 Source/bindexplib.cxx |   19 +++
 1 file changed, 15 insertions(+), 4 deletions(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, next, updated. v3.3.1-2885-g993e178

[Brad King]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  993e178cfd3fab54f089fe28a03257a41409d7ba (commit)
   via  db7f069a4b33f3e8b45142b67289e51c142c90b4 (commit)
  from  f8aeb20b2c7da9b67adc960d44d0f7ce588d8b7c (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=993e178cfd3fab54f089fe28a03257a41409d7ba
commit 993e178cfd3fab54f089fe28a03257a41409d7ba
Merge: f8aeb20 db7f069
Author: Brad King 
AuthorDate: Mon Sep 14 09:18:34 2015 -0400
Commit: CMake Topic Stage 
CommitDate: Mon Sep 14 09:18:34 2015 -0400

Merge topic 'fix_64bit_autodef' into next

db7f069a Windows: Fix 64-bit DLL module definition file generation on VS 
2015


http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=db7f069a4b33f3e8b45142b67289e51c142c90b4
commit db7f069a4b33f3e8b45142b67289e51c142c90b4
Author: Bill Hoffman 
AuthorDate: Thu Sep 10 17:12:41 2015 -0400
Commit: Brad King 
CommitDate: Mon Sep 14 09:16:49 2015 -0400

Windows: Fix 64-bit DLL module definition file generation on VS 2015

With 64-bit Windows builds, there is no need to remove the leading
underscore from all the symbols.  This is because it does not have one
in the .obj file unless it is really in the name.  This did not cause
any trouble until VS 2015 which has some system functions that have a
leading underscore that end up in the .def file.

diff --git a/Source/bindexplib.cxx b/Source/bindexplib.cxx
index 11e3f34..dc4db63 100644
--- a/Source/bindexplib.cxx
+++ b/Source/bindexplib.cxx
@@ -173,7 +173,7 @@ public:
*/
 
DumpSymbols(ObjectHeaderType* ih,
-   FILE* fout) {
+   FILE* fout, bool is64) {
   this->ObjectImageHeader = ih;
   this->SymbolTable = (SymbolTableType*)
   ((DWORD_PTR)this->ObjectImageHeader
@@ -183,6 +183,7 @@ public:
 GetSectionHeaderOffset(this->ObjectImageHeader);
   this->ImportFlag = true;
   this->SymbolCount = this->ObjectImageHeader->NumberOfSymbols;
+  this->Is64Bit = is64;
}
 
   /*
@@ -287,7 +288,14 @@ public:
   symbol.erase(posAt);
}
 }
-if (symbol[0] == '_') symbol.erase(0,1);
+// For 64 bit builds we don't need to remove _
+if(!this->Is64Bit)
+  {
+  if (symbol[0] == '_')
+{
+symbol.erase(0,1);
+}
+  }
 if (this->ImportFlag) {
this->ImportFlag = false;
fprintf(this->FileOut,"EXPORTS \n");
@@ -355,6 +363,7 @@ private:
   PIMAGE_SECTION_HEADER SectionHeaders;
   ObjectHeaderType* ObjectImageHeader;
   SymbolTableType*  SymbolTable;
+  bool Is64Bit;
 };
 
 bool
@@ -406,7 +415,8 @@ DumpFile(const char* filename, FILE *fout)
   * and IMAGE_FILE_HEADER.SizeOfOptionalHeader == 0;
   */
   DumpSymbols
-symbolDumper((PIMAGE_FILE_HEADER) lpFileBase, fout);
+symbolDumper((PIMAGE_FILE_HEADER) lpFileBase, fout,
+ (dosHeader->e_magic == IMAGE_FILE_MACHINE_AMD64));
   symbolDumper.DumpObjFile();
} else {
   // check for /bigobj format
@@ -414,7 +424,8 @@ DumpFile(const char* filename, FILE *fout)
 (cmANON_OBJECT_HEADER_BIGOBJ*) lpFileBase;
   if(h->Sig1 == 0x0 && h->Sig2 == 0x) {
  DumpSymbols
-   symbolDumper((cmANON_OBJECT_HEADER_BIGOBJ*) lpFileBase, fout);
+   symbolDumper((cmANON_OBJECT_HEADER_BIGOBJ*) lpFileBase, fout,
+(dosHeader->e_magic == IMAGE_FILE_MACHINE_AMD64));
  symbolDumper.DumpObjFile();
   } else {
  printf("unrecognized file format in '%s'\n", filename);

---

Summary of changes:


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, master, updated. v3.3.1-1157-g75ad8d3

[Brad King]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  75ad8d342119be9e71006c2f352755ad9565963b (commit)
   via  97ffbcd8a4be25bbc661c68cb7d866bf9d5008d4 (commit)
  from  e32604d67be88dda63601eec5bfe734657b0d2ac (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=75ad8d342119be9e71006c2f352755ad9565963b
commit 75ad8d342119be9e71006c2f352755ad9565963b
Merge: e32604d 97ffbcd
Author: Brad King 
AuthorDate: Mon Sep 14 09:19:57 2015 -0400
Commit: CMake Topic Stage 
CommitDate: Mon Sep 14 09:19:57 2015 -0400

Merge topic 'fix-implicit-lib-redhat-hardened-ld'

97ffbcd8 CMakeParseImplicitLinkInfo: Do not match "VAR=..." as link line 
(#15737)


---

Summary of changes:
 Modules/CMakeParseImplicitLinkInfo.cmake   |2 +-
 Tests/CMakeTests/ImplicitLinkInfoTest.cmake.in |7 +++
 2 files changed, 8 insertions(+), 1 deletion(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, master, updated. v3.3.1-1155-ge32604d

[Brad King]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  e32604d67be88dda63601eec5bfe734657b0d2ac (commit)
   via  2468eb33b98fc4b315a40e14f146c29590ba666b (commit)
  from  8af34749fe95e03596db0fd79184e2adf8d8b1fb (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e32604d67be88dda63601eec5bfe734657b0d2ac
commit e32604d67be88dda63601eec5bfe734657b0d2ac
Merge: 8af3474 2468eb3
Author: Brad King 
AuthorDate: Mon Sep 14 09:19:55 2015 -0400
Commit: CMake Topic Stage 
CommitDate: Mon Sep 14 09:19:55 2015 -0400

Merge topic 'doc-OBJECT_DEPENDS-limitations'

2468eb33 Help: Document limitations of the OBJECT_DEPENDS source file 
property


---

Summary of changes:
 Help/prop_sf/OBJECT_DEPENDS.rst |   13 -
 1 file changed, 8 insertions(+), 5 deletions(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[cmake-developers] [CMake 0015742]: string(REGEX MATCH) and string(REGEX MATCHALL) concatenate arguments

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
http://public.kitware.com/Bug/view.php?id=15742 
== 
Reported By:Fujii Hironori
Assigned To:
== 
Project:CMake
Issue ID:   15742
Category:   Documentation
Reproducibility:N/A
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2015-09-14 09:43 EDT
Last Modified:  2015-09-14 09:43 EDT
== 
Summary:string(REGEX MATCH) and string(REGEX MATCHALL)
concatenate arguments
Description: 
> string(REGEX MATCH "a." out a b c)

'out' becomes "ab".

This is a intended behavior.

 [Cmake] regex error ? in 2.1
 http://www.cmake.org/pipermail/cmake/2004-June/005173.html

This should be documented.

== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2015-09-14 09:43 Fujii Hironori New Issue
==

-- 

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] [CPackDeb] empty directories in packages

[Raffi Enficiaud]

Hi Brad and Domen and others,

I was looking at this issue
http://public.kitware.com/Bug/view.php?id=13009

and apparently it is not possible to install empty directories (I just 
tested).


I believe that it should be possible to do that (even if there are 
better ways like postinst).

What is your opinion?

The attached patch addresses this (and adds the corresponding test). It 
is based on my previous patch 
"0001-CPackDeb-preventing-md5sum-on-symlinks.patch".


Thanks,
Raffi

From 96a0b35d408f8c0d9310eb753e95ed5d1f37424e Mon Sep 17 00:00:00 2001
From: Raffi Enficiaud 
Date: Mon, 14 Sep 2015 15:25:50 +0200
Subject: [PATCH] CPackDeb: enables empty directories in packages

---
 Source/CPack/cmCPackDebGenerator.cxx| 2 ++
 Tests/CPackComponentsDEB/CMakeLists.txt | 3 +--
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/Source/CPack/cmCPackDebGenerator.cxx 
b/Source/CPack/cmCPackDebGenerator.cxx
index 090c076..3c2189f 100644
--- a/Source/CPack/cmCPackDebGenerator.cxx
+++ b/Source/CPack/cmCPackDebGenerator.cxx
@@ -95,6 +95,7 @@ int cmCPackDebGenerator::PackageOnePack(std::string 
initialTopLevel,
   std::string findExpr(this->GetOption("GEN_WDIR"));
   findExpr += "/*";
   gl.RecurseOn();
+  gl.SetRecurseListDirs(true);
   if ( !gl.FindFiles(findExpr) )
 {
 cmCPackLogger(cmCPackLog::LOG_ERROR,
@@ -222,6 +223,7 @@ int cmCPackDebGenerator::PackageComponentsAllInOne()
   std::string findExpr(this->GetOption("GEN_WDIR"));
   findExpr += "/*";
   gl.RecurseOn();
+  gl.SetRecurseListDirs(true);
   if ( !gl.FindFiles(findExpr) )
 {
 cmCPackLogger(cmCPackLog::LOG_ERROR,
diff --git a/Tests/CPackComponentsDEB/CMakeLists.txt 
b/Tests/CPackComponentsDEB/CMakeLists.txt
index 8ed81ac..d4bd9f1 100644
--- a/Tests/CPackComponentsDEB/CMakeLists.txt
+++ b/Tests/CPackComponentsDEB/CMakeLists.txt
@@ -104,9 +104,8 @@ install(FILES ${CPackComponentsDEB_BINARY_DIR}/symtest
 if(EXISTS "./dirtest")
   execute_process(COMMAND ${CMAKE_COMMAND} -E remove_directory ./dirtest)
 endif()
+# NOTE: directory left empty on purpose
 execute_process(COMMAND ${CMAKE_COMMAND} -E make_directory ./dirtest)
-# BUG: apparently cannot add an empty directory
-execute_process(COMMAND ${CMAKE_COMMAND} -E create_symlink ../mylibapp 
./dirtest/symtest)
 # NOTE: we should not add the trailing "/" to dirtest
 install(DIRECTORY ${CPackComponentsDEB_BINARY_DIR}/dirtest
 DESTINATION bin/
-- 
1.9.1

-- 

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] Python extension to FindProtobuf

[Brad King]

On 09/14/2015 03:42 AM, Andreas Bergmeier wrote:
> I now added documentation, removed ARGS and GENERATED property.

Thanks.  Applied with minor wording tweaks:

 FindProtobuf: Add protobuf_generate_python function
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=143579c3

-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-commits] CMake branch, next, updated. v3.3.1-2899-g6e4c900

[Brad King]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  6e4c9000aa52c0b8140e612cb27fb4e4fc6ac82c (commit)
   via  ef29f5ef895f64ad7312ffe48029eee925ac3ae0 (commit)
   via  7de8f67af3fce3df9aee2b2a1c703fcbf4df6625 (commit)
  from  e81aa1a379fa721c800caef75c74e26e8acb9585 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6e4c9000aa52c0b8140e612cb27fb4e4fc6ac82c
commit 6e4c9000aa52c0b8140e612cb27fb4e4fc6ac82c
Merge: e81aa1a ef29f5e
Author: Brad King 
AuthorDate: Mon Sep 14 09:24:28 2015 -0400
Commit: CMake Topic Stage 
CommitDate: Mon Sep 14 09:24:28 2015 -0400

Merge topic 'update-kwsys' into next

ef29f5ef Merge branch 'upstream-kwsys' into update-kwsys
7de8f67a KWSys 2015-09-11 (cfeb27cc)


http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ef29f5ef895f64ad7312ffe48029eee925ac3ae0
commit ef29f5ef895f64ad7312ffe48029eee925ac3ae0
Merge: 6dad4c2 7de8f67
Author: Brad King 
AuthorDate: Mon Sep 14 09:24:05 2015 -0400
Commit: Brad King 
CommitDate: Mon Sep 14 09:24:05 2015 -0400

Merge branch 'upstream-kwsys' into update-kwsys


http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7de8f67af3fce3df9aee2b2a1c703fcbf4df6625
commit 7de8f67af3fce3df9aee2b2a1c703fcbf4df6625
Author: KWSys Robot 
AuthorDate: Fri Sep 11 11:20:29 2015 -0400
Commit: Brad King 
CommitDate: Mon Sep 14 09:24:02 2015 -0400

KWSys 2015-09-11 (cfeb27cc)

Extract upstream KWSys using the following shell commands.

$ git archive --prefix=upstream-kwsys/ cfeb27cc | tar x
$ git shortlog --no-merges --abbrev=8 --format='%h %s' dc3fdd7f..cfeb27cc
Gilles Khouzam (2):
  27714139 SystemTools: Call GetVersionEx more robustly
  cfeb27cc SystemTools: Report Windows 7, 8, 8.1 and 10 by name

diff --git a/SystemTools.cxx b/SystemTools.cxx
index 97a1df8..3857e41 100644
--- a/SystemTools.cxx
+++ b/SystemTools.cxx
@@ -4879,11 +4879,8 @@ std::string 
SystemTools::GetOperatingSystemNameAndVersion()
   OSVERSIONINFOEXA osvi;
   BOOL bOsVersionInfoEx;
 
-  // Try calling GetVersionEx using the OSVERSIONINFOEX structure.
-  // If that fails, try using the OSVERSIONINFO structure.
-
-  ZeroMemory(, sizeof(OSVERSIONINFOEXA));
-  osvi.dwOSVersionInfoSize = sizeof(OSVERSIONINFOEXA);
+  ZeroMemory(, sizeof(osvi));
+  osvi.dwOSVersionInfoSize = sizeof(osvi);
 
 #ifdef KWSYS_WINDOWS_DEPRECATED_GetVersionEx
 # pragma warning (push)
@@ -4893,14 +4890,10 @@ std::string 
SystemTools::GetOperatingSystemNameAndVersion()
 #  pragma warning (disable:4996)
 # endif
 #endif
-  bOsVersionInfoEx = GetVersionEx((OSVERSIONINFO *));
+  bOsVersionInfoEx = GetVersionExA((OSVERSIONINFOA *));
   if (!bOsVersionInfoEx)
 {
-osvi.dwOSVersionInfoSize = sizeof(OSVERSIONINFO);
-if (!GetVersionEx((OSVERSIONINFO *)))
-  {
-  return 0;
-  }
+return 0;
 }
 #ifdef KWSYS_WINDOWS_DEPRECATED_GetVersionEx
 # pragma warning (pop)
@@ -4913,10 +4906,56 @@ std::string 
SystemTools::GetOperatingSystemNameAndVersion()
 case VER_PLATFORM_WIN32_NT:
 
   // Test for the specific product family.
+  if (osvi.dwMajorVersion == 10 && osvi.dwMinorVersion == 0)
+{
+if (osvi.wProductType == VER_NT_WORKSTATION)
+  {
+  res += "Microsoft Windows 10";
+  }
+else
+  {
+  res += "Microsoft Windows Server 2016 family";
+  }
+}
+
+  if (osvi.dwMajorVersion == 6 && osvi.dwMinorVersion == 3)
+{
+if (osvi.wProductType == VER_NT_WORKSTATION)
+  {
+  res += "Microsoft Windows 8.1";
+  }
+else
+  {
+  res += "Microsoft Windows Server 2012 R2 family";
+  }
+}
+
+  if (osvi.dwMajorVersion == 6 && osvi.dwMinorVersion == 2)
+{
+if (osvi.wProductType == VER_NT_WORKSTATION)
+  {
+  res += "Microsoft Windows 8";
+  }
+else
+  {
+  res += "Microsoft Windows Server 2012 family";
+  }
+}
+
+  if (osvi.dwMajorVersion == 6 && osvi.dwMinorVersion == 1)
+{
+if (osvi.wProductType == VER_NT_WORKSTATION)
+  {
+  res += "Microsoft Windows 7";
+  }
+else
+  {
+  res += "Microsoft Windows Server 2008 R2 family";
+  }
+}
 
   if (osvi.dwMajorVersion == 6 && osvi.dwMinorVersion == 0)
 {
-#if (_MSC_VER >= 1300)
 if (osvi.wProductType == 

Re: [cmake-developers] Portability patches / bug fixes

[Brad King]

On 09/12/2015 11:03 AM, Joerg Sonnenberger wrote:
> attached are three patches for cmake. The first two should be trivial
> and self-explaining. The third is a more involved change for ccmake.

Thanks.  I've applied the changes:

 jsoncpp: Fix compilation as C99 on Solaris
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=75644daf

 ccmake: Pass format string to 'printw' (#15738)
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=acd9b4d3

 ccmake: Avoid using non-portable 'curcol' field (#15739)
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=045a845d

The latter two were also submitted to the issue tracker so I added
the issue numbers.  Another related patch was also submitted there:

 ccmake: Use more-portable call to set_field_buffer (#15740)
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c2128679

-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-commits] CMake branch, next, updated. v3.3.1-2912-g53ec406

[Brad King]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  53ec40614e8a0e638a9ef83f6b859fe4ec46c0b7 (commit)
   via  ec8e5fb3af5a24712dc3d4948de88cd4fda83cab (commit)
  from  a01af51341752f994023d73559d45fd12f02c652 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=53ec40614e8a0e638a9ef83f6b859fe4ec46c0b7
commit 53ec40614e8a0e638a9ef83f6b859fe4ec46c0b7
Merge: a01af51 ec8e5fb
Author: Brad King 
AuthorDate: Mon Sep 14 10:50:29 2015 -0400
Commit: CMake Topic Stage 
CommitDate: Mon Sep 14 10:50:29 2015 -0400

Merge topic 'fix-bad-search-ordering' into next

ec8e5fb3 find_*: Fix search order when the environment duplicates some HINTS


http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ec8e5fb3af5a24712dc3d4948de88cd4fda83cab
commit ec8e5fb3af5a24712dc3d4948de88cd4fda83cab
Author: Chuck Atkins 
AuthorDate: Wed Sep 9 16:03:04 2015 -0400
Commit: Brad King 
CommitDate: Mon Sep 14 10:46:44 2015 -0400

find_*: Fix search order when the environment duplicates some HINTS

Refactoring in the topic merged by commit v3.2.0-rc1~400 (Merge topic
'refactor-search-path-construction', 2014-11-13) introduced a bug that
filters out duplicate paths in an incorrect order.  Restore the search
path to its documented order even when duplicate paths are present.

Reported-by: Marc CHEVRIER 

diff --git a/Source/cmFindBase.cxx b/Source/cmFindBase.cxx
index 7959ffe..fa9b381 100644
--- a/Source/cmFindBase.cxx
+++ b/Source/cmFindBase.cxx
@@ -207,6 +207,10 @@ void cmFindBase::ExpandPaths()
   {
   this->FillCMakeEnvironmentPath();
   }
+}
+  this->FillUserHintsPath();
+  if(!this->NoDefaultPath)
+{
 if(!this->NoSystemEnvironmentPath)
   {
   this->FillSystemEnvironmentPath();
@@ -216,8 +220,6 @@ void cmFindBase::ExpandPaths()
   this->FillCMakeSystemVariablePath();
   }
 }
-
-  this->FillUserHintsPath();
   this->FillUserGuessPath();
 }
 
diff --git a/Source/cmFindPackageCommand.cxx b/Source/cmFindPackageCommand.cxx
index 9b9071d..64176e7 100644
--- a/Source/cmFindPackageCommand.cxx
+++ b/Source/cmFindPackageCommand.cxx
@@ -1133,6 +1133,10 @@ void cmFindPackageCommand::ComputePrefixes()
   {
   this->FillPrefixesCMakeEnvironment();
   }
+}
+  this->FillPrefixesUserHints();
+  if(!this->NoDefaultPath)
+{
 if(!this->NoSystemEnvironmentPath)
   {
   this->FillPrefixesSystemEnvironment();
@@ -1150,7 +1154,6 @@ void cmFindPackageCommand::ComputePrefixes()
   this->FillPrefixesSystemRegistry();
   }
 }
-  this->FillPrefixesUserHints();
   this->FillPrefixesUserGuess();
 
   this->ComputeFinalPaths();

---

Summary of changes:


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

Re: [cmake-developers] find_program HINTS no longer preferred over PATH

[Brad King]

On 09/14/2015 03:05 AM, CHEVRIER, Marc wrote:
> Any news on this subject?

Chuck has had a fix in 'next' for a few days:

 find_*: Fix search order when the environment duplicates some HINTS
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ec8e5fb3

but the topic is still missing a test case.

-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-commits] CMake branch, next, updated. v3.3.1-2901-ge9b1715

[Brad King]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  e9b171516ce17f0c8eb2dc964b8997ff1f4e5b30 (commit)
   via  75644dafe54c21902f14cfe58cb8338b553b69d8 (commit)
  from  6e4c9000aa52c0b8140e612cb27fb4e4fc6ac82c (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e9b171516ce17f0c8eb2dc964b8997ff1f4e5b30
commit e9b171516ce17f0c8eb2dc964b8997ff1f4e5b30
Merge: 6e4c900 75644da
Author: Brad King 
AuthorDate: Mon Sep 14 09:41:49 2015 -0400
Commit: CMake Topic Stage 
CommitDate: Mon Sep 14 09:41:49 2015 -0400

Merge topic 'jsoncpp-portability' into next

75644daf jsoncpp: Fix compilation as C99 on Solaris


http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=75644dafe54c21902f14cfe58cb8338b553b69d8
commit 75644dafe54c21902f14cfe58cb8338b553b69d8
Author: Joerg Sonnenberger 
AuthorDate: Sat Sep 12 16:34:12 2015 +0200
Commit: Brad King 
CommitDate: Mon Sep 14 09:40:38 2015 -0400

jsoncpp: Fix compilation as C99 on Solaris

In C99 mode, Solaris variants may already define isfinite, so check for
the existence first.

diff --git a/Utilities/cmjsoncpp/src/lib_json/json_writer.cpp 
b/Utilities/cmjsoncpp/src/lib_json/json_writer.cpp
index b64cdb0..e3f4e53 100644
--- a/Utilities/cmjsoncpp/src/lib_json/json_writer.cpp
+++ b/Utilities/cmjsoncpp/src/lib_json/json_writer.cpp
@@ -24,7 +24,9 @@
 // Solaris
 #if defined(__sun)
 # include 
-# define isfinite finite
+# if !defined(isfinite)
+#  define isfinite finite
+# endif
 #endif
 
 // AIX

---

Summary of changes:
 Utilities/cmjsoncpp/src/lib_json/json_writer.cpp |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, next, updated. v3.3.1-2905-gc8c7983

[Brad King]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  c8c79835fc8e3a062dd3a04b1d7d7d465d7e3a61 (commit)
   via  c212867961e4ce5ce99fbc682324aed4627e7a6f (commit)
   via  045a845d4744b8604ccdddb9091d3d7177b9a690 (commit)
   via  acd9b4d39300c8b3285bdc92c0db08b0bbf75574 (commit)
  from  e9b171516ce17f0c8eb2dc964b8997ff1f4e5b30 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c8c79835fc8e3a062dd3a04b1d7d7d465d7e3a61
commit c8c79835fc8e3a062dd3a04b1d7d7d465d7e3a61
Merge: e9b1715 c212867
Author: Brad King 
AuthorDate: Mon Sep 14 09:51:51 2015 -0400
Commit: CMake Topic Stage 
CommitDate: Mon Sep 14 09:51:51 2015 -0400

Merge topic 'ccmake-portability' into next

c2128679 ccmake: Use more-portable call to set_field_buffer (#15740)
045a845d ccmake: Avoid using non-portable 'curcol' field (#15739)
acd9b4d3 ccmake: Pass format string to 'printw' (#15738)


http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c212867961e4ce5ce99fbc682324aed4627e7a6f
commit c212867961e4ce5ce99fbc682324aed4627e7a6f
Author: Thomas Klausner 
AuthorDate: Mon Sep 14 09:32:54 2015 -0400
Commit: Brad King 
CommitDate: Mon Sep 14 09:48:01 2015 -0400

ccmake: Use more-portable call to set_field_buffer (#15740)

The set_field_buffer function on NetBSD and Solaris:

  http://netbsd.gw.com/cgi-bin/man-cgi?set_field_buffer++NetBSD-current
  
https://docs.oracle.com/cd/E36784_01/html/E36880/set-field-buffer-3curses.html

has as third argument "char *" while ncurses has "const char *".  Cast
the argument type in our call to account for the missing "const".

diff --git a/Source/CursesDialog/cmCursesWidget.cxx 
b/Source/CursesDialog/cmCursesWidget.cxx
index e5363f4..a12e4c2 100644
--- a/Source/CursesDialog/cmCursesWidget.cxx
+++ b/Source/CursesDialog/cmCursesWidget.cxx
@@ -49,7 +49,7 @@ void cmCursesWidget::Move(int x, int y, bool isNewPage)
 void cmCursesWidget::SetValue(const std::string& value)
 {
   this->Value = value;
-  set_field_buffer(this->Field, 0, value.c_str());
+  set_field_buffer(this->Field, 0, const_cast(value.c_str()));
 }
 
 const char* cmCursesWidget::GetValue()

http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=045a845d4744b8604ccdddb9091d3d7177b9a690
commit 045a845d4744b8604ccdddb9091d3d7177b9a690
Author: Joerg Sonnenberger 
AuthorDate: Sat Sep 12 16:37:35 2015 +0200
Commit: Brad King 
CommitDate: Mon Sep 14 09:46:55 2015 -0400

ccmake: Avoid using non-portable 'curcol' field (#15739)

'curcol' is an implementation detail of ncurses so other implementations
of 'form' may not have it.  The switch-to-previous-field logic only
exists for overloaded requests of REQ_DEL_PREV, so no need to check for
REQ_DEL_CHAR.  For REQ_DEL_PREV, check if the field changed and if it
did, change it back.

diff --git a/Source/CursesDialog/cmCursesStringWidget.cxx 
b/Source/CursesDialog/cmCursesStringWidget.cxx
index 1fe0945..8be2aa0 100644
--- a/Source/CursesDialog/cmCursesStringWidget.cxx
+++ b/Source/CursesDialog/cmCursesStringWidget.cxx
@@ -168,17 +168,16 @@ bool cmCursesStringWidget::HandleInput(int& key, 
cmCursesMainForm* fm,
 else if ( key == 127 ||
   key == KEY_BACKSPACE )
   {
-  if ( form->curcol > 0 )
-{
+FIELD *cur = current_field(form);
 form_driver(form, REQ_DEL_PREV);
-}
+if (current_field(form) != cur)
+  {
+  set_current_field(form, cur);
+  }
   }
 else if ( key == ctrl('d') ||key == KEY_DC )
   {
-  if ( form->curcol >= 0 )
-{
-form_driver(form, REQ_DEL_CHAR);
-}
+  form_driver(form, REQ_DEL_CHAR);
   }
 else
   {

http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=acd9b4d39300c8b3285bdc92c0db08b0bbf75574
commit acd9b4d39300c8b3285bdc92c0db08b0bbf75574
Author: Joerg Sonnenberger 
AuthorDate: Sat Sep 12 16:35:36 2015 +0200
Commit: Brad King 
CommitDate: Mon Sep 14 09:43:04 2015 -0400

ccmake: Pass format string to 'printw' (#15738)

printw takes a format string as first argument, so don't pass variable
strings to it directly.

diff --git a/Source/CursesDialog/cmCursesLongMessageForm.cxx 
b/Source/CursesDialog/cmCursesLongMessageForm.cxx
index 67e4aab..2e5e322 100644
--- a/Source/CursesDialog/cmCursesLongMessageForm.cxx
+++ b/Source/CursesDialog/cmCursesLongMessageForm.cxx
@@ -82,10 +82,10 @@ void 

[Cmake-commits] CMake branch, next, updated. v3.3.1-2910-ga01af51

[Brad King]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  a01af51341752f994023d73559d45fd12f02c652 (commit)
   via  3809150a3895c5e15793a6801ca1bd0eb1ee61b1 (commit)
   via  5f2c47c44c984e58887ac8c62f6319f75128cb13 (commit)
  from  ec5077cfa1f42eb7e10138098d1a4693fe6ce402 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a01af51341752f994023d73559d45fd12f02c652
commit a01af51341752f994023d73559d45fd12f02c652
Merge: ec5077c 3809150
Author: Brad King 
AuthorDate: Mon Sep 14 10:38:57 2015 -0400
Commit: CMake Topic Stage 
CommitDate: Mon Sep 14 10:38:57 2015 -0400

Merge topic 'doc-string-REGEX-concat' into next

3809150a Help: Document string(REGEX) input concatentation (#15742)
5f2c47c4 Help: Organize string command docs into sections


http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3809150a3895c5e15793a6801ca1bd0eb1ee61b1
commit 3809150a3895c5e15793a6801ca1bd0eb1ee61b1
Author: Brad King 
AuthorDate: Mon Sep 14 10:37:59 2015 -0400
Commit: Brad King 
CommitDate: Mon Sep 14 10:37:59 2015 -0400

Help: Document string(REGEX) input concatentation (#15742)

These commands concatenate all their input before matching.  Document
this behavior.

diff --git a/Help/command/string.rst b/Help/command/string.rst
index 4d6c0d0..0361c74 100644
--- a/Help/command/string.rst
+++ b/Help/command/string.rst
@@ -46,6 +46,7 @@ REGEX MATCH
[...])
 
 Match the regular expression once and store the match in the output variable.
+All  arguments are concatenated before matching.
 
 REGEX MATCHALL
 ""
@@ -57,6 +58,7 @@ REGEX MATCHALL
 
 Match the regular expression as many times as possible and store the matches
 in the output variable as a list.
+All  arguments are concatenated before matching.
 
 REGEX REPLACE
 "
@@ -69,6 +71,7 @@ REGEX REPLACE
 
 Match the regular expression as many times as possible and substitute the
 replacement expression for the match in the output.
+All  arguments are concatenated before matching.
 
 The replace expression may refer to paren-delimited subexpressions of the
 match using ``\1``, ``\2``, ..., ``\9``.  Note that two backslashes (``\\1``)

http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5f2c47c44c984e58887ac8c62f6319f75128cb13
commit 5f2c47c44c984e58887ac8c62f6319f75128cb13
Author: Brad King 
AuthorDate: Mon Sep 14 10:35:50 2015 -0400
Commit: Brad King 
CommitDate: Mon Sep 14 10:37:40 2015 -0400

Help: Organize string command docs into sections

Add section headers and titles for each command signature.  Group
related commands into sections.

diff --git a/Help/command/string.rst b/Help/command/string.rst
index 20f8094..4d6c0d0 100644
--- a/Help/command/string.rst
+++ b/Help/command/string.rst
@@ -1,102 +1,81 @@
 string
 --
 
+.. only:: html
+
+   .. contents::
+
 String operations.
 
+Search and Replace
+^^
+
+FIND
+
+
 ::
 
-  string(REGEX MATCH 
-   [...])
-  string(REGEX MATCHALL 
-   [...])
-  string(REGEX REPLACE 
-  
-  [...])
-  string(REPLACE 
-  
-  [...])
-  string(APPEND  [...])
-  string(CONCAT  [...])
-  string(
-  )
-  string(COMPARE EQUAL   )
-  string(COMPARE NOTEQUAL   )
-  string(COMPARE LESS   )
-  string(COMPARE GREATER   )
-  string(ASCII  [ ...] )
-  string(CONFIGURE  
- [@ONLY] [ESCAPE_QUOTES])
-  string(TOUPPER  )
-  string(TOLOWER  )
-  string(LENGTH  )
-  string(SUBSTRING)
-  string(STRIP  )
-  string(RANDOM [LENGTH ] [ALPHABET ]
- [RANDOM_SEED ] )
   string(FIND[REVERSE])
-  string(TIMESTAMP  [] [UTC])
-  string(MAKE_C_IDENTIFIER  )
-  string(GENEX_STRIP  )
-  string(UUID  NAMESPACE  NAME 
- TYPE  [UPPER])
 
-``REGEX MATCH`` will match the regular expression once and store the match
-in the output variable.
+Return the position where the given substring was found in
+the supplied string.  If the ``REVERSE`` flag was used, the command will
+search for the position of the last occurrence of the specified
+substring.  If the substring is not found, a position of -1 is returned.
 
-``REGEX MATCHALL`` will match the regular expression as many times as
-possible and store the matches in the output variable as a list.
+REPLACE
+"""
 
-``REGEX REPLACE`` will match the regular expression as many times as
-possible and substitute the replacement expression for the 

[Cmake-commits] CMake branch, next, updated. v3.3.1-2907-gec5077c

[Brad King]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  ec5077cfa1f42eb7e10138098d1a4693fe6ce402 (commit)
   via  143579c319472facbcfc3285f0b6b0ab56f1bde3 (commit)
  from  c8c79835fc8e3a062dd3a04b1d7d7d465d7e3a61 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ec5077cfa1f42eb7e10138098d1a4693fe6ce402
commit ec5077cfa1f42eb7e10138098d1a4693fe6ce402
Merge: c8c7983 143579c
Author: Brad King 
AuthorDate: Mon Sep 14 10:11:18 2015 -0400
Commit: CMake Topic Stage 
CommitDate: Mon Sep 14 10:11:18 2015 -0400

Merge topic 'FindProtobuf-python-extension' into next

143579c3 FindProtobuf: Add protobuf_generate_python function


http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=143579c319472facbcfc3285f0b6b0ab56f1bde3
commit 143579c319472facbcfc3285f0b6b0ab56f1bde3
Author: Andreas Bergmeier 
AuthorDate: Mon Sep 14 09:41:38 2015 +0200
Commit: Brad King 
CommitDate: Mon Sep 14 10:10:35 2015 -0400

FindProtobuf: Add protobuf_generate_python function

diff --git a/Help/release/dev/FindProtobuf-python-extension.rst 
b/Help/release/dev/FindProtobuf-python-extension.rst
new file mode 100644
index 000..95463bf
--- /dev/null
+++ b/Help/release/dev/FindProtobuf-python-extension.rst
@@ -0,0 +1,6 @@
+FindProtobuf-python-extension
+-
+
+* The :module:`FindProtobuf` module gained a new
+  :command:`protobuf_generate_python` function to generate python
+  sources from ``.proto`` files.
diff --git a/Modules/FindProtobuf.cmake b/Modules/FindProtobuf.cmake
index 335c408..6bf565b 100644
--- a/Modules/FindProtobuf.cmake
+++ b/Modules/FindProtobuf.cmake
@@ -57,17 +57,18 @@
 #   include_directories(${PROTOBUF_INCLUDE_DIRS})
 #   include_directories(${CMAKE_CURRENT_BINARY_DIR})
 #   protobuf_generate_cpp(PROTO_SRCS PROTO_HDRS foo.proto)
+#   protobuf_generate_python(PROTO_PY foo.proto)
 #   add_executable(bar bar.cc ${PROTO_SRCS} ${PROTO_HDRS})
 #   target_link_libraries(bar ${PROTOBUF_LIBRARIES})
 #
 # .. note::
-#   The PROTOBUF_GENERATE_CPP macro and add_executable() or
-#   add_library() calls only work properly within the same
-#   directory.
+#   The ``protobuf_generate_cpp`` and ``protobuf_generate_python``
+#   functions and :command:`add_executable` or :command:`add_library`
+#   calls only work properly within the same directory.
 #
 # .. command:: protobuf_generate_cpp
 #
-#   Add custom commands to process ``.proto`` files::
+#   Add custom commands to process ``.proto`` files to C++::
 #
 # protobuf_generate_cpp (  [...])
 #
@@ -77,6 +78,17 @@
 # Variable to define with autogenerated header files
 #   ``ARGN``
 # ``.proto`` files
+#
+# .. command:: protobuf_generate_python
+#
+#   Add custom commands to process ``.proto`` files to Python::
+#
+# protobuf_generate_python ( [...])
+#
+#   ``PY``
+# Variable to define with autogenerated Python files
+#   ``ARGN``
+# ``.proto`` filess
 
 #=
 # Copyright 2009 Kitware, Inc.
@@ -147,6 +159,53 @@ function(PROTOBUF_GENERATE_CPP SRCS HDRS)
   set(${HDRS} ${${HDRS}} PARENT_SCOPE)
 endfunction()
 
+function(PROTOBUF_GENERATE_PYTHON SRCS)
+  if(NOT ARGN)
+message(SEND_ERROR "Error: PROTOBUF_GENERATE_PYTHON() called without any 
proto files")
+return()
+  endif()
+
+  if(PROTOBUF_GENERATE_CPP_APPEND_PATH)
+# Create an include path for each file specified
+foreach(FIL ${ARGN})
+  get_filename_component(ABS_FIL ${FIL} ABSOLUTE)
+  get_filename_component(ABS_PATH ${ABS_FIL} PATH)
+  list(FIND _protobuf_include_path ${ABS_PATH} _contains_already)
+  if(${_contains_already} EQUAL -1)
+  list(APPEND _protobuf_include_path -I ${ABS_PATH})
+  endif()
+endforeach()
+  else()
+set(_protobuf_include_path -I ${CMAKE_CURRENT_SOURCE_DIR})
+  endif()
+
+  if(DEFINED PROTOBUF_IMPORT_DIRS)
+foreach(DIR ${PROTOBUF_IMPORT_DIRS})
+  get_filename_component(ABS_PATH ${DIR} ABSOLUTE)
+  list(FIND _protobuf_include_path ${ABS_PATH} _contains_already)
+  if(${_contains_already} EQUAL -1)
+  list(APPEND _protobuf_include_path -I ${ABS_PATH})
+  endif()
+endforeach()
+  endif()
+
+  set(${SRCS})
+  foreach(FIL ${ARGN})
+get_filename_component(ABS_FIL ${FIL} ABSOLUTE)
+get_filename_component(FIL_WE ${FIL} NAME_WE)
+
+list(APPEND ${SRCS} "${CMAKE_CURRENT_BINARY_DIR}/${FIL_WE}.pb.py")
+add_custom_command(
+  OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/${FIL_WE}.pb.py"
+ 

Re: [CMake] FindGit.cmake proposal

[Gregor Jasny via CMake]

Hello,

On 10/09/15 16:34, Daniel Wirtz wrote:
> i've now quite often encountered the need to access basic git
> information about the source tree from within cmake.
> i've attached the current FindGit.cmake module shipped with CMake
> enhanced by two functions: getGitRevision and getGitBranch.
> if you fancy the idea of having this included, feel free to include any
> part of it in future releases.

Very helpful. ARAIR functions declared inside modules should be prefixed
by the module name. So your functions should become

git_get_xyz()

Please also properly document your function
(add a .. command:: ):

http://www.cmake.org/cmake/help/v3.3/manual/cmake-developer.7.html#help

If you need assistance, I'm glad to help.

Thanks,
Gregor


-- 

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

Re: [cmake-developers] Listing all targets

[David Cole via cmake-developers]

Finally getting back to this, hopefully can push to next this week,
and have this completed in time for the upcoming 3.4 release.

I have three questions before attempting my first merge-to-next for testing:

(1) I see how I can easily move "COMPONENTS" from
cmGetCMakePropertyCommand::InitialPass to cmState::GetGlobalProperty
because I can access the global generator from cmState as well... To
move "VARIABLES" and "MACROS," though, I need access to the correct
cmMakefile in which the cmGetCMakePropertyCommand is running. Do I
need to pass the cmMakefile instance as a new parameter to
cmState::GetGlobalProperty, or is the correct Makefile instance
already available from the context of the cmState? (If so, it's
non-obvious to me from code analysis...) Steve, Brad? Any input on
this question?

(2) I will update the documentation of get_cmake_property to say these
are all also available via get_property(GLOBAL ... That's the correct
intent, right? All calls to get_cmake_property should have exactly the
same content as a corresponding call to get_property(GLOBAL?

(3) Is anyone concerned about adding a global property with the
somewhat generic name "TARGETS" ? Do we care if any projects out there
are already doing a set_property(GLOBAL with the name "TARGETS"? The
downside of a project doing so would be that when they try to read the
value back with get_property, CMake's implementation will overwrite
their set values with the list of all available CMake targets, which
may be different than what the project had set into the property.


Thanks for any feedback,
David C.




On Mon, Jul 20, 2015 at 9:30 AM, Brad King  wrote:
> On 07/17/2015 06:05 PM, David Cole via cmake-developers wrote:
>> Attached is a patch file of my first attempt. I can iterate some more
>> on this (better testing, add docs, clarify existing docs, address
>> anybody's comments, submit to stage) next week. Attached now in case
>> anybody wants to try it out over the weekend.
> [snip]
>>> I think the see also is relevant because it points to another way to
>>> get to a whole different set of "properties". Perhaps what they're
>>> looking for when they stumble upon get_cmake_property is actually
>>> target properties, which are only accessible via get_property.
>
> get_cmake_property is get_property with the GLOBAL scope, except that
> it looks like the special VARIABLES, MACROS, and COMPONENTS properties
> are hard-coded into get_cmake_property incorrectly.
>
> This should all be moved over to cmState::GetGlobalProperty and the
> new TARGETS property added there.  That method already has special
> handling for a few other properties too.
>
> Also the documentation of get_cmake_property should be updated to
> mention "global" properties.
>
> -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
-- 

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] Features: Only enable C11 support on GCC >= 4.9.

[Raphael Kubo da Costa]

As of version 3.3.1, CMake sets CMAKE_C11_STANDARD_COMPILE_OPTION and
CMAKE_C11_EXTENSION_COMPILE_OPTION for GCC >= 4.7, and checks for C11
features for GCC >= 4.6. It also means CMake itself will be built with
-std=gnu11 if GCC >= 4.7 is used.

However, GCC only has full C11 support with the 4.9 release according to
https://gcc.gnu.org/wiki/C11Status. Specifically, support for C11's
_Thread_local is only present on GCC >= 4.9. This combination makes
CMake fail to build with GCC 4.7 and 4.8 on FreeBSD, as runetype.h uses
_Thread_local and the fact that -std=gnu11 is passed makes it not be a
typedef or define for something else that would work.

Adjust the GCC feature detection code to only consider C11 support to
exist on GCC >= 4.9.

Bug: http://www.cmake.org/Bug/view.php?id=15741
---
 Modules/Compiler/GNU-C-FeatureTests.cmake | 7 +--
 Modules/Compiler/GNU-C.cmake  | 7 ++-
 2 files changed, 3 insertions(+), 11 deletions(-)

diff --git a/Modules/Compiler/GNU-C-FeatureTests.cmake 
b/Modules/Compiler/GNU-C-FeatureTests.cmake
index b3fe33f..c7f5050 100644
--- a/Modules/Compiler/GNU-C-FeatureTests.cmake
+++ b/Modules/Compiler/GNU-C-FeatureTests.cmake
@@ -1,12 +1,7 @@
 
 set(_cmake_oldestSupported "(__GNUC__ * 100 + __GNUC_MINOR__) >= 404")
 
-# GNU 4.7 correctly sets __STDC_VERSION__ to 201112L, but GNU 4.6 sets it
-# to 201000L.  As the former is strictly greater than the latter, test only
-# for the latter.  If in the future CMake learns about a C feature which was
-# introduced with GNU 4.7, that should test for the correct version, similar
-# to the distinction between __cplusplus and __GXX_EXPERIMENTAL_CXX0X__ tests.
-set(GNU46_C11 "(__GNUC__ * 100 + __GNUC_MINOR__) >= 406 && 
defined(__STDC_VERSION__) && __STDC_VERSION__ >= 201000L")
+set(GNU49_C11 "(__GNUC__ * 100 + __GNUC_MINOR__) >= 409 && 
defined(__STDC_VERSION__) && __STDC_VERSION__ >= 201112L")
 set(_cmake_feature_test_c_static_assert "${GNU46_C11}")
 # Since 4.4 at least:
 set(GNU44_C99 "(__GNUC__ * 100 + __GNUC_MINOR__) >= 404 && 
defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L")
diff --git a/Modules/Compiler/GNU-C.cmake b/Modules/Compiler/GNU-C.cmake
index 031ab73..f1036db 100644
--- a/Modules/Compiler/GNU-C.cmake
+++ b/Modules/Compiler/GNU-C.cmake
@@ -14,12 +14,9 @@ if (NOT CMAKE_C_COMPILER_VERSION VERSION_LESS 4.4)
   set(CMAKE_C99_EXTENSION_COMPILE_OPTION "-std=gnu99")
 endif()
 
-if (NOT CMAKE_C_COMPILER_VERSION VERSION_LESS 4.7)
+if (NOT CMAKE_C_COMPILER_VERSION VERSION_LESS 4.9)
   set(CMAKE_C11_STANDARD_COMPILE_OPTION "-std=c11")
   set(CMAKE_C11_EXTENSION_COMPILE_OPTION "-std=gnu11")
-elseif (NOT CMAKE_C_COMPILER_VERSION VERSION_LESS 4.6)
-  set(CMAKE_C11_STANDARD_COMPILE_OPTION "-std=c1x")
-  set(CMAKE_C11_EXTENSION_COMPILE_OPTION "-std=gnu1x")
 endif()
 
 if (NOT CMAKE_C_COMPILER_VERSION VERSION_LESS 5.0)
@@ -34,7 +31,7 @@ macro(cmake_record_c_compile_features)
   endmacro()
 
   set(_result 0)
-  if (NOT CMAKE_C_COMPILER_VERSION VERSION_LESS 4.6)
+  if (NOT CMAKE_C_COMPILER_VERSION VERSION_LESS 4.9)
 _get_gcc_features(${CMAKE_C11_STANDARD_COMPILE_OPTION} 
CMAKE_C11_COMPILE_FEATURES)
   endif()
   if (NOT CMAKE_C_COMPILER_VERSION VERSION_LESS 4.4)
-- 
2.5.2

-- 

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-commits] CMake branch, next, updated. v3.3.1-2914-gab5441a

[Chuck Atkins]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  ab5441a9540c4bf649927845a08214de6152f353 (commit)
   via  14161a21f0e873dbc71ef770813494264f6449d8 (commit)
  from  53ec40614e8a0e638a9ef83f6b859fe4ec46c0b7 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ab5441a9540c4bf649927845a08214de6152f353
commit ab5441a9540c4bf649927845a08214de6152f353
Merge: 53ec406 14161a2
Author: Chuck Atkins 
AuthorDate: Mon Sep 14 11:52:51 2015 -0400
Commit: CMake Topic Stage 
CommitDate: Mon Sep 14 11:52:51 2015 -0400

Merge topic 'restrict-shlib-link-flags-to-enable-exports' into next

14161a21 CMP0065: Miscelaneous cleanup


http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=14161a21f0e873dbc71ef770813494264f6449d8
commit 14161a21f0e873dbc71ef770813494264f6449d8
Author: Chuck Atkins 
AuthorDate: Mon Sep 14 11:49:13 2015 -0400
Commit: Chuck Atkins 
CommitDate: Mon Sep 14 11:49:13 2015 -0400

CMP0065: Miscelaneous cleanup

diff --git a/Source/cmLocalGenerator.cxx b/Source/cmLocalGenerator.cxx
index 36fa610..e2aa796 100644
--- a/Source/cmLocalGenerator.cxx
+++ b/Source/cmLocalGenerator.cxx
@@ -1546,7 +1546,7 @@ void cmLocalGenerator::OutputLinkLibraries(std::string& 
linkLibraries,
   std::ostringstream w;
   w << cmPolicies::GetPolicyWarning(cmPolicies::CMP0065) << "\n"
 "For compatibility with older versions of CMake, "
-"CMAKE_SHARED_LIBRARY_LINK__FLAGS are being used on all "
+"additional flags may be added to export symbols on all "
 "executables regardless of thier ENABLE_EXPORTS property.";
   this->Makefile->IssueMessage(cmake::AUTHOR_WARNING, w.str());
   }
diff --git a/Source/cmPolicies.h b/Source/cmPolicies.h
index 72f889e..820c9cc 100644
--- a/Source/cmPolicies.h
+++ b/Source/cmPolicies.h
@@ -222,7 +222,7 @@ class cmPolicy;
 "Support new TEST if() operator.", \
 3, 3, 0, cmPolicies::WARN) \
   SELECT(POLICY, CMP0065, \
-"Only use CMAKE_SHARED_LIBRARY_LINK__FLAGS on executables with " \
+"Only use additional flags to export symbols on executables with " \
 "the ENABLE_EXPORTS property.", \
 3, 3, 0, cmPolicies::WARN)
 
diff --git a/Tests/RunCMake/CMP0065/NEWBad.cmake 
b/Tests/RunCMake/CMP0065/NEWBad.cmake
index e25bc9d..79d9adb 100644
--- a/Tests/RunCMake/CMP0065/NEWBad.cmake
+++ b/Tests/RunCMake/CMP0065/NEWBad.cmake
@@ -1,5 +1,4 @@
-cmake_minimum_required(VERSION 3.3)
-project(TestCMP0065 C)
+enable_language(C)
 include(BuildTargetInSubProject.cmake)
 
 BuildTargetInSubProject(TestPolicyCMP0065 FooNEWBad FALSE)
diff --git a/Tests/RunCMake/CMP0065/NEWGood.cmake 
b/Tests/RunCMake/CMP0065/NEWGood.cmake
index 66f822d..a5b5d04 100644
--- a/Tests/RunCMake/CMP0065/NEWGood.cmake
+++ b/Tests/RunCMake/CMP0065/NEWGood.cmake
@@ -1,5 +1,4 @@
-cmake_minimum_required(VERSION 3.3)
-project(TestCMP0065 C)
+enable_language(C)
 include(BuildTargetInSubProject.cmake)
 
 BuildTargetInSubProject(TestPolicyCMP0065 FooNEWGood TRUE)
diff --git a/Tests/RunCMake/CMP0065/OLDBad1.cmake 
b/Tests/RunCMake/CMP0065/OLDBad1.cmake
index 7234808..6d780b4 100644
--- a/Tests/RunCMake/CMP0065/OLDBad1.cmake
+++ b/Tests/RunCMake/CMP0065/OLDBad1.cmake
@@ -1,5 +1,4 @@
-cmake_minimum_required(VERSION 3.3)
-project(TestCMP0065 C)
+enable_language(C)
 include(BuildTargetInSubProject.cmake)
 
 BuildTargetInSubProject(TestPolicyCMP0065 FooOLDBad1 FALSE)
diff --git a/Tests/RunCMake/CMP0065/OLDBad2.cmake 
b/Tests/RunCMake/CMP0065/OLDBad2.cmake
index 2c877d9..7196473 100644
--- a/Tests/RunCMake/CMP0065/OLDBad2.cmake
+++ b/Tests/RunCMake/CMP0065/OLDBad2.cmake
@@ -1,5 +1,4 @@
-cmake_minimum_required(VERSION 3.3)
-project(TestCMP0065 C)
+enable_language(C)
 include(BuildTargetInSubProject.cmake)
 
 BuildTargetInSubProject(TestPolicyCMP0065 FooOLDBad2 FALSE)
diff --git a/Tests/RunCMake/CMakeLists.txt b/Tests/RunCMake/CMakeLists.txt
index 4049fac..d5d54fc 100644
--- a/Tests/RunCMake/CMakeLists.txt
+++ b/Tests/RunCMake/CMakeLists.txt
@@ -108,8 +108,7 @@ add_RunCMake_test(CMP0064)
 # The test for Policy 65 requires the use of the
 # CMAKE_SHARED_LIBRARY_LINK_CXX_FLAGS variable, which both the VS and Xcode
 # generators ignore.  The policy will have no effect on those generators.
-if((NOT CMAKE_GENERATOR MATCHES "Visual Studio") AND
-   (NOT CMAKE_GENERATOR MATCHES "Xcode"))
+if(NOT CMAKE_GENERATOR MATCHES "Visual Studio|Xcode")
   add_RunCMake_test(CMP0065)
 endif()
 if(CMAKE_GENERATOR MATCHES "Make")

[Cmake-commits] CMake branch, next, updated. v3.3.1-2917-g37278dc

[Chuck Atkins]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  37278dc705eb7cdb395a0d7b970cc4d82d2bf118 (commit)
   via  24ea86e9c04630c070baf897d361aa64ebaed781 (commit)
   via  ffbe3728a00d941115ac59c3cd3778a35eb03053 (commit)
  from  ab5441a9540c4bf649927845a08214de6152f353 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=37278dc705eb7cdb395a0d7b970cc4d82d2bf118
commit 37278dc705eb7cdb395a0d7b970cc4d82d2bf118
Merge: ab5441a 24ea86e
Author: Chuck Atkins 
AuthorDate: Mon Sep 14 11:53:35 2015 -0400
Commit: CMake Topic Stage 
CommitDate: Mon Sep 14 11:53:35 2015 -0400

Merge topic 'restrict-shlib-link-flags-to-enable-exports' into next

24ea86e9 try_compile: Propogate CMP0065 to the generated project.
ffbe3728 CMP0065: Restrict the use of CMAKE_SHARED_LIBRARY_LINK__FLAGS


http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=24ea86e9c04630c070baf897d361aa64ebaed781
commit 24ea86e9c04630c070baf897d361aa64ebaed781
Author: Chuck Atkins 
AuthorDate: Mon Aug 24 22:56:31 2015 -0400
Commit: Chuck Atkins 
CommitDate: Mon Sep 14 11:53:19 2015 -0400

try_compile: Propogate CMP0065 to the generated project.

Set policy CMP0065 to the value used in the calling project.

Set the the value of CMAKE_ENABLE_EXPORTS if set in the calling
project to initialize the target property appropriately.

diff --git a/Help/command/try_compile.rst b/Help/command/try_compile.rst
index 1ed24df..28dae80 100644
--- a/Help/command/try_compile.rst
+++ b/Help/command/try_compile.rst
@@ -100,6 +100,7 @@ If set, the following variables are passed in to the 
generated
 try_compile CMakeLists.txt to initialize compile target properties with
 default values:
 
+* :variable:`CMAKE_ENABLE_EXPORTS`
 * :variable:`CMAKE_LINK_SEARCH_START_STATIC`
 * :variable:`CMAKE_LINK_SEARCH_END_STATIC`
 * :variable:`CMAKE_POSITION_INDEPENDENT_CODE`
@@ -107,5 +108,7 @@ default values:
 If :policy:`CMP0056` is set to ``NEW``, then
 :variable:`CMAKE_EXE_LINKER_FLAGS` is passed in as well.
 
+The current setting of :policy:`CMP0065` is set in the generated project.
+
 Set the :variable:`CMAKE_TRY_COMPILE_CONFIGURATION` variable to choose
 a build configuration.
diff --git a/Source/cmCoreTryCompile.cxx b/Source/cmCoreTryCompile.cxx
index 9411555..e489ad2 100644
--- a/Source/cmCoreTryCompile.cxx
+++ b/Source/cmCoreTryCompile.cxx
@@ -481,6 +481,16 @@ int 
cmCoreTryCompile::TryCompileCode(std::vector const& argv)
   fprintf(fout, "set(CMAKE_LINK_SEARCH_END_STATIC \"%s\")\n", lssDef);
   }
 
+/* Set the appropriate policy information for ENABLE_EXPORTS */
+fprintf(fout, "cmake_policy(SET CMP0065 %s)\n",
+   this->Makefile->GetPolicyStatus(cmPolicies::CMP0065) ==
+ cmPolicies::NEW ? "NEW" : "OLD");
+if(const char *ee = this->Makefile->GetDefinition(
+"CMAKE_ENABLE_EXPORTS"))
+  {
+  fprintf(fout, "set(CMAKE_ENABLE_EXPORTS %s)\n", ee);
+  }
+
 /* Put the executable at a known location (for COPY_FILE).  */
 fprintf(fout, "set(CMAKE_RUNTIME_OUTPUT_DIRECTORY \"%s\")\n",
 this->BinaryDirectory.c_str());

http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ffbe3728a00d941115ac59c3cd3778a35eb03053
commit ffbe3728a00d941115ac59c3cd3778a35eb03053
Author: Chuck Atkins 
AuthorDate: Mon Aug 24 14:33:31 2015 -0400
Commit: Chuck Atkins 
CommitDate: Mon Sep 14 11:53:12 2015 -0400

CMP0065: Restrict the use of CMAKE_SHARED_LIBRARY_LINK__FLAGS

This new policy restricts the addition of the shared library link flags
to executables only when the ENABLE_EXPORTS property is set to True.

diff --git a/Help/manual/cmake-policies.7.rst b/Help/manual/cmake-policies.7.rst
index 590f10d..ae5354f 100644
--- a/Help/manual/cmake-policies.7.rst
+++ b/Help/manual/cmake-policies.7.rst
@@ -122,3 +122,4 @@ All Policies
/policy/CMP0062
/policy/CMP0063
/policy/CMP0064
+   /policy/CMP0065
diff --git a/Help/manual/cmake-variables.7.rst 
b/Help/manual/cmake-variables.7.rst
index e0dbdeb..1fa117f 100644
--- a/Help/manual/cmake-variables.7.rst
+++ b/Help/manual/cmake-variables.7.rst
@@ -245,6 +245,7 @@ Variables that Control the Build
/variable/CMAKE_COMPILE_PDB_OUTPUT_DIRECTORY_CONFIG
/variable/CMAKE_CONFIG_POSTFIX
/variable/CMAKE_DEBUG_POSTFIX
+   /variable/CMAKE_ENABLE_EXPORTS
/variable/CMAKE_EXE_LINKER_FLAGS_CONFIG
/variable/CMAKE_EXE_LINKER_FLAGS
/variable/CMAKE_Fortran_FORMAT
diff --git 

Re: [cmake-developers] [PATCH] Features: Only enable C11 support on GCC >= 4.9.

[Stephen Kelly]

Raphael Kubo da Costa wrote:

> Adjust the GCC feature detection code to only consider C11 support to
> exist on GCC >= 4.9.

If you do that you must remove the definition of 
CMAKE_CXX11_STANDARD_COMPILE_OPTION for GNU < 4.8.1 too.

IOW, this patch is not correct, and should not be merged.

According to

 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203066

sys/cdefs.h requires that if you use -std=c11, your compiler must have the 
c_thread_local feature. Therefore, you must not use -std=c11 with GNU < 4.9.

So, because of the apparent requirement of the FreeBSD header, if you build 
cmake with GNU < 4.9, you must configure it with CMake_NO_C_STANDARD=TRUE.

Of course, the actual bug is in sys/cdefs.h as comment #2 in 

 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203066

describes.

The __STDC_VERSION__ macro on its own (just like the __cplusplus macro on 
its own) is not suitable for feature testing. You must check the compiler 
vendor and version (or use SD-6 for C++).

Comment #3 in 

 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203066

seems strange to me, as it assumes that changing Ports packages is 
sufficient to solving the problem. Should third parties be able to build 
their code on FreeBSD? If so, then a compiler vendor and version check in 
sys/cdefs.h is the right thing to do, and I recommend getting that done.

So, in summary, there is no bug in CMake, but either your package needs to 
change (to add CMake_NO_C_STANDARD=TRUE), or sys/cdefs.h needs to change, or 
both.

Thanks,

Steve.


-- 

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] Listing all targets

[Brad King]

On 09/14/2015 11:46 AM, David Cole wrote:
> (1) I see how I can easily move "COMPONENTS" from
> cmGetCMakePropertyCommand::InitialPass to cmState::GetGlobalProperty
> because I can access the global generator from cmState as well...

Yes.

> move "VARIABLES" and "MACROS," though, I need access to the correct
> cmMakefile in which the cmGetCMakePropertyCommand is running.

Those are actually directory properties and should never have been
available through get_cmake_property().  They should already be
available through get_property() in the DIRECTORY scope.  Please
instead deprecate them with a warning.

> (2) I will update the documentation of get_cmake_property to say these
> are all also available via get_property(GLOBAL ...

The command docs already say something along those lines but the wording
could be made more consistent with get_property's GLOBAL scope.

> All calls to get_cmake_property should have exactly the
> same content as a corresponding call to get_property(GLOBAL?

The behavior for unset properties differs.

> (3) Is anyone concerned about adding a global property with the
> somewhat generic name "TARGETS" ? Do we care if any projects out there
> are already doing a set_property(GLOBAL with the name "TARGETS"?

We could call it CMAKE_ALL_TARGETS.  Other name ideas, anyone?

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] Allow ALIAS of IMPORTED targets

[Stephen Kelly]

Michael Scott wrote:

> Hi,
> 
> I'm planning on having a look at the CMake issue "Allow ALIAS of
> IMPORTED targets", 0015569. After reading the thread between yourself
> and Marc, I wanted to ask a couple of things before I start going
> further with it.

Thanks for working on this.

> The proposed change would be for the add_library and add_executable
> commands only right?

Yes, I guess so.

> Having a quick look at the code for those two commands, they
> specifically check for a combination of ALIAS and IMPORTED and don't
> allow it. I'm guessing that the required changes to allow both
> simultaneously wouldn't be to just remove this check, there would be
> other areas to modify as well right?

Perhaps. Finding that out is the real task :). I don't have all the answers 
to it. The specific disallowing of ALIAS and IMPORTED together by issuing an 
error was a way to defer finding those answers while not being required to 
maintain compatibility with a particular behavior. I didn't want finding 
those answers to delay getting the ALIAS feature in, because it was useful 
already as it was.

Now, we have time to consider all of the implications of allowing this as 
part of the design.

For example, if an ALIAS can be IMPORTED, does it makes sense that it can be 
exported with export() and install(EXPORT)?

If we have 

 add_library(CoreStatic ${Core_SRCS})
 add_library(MyNS::Core ALIAS CoreStatic)

and I export both of them with the NAMESPACE 'MyNS::', do I end up with 

 MyNS::MyNS::Core 

?

Or would the exporting code strip of everything before a '::' in the alias 
name?

Or should exporting ALIAS targets still be disallowed?

The two use cases described in 
 
 http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/52452

seem like they would not benefit from exporting ALIAS targets.

A reasonable way forward might be:

* Keep the restriction that ALIAS targets may not be exported.
* Remove the code disallowing ALIAS IMPORTED targets.
* Remove the unit test proving it is not allowed
* Add new unit tests that it basically works
* Add a unit test for using an ALIAS with try_compile(LINK_LIBRARIES)
* (Anything else that comes up along the way)

Thanks,

Steve.


-- 

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-commits] CMake branch, next, updated. v3.3.1-2931-g664a9b0

[Domen Vrankar]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  664a9b09edd414a6be33eaa5b7d5e7536c47cd5c (commit)
   via  76c59007dd3944e23848b7d5912a59a7d3db6398 (commit)
   via  68dba7f7198557833a7b1339254b00a1f6f4ec75 (commit)
  from  9f5b349e0a8f423eee9852b9c44408c6c1f9395d (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=664a9b09edd414a6be33eaa5b7d5e7536c47cd5c
commit 664a9b09edd414a6be33eaa5b7d5e7536c47cd5c
Merge: 9f5b349 76c5900
Author: Domen Vrankar 
AuthorDate: Mon Sep 14 16:55:05 2015 -0400
Commit: CMake Topic Stage 
CommitDate: Mon Sep 14 16:55:05 2015 -0400

Merge topic 'cpack-deb-fakeroot-removal' into next

76c59007 CPack/DEB: test preserve extra config file permissions
68dba7f7 fixup! CPackDeb: use of libarchive and removal of fakeroot


http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=76c59007dd3944e23848b7d5912a59a7d3db6398
commit 76c59007dd3944e23848b7d5912a59a7d3db6398
Author: Domen Vrankar 
AuthorDate: Mon Sep 14 22:44:00 2015 +0200
Commit: Domen Vrankar 
CommitDate: Mon Sep 14 22:44:00 2015 +0200

CPack/DEB: test preserve extra config file permissions

diff --git a/Tests/RunCMake/CPack/DEB/DEB_EXTRA-VerifyResult.cmake 
b/Tests/RunCMake/CPack/DEB/DEB_EXTRA-VerifyResult.cmake
index 78b6114..5f929ff 100644
--- a/Tests/RunCMake/CPack/DEB/DEB_EXTRA-VerifyResult.cmake
+++ b/Tests/RunCMake/CPack/DEB/DEB_EXTRA-VerifyResult.cmake
@@ -1,11 +1,17 @@
 set(foo_preinst "^echo default_preinst$")
+set(foo_preinst_permissions_regex "-rwxr-xr-x .*")
 set(foo_prerm "^echo default_prerm$")
+set(foo_prerm_permissions_regex "-rwxr-xr-x .*")
 verifyDebControl("${FOUND_FILE_1}" "foo" "preinst;prerm")
 
 set(bar_preinst "^echo bar_preinst$")
+set(bar_prerm_permissions_regex "-rwx-- .*")
 set(bar_prerm "^echo bar_prerm$")
+set(bar_prerm_permissions_regex "-rwx-- .*")
 verifyDebControl("${FOUND_FILE_2}" "bar" "preinst;prerm")
 
 set(bas_preinst "^echo default_preinst$")
+set(bas_prerm_permissions_regex "-rwxr-xr-x .*")
 set(bas_prerm "^echo default_prerm$")
+set(bas_prerm_permissions_regex "-rwxr-xr-x .*")
 verifyDebControl("${FOUND_FILE_3}" "bas" "preinst;prerm")
diff --git a/Tests/RunCMake/CPack/DEB/Helpers.cmake 
b/Tests/RunCMake/CPack/DEB/Helpers.cmake
index b6f113b..f490130 100644
--- a/Tests/RunCMake/CPack/DEB/Helpers.cmake
+++ b/Tests/RunCMake/CPack/DEB/Helpers.cmake
@@ -24,6 +24,19 @@ function(verifyDebControl FILE PREFIX VERIFY_FILES)
   message(FATAL_ERROR "Unexpected content in for '${PREFIX}_${FILE_}'!"
   " Content: '${content_}'")
 endif()
+
+execute_process(COMMAND ls -l 
"${CMAKE_CURRENT_BINARY_DIR}/control_${PREFIX}/${FILE_}"
+  OUTPUT_VARIABLE package_permissions_
+  ERROR_VARIABLE package_permissions_error_
+  OUTPUT_STRIP_TRAILING_WHITESPACE)
+
+if(NOT package_permissions_error_)
+  if(NOT package_permissions_ MATCHES 
"${${PREFIX}_${FILE_}_permissions_regex}")
+message(FATAL_ERROR "Unexpected file permissions for 
${PREFIX}_${FILE_}: '${package_permissions_}'!")
+  endif()
+else()
+  message(FATAL_ERROR "Listing file permissions failed 
(${package_permissions_error_})!")
+endif()
   endforeach()
 endfunction()
 
diff --git a/Tests/RunCMake/CPack/DEB_EXTRA.cmake 
b/Tests/RunCMake/CPack/DEB_EXTRA.cmake
index 46d848d..3c291d5 100644
--- a/Tests/RunCMake/CPack/DEB_EXTRA.cmake
+++ b/Tests/RunCMake/CPack/DEB_EXTRA.cmake
@@ -2,14 +2,32 @@ install(FILES CMakeLists.txt DESTINATION foo COMPONENT foo)
 install(FILES CMakeLists.txt DESTINATION bar COMPONENT bar)
 install(FILES CMakeLists.txt DESTINATION bas COMPONENT bas)
 
-file(WRITE ${CMAKE_CURRENT_BINARY_DIR}/preinst "echo default_preinst")
-file(WRITE ${CMAKE_CURRENT_BINARY_DIR}/prerm "echo default_prerm")
+file(WRITE ${CMAKE_CURRENT_BINARY_DIR}/tmp/preinst "echo default_preinst")
+file(WRITE ${CMAKE_CURRENT_BINARY_DIR}/tmp/prerm "echo default_prerm")
+
+foreach(file_ preinst prerm)
+  file(COPY ${CMAKE_CURRENT_BINARY_DIR}/tmp/${file_}
+DESTINATION ${CMAKE_CURRENT_BINARY_DIR}
+FILE_PERMISSIONS
+  OWNER_READ OWNER_WRITE OWNER_EXECUTE
+  GROUP_READ GROUP_EXECUTE
+  WORLD_READ WORLD_EXECUTE)
+endforeach()
 
 set(CPACK_DEBIAN_PACKAGE_CONTROL_EXTRA
-"${CMAKE_CURRENT_BINARY_DIR}/preinst;${CMAKE_CURRENT_BINARY_DIR}/prerm")
+
"${CMAKE_CURRENT_BINARY_DIR}/preinst;${CMAKE_CURRENT_BINARY_DIR}/prerm;${CMAKE_CURRENT_BINARY_DIR}/conffiles")
+
+file(WRITE ${CMAKE_CURRENT_BINARY_DIR}/bar_tmp/preinst "echo bar_preinst")

Re: [cmake-developers] [CPackDeb][libarchive] removing use of fakeroot and supporting UID/GID/UNAME etc in libarchive

[Raffi Enficiaud]

Le 14/09/15 23:34, Domen Vrankar a écrit :

Thank you. However those two test are not mutually exclusive. I think having
them on lintian is also a good thing.


I've tried your test change before but lintian test complained that
775 are invalid permissions (should be 755). Is this caused by a
different version of lintian or should I just modify your test to use
755 permissions and apply that?



That's very good that it fails :)

I tested on Ubuntu 14.04, maybe Debian distributions are even more 
strict. Apparently the files that "file(WRITE ...)" created on your 
system are with 775. I believe the problem lies in the "file(" commands 
rather than on a different version of lintian.


OTOH, I can see from this:

https://lintian.debian.org/tags/control-file-has-bad-permissions.html

that all files should have at least a permission mask set to ~S_IWGRP & 
~S_IWOTH (with "control_tar.SetPermissionsMask(~S_IWGRP & ~S_IWOTH)"), 
so that the executable bit is left unchanged and the write bit is 
cleared for group and others (755 and 644).


What do you think?

Raffi



--

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] [CPackDeb][libarchive] removing use of fakeroot and supporting UID/GID/UNAME etc in libarchive

[Raffi Enficiaud]

Hi Domen,

Thank you. However those two test are not mutually exclusive. I think 
having them on lintian is also a good thing.


Best and thanks,
Raffi

Le 14/09/15 23:19, Domen Vrankar a écrit :

I just realized that the permissions for the extra control files should
be set in a different way than for the md5sum checksum file.

Please find attached the patch correcting this and the corresponding
test that fires the problem.


Thanks, applied the fix:
http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=68dba7f

I've extended RunCMake.CPack_DEB DEB_EXTRA test instead of using your
test as I am trying to put new tests there.

Thanks,
Domen




--

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] [CPackDeb][libarchive] removing use of fakeroot and supporting UID/GID/UNAME etc in libarchive

[Domen Vrankar]

>> I just realized that the permissions for the extra control files should
>> be set in a different way than for the md5sum checksum file.
>>
>> Please find attached the patch correcting this and the corresponding
>> test that fires the problem.

Thanks, applied the fix:
http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=68dba7f

I've extended RunCMake.CPack_DEB DEB_EXTRA test instead of using your
test as I am trying to put new tests there.

Thanks,
Domen
-- 

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] Need help with COMPILE_DEFINITIONS_

[Pau Garcia i Quiles]

Hello,

Have you tried

set_property(TARGET ${PrjName0} PROPERTY COMPILE_DEFINITIONS_DEBUG -DATEST)

?



On Mon, Sep 14, 2015 at 9:35 PM, Carl Poirier 
wrote:

> Hi folks,
>
> I need some help setting the COMPILE_DEFINITIONS_. I'm using the
> Visual Studio 2008 generator. I use this command to do so which I took in
> the notes  when the feature
> was added:
>
> set_property(TARGET ${PrjName0} PROPERTY COMPILE_DEFINITIONS_DEBUG ATEST)
>
> Then, once the solution and project is generated, I go into the project
> properties under the C++ preprocessor and I can't see the define. Removing
> the configuration name does set it correctly for all of them, so it leads
> me to believe the rest of my CMakeLists.txt is fine:
>
> set_property(TARGET ${PrjName0} PROPERTY COMPILE_DEFINITIONS ATEST)
>
> So is this supposed to work?
>
> Thank you,
>
> Carl
>
> --
>
> 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
>



-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
-- 

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

Re: [cmake-developers] [CPackDeb][libarchive] removing use of fakeroot and supporting UID/GID/UNAME etc in libarchive

[Domen Vrankar]

> Thank you. However those two test are not mutually exclusive. I think having
> them on lintian is also a good thing.

I've tried your test change before but lintian test complained that
775 are invalid permissions (should be 755). Is this caused by a
different version of lintian or should I just modify your test to use
755 permissions and apply that?

Regards,
Domen
-- 

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] Allow ALIAS of IMPORTED targets

[Tamás Kenéz]

> For example, if an ALIAS can be IMPORTED, does it makes sense that it can
be
> exported with export() and install(EXPORT)?

Yes: couple of months ago I was adding install(EXPORT) to an existing
CMakeList. The name of the library target which I had to export was not
correct as export target name but I was not able change the library target
name because of backward compatibility. Being able to export an alias would
have helped.

> and I export both of them with the NAMESPACE 'MyNS::', do I end up with
> MyNS::MyNS::Core

I guess so, at least that's what I would expect. As far as I know the
install(EXPORT) blindly preprends the target name with the namespace string.

Tamas

On Mon, Sep 14, 2015 at 7:34 PM, Stephen Kelly  wrote:

> Michael Scott wrote:
>
> > Hi,
> >
> > I'm planning on having a look at the CMake issue "Allow ALIAS of
> > IMPORTED targets", 0015569. After reading the thread between yourself
> > and Marc, I wanted to ask a couple of things before I start going
> > further with it.
>
> Thanks for working on this.
>
> > The proposed change would be for the add_library and add_executable
> > commands only right?
>
> Yes, I guess so.
>
> > Having a quick look at the code for those two commands, they
> > specifically check for a combination of ALIAS and IMPORTED and don't
> > allow it. I'm guessing that the required changes to allow both
> > simultaneously wouldn't be to just remove this check, there would be
> > other areas to modify as well right?
>
> Perhaps. Finding that out is the real task :). I don't have all the answers
> to it. The specific disallowing of ALIAS and IMPORTED together by issuing
> an
> error was a way to defer finding those answers while not being required to
> maintain compatibility with a particular behavior. I didn't want finding
> those answers to delay getting the ALIAS feature in, because it was useful
> already as it was.
>
> Now, we have time to consider all of the implications of allowing this as
> part of the design.
>
> For example, if an ALIAS can be IMPORTED, does it makes sense that it can
> be
> exported with export() and install(EXPORT)?
>
> If we have
>
>  add_library(CoreStatic ${Core_SRCS})
>  add_library(MyNS::Core ALIAS CoreStatic)
>
> and I export both of them with the NAMESPACE 'MyNS::', do I end up with
>
>  MyNS::MyNS::Core
>
> ?
>
> Or would the exporting code strip of everything before a '::' in the alias
> name?
>
> Or should exporting ALIAS targets still be disallowed?
>
> The two use cases described in
>
>  http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/52452
>
> seem like they would not benefit from exporting ALIAS targets.
>
> A reasonable way forward might be:
>
> * Keep the restriction that ALIAS targets may not be exported.
> * Remove the code disallowing ALIAS IMPORTED targets.
> * Remove the unit test proving it is not allowed
> * Add new unit tests that it basically works
> * Add a unit test for using an ALIAS with try_compile(LINK_LIBRARIES)
> * (Anything else that comes up along the way)
>
> Thanks,
>
> Steve.
>
>
> --
>
> 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
>
-- 

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-commits] CMake branch, next, updated. v3.3.1-2928-g9f5b349

[Brad King]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  9f5b349e0a8f423eee9852b9c44408c6c1f9395d (commit)
   via  050a14f4a7117936b54b4205a5fba70d88cb266a (commit)
  from  4653dc36efc23e6a35449521a7d7a7688b0ab288 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9f5b349e0a8f423eee9852b9c44408c6c1f9395d
commit 9f5b349e0a8f423eee9852b9c44408c6c1f9395d
Merge: 4653dc3 050a14f
Author: Brad King 
AuthorDate: Mon Sep 14 16:20:43 2015 -0400
Commit: Brad King 
CommitDate: Mon Sep 14 16:20:43 2015 -0400

Merge branch 'master' into next


---

Summary of changes:


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

Re: [CMake] Need help with COMPILE_DEFINITIONS_

[Hendrik Sattler]

Am 14. September 2015 22:25:00 MESZ, schrieb Pau Garcia i Quiles 
:
>Hello,
>
>Have you tried
>
>set_property(TARGET ${PrjName0} PROPERTY COMPILE_DEFINITIONS_DEBUG
>-DATEST)

That would be the right thing for add_definitions() but not here.
He could try with generator expressions though.

>
>On Mon, Sep 14, 2015 at 9:35 PM, Carl Poirier
>
>wrote:
>
>> Hi folks,
>>
>> I need some help setting the COMPILE_DEFINITIONS_. I'm using
>the
>> Visual Studio 2008 generator. I use this command to do so which I
>took in
>> the notes  when the
>feature
>> was added:
>>
>> set_property(TARGET ${PrjName0} PROPERTY COMPILE_DEFINITIONS_DEBUG
>ATEST)
>>
>> Then, once the solution and project is generated, I go into the
>project
>> properties under the C++ preprocessor and I can't see the define.
>Removing
>> the configuration name does set it correctly for all of them, so it
>leads
>> me to believe the rest of my CMakeLists.txt is fine:
>>
>> set_property(TARGET ${PrjName0} PROPERTY COMPILE_DEFINITIONS ATEST)
>>
>> So is this supposed to work?
>>
>> Thank you,
>>
>> Carl
>>
>> --
>>
>> 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
>>

-- 

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

Re: [cmake-developers] CMake user-provided manifest files

[Brad King]

On 09/11/2015 03:02 PM, Brad King wrote:
> On 09/11/2015 02:09 PM, Brad King wrote:
>> I would be very happy to get rid of the vs_link_exe and vs_link_dll code.
> 
> There is documentation here about what those are doing:
> 
>  https://msdn.microsoft.com/en-us/library/ms235591.aspx
>  http://blogs.msdn.com/b/zakramer/archive/2006/05/22/603558.aspx

I just looked back through the implementations of vs_link_{exe,dll}
in more detail.  For non-incremental linking it just does:

 link ... /manifest /out:Foo.exe ...
 mt -manifest Foo.exe.manifest -outputresource:Foo.exe;1

For incremental linking it does:

 (create empty "embed.manifest" and Foo.rc referencing it)
 rc Foo.rc -foFoo.res
 link ... /manifest /manifestfile:tmp.manifest Foo.res
 mt -manifest tmp.manifest -out:embed.manifest
 (if "embed.manifest" changed):
   rc Foo.rc -foFoo.res
   link ... /manifest /manifestfile:tmp.manifest Foo.res

The latter/conditional "rc" and "link" invocations are identical
to the first invocations of these tools.

In both cases the link tool generates the manifest file and then
some steps are taken to embed it in the binary.  In both cases
there is a "mt" invocation that could be extended to list
user-provided manifest files after the linker-generated one.

On 09/11/2015 11:45 AM, James Johnston wrote:
> Because CMake already does *some* things with the linker it makes it
> impossible for me to cleanly specify and use link.exe manifest-related
> switches myself.  For example, it hard-codes usage of link.exe /MANIFESTFILE
> and the user can't specify their own location.  And the locations it does
> use are undocumented.

Is there a use case for doing something with the linker-generated
manifest file other than passing it to a "mt" invocation along
with (possibly) user-specified manifest files?  If not then there
is no reason to make the manifest file location public.

I think our path forward here is to teach the Makefile and Ninja
generators how to add user-specified manifest files to the "mt"
invocations as outlined above.  Gilles has already posted an
implementation for doing this on VS 10+.

-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] FindPythonLibs patches for version searching and frameworks

[David Gobbi]

Hi All,

I've attached three suggested patches for cmake.

The first is trivial, it simply adds Python 3.5 and 3.6 to the search list.

The second removes the long-deprecated PYTHON_INCLUDE_PATH as a suggestion
for PYTHON_INCLUDE_DIR.

The third does two important things: 1) it fixes bugs for searching for
specific versions of the libs and headers for framework installs of Python
on OS X, and 2) it doesn't search for the include directory until after
library has been found, so that it can use the library version to direct
the search for the include directory.

Any comments on these patches would be appreciated.

Cheers,
 - David


0001-Add-Python-3.6-3.5-to-the-versions-searched-for.patch
Description: Binary data


0002-Remove-PYTHON_INCLUDE_PATH-as-input-to-FindPythonLib.patch
Description: Binary data


0003-Match-python-include-dir-to-library-version.patch
Description: Binary data
-- 

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

[Cmake-commits] CMake branch, master, updated. v3.3.1-1169-g075de28

[Kitware Robot]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  075de28b3606211d48fc428c7af3be8ade3e6cfa (commit)
  from  050a14f4a7117936b54b4205a5fba70d88cb266a (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=075de28b3606211d48fc428c7af3be8ade3e6cfa
commit 075de28b3606211d48fc428c7af3be8ade3e6cfa
Author: Kitware Robot <kwro...@kitware.com>
AuthorDate: Tue Sep 15 00:01:04 2015 -0400
Commit: Kitware Robot <kwro...@kitware.com>
CommitDate: Tue Sep 15 00:01:04 2015 -0400

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index b122777..087db9e 100644
--- a/Source/CMakeVersion.cmake
+++ b/Source/CMakeVersion.cmake
@@ -1,5 +1,5 @@
 # CMake version number components.
 set(CMake_VERSION_MAJOR 3)
 set(CMake_VERSION_MINOR 3)
-set(CMake_VERSION_PATCH 20150914)
+set(CMake_VERSION_PATCH 20150915)
 #set(CMake_VERSION_RC 1)

---

Summary of changes:
 Source/CMakeVersion.cmake |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

Re: [CMake] fixup_bundles on macosx for non-.app target

[Michael Jackson]

Sorry for the delay. 
  https://github.com/dream3d/DREAM3D/tree/develop/Support/cmp/OSX_Tools

the CompleteTool.cmake.in calls the CompleteTool.sh.in files through a custom 
cmake command after they are "Configured" through "configure_file". I think you 
can figure out what is going on. There may be some issues with the shell script 
regarding temp file cleanup but it generally works. We build and package every 
night on our build systems.

Mike Jackson

On Sep 12, 2015, at 11:07 PM, Seth Cantrell  wrote:

> Please, I would like to see that script template. I'm also looking at the 
> source for BundleUtilities. It seems like it shouldn't be difficult to make a 
> module that provides the generic functionality  across platforms.
> 
>> On Sep 12, 2015, at 9:09 PM, Michael Jackson  
>> wrote:
>> 
>> I have a mix of .app and command line executables for our project on OS X. I 
>> wrote a templated .sh file that cmake uses to “configure_file()” by filling 
>> in details needed. The Script itself does the “fix up” stuff by running 
>> otool, parsing the output, looking for the libraries and then updating 
>> everything. You are welcome to the script if you find it useful.
>> 
>> Mike Jackson
>> 
>>> On Sep 12, 2015, at 7:54 PM, Seth Cantrell  wrote:
>>> 
 
 On Sep 12, 2015, at 5:28 PM, Dan Kegel  wrote:
 
 On Sat, Sep 12, 2015 at 1:52 PM, Seth Cantrell  
 wrote:
> I have a project which uses fixup_bundle on Windows to package up the exe 
> with the third-party dlls it requires. On Mac OS X this same packaging 
> process fails. It looks like on Mac OS X this utility is assuming I want 
> to producing a .app bundle.
 
 Given that a .app bundle is just a directory containing the executable and
 the things it depends on, what's wrong with what fixup_bundle does?
 Do you have a special reason to not want to follow the .app convention?
 - Dan
>>> 
>>> The primary problem is simply that install and CPack processes fail on Mac 
>>> OS X. If I can get the process to succeed, even if that means producing a 
>>> .app directory structure for this non-.app, command line executable that 
>>> would be a fine first step. But ultimately I'd rather not have to fake the 
>>> .app structure either.
>>> 
>>> On Windows installing and packaging succeed. For example on windows I get a 
>>> .zip file named myproj-0.1.1-win64.zip that contains:
>>> 
>>> myproj-0.1.1-win64.zip\
>>> myproj-0.1.1-win64\
>>>  main.exe
>>>  somelib.dll
>>>  someotherlib.dll
>>> 
>>> And of course the _CPack_Packages structure used to generate this is
>>> 
>>> _CPack_Packages\
>>> win64\
>>>  ZIP\
>>>myproj-0.1.1-win64\
>>>  main.exe
>>>  somelib.dll
>>>  someotherlib.dll
>>> 
>>> This is the same structure I'd like to produce on OS X.
>>> 
>>> On Mac OS X the packaging process fails:
>>> 
 [1/1] Run CPack packaging tool...
 CPack: Create package using ZIP
 CPack: Install projects
 CPack: - Install project: scratch
 exe_dotapp_dir/='/Volumes/D/Builds/scratch/_CPack_Packages/Darwin/ZIP/scratch-0.1.1-Darwin/'
 item_substring='/Volumes/D/Builds/scratch/_CPack_Packages/Darwin/ZIP/MacOS/somelib'
 resolved_embedded_item='/Volumes/D/Builds/scratch/_CPack_Packages/Darwin/ZIP/MacOS/somelib.dylib'
 
 Install or copy the item into the bundle before calling fixup_bundle.
 Or maybe there's a typo or incorrect path in one of the args to 
 fixup_bundle?
 
 CMake Error at 
 /Applications/CMake.app/Contents/share/cmake-3.3/Modules/BundleUtilities.cmake:737
  (message):
 cannot fixup an item that is not in the bundle...
 Call Stack (most recent call first):
 /Applications/CMake.app/Contents/share/cmake-3.3/Modules/BundleUtilities.cmake:848
  (fixup_bundle_item)
 /Volumes/D/Builds/scratch/FixBundle.cmake:11 (fixup_bundle)
 /Volumes/D/Builds/scratch/cmake_install.cmake:41 (include)
 
 
 CPack Error: Error when generating package: scratch
 FAILED: cd /Volumes/D/Builds/scratch && 
 /Applications/CMake.app/Contents/bin/cpack --config ./CPackConfig.cmake
 ninja: build stopped: subcommand failed.
>>> 
>>> On Mac OS X after the packaging failure I can see that _CPack_Packages 
>>> contains a directory structure
>>> 
>>> _CPack_Packages\
>>> Darwin\
>>>  ZIP\
>>>MacOS\
>>>  somelib.dylib
>>>  someotherlib.dylib
>>>myproj-0.1.1-Darwin\
>>>  main
>>> 
>>> and the process has stopped before generating the zip file.
>>> 
>>> The initial error is due to the fact that I'm putting the executable in the 
>>> root of the install tree: install(TARGETS main DESTINATION "."). This 
>>> causes fixup_bundle's behavior on Mac OS to put the libraries outside the 
>>> directory that CPack is preparing to zip, causing an error where fixup 
>>> (quite correctly) refuses to work when the 

[Cmake-commits] CMake branch, master, updated. v3.3.1-1168-g050a14f

[Brad King]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  050a14f4a7117936b54b4205a5fba70d88cb266a (commit)
   via  4734df5f79d7101bf425f21065ab5c853bacc388 (commit)
  from  6dad4c25b06ae232c766d76747b080373fb2499d (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=050a14f4a7117936b54b4205a5fba70d88cb266a
commit 050a14f4a7117936b54b4205a5fba70d88cb266a
Merge: 6dad4c2 4734df5
Author: Brad King 
AuthorDate: Mon Sep 14 16:20:28 2015 -0400
Commit: CMake Topic Stage 
CommitDate: Mon Sep 14 16:20:28 2015 -0400

Merge topic 'extend-windows-version-detection'

4734df5f Windows: Set CMAKE_HOST_SYSTEM_VERSION with three components


---

Summary of changes:
 Source/cmGlobalGenerator.cxx |   13 -
 1 file changed, 8 insertions(+), 5 deletions(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

Re: [cmake-developers] Allow ALIAS of IMPORTED targets

[CHEVRIER, Marc]

Hi Michael,

If this feature can be supported for libraries and executables, it will be 
perfect for me.
Thank you.

Marc



On 12/09/15 23:48, "cmake-developers on behalf of Michael Scott" 
 
wrote:

>Hi,
>
>I'm planning on having a look at the CMake issue "Allow ALIAS of 
>IMPORTED targets", 0015569. After reading the thread between yourself 
>and Marc, I wanted to ask a couple of things before I start going 
>further with it.
>
>The proposed change would be for the add_library and add_executable 
>commands only right?
>
>Having a quick look at the code for those two commands, they 
>specifically check for a combination of ALIAS and IMPORTED and don't 
>allow it. I'm guessing that the required changes to allow both 
>simultaneously wouldn't be to just remove this check, there would be 
>other areas to modify as well right?
>
>Cheers,
>Michael
>-- 
>
>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
-- 

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] find_program HINTS no longer preferred over PATH

[CHEVRIER, Marc]

Any news on this subject?
I think it is a critical bug because behaviour is broken. So I cannot rely on 
find_executable anymore to get the expected program!

Marc



On 09/09/15 20:20, "Brad King"  wrote:

>On 09/09/2015 11:50 AM, Chuck Atkins wrote:
>> From what I can tell, the search order is still preserved as expected.
>
>The example Marc attached earlier shows that the problem is when
>ENV{PATH} contains one of the *same* values that is one of the HINTS.
>The fact that a path appears in ENV{PATH} somehow causes it to be
>dropped from the list of HINTS or otherwise ordered after the other
>hints.
>
>-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] Python extension to FindProtobuf

[Andreas Bergmeier]

I now added documentation, removed ARGS and GENERATED property.

-Original Message-
From: Brad King [mailto:brad.k...@kitware.com]
Sent: Freitag, 11. September 2015 20:33
To: Andreas Bergmeier
Cc: Rolf Eike Beer; cmake-developers@cmake.org
Subject: Re: [cmake-developers] Python extension to FindProtobuf

On 09/11/2015 11:11 AM, Andreas Bergmeier wrote:
> Here is the commit.

Thanks.  Please revise the patch to also update the documentation of the module 
to mention the new API.

> +list(APPEND ${SRCS} "${CMAKE_CURRENT_BINARY_DIR}/${FIL_WE}.pb.py")
> +add_custom_command(
> +  OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/${FIL_WE}.pb.py"
> +  COMMAND  ${PROTOBUF_PROTOC_EXECUTABLE}
> +  ARGS --python_out  ${CMAKE_CURRENT_BINARY_DIR}
> + ${_protobuf_include_path} ${ABS_FIL}

The ARGS option can be dropped.  It is silently ignored anyway.
The arguments after it will be collected by COMMAND already.

> +  DEPENDS ${ABS_FIL} ${PROTOBUF_PROTOC_EXECUTABLE}
> +  COMMENT "Running Python protocol buffer compiler on ${FIL}"
> +  VERBATIM )
> +  endforeach()
> +
> +  set_source_files_properties(${${SRCS}} PROPERTIES GENERATED TRUE)

We do not need to explicitly set the GENERATED property.  That convention has 
been outdated for years.  The add_custom_command call automatically sets this 
on the OUTPUT.

Thanks,
-Brad


 Diese E-mail enthält VERTRAULICHE UND PERSÖNLICHE INFORMATIONEN und/oder 
PRIVILEGIERTE UND VERTRAULICHE MITTEILUNGEN, die ausschließlich für die 
angesprochenen Empfänger bestimmt sind. Ohne ausdrückliche schriftliche 
Zustimmung des Absenders dürfen diese Informationen und Mitteilungen nicht an 
irgendeinen Dritten außerhalb der Organisation des Empfängers weitergeleitet 
oder zur Kenntnis gebracht werden. Wenn Sie diese E-mail versehentlich 
empfangen haben, teilen Sie dies bitte dem Absender umgehend telefonisch oder 
durch Rücksendung dieser E-mail mit, und zerstören Sie die Mail sowie Ihre 
evtl. Rückmail bitte anschließend, ohne eine Kopie zu erstellen. Koch Media 
übernimmt keinerlei Verantwortung für mögliche Verluste oder Beschädigungen, 
resultierend aus virus-infizierten E-mails bzw. Viren in Anhängen.

This e-mail may contain CONFIDENTIAL AND PROPRIETARY INFORMATION and/or 
PRIVILEGED AND CONFIDENTIAL COMMUNICATION intended solely for the recipient 
and, therefore, may not be retransmitted to any party outside of the 
recipient's organization without the prior written consent of the sender. If 
you have received this e-mail in error please notify the sender immediately by 
telephone or reply e-mail and destroy the original message without making a 
copy. Koch Media accepts no liability for any losses or damages resulting from 
infected e-mail transmissions and viruses in e-mail attachment.


commit-226ffb3
Description: commit-226ffb3
-- 

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] Listing all targets

[Stephen Kelly]

Brad King wrote:

> On 09/14/2015 11:46 AM, David Cole wrote:
>> (1) I see how I can easily move "COMPONENTS" from
>> cmGetCMakePropertyCommand::InitialPass to cmState::GetGlobalProperty
>> because I can access the global generator from cmState as well...
> 
> Yes.

I assume you're thinking of getting the global generator from the cmake 
instance?

That's not appropriate. The cmState should not know the cmake instance or 
the global generator.  The fact that it currently knows the cmake instance 
is a temporary evil of the cache stuff not being fully refactored yet. 

The install components would need to become 'first-class' parts of cmState, 
in the same way that definitions and properties became first-class (ie, not 
by making cmState aware of cmMakefile!). 

That refactoring can be done if you want to give it a shot and see what's 
needed, but it is a post-3.4 branch. 

Making the target names available through properties via cmState is also 
trivial after targets become first-class parts of cmState (cmState::Target 
like cmState::Directory).

That can happen sooner (it's on my plate), but required refactoring is also 
on hold until after CMake 3.4.

 
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/14286/focus=14323

Thanks,

Steve.


-- 

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] Features: Only enable C11 support on GCC >= 4.9.

[Brad King]

On 09/14/2015 01:53 PM, Raphael Kubo da Costa wrote:
> Especially if you take into account the
> CMAKE_CXX11_STANDARD_COMPILE_OPTION argument, one could argue that this
> is about choosing how strict CMake should be when determining whether a
> compiler implements a standard: enabling C++11 support only with GCC 4.8
> looks limiting and leaves out all the cases where it actually works fine
> with earlier versions. Is this patch too broad for C11 and GCC, or is it
> different from the C++11 case?

The idea of these option tables is for CMake to be able to tell the
compiler to *nominally* enable support for a given language standard.
The extent to which the compiler actually supports it is up to the
project to deal with.  If we waited for 100% support of a language
then many compilers will never get there.

In this case CMake itself cannot build with C11 on this compiler/platform
combination so we should not try to do so.  We already have some checks
here:

 http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=CMakeLists.txt;hb=v3.3.1#l39

to decide whether to try using the latest standard or not.  One could
add a check for the case in question if necessary.

> It sounded like Brad was in favor of the former, whereas you'd like the
> change not to be merged.

Actually I didn't investigate deeply enough before commenting.  The
mailing list is a much better place for such discussion anyway.

-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] Features: Only enable C11 support on GCC >= 4.9.

[Raphael Kubo da Costa]

Stephen Kelly  writes:

> Raphael Kubo da Costa wrote:
>
>> Adjust the GCC feature detection code to only consider C11 support to
>> exist on GCC >= 4.9.
>
> If you do that you must remove the definition of
> CMAKE_CXX11_STANDARD_COMPILE_OPTION for GNU < 4.8.1 too.
[...]
> sys/cdefs.h requires that if you use -std=c11, your compiler must have the
> c_thread_local feature. Therefore, you must not use -std=c11 with GNU < 4.9.
[...]
> Of course, the actual bug is in sys/cdefs.h as comment #2 in
>  https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203066
> describes.

I don't think comment #2 acknowledges there's a bug in cdefs.h; I see it
as more of an acknowledgment that adding an additional check there would
help work around/solve the issue.

> The __STDC_VERSION__ macro on its own (just like the __cplusplus macro on
> its own) is not suitable for feature testing. You must check the compiler
> vendor and version (or use SD-6 for C++).
[...]
> So, in summary, there is no bug in CMake, but either your package needs to
> change (to add CMake_NO_C_STANDARD=TRUE), or sys/cdefs.h needs to change, or
> both.

I see your point, and building with CMake_NO_C_STANDARD=TRUE or
CMAKE_C_STANDARD=99 is definitely an option. I wouldn't count on cdefs.h
being changed, and even if it was it wouldn't solve the issue on
existing systems.

Especially if you take into account the
CMAKE_CXX11_STANDARD_COMPILE_OPTION argument, one could argue that this
is about choosing how strict CMake should be when determining whether a
compiler implements a standard: enabling C++11 support only with GCC 4.8
looks limiting and leaves out all the cases where it actually works fine
with earlier versions. Is this patch too broad for C11 and GCC, or is it
different from the C++11 case? It sounded like Brad was in favor of the
former, whereas you'd like the change not to be merged.

I am fine with just changing the way CMake is packaged on FreeBSD, but
it still leaves it broken with third-party software (even outside
FreeBSD in case they use an older GCC and _Thread_local) like you
mentioned.

-- 

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] find_program HINTS no longer preferred over PATH

[Brad King]

On 09/14/2015 02:00 PM, Alan W. Irwin wrote:
> Because this find regression is against 3.1.3 from what Marc said, may
> I assume you are planning to include the fix for this regression in
> both future cmake-3.2.x and 3.3.y releases?

We may backport it for a possible 3.3.2 but there will be no further
upstream 3.2.x releases.

-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] Features: Only enable C11 support on GCC >= 4.9.

[Raphael Kubo da Costa]

Brad King  writes:

> In this case CMake itself cannot build with C11 on this compiler/platform
> combination so we should not try to do so.  We already have some checks
> here:
>
>  http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=CMakeLists.txt;hb=v3.3.1#l39
>
> to decide whether to try using the latest standard or not.  One could
> add a check for the case in question if necessary.

Do you mean checking for FreeBSD and compiler version? I thought it'd be
too specific for upstream and was just going to make it be built with a
different standard (or no standard) on FreeBSD itself.

-- 

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-commits] CMake branch, next, updated. v3.3.1-2919-gef34192

[Brad King]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  ef34192b04d49f21d39ecb9ceebfd5d95ec35bc2 (commit)
   via  1b87abf73a6a1ac97cfc79f92baba28ee536e489 (commit)
  from  37278dc705eb7cdb395a0d7b970cc4d82d2bf118 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ef34192b04d49f21d39ecb9ceebfd5d95ec35bc2
commit ef34192b04d49f21d39ecb9ceebfd5d95ec35bc2
Merge: 37278dc 1b87abf
Author: Brad King 
AuthorDate: Mon Sep 14 14:41:20 2015 -0400
Commit: CMake Topic Stage 
CommitDate: Mon Sep 14 14:41:20 2015 -0400

Merge topic 'fix-bad-search-ordering' into next

1b87abf7 fixup! find_*: Fix search order when the environment duplicates 
some HINTS


http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1b87abf73a6a1ac97cfc79f92baba28ee536e489
commit 1b87abf73a6a1ac97cfc79f92baba28ee536e489
Author: Brad King 
AuthorDate: Mon Sep 14 14:40:46 2015 -0400
Commit: Brad King 
CommitDate: Mon Sep 14 14:40:49 2015 -0400

fixup! find_*: Fix search order when the environment duplicates some HINTS

Add a test case.

diff --git a/Tests/RunCMake/find_program/A/test 
b/Tests/RunCMake/find_program/A/test
new file mode 100755
index 000..1a24852
--- /dev/null
+++ b/Tests/RunCMake/find_program/A/test
@@ -0,0 +1 @@
+#!/bin/sh
diff --git a/Tests/RunCMake/find_program/B/test 
b/Tests/RunCMake/find_program/B/test
new file mode 100755
index 000..1a24852
--- /dev/null
+++ b/Tests/RunCMake/find_program/B/test
@@ -0,0 +1 @@
+#!/bin/sh
diff --git a/Tests/RunCMake/find_program/EnvAndHints-stdout.txt 
b/Tests/RunCMake/find_program/EnvAndHints-stdout.txt
new file mode 100644
index 000..113263e
--- /dev/null
+++ b/Tests/RunCMake/find_program/EnvAndHints-stdout.txt
@@ -0,0 +1 @@
+-- PROG='[^']*/Tests/RunCMake/find_program/A/test'
diff --git a/Tests/RunCMake/find_program/EnvAndHints.cmake 
b/Tests/RunCMake/find_program/EnvAndHints.cmake
new file mode 100644
index 000..3e30157
--- /dev/null
+++ b/Tests/RunCMake/find_program/EnvAndHints.cmake
@@ -0,0 +1,6 @@
+set(ENV{PATH} ${CMAKE_CURRENT_SOURCE_DIR}/A)
+find_program(PROG
+  NAMES test
+  HINTS ${CMAKE_CURRENT_SOURCE_DIR}/A ${CMAKE_CURRENT_SOURCE_DIR}/B
+  )
+message(STATUS "PROG='${PROG}'")
diff --git a/Tests/RunCMake/find_program/RunCMakeTest.cmake 
b/Tests/RunCMake/find_program/RunCMakeTest.cmake
index 2adec11..89307c1 100644
--- a/Tests/RunCMake/find_program/RunCMakeTest.cmake
+++ b/Tests/RunCMake/find_program/RunCMakeTest.cmake
@@ -1,5 +1,6 @@
 include(RunCMake)
 
+run_cmake(EnvAndHints)
 run_cmake(DirsPerName)
 run_cmake(NamesPerDir)
 

---

Summary of changes:
 Tests/RunCMake/find_program/A/{testA => test}  |0
 Tests/RunCMake/find_program/{A/testA => B/test}|0
 Tests/RunCMake/find_program/EnvAndHints-stdout.txt |1 +
 Tests/RunCMake/find_program/EnvAndHints.cmake  |6 ++
 Tests/RunCMake/find_program/RunCMakeTest.cmake |1 +
 5 files changed, 8 insertions(+)
 copy Tests/RunCMake/find_program/A/{testA => test} (100%)
 copy Tests/RunCMake/find_program/{A/testA => B/test} (100%)
 create mode 100644 Tests/RunCMake/find_program/EnvAndHints-stdout.txt
 create mode 100644 Tests/RunCMake/find_program/EnvAndHints.cmake


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

Re: [cmake-developers] find_program HINTS no longer preferred over PATH

[Alan W. Irwin]

On 2015-09-14 10:51-0400 Brad King wrote:


On 09/14/2015 03:05 AM, CHEVRIER, Marc wrote:

Any news on this subject?


Chuck has had a fix in 'next' for a few days:

find_*: Fix search order when the environment duplicates some HINTS
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ec8e5fb3

but the topic is still missing a test case.


Hi Brad:

My judgement is this is a fairly important find regression that is
likely to affect most users (like me) who are trying to find some package that
is in a non-system location when the same package exists in the
standard system location.  Therefore, my thanks to Marc for
discovering and documenting this issue, and my thanks to Chuck for
coming up with a fix for the issue.

Because this find regression is against 3.1.3 from what Marc said, may
I assume you are planning to include the fix for this regression in
both future cmake-3.2.x and 3.3.y releases?

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__
--

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] Features: Only enable C11 support on GCC >= 4.9.

[Brad King]

On 09/14/2015 02:29 PM, Raphael Kubo da Costa wrote:
> Do you mean checking for FreeBSD and compiler version? I thought it'd be
> too specific for upstream and was just going to make it be built with a
> different standard (or no standard) on FreeBSD itself.

I meant to add a try_compile check with

  CMAKE_FLAGS -DCMAKE_C_STANDARD=11

using a source file that exercises the problematic code in question.
See similar checks here:

 
http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Source/Checks/cm_cxx14_cstdio.cmake;hb=v3.3.1
 
http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Source/Checks/cm_cxx11_unordered_map.cmake;hb=v3.3.1

that check if using certain CMAKE_CXX_STANDARD values works for some
cases CMake hits with broken C++11 and C++14 platform/compiler combos.

This will help CMake build out of the box on FreeBSD with GCC 4.7
without manually adding -DCMake_NO_C_STANDARD=TRUE.

-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] Need help with COMPILE_DEFINITIONS_

[Carl Poirier]

Hi folks,

I need some help setting the COMPILE_DEFINITIONS_. I'm using the
Visual Studio 2008 generator. I use this command to do so which I took in
the notes  when the feature was
added:

set_property(TARGET ${PrjName0} PROPERTY COMPILE_DEFINITIONS_DEBUG ATEST)

Then, once the solution and project is generated, I go into the project
properties under the C++ preprocessor and I can't see the define. Removing
the configuration name does set it correctly for all of them, so it leads
me to believe the rest of my CMakeLists.txt is fine:

set_property(TARGET ${PrjName0} PROPERTY COMPILE_DEFINITIONS ATEST)

So is this supposed to work?

Thank you,

Carl
-- 

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

[Cmake-commits] CMake branch, next, updated. v3.3.1-2923-g35f46e3

[Brad King]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  35f46e30fe43345610408874db2504614bc72d47 (commit)
   via  af2a0b5b0facf8b08ebffaefa5a2a3f8723851d5 (commit)
   via  82df6286943681765a47d55b431eae952960f5d3 (commit)
   via  02440154fb457e481d44aa0a2c2134e1a66e0f4b (commit)
  from  ef34192b04d49f21d39ecb9ceebfd5d95ec35bc2 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=35f46e30fe43345610408874db2504614bc72d47
commit 35f46e30fe43345610408874db2504614bc72d47
Merge: ef34192 af2a0b5
Author: Brad King 
AuthorDate: Mon Sep 14 14:54:44 2015 -0400
Commit: CMake Topic Stage 
CommitDate: Mon Sep 14 14:54:44 2015 -0400

Merge topic 'fix-bad-search-ordering-for-master' into next

af2a0b5b Tests: Cover find_program when the environment duplicate some HINTS
82df6286 Merge branch 'fix-bad-search-ordering' into 
fix-bad-search-ordering-for-master
02440154 find_*: Fix search order when the environment duplicates some HINTS


http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=af2a0b5b0facf8b08ebffaefa5a2a3f8723851d5
commit af2a0b5b0facf8b08ebffaefa5a2a3f8723851d5
Author: Brad King 
AuthorDate: Mon Sep 14 14:49:49 2015 -0400
Commit: Brad King 
CommitDate: Mon Sep 14 14:49:49 2015 -0400

Tests: Cover find_program when the environment duplicate some HINTS

Reported-by: Marc CHEVRIER 

diff --git a/Tests/RunCMake/find_program/A/test 
b/Tests/RunCMake/find_program/A/test
new file mode 100755
index 000..1a24852
--- /dev/null
+++ b/Tests/RunCMake/find_program/A/test
@@ -0,0 +1 @@
+#!/bin/sh
diff --git a/Tests/RunCMake/find_program/B/test 
b/Tests/RunCMake/find_program/B/test
new file mode 100755
index 000..1a24852
--- /dev/null
+++ b/Tests/RunCMake/find_program/B/test
@@ -0,0 +1 @@
+#!/bin/sh
diff --git a/Tests/RunCMake/find_program/EnvAndHints-stdout.txt 
b/Tests/RunCMake/find_program/EnvAndHints-stdout.txt
new file mode 100644
index 000..113263e
--- /dev/null
+++ b/Tests/RunCMake/find_program/EnvAndHints-stdout.txt
@@ -0,0 +1 @@
+-- PROG='[^']*/Tests/RunCMake/find_program/A/test'
diff --git a/Tests/RunCMake/find_program/EnvAndHints.cmake 
b/Tests/RunCMake/find_program/EnvAndHints.cmake
new file mode 100644
index 000..3e30157
--- /dev/null
+++ b/Tests/RunCMake/find_program/EnvAndHints.cmake
@@ -0,0 +1,6 @@
+set(ENV{PATH} ${CMAKE_CURRENT_SOURCE_DIR}/A)
+find_program(PROG
+  NAMES test
+  HINTS ${CMAKE_CURRENT_SOURCE_DIR}/A ${CMAKE_CURRENT_SOURCE_DIR}/B
+  )
+message(STATUS "PROG='${PROG}'")
diff --git a/Tests/RunCMake/find_program/RunCMakeTest.cmake 
b/Tests/RunCMake/find_program/RunCMakeTest.cmake
index 2adec11..89307c1 100644
--- a/Tests/RunCMake/find_program/RunCMakeTest.cmake
+++ b/Tests/RunCMake/find_program/RunCMakeTest.cmake
@@ -1,5 +1,6 @@
 include(RunCMake)
 
+run_cmake(EnvAndHints)
 run_cmake(DirsPerName)
 run_cmake(NamesPerDir)
 

http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=82df6286943681765a47d55b431eae952960f5d3
commit 82df6286943681765a47d55b431eae952960f5d3
Merge: 0e7f34c 0244015
Author: Brad King 
AuthorDate: Mon Sep 14 14:49:37 2015 -0400
Commit: Brad King 
CommitDate: Mon Sep 14 14:49:37 2015 -0400

Merge branch 'fix-bad-search-ordering' into 
fix-bad-search-ordering-for-master


http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=02440154fb457e481d44aa0a2c2134e1a66e0f4b
commit 02440154fb457e481d44aa0a2c2134e1a66e0f4b
Author: Chuck Atkins 
AuthorDate: Wed Sep 9 16:03:04 2015 -0400
Commit: Brad King 
CommitDate: Mon Sep 14 14:43:38 2015 -0400

find_*: Fix search order when the environment duplicates some HINTS

Refactoring in the topic merged by commit v3.2.0-rc1~400 (Merge topic
'refactor-search-path-construction', 2014-11-13) introduced a bug that
filters out duplicate paths in an incorrect order.  Restore the search
path to its documented order even when duplicate paths are present.

Reported-by: Marc CHEVRIER 

diff --git a/Source/cmFindBase.cxx b/Source/cmFindBase.cxx
index add06a7..e2f86ce 100644
--- a/Source/cmFindBase.cxx
+++ b/Source/cmFindBase.cxx
@@ -207,6 +207,10 @@ void cmFindBase::ExpandPaths()
   {
   this->FillCMakeEnvironmentPath();
   }
+}
+  this->FillUserHintsPath();
+  if(!this->NoDefaultPath)
+{
 if(!this->NoSystemEnvironmentPath)
   {
   this->FillSystemEnvironmentPath();
@@ -216,8 +220,6 @@ void 

[Cmake-commits] CMake branch, next, updated. v3.3.1-2926-g4653dc3

[Gregor Jasny via Cmake-commits]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  4653dc36efc23e6a35449521a7d7a7688b0ab288 (commit)
   via  c4c34af1a8e951026178db532f18660e0a7f28bf (commit)
   via  40a85b503c9eaa579c5b497f7f7155911f7a67c3 (commit)
  from  35f46e30fe43345610408874db2504614bc72d47 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4653dc36efc23e6a35449521a7d7a7688b0ab288
commit 4653dc36efc23e6a35449521a7d7a7688b0ab288
Merge: 35f46e3 c4c34af
Author: Gregor Jasny 
AuthorDate: Mon Sep 14 15:18:41 2015 -0400
Commit: CMake Topic Stage 
CommitDate: Mon Sep 14 15:18:41 2015 -0400

Merge topic 'xcode-support-system-include' into next

c4c34af1 Swift: Add includes to OTHER_SWIFT_FLAGS in Xcode
40a85b50 Xcode: Obey SYSTEM keyword for includes (#15687)


http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c4c34af1a8e951026178db532f18660e0a7f28bf
commit c4c34af1a8e951026178db532f18660e0a7f28bf
Author: Gregor Jasny 
AuthorDate: Mon Sep 14 21:04:17 2015 +0200
Commit: Gregor Jasny 
CommitDate: Mon Sep 14 21:15:28 2015 +0200

Swift: Add includes to OTHER_SWIFT_FLAGS in Xcode

diff --git a/Modules/CMakeSwiftInformation.cmake 
b/Modules/CMakeSwiftInformation.cmake
index 61ad928..85d3143 100644
--- a/Modules/CMakeSwiftInformation.cmake
+++ b/Modules/CMakeSwiftInformation.cmake
@@ -13,6 +13,7 @@
 #  License text for the above reference.)
 
 set(CMAKE_Swift_OUTPUT_EXTENSION .o)
+set(CMAKE_INCLUDE_FLAG_Swift "-I")
 
 # Load compiler-specific information.
 if(CMAKE_Swift_COMPILER_ID)
diff --git a/Source/cmGlobalXCodeGenerator.cxx 
b/Source/cmGlobalXCodeGenerator.cxx
index e131ddc..de1e506 100644
--- a/Source/cmGlobalXCodeGenerator.cxx
+++ b/Source/cmGlobalXCodeGenerator.cxx
@@ -2300,6 +2300,11 @@ void 
cmGlobalXCodeGenerator::CreateBuildSettings(cmTarget& target,
   buildSettings->AddAttribute("OTHER_CFLAGS",
   this->CreateString(flags.c_str()));
   }
+else if (*li == "Swift")
+  {
+  buildSettings->AddAttribute("OTHER_SWIFT_FLAGS",
+  this->CreateString(flags.c_str()));
+  }
 }
 
   // Add Fortran source format attribute if property is set.

http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=40a85b503c9eaa579c5b497f7f7155911f7a67c3
commit 40a85b503c9eaa579c5b497f7f7155911f7a67c3
Author: Gregor Jasny 
AuthorDate: Mon Aug 31 22:33:37 2015 +0200
Commit: Gregor Jasny 
CommitDate: Mon Sep 14 21:15:11 2015 +0200

Xcode: Obey SYSTEM keyword for includes (#15687)

CMake used to put all header search paths into HEADER_SEARCH_PATHS
attribute. Unfortunately this attribute does not support to declare
a search path as a system include.

As a hack one could add a -isystem /path to the cflags but then include
ordering is not deterministic. A better approach was chosen with this
patch by not filling HEADER_SEARCH_PATHS at all and to populate
the C, C++, and Fortran flags directly. The include paths used by
Xcode should be now identical to the ones used by Unix Makefiles and
Ninja generator.

diff --git a/Source/cmGlobalXCodeGenerator.cxx 
b/Source/cmGlobalXCodeGenerator.cxx
index 33babec..e131ddc 100644
--- a/Source/cmGlobalXCodeGenerator.cxx
+++ b/Source/cmGlobalXCodeGenerator.cxx
@@ -2177,34 +2177,27 @@ void 
cmGlobalXCodeGenerator::CreateBuildSettings(cmTarget& target,
 this->CreateString("NO"));
 }
 
-  BuildObjectListOrString dirs(this, this->XcodeVersion >= 30);
-  BuildObjectListOrString fdirs(this, this->XcodeVersion >= 30);
-  std::vector includes;
-  this->CurrentLocalGenerator->GetIncludeDirectories(includes, gtgt,
- "C", configName);
-  std::set emitted;
-  emitted.insert("/System/Library/Frameworks");
-  for(std::vector::iterator i = includes.begin();
-  i != includes.end(); ++i)
+  for(std::set::iterator li = languages.begin();
+  li != languages.end(); ++li)
 {
-if(this->NameResolvesToFramework(i->c_str()))
-  {
-  std::string frameworkDir = *i;
-  frameworkDir += "/../";
-  frameworkDir = cmSystemTools::CollapseFullPath(frameworkDir.c_str());
-  if(emitted.insert(frameworkDir).second)
-{
-fdirs.Add(this->XCodeEscapePath(frameworkDir.c_str()).c_str());
-}
-  }
-else
+std::vector includes;
+this->CurrentLocalGenerator->GetIncludeDirectories(includes, gtgt, *li);
+
+ 

Re: [cmake-developers] [PATCH] Features: Only enable C11 support on GCC >= 4.9.

[Stephen Kelly]

Raphael Kubo da Costa wrote:

> Stephen Kelly  writes:
> 
>> Raphael Kubo da Costa wrote:
>>
>>> Adjust the GCC feature detection code to only consider C11 support to
>>> exist on GCC >= 4.9.
>>
>> If you do that you must remove the definition of
>> CMAKE_CXX11_STANDARD_COMPILE_OPTION for GNU < 4.8.1 too.
> [...]
>> sys/cdefs.h requires that if you use -std=c11, your compiler must have
>> the c_thread_local feature. Therefore, you must not use -std=c11 with GNU
>> < 4.9.
> [...]
>> Of course, the actual bug is in sys/cdefs.h as comment #2 in
>>  https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203066
>> describes.
> 
> I don't think comment #2 acknowledges there's a bug in cdefs.h; I see it
> as more of an acknowledgment that adding an additional check there would
> help work around/solve the issue.

I do consider it a bug :). Standards are too coarse, features of the 
compiler are what is relevant:

 
http://www.kdab.com/modern-cmake-with-qt-and-boost/#compile-feature-specification

That's also the whole point of SD-6 for C++.

The problematic content of the header affects all third party code in and 
out of the ports system, using cmake or not :).

But it doesn't matter that I consider it a bug. I'm not going to fix 
sys/cdefs.h either :). I can keep my opinions to myself, and people using 
that combination of toolchain have to deal with it :). 

> Especially if you take into account the
> CMAKE_CXX11_STANDARD_COMPILE_OPTION argument, one could argue that this
> is about choosing how strict CMake should be when determining whether a
> compiler implements a standard: enabling C++11 support only with GCC 4.8
> looks limiting and leaves out all the cases where it actually works fine
> with earlier versions.

Conversely, claiming GNU 4.4 supports C++11 doesn't make sense either 
(because standards are too coarse, features are what is relevant), which is 
why I consider CMAKE_CXX_STANDARD_REQUIRED to be nonsense.

So, yes, I agree with you here :).

Thanks,

Steve.


-- 

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] Libraries for a Target and/or its Dependents

[Wojciech Mamrak]

Hello,

The docs say [1]:
"Libraries and targets following PRIVATE are linked to, but are not
made part of the link interface."

If so, why does this snippet:

add_library(private_lib STATIC ...)
add_library(public_lib STATIC ...)

target_link_libraries(Test PRIVATE private_lib
PUBLIC public_lib)
install(EXPORT ...)

sets Test's imported target's properties with:

IMPORTED_LINK_INTERFACE_LIBRARIES_RELEASE "private_lib;public_lib"

I thought BUILD_INTERFACE and INSTALL_INTERFACE generator expressions
can solve this, but it turns out BUILD_INTERFACE is propagated, and
INSTALL_INTERFACE is not, i.e.

IMPORTED_LINK_INTERFACE_LIBRARIES_RELEASE
"private_lib;public_lib;build_interface_lib"

regards

[1] 
http://www.cmake.org/cmake/help/v3.3/command/target_link_libraries.html#libraries-for-a-target-and-or-its-dependents
-- 

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