[Cmake-commits] CMake branch, master, updated. v3.7.0-650-g2f7e05f

[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  2f7e05fbc20150377668a4ea1b114fd1b4d92df6 (commit)
  from  4093bd4025e65bdc75254bc7d08a675b10808a22 (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 -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2f7e05fbc20150377668a4ea1b114fd1b4d92df6
commit 2f7e05fbc20150377668a4ea1b114fd1b4d92df6
Author: Kitware Robot <kwro...@kitware.com>
AuthorDate: Tue Nov 29 00:01:04 2016 -0500
Commit: Kitware Robot <kwro...@kitware.com>
CommitDate: Tue Nov 29 00:01:04 2016 -0500

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 7499895..3086639 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 7)
-set(CMake_VERSION_PATCH 20161128)
+set(CMake_VERSION_PATCH 20161129)
 #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] VS2017 + CMake integration

[Marian Luparu via CMake]

Once we have it ready, it will be updated in-place in VS in one of the future 
releases. We can't commit yet that CMake 3.7 will be in VS 2017 RTW but it will 
definitely be in one of the VS Updates. VS ships every 1-2 months a preview 
update and every 3-4 months a major update. 

In parallel, we'll also start the PR process to make sure that the changes 
needed by VS are available eventually in the official CMake builds too.

-Original Message-
From: rcdai...@gmail.com [mailto:rcdai...@gmail.com] On Behalf Of Robert Dailey
Sent: Monday, November 28, 2016 8:35 AM
To: Marian Luparu 
Cc: CMake 
Subject: Re: [CMake] VS2017 + CMake integration

Thanks for the feedback Marian!

If/when you rebase to CMake 3.7, how will that package be delivered to Visual 
Studio customers? My real concern stems from basically our minimum required 
version of CMake for our specific scripts. The minimum is 3.7 due to the 
awesome Android integration added in that version. Which means obviously I 
can't use the bundled version of CMake in VS currently.

On Wed, Nov 23, 2016 at 1:57 PM, Marian Luparu  wrote:
> Thanks Robert -- this is great feedback
>
> Yes, VS ships with a patched 3.6 CMake that includes both changes to find the 
> VS 2017 installation as well as the CMake-Server functionality needed for the 
> IDE services. We have not yet started upstreaming these changes (got totally 
> sidetracked by getting the VS 2017 RC release out the door) but are 
> absolutely committed to do so. As a first step, we will be rebasing our 
> changes to the 3.7 CMake release and then start contributing these pieces.
>
> Once the changes are in PR, at a minimum, you will be able to compile your 
> own version of CMake if you wanted to, to replace the one shipping in VS. But 
> currently, to answer your other question, we have no capability of pointing 
> VS to a different version of CMake. That's primarily because of the 
> thick-coupling between VS and the custom patches we need in CMake to make the 
> end-to-end experience work.
>
> Thanks,
> Marian Luparu
> Visual C++ PM Lead
>
> -Original Message-
> From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Robert 
> Dailey
> Sent: Tuesday, November 22, 2016 10:58 AM
> To: CMake 
> Subject: [CMake] VS2017 + CMake integration
>
> First of all, I personally find the CMake integration in Visual Studio just 
> absolutely amazing. Granted I am not doing any cross-compiling with Android 
> yet, but for just building on Windows it's phenomenal.
>
> I noticed that Visual Studio 2017 RC is actually packaging its own version of 
> CMake:
>
> E:\PROGRAM FILES (X86)\MICROSOFT VISUAL 
> STUDIO\2017\PROFESSIONAL\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\CMAKE\
> CMake\bin\cmake.exe
>
> Is Microsoft patching the CMake code base to support what they are doing? And 
> if so, are those changes not upstream yet? Personally, I'd rather have the 
> ability to tell Visual Studio to use my external version of CMake that is on 
> PATH, rather than its own. I can understand if that isn't possible right now 
> due to custom changes, but I'm curious to learn more, assuming Kitware has 
> had a partnership with Microsoft for this integration with Visual Studio.
>
> Would anyone be able to provide more news here? Is there a way to make VS 
> 2017 use my separate install of CMake? Are the Microsoft-specific patches 
> contributed to upstream (or planned to be)?
> --
>
> Powered by 
> https://na01.safelinks.protection.outlook.com/?url=www.kitware.com
> a=02%7C01%7Cmluparu%40microsoft.com%7C00957bc2ac4847ee794f08d413098464
> %7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636154378985417863
> =Plv73v%2B4m3KwGsh6VinIPPgg1qUsCdmDlx%2F9U2urOqA%3D=0
>
> Please keep messages on-topic and check the CMake FAQ at: 
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.cm
> ake.org%2FWiki%2FCMake_FAQ=02%7C01%7Cmluparu%40microsoft.com%7C00
> 957bc2ac4847ee794f08d413098464%7C72f988bf86f141af91ab2d7cd011db47%7C1%
> 7C0%7C636154378985417863=qBtWeiauHkzD7ISZxtqz3Q72SaDZZwKwdY%2F1v
> oAI2U8%3D=0
>
> Kitware offers various services to support the CMake community. For more 
> information on each offering, please visit:
>
> CMake Support: 
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcmake.
> org%2Fcmake%2Fhelp%2Fsupport.html=02%7C01%7Cmluparu%40microsoft.c
> om%7C00957bc2ac4847ee794f08d413098464%7C72f988bf86f141af91ab2d7cd011db
> 47%7C1%7C0%7C636154378985417863=NZgcc%2BxtLPkIWXjqcIwItZr7KXAe6c
> qbcQaLpAMMA9Q%3D=0 CMake Consulting: 
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcmake.
> org%2Fcmake%2Fhelp%2Fconsulting.html=02%7C01%7Cmluparu%40microsof
> t.com%7C00957bc2ac4847ee794f08d413098464%7C72f988bf86f141af91ab2d7cd01
> 1db47%7C1%7C0%7C636154378985417863=YXiCCEGtOMh3qvpKtXTgiL86czKy8
> xedQbUOoFaTsXA%3D=0 CMake Training Courses: 
> 

[Cmake-commits] CMake branch, next, updated. v3.7.0-1380-g35edbdb

[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  35edbdb02c0566eb56c3b649450caf68607b5216 (commit)
   via  745b56f58c8147aa6015a918f3bfd19abc807b48 (commit)
   via  0ab9cb4699dbbba808f243c4dc32aebe23a69a34 (commit)
   via  703d194338039e0231638b1f690748025ecca505 (commit)
  from  cc653bea23a94e8c494203954954efd319d31cda (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 -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=35edbdb02c0566eb56c3b649450caf68607b5216
commit 35edbdb02c0566eb56c3b649450caf68607b5216
Merge: cc653be 745b56f
Author: Brad King 
AuthorDate: Mon Nov 28 16:42:39 2016 -0500
Commit: CMake Topic Stage 
CommitDate: Mon Nov 28 16:42:39 2016 -0500

Merge topic 'find-module-cleanup-sweep' into next

745b56f5 Find*.cmake: drop the comments before including FPHSA
0ab9cb46 FindLibArchive: do not set LibArchive_FOUND explicitly
703d1943 FindLibArchive: use CMAKE_CURRENT_LIST_DIR to find FPHSA


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=745b56f58c8147aa6015a918f3bfd19abc807b48
commit 745b56f58c8147aa6015a918f3bfd19abc807b48
Author: Rolf Eike Beer 
AuthorDate: Tue Nov 22 22:18:04 2016 +0100
Commit: Brad King 
CommitDate: Mon Nov 28 16:40:13 2016 -0500

Find*.cmake: drop the comments before including FPHSA

No need to explain this over and over again.  While at it, do some other
minor cleanups to whitespace and comments (i.e. delete them).

diff --git a/Modules/FindALSA.cmake b/Modules/FindALSA.cmake
index d0ffa03..fa9a434 100644
--- a/Modules/FindALSA.cmake
+++ b/Modules/FindALSA.cmake
@@ -39,8 +39,6 @@ if(ALSA_INCLUDE_DIR AND EXISTS 
"${ALSA_INCLUDE_DIR}/alsa/version.h")
   unset(alsa_version_str)
 endif()
 
-# handle the QUIETLY and REQUIRED arguments and set ALSA_FOUND to TRUE if
-# all listed variables are TRUE
 include(${CMAKE_CURRENT_LIST_DIR}/FindPackageHandleStandardArgs.cmake)
 FIND_PACKAGE_HANDLE_STANDARD_ARGS(ALSA
   REQUIRED_VARS ALSA_LIBRARY ALSA_INCLUDE_DIR
diff --git a/Modules/FindASPELL.cmake b/Modules/FindASPELL.cmake
index 8f2b007..6944ac1 100644
--- a/Modules/FindASPELL.cmake
+++ b/Modules/FindASPELL.cmake
@@ -25,8 +25,6 @@ find_program(ASPELL_EXECUTABLE
 
 find_library(ASPELL_LIBRARIES NAMES aspell aspell-15 libaspell-15 libaspell)
 
-# handle the QUIETLY and REQUIRED arguments and set ASPELL_FOUND to TRUE if
-# all listed variables are TRUE
 include(${CMAKE_CURRENT_LIST_DIR}/FindPackageHandleStandardArgs.cmake)
 FIND_PACKAGE_HANDLE_STANDARD_ARGS(ASPELL DEFAULT_MSG ASPELL_LIBRARIES 
ASPELL_INCLUDE_DIR ASPELL_EXECUTABLE)
 
diff --git a/Modules/FindAVIFile.cmake b/Modules/FindAVIFile.cmake
index 38701be..88a2a25 100644
--- a/Modules/FindAVIFile.cmake
+++ b/Modules/FindAVIFile.cmake
@@ -32,8 +32,6 @@ if (UNIX)
 
 endif ()
 
-# handle the QUIETLY and REQUIRED arguments and set AVIFILE_FOUND to TRUE if
-# all listed variables are TRUE
 include(${CMAKE_CURRENT_LIST_DIR}/FindPackageHandleStandardArgs.cmake)
 FIND_PACKAGE_HANDLE_STANDARD_ARGS(AVIFile DEFAULT_MSG AVIFILE_INCLUDE_DIR 
AVIFILE_AVIPLAY_LIBRARY)
 
diff --git a/Modules/FindArmadillo.cmake b/Modules/FindArmadillo.cmake
index fab04c2..95f0c56 100644
--- a/Modules/FindArmadillo.cmake
+++ b/Modules/FindArmadillo.cmake
@@ -73,10 +73,6 @@ if(ARMADILLO_INCLUDE_DIR)
   set(ARMADILLO_VERSION_STRING 
"${ARMADILLO_VERSION_MAJOR}.${ARMADILLO_VERSION_MINOR}.${ARMADILLO_VERSION_PATCH}")
 endif ()
 
-#==
-
-
-# Checks 'REQUIRED', 'QUIET' and versions.
 include(${CMAKE_CURRENT_LIST_DIR}/FindPackageHandleStandardArgs.cmake)
 find_package_handle_standard_args(Armadillo
   REQUIRED_VARS ARMADILLO_LIBRARY ARMADILLO_INCLUDE_DIR
@@ -88,10 +84,7 @@ if (ARMADILLO_FOUND)
   set(ARMADILLO_LIBRARIES ${ARMADILLO_LIBRARY})
 endif ()
 
-
 # Hide internal variables
 mark_as_advanced(
   ARMADILLO_INCLUDE_DIR
   ARMADILLO_LIBRARY)
-
-#==
diff --git a/Modules/FindBISON.cmake b/Modules/FindBISON.cmake
index d40b806..0ebd465 100644
--- a/Modules/FindBISON.cmake
+++ b/Modules/FindBISON.cmake
@@ -253,5 +253,3 @@ endif()
 include(${CMAKE_CURRENT_LIST_DIR}/FindPackageHandleStandardArgs.cmake)
 FIND_PACKAGE_HANDLE_STANDARD_ARGS(BISON REQUIRED_VARS  BISON_EXECUTABLE
 VERSION_VAR BISON_VERSION)
-
-# FindBISON.cmake ends here
diff --git a/Modules/FindBZip2.cmake b/Modules/FindBZip2.cmake
index 2d93eba..d2307f1 100644
--- a/Modules/FindBZip2.cmake
+++ b/Modules/FindBZip2.cmake
@@ -45,8 +45,6 @@ if (BZIP2_INCLUDE_DIR AND EXISTS 

Re: [cmake-developers] QtSDK integration

[Konstantin Podsvirov]

Well, thank you Brad!22:14, 28 november 2016 г., Brad King :On 11/28/2016 08:49 AM, Konstantin Podsvirov wrote: Anybody known where Brad King? Or anybody can help me to review and merge !280, !281 and !282 MRs into 'next' for testing?I was on vacation for the US Thanksgiving holiday.  I'll get tothese when I can.Thanks,-BradI would also like to say thank you that I have included in the project team on GitLab site and in the Copyright text.--Regards,Konstantin Podsvirov
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

[Cmake-commits] CMake branch, next, updated. v3.7.0-1376-gcc653be

[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  cc653bea23a94e8c494203954954efd319d31cda (commit)
   via  7abb12c826cad6e5847c32d4769c076732581901 (commit)
   via  d3f9f5120c05e4756d7ee1ed81917f74583455a2 (commit)
  from  23e8657e5854ff3fef364ec490a14fb06556f04d (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 -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=cc653bea23a94e8c494203954954efd319d31cda
commit cc653bea23a94e8c494203954954efd319d31cda
Merge: 23e8657 7abb12c
Author: Brad King 
AuthorDate: Mon Nov 28 16:33:41 2016 -0500
Commit: CMake Topic Stage 
CommitDate: Mon Nov 28 16:33:41 2016 -0500

Merge topic 'FindDevIL-updates' into next

7abb12c8 FindDevIL: Make the ILUT library optional
d3f9f512 FindDevIL: fail properly when library is not found.


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7abb12c826cad6e5847c32d4769c076732581901
commit 7abb12c826cad6e5847c32d4769c076732581901
Author: Vladimír Vondruš 
AuthorDate: Thu Nov 24 12:40:22 2016 +0100
Commit: Brad King 
CommitDate: Mon Nov 28 16:31:25 2016 -0500

FindDevIL: Make the ILUT library optional

Some distributions (such as ArchLinux) have only the IL and ILU
libraries and since these are mainly used, the module should succeed
even though ILUT was not found.  Removed it from the FPHSA() macro call,
making it effectively optional.

diff --git a/Modules/FindDevIL.cmake b/Modules/FindDevIL.cmake
index 4b6128b..45fab82 100644
--- a/Modules/FindDevIL.cmake
+++ b/Modules/FindDevIL.cmake
@@ -69,4 +69,4 @@ find_library(ILU_LIBRARIES
 
 FIND_PACKAGE_HANDLE_STANDARD_ARGS(DevIL DEFAULT_MSG
   IL_LIBRARIES ILU_LIBRARIES
-  ILUT_LIBRARIES IL_INCLUDE_DIR)
+  IL_INCLUDE_DIR)

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d3f9f5120c05e4756d7ee1ed81917f74583455a2
commit d3f9f5120c05e4756d7ee1ed81917f74583455a2
Author: Vladimír Vondruš 
AuthorDate: Thu Nov 24 12:26:56 2016 +0100
Commit: Brad King 
CommitDate: Mon Nov 28 16:31:04 2016 -0500

FindDevIL: fail properly when library is not found.

Due to a mismatch between module name and name passed to FPHSA() the
macro printed an error message but the error was not caught up by CMake.
Fix the typo.

diff --git a/Modules/FindDevIL.cmake b/Modules/FindDevIL.cmake
index dc8e38a..4b6128b 100644
--- a/Modules/FindDevIL.cmake
+++ b/Modules/FindDevIL.cmake
@@ -67,6 +67,6 @@ find_library(ILU_LIBRARIES
 
 #message("ILU_LIBRARIES is ${ILU_LIBRARIES}")
 
-FIND_PACKAGE_HANDLE_STANDARD_ARGS(IL DEFAULT_MSG
+FIND_PACKAGE_HANDLE_STANDARD_ARGS(DevIL DEFAULT_MSG
   IL_LIBRARIES ILU_LIBRARIES
   ILUT_LIBRARIES IL_INCLUDE_DIR)

---

Summary of changes:
 Modules/FindDevIL.cmake |4 ++--
 1 file changed, 2 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, next, updated. v3.7.0-1373-g23e8657

[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  23e8657e5854ff3fef364ec490a14fb06556f04d (commit)
   via  cbccebbac970e37a772ee06ab766b6cbc085532f (commit)
  from  0235eda8011ac6f8bdafa2a2e2ae8044c47556dc (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 -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=23e8657e5854ff3fef364ec490a14fb06556f04d
commit 23e8657e5854ff3fef364ec490a14fb06556f04d
Merge: 0235eda cbccebb
Author: Brad King 
AuthorDate: Mon Nov 28 16:20:17 2016 -0500
Commit: CMake Topic Stage 
CommitDate: Mon Nov 28 16:20:17 2016 -0500

Merge topic 'FindPkgConfig-fix-print-errors' into next

cbccebba FindPkgConfig: Fix missing error text when library version is 
specified


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=cbccebbac970e37a772ee06ab766b6cbc085532f
commit cbccebbac970e37a772ee06ab766b6cbc085532f
Author: Gautier Pelloux-Prayer 
AuthorDate: Thu Nov 24 11:14:29 2016 +0100
Commit: Brad King 
CommitDate: Mon Nov 28 16:18:07 2016 -0500

FindPkgConfig: Fix missing error text when library version is specified

Calls like `pkg_check_modules(somelibrary>=3.22)` that specify a version
requirement should still display an informative error when the package
is not found.  Fix our logic accordingly.

diff --git a/Modules/FindPkgConfig.cmake b/Modules/FindPkgConfig.cmake
index 3f75b19..8b7131b 100644
--- a/Modules/FindPkgConfig.cmake
+++ b/Modules/FindPkgConfig.cmake
@@ -381,8 +381,9 @@ macro(_pkg_check_modules_internal _is_required _is_silent 
_no_cmake_path _no_cma
   if (_pkg_check_modules_pkg_op)
 list(APPEND _pkg_check_modules_exist_query 
"${_pkg_check_modules_pkg_ver}")
   else()
-list(APPEND _pkg_check_modules_exist_query --exists --print-errors 
--short-errors)
+list(APPEND _pkg_check_modules_exist_query --exists)
   endif()
+  list(APPEND _pkg_check_modules_exist_query --print-errors --short-errors)
 
   _pkgconfig_unset(${_prefix}_${_pkg_check_modules_pkg_name}_VERSION)
   _pkgconfig_unset(${_prefix}_${_pkg_check_modules_pkg_name}_PREFIX)

---

Summary of changes:
 Modules/FindPkgConfig.cmake |3 ++-
 1 file changed, 2 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.7.0-1371-g0235eda

[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  0235eda8011ac6f8bdafa2a2e2ae8044c47556dc (commit)
   via  dd84d713d8bc75aef40564320afecea2ea8165fd (commit)
  from  03ed0e9279261bc7967d77b19ab9d71d3a929512 (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 -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0235eda8011ac6f8bdafa2a2e2ae8044c47556dc
commit 0235eda8011ac6f8bdafa2a2e2ae8044c47556dc
Merge: 03ed0e9 dd84d71
Author: Brad King 
AuthorDate: Mon Nov 28 15:57:40 2016 -0500
Commit: CMake Topic Stage 
CommitDate: Mon Nov 28 15:57:40 2016 -0500

Merge topic 'vs-default-build-package' into next

dd84d713 VS: Add option to place `PACKAGE` target in solution default build


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=dd84d713d8bc75aef40564320afecea2ea8165fd
commit dd84d713d8bc75aef40564320afecea2ea8165fd
Author: Michael Stürmer 
AuthorDate: Mon Nov 21 13:25:35 2016 +0100
Commit: Brad King 
CommitDate: Mon Nov 28 15:55:42 2016 -0500

VS: Add option to place `PACKAGE` target in solution default build

Add a `CMAKE_VS_INCLUDE_PACKAGE_TO_DEFAULT_BUILD` variable to control
this behavior.

diff --git a/Help/manual/cmake-variables.7.rst 
b/Help/manual/cmake-variables.7.rst
index d68265d..c621d3a 100644
--- a/Help/manual/cmake-variables.7.rst
+++ b/Help/manual/cmake-variables.7.rst
@@ -328,6 +328,7 @@ Variables that Control the Build
/variable/CMAKE_USE_RELATIVE_PATHS
/variable/CMAKE_VISIBILITY_INLINES_HIDDEN
/variable/CMAKE_VS_INCLUDE_INSTALL_TO_DEFAULT_BUILD
+   /variable/CMAKE_VS_INCLUDE_PACKAGE_TO_DEFAULT_BUILD
/variable/CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS
/variable/CMAKE_WIN32_EXECUTABLE
/variable/CMAKE_XCODE_ATTRIBUTE_an-attribute
diff --git a/Help/release/dev/vs-default-build-package.rst 
b/Help/release/dev/vs-default-build-package.rst
new file mode 100644
index 000..62c66e0
--- /dev/null
+++ b/Help/release/dev/vs-default-build-package.rst
@@ -0,0 +1,7 @@
+vs-default-build-package
+
+
+* The :ref:`Visual Studio Generators` for VS 2010 and above now support
+  adding the PACKAGE target to the targets which are built by default.
+  The behavior is similar to 
:variable:`CMAKE_VS_INCLUDE_INSTALL_TO_DEFAULT_BUILD`
+  and can be toggled using 
:variable:`CMAKE_VS_INCLUDE_PACKAGE_TO_DEFAULT_BUILD`.
diff --git a/Help/variable/CMAKE_VS_INCLUDE_PACKAGE_TO_DEFAULT_BUILD.rst 
b/Help/variable/CMAKE_VS_INCLUDE_PACKAGE_TO_DEFAULT_BUILD.rst
new file mode 100644
index 000..693ba45
--- /dev/null
+++ b/Help/variable/CMAKE_VS_INCLUDE_PACKAGE_TO_DEFAULT_BUILD.rst
@@ -0,0 +1,8 @@
+CMAKE_VS_INCLUDE_PACKAGE_TO_DEFAULT_BUILD
+-
+
+Include ``PACKAGE`` target to default build.
+
+In Visual Studio solution, by default the ``PACKAGE`` target will not be part
+of the default build. Setting this variable will enable the ``PACKAGE`` target
+to be part of the default build.
diff --git a/Source/cmGlobalVisualStudio7Generator.cxx 
b/Source/cmGlobalVisualStudio7Generator.cxx
index c60a1ff..602666e 100644
--- a/Source/cmGlobalVisualStudio7Generator.cxx
+++ b/Source/cmGlobalVisualStudio7Generator.cxx
@@ -681,20 +681,27 @@ std::set 
cmGlobalVisualStudio7Generator::IsPartOfDefaultBuild(
   // default build if another target depends on it
   int type = target->GetType();
   if (type == cmStateEnums::GLOBAL_TARGET) {
-// check if INSTALL target is part of default build
-if (target->GetName() == "INSTALL") {
-  // inspect CMAKE_VS_INCLUDE_INSTALL_TO_DEFAULT_BUILD properties
-  for (std::vector::const_iterator i = configs.begin();
-   i != configs.end(); ++i) {
-const char* propertyValue =
-  target->Target->GetMakefile()->GetDefinition(
-"CMAKE_VS_INCLUDE_INSTALL_TO_DEFAULT_BUILD");
-cmGeneratorExpression ge;
-CM_AUTO_PTR cge =
-  ge.Parse(propertyValue);
-if (cmSystemTools::IsOn(
-  cge->Evaluate(target->GetLocalGenerator(), *i))) {
-  activeConfigs.insert(*i);
+std::list targetNames;
+targetNames.push_back("INSTALL");
+targetNames.push_back("PACKAGE");
+for (std::list::const_iterator t = targetNames.begin();
+ t != targetNames.end(); ++t) {
+  // check if target <*t> is part of default build
+  if (target->GetName() == *t) {
+const std::string propertyName =
+  "CMAKE_VS_INCLUDE_" + *t + "_TO_DEFAULT_BUILD";
+// inspect CMAKE_VS_INCLUDE_<*t>_TO_DEFAULT_BUILD properties
+for 

[Cmake-commits] CMake branch, next, updated. v3.7.0-1369-g03ed0e9

[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  03ed0e9279261bc7967d77b19ab9d71d3a929512 (commit)
   via  6f23daea4391c2db8bc27d2e4cb42eac02368822 (commit)
   via  7d433206cf7de8f28aa2d169ed25cd401fcfc413 (commit)
  from  f86efd538055a50001396eed9648f151a0a54088 (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 -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=03ed0e9279261bc7967d77b19ab9d71d3a929512
commit 03ed0e9279261bc7967d77b19ab9d71d3a929512
Merge: f86efd5 6f23dae
Author: Brad King 
AuthorDate: Mon Nov 28 15:24:23 2016 -0500
Commit: CMake Topic Stage 
CommitDate: Mon Nov 28 15:24:23 2016 -0500

Merge topic 'libarchive-openssl-1.1' into next

6f23daea libarchive: Add support for building with OpenSSL 1.1
7d433206 libarchive: Add headers to adapt between OpenSSL 1.1 and older 
versions


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6f23daea4391c2db8bc27d2e4cb42eac02368822
commit 6f23daea4391c2db8bc27d2e4cb42eac02368822
Author: Brad King 
AuthorDate: Thu Nov 17 15:44:44 2016 -0500
Commit: Brad King 
CommitDate: Mon Nov 28 14:55:42 2016 -0500

libarchive: Add support for building with OpenSSL 1.1

OpenSSL 1.1 made some CTX structures opaque.  Port our code to use the
structures only through pointers via OpenSSL 1.1 APIs.  Use our adaption
layer to make this work with OpenSSL 1.0 and below.

Patch-by: Tomas Mraz 
Patch-from: https://bugzilla.redhat.com/1383744

diff --git a/Utilities/cmlibarchive/libarchive/archive_cryptor.c 
b/Utilities/cmlibarchive/libarchive/archive_cryptor.c
index 0be30c6..2a51dfe 100644
--- a/Utilities/cmlibarchive/libarchive/archive_cryptor.c
+++ b/Utilities/cmlibarchive/libarchive/archive_cryptor.c
@@ -302,6 +302,7 @@ aes_ctr_release(archive_crypto_ctx *ctx)
 static int
 aes_ctr_init(archive_crypto_ctx *ctx, const uint8_t *key, size_t key_len)
 {
+   ctx->ctx = EVP_CIPHER_CTX_new();
 
switch (key_len) {
case 16: ctx->type = EVP_aes_128_ecb(); break;
@@ -314,7 +315,7 @@ aes_ctr_init(archive_crypto_ctx *ctx, const uint8_t *key, 
size_t key_len)
memcpy(ctx->key, key, key_len);
memset(ctx->nonce, 0, sizeof(ctx->nonce));
ctx->encr_pos = AES_BLOCK_SIZE;
-   EVP_CIPHER_CTX_init(>ctx);
+   EVP_CIPHER_CTX_init(ctx->ctx);
return 0;
 }
 
@@ -324,10 +325,10 @@ aes_ctr_encrypt_counter(archive_crypto_ctx *ctx)
int outl = 0;
int r;
 
-   r = EVP_EncryptInit_ex(>ctx, ctx->type, NULL, ctx->key, NULL);
+   r = EVP_EncryptInit_ex(ctx->ctx, ctx->type, NULL, ctx->key, NULL);
if (r == 0)
return -1;
-   r = EVP_EncryptUpdate(>ctx, ctx->encr_buf, , ctx->nonce,
+   r = EVP_EncryptUpdate(ctx->ctx, ctx->encr_buf, , ctx->nonce,
AES_BLOCK_SIZE);
if (r == 0 || outl != AES_BLOCK_SIZE)
return -1;
@@ -337,7 +338,7 @@ aes_ctr_encrypt_counter(archive_crypto_ctx *ctx)
 static int
 aes_ctr_release(archive_crypto_ctx *ctx)
 {
-   EVP_CIPHER_CTX_cleanup(>ctx);
+   EVP_CIPHER_CTX_free(ctx->ctx);
memset(ctx->key, 0, ctx->key_len);
memset(ctx->nonce, 0, sizeof(ctx->nonce));
return 0;
diff --git a/Utilities/cmlibarchive/libarchive/archive_cryptor_private.h 
b/Utilities/cmlibarchive/libarchive/archive_cryptor_private.h
index 1c1a8c0..0ca544b 100644
--- a/Utilities/cmlibarchive/libarchive/archive_cryptor_private.h
+++ b/Utilities/cmlibarchive/libarchive/archive_cryptor_private.h
@@ -104,7 +104,7 @@ typedef struct {
 #define AES_MAX_KEY_SIZE 32
 
 typedef struct {
-   EVP_CIPHER_CTX  ctx;
+   EVP_CIPHER_CTX  *ctx;
const EVP_CIPHER *type;
uint8_t key[AES_MAX_KEY_SIZE];
unsignedkey_len;
diff --git a/Utilities/cmlibarchive/libarchive/archive_digest.c 
b/Utilities/cmlibarchive/libarchive/archive_digest.c
index f009d31..4153923 100644
--- a/Utilities/cmlibarchive/libarchive/archive_digest.c
+++ b/Utilities/cmlibarchive/libarchive/archive_digest.c
@@ -207,7 +207,9 @@ __archive_nettle_md5final(archive_md5_ctx *ctx, void *md)
 static int
 __archive_openssl_md5init(archive_md5_ctx *ctx)
 {
-  EVP_DigestInit(ctx, EVP_md5());
+  if ((*ctx = EVP_MD_CTX_new()) == NULL)
+   return (ARCHIVE_FAILED);
+  EVP_DigestInit(*ctx, EVP_md5());
   return (ARCHIVE_OK);
 }
 
@@ -215,7 +217,7 @@ static int
 __archive_openssl_md5update(archive_md5_ctx *ctx, const void *indata,
 size_t insize)
 {
-  EVP_DigestUpdate(ctx, indata, insize);
+  EVP_DigestUpdate(*ctx, indata, insize);
   

Re: [cmake-developers] GitLab speed

[Brad King]

On 11/28/2016 02:27 PM, Harry Mallon wrote:
> moving around the interface and even pushing to repos seems to be
> much slower than the equivalent thing on github.

Has it only been today or the last few days that you've noticed this?
It does feel slower today than usual.  I'll check with our admins.

> I am not sure whether this report is constructive

It is legitimate feedback presented in a civil tone.

Thanks,
-Brad

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

[cmake-developers] GitLab speed

[Harry Mallon]

Hello all,

While I appreciate having an integrated workflow and well defined contributing 
rules is useful for CMake I am finding it hard to get used to GitLab. The main 
reason is speed. Creating merge requests, moving around the interface and even 
pushing to repos seems to be much slower than the equivalent thing on github. I 
am not sure whether this report is constructive at all so feel free to dismiss 
my moaning.

Yours,
Harry

Harry Mallon
CODEX | Software Engineer
60 Poland Street | London | England | W1F 7NT
E ha...@codexdigital.com | T +44 203 7000 989
-- 

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] [EXTERNAL]: Errors with cmake for VS2105 (update 3) + clang + nmake

[Parag Chandra]

I’m not sure if the toolset parameter will have any effect if you’re *not* also 
going to output vcxproj files, but can you try “v140_clang_c2” as the toolset? 
 

Parag Chandra
Technical Lead, Mobile Team
Mobile: +1.919.824.1410

Ionic Security Inc.
1170 Peachtree St. NE STE 400, Atlanta, GA 30309
 

On 11/24/16, 8:20 AM, "CMake on behalf of Peter Jansen" 
 wrote:

Hi Parag,

Thanks for your feedback. 

The instructions you are referring to are for this cmake command :

   cmake -G"Visual Studio 14 2015" -T"LLVM-vs2014" ..

But in my case I'd like (1) to use the MS VS 2015 "Nmake Makefiles" as -G
option, and (2) the MS VS 2015 (update 3) included "clang" (which is version
3.8.0) compiler, referred to as Clang/C2 (i.e. using the MS VS 2015 linker
etc., NOT the Clang/LLVM system)
.
I have been trying to find information whether an appropriate -T option is
available for this, but was unsuccessful at this.

Any continued support with this would be appreciated.

Thanks,

Peter




--
View this message in context: 
http://cmake.3232098.n2.nabble.com/Errors-with-cmake-for-VS2105-update-3-clang-nmake-tp7594637p7594651.html
Sent from the CMake mailing list archive at Nabble.com.
-- 

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

[Cmake-commits] CMake branch, next, updated. v3.7.0-1366-gf86efd5

[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  f86efd538055a50001396eed9648f151a0a54088 (commit)
   via  6d604c4972d744defe783e7a5f9fbf478eee2dfe (commit)
  from  d98f7178adc3cb8ea3f46302e3efaf2f58088a8f (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 -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f86efd538055a50001396eed9648f151a0a54088
commit f86efd538055a50001396eed9648f151a0a54088
Merge: d98f717 6d604c4
Author: Brad King 
AuthorDate: Mon Nov 28 14:36:36 2016 -0500
Commit: CMake Topic Stage 
CommitDate: Mon Nov 28 14:36:36 2016 -0500

Merge topic 'try_compile-honor-CMAKE_WARN_DEPRECATED' into next

6d604c49 try_compile: Honor CMAKE_WARN_DEPRECATED in test project


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6d604c4972d744defe783e7a5f9fbf478eee2dfe
commit 6d604c4972d744defe783e7a5f9fbf478eee2dfe
Author: Brad King 
AuthorDate: Tue Nov 22 10:08:45 2016 -0500
Commit: Brad King 
CommitDate: Tue Nov 22 10:17:20 2016 -0500

try_compile: Honor CMAKE_WARN_DEPRECATED in test project

This causes the `-Wno-deprecated` option to be honored even inside a
`try_compile` test project, which is needed to suppress all deprecation
warnings as the option documents.

Closes: #16446

diff --git a/Help/release/dev/try_compile-honor-CMAKE_WARN_DEPRECATED.rst 
b/Help/release/dev/try_compile-honor-CMAKE_WARN_DEPRECATED.rst
new file mode 100644
index 000..9e13575
--- /dev/null
+++ b/Help/release/dev/try_compile-honor-CMAKE_WARN_DEPRECATED.rst
@@ -0,0 +1,6 @@
+try_compile-honor-CMAKE_WARN_DEPRECATED
+---
+
+* The :command:`try_compile` command source file signature now
+  honors the :variable:`CMAKE_WARN_DEPRECATED` variable value
+  in the generated test project.
diff --git a/Source/cmCoreTryCompile.cxx b/Source/cmCoreTryCompile.cxx
index 3b46fc0..fbad778 100644
--- a/Source/cmCoreTryCompile.cxx
+++ b/Source/cmCoreTryCompile.cxx
@@ -44,6 +44,7 @@ static std::string const kCMAKE_TRY_COMPILE_OSX_ARCHITECTURES 
=
   "CMAKE_TRY_COMPILE_OSX_ARCHITECTURES";
 static std::string const kCMAKE_TRY_COMPILE_PLATFORM_VARIABLES =
   "CMAKE_TRY_COMPILE_PLATFORM_VARIABLES";
+static std::string const kCMAKE_WARN_DEPRECATED = "CMAKE_WARN_DEPRECATED";
 
 int cmCoreTryCompile::TryCompileCode(std::vector const& argv,
  bool isTryRun)
@@ -453,6 +454,7 @@ int 
cmCoreTryCompile::TryCompileCode(std::vector const& argv,
   vars.insert(kCMAKE_OSX_SYSROOT);
   vars.insert(kCMAKE_POSITION_INDEPENDENT_CODE);
   vars.insert(kCMAKE_SYSROOT);
+  vars.insert(kCMAKE_WARN_DEPRECATED);
 
   if (const char* varListStr = this->Makefile->GetDefinition(
 kCMAKE_TRY_COMPILE_PLATFORM_VARIABLES)) {
diff --git a/Tests/RunCMake/try_compile/RunCMakeTest.cmake 
b/Tests/RunCMake/try_compile/RunCMakeTest.cmake
index 522433a..4934bcd 100644
--- a/Tests/RunCMake/try_compile/RunCMakeTest.cmake
+++ b/Tests/RunCMake/try_compile/RunCMakeTest.cmake
@@ -18,6 +18,7 @@ run_cmake(NonSourceCompileDefinitions)
 
 set(RunCMake_TEST_OPTIONS --debug-trycompile)
 run_cmake(PlatformVariables)
+run_cmake(WarnDeprecated)
 unset(RunCMake_TEST_OPTIONS)
 
 run_cmake(TargetTypeExe)
diff --git a/Tests/RunCMake/try_compile/WarnDeprecated.cmake 
b/Tests/RunCMake/try_compile/WarnDeprecated.cmake
new file mode 100644
index 000..dfcb5f9
--- /dev/null
+++ b/Tests/RunCMake/try_compile/WarnDeprecated.cmake
@@ -0,0 +1,19 @@
+enable_language(C)
+
+set(CMAKE_WARN_DEPRECATED SOME_VALUE)
+
+try_compile(result ${CMAKE_CURRENT_BINARY_DIR}
+  SOURCES ${CMAKE_CURRENT_SOURCE_DIR}/src.c
+  OUTPUT_VARIABLE out
+  )
+if(NOT result)
+  message(FATAL_ERROR "try_compile failed:\n${out}")
+endif()
+
+# Check that the cache was populated with our custom variable.
+file(STRINGS ${CMAKE_BINARY_DIR}/CMakeFiles/CMakeTmp/CMakeCache.txt entries
+  REGEX CMAKE_WARN_DEPRECATED:UNINITIALIZED=${CMAKE_WARN_DEPRECATED}
+  )
+if(NOT entries)
+  message(FATAL_ERROR "try_compile did not populate cache as expected")
+endif()

---

Summary of changes:
 Help/release/dev/try_compile-honor-CMAKE_WARN_DEPRECATED.rst   |6 ++
 Source/cmCoreTryCompile.cxx|2 ++
 Tests/RunCMake/try_compile/RunCMakeTest.cmake  |1 +
 .../{PlatformVariables.cmake => WarnDeprecated.cmake}  |8 ++--
 4 files changed, 11 insertions(+), 6 deletions(-)
 create mode 100644 

[Cmake-commits] CMake branch, next, updated. v3.7.0-1364-gd98f717

[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  d98f7178adc3cb8ea3f46302e3efaf2f58088a8f (commit)
   via  4093bd4025e65bdc75254bc7d08a675b10808a22 (commit)
   via  56c5c8e17aab80fe006d3de064d322dc31e8f25b (commit)
   via  8a975efc94518c93124d66a7a6626d8ab13f9561 (commit)
   via  1b22cb0a07be25bf6b8bf3afc8ffae7c928a90c9 (commit)
  from  398ab66bf2da85aa50a5fa9638a4cff14ec6d024 (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 -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d98f7178adc3cb8ea3f46302e3efaf2f58088a8f
commit d98f7178adc3cb8ea3f46302e3efaf2f58088a8f
Merge: 398ab66 4093bd4
Author: Brad King 
AuthorDate: Mon Nov 28 14:26:09 2016 -0500
Commit: Brad King 
CommitDate: Mon Nov 28 14:26:09 2016 -0500

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.7.0-644-g56c5c8e

[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  56c5c8e17aab80fe006d3de064d322dc31e8f25b (commit)
   via  50c3ebb90309d3165b30c243b4047a71eba34f73 (commit)
   via  a8a47098082a57a5b22cac546f030b551e1b9c32 (commit)
   via  48456535f3c59e19572857d7071d9551783e06d6 (commit)
   via  d040d1647d2192ab97db9b041599c9e224c93553 (commit)
   via  2cc479bdac84843d0284573cf801ee526e798c54 (commit)
   via  181e9bb6128c9ad4043c41ef270c79318146e1ad (commit)
   via  b687d2ba093b1b79e9faf09e45d11567b0ec9ac1 (commit)
   via  ed8858edb7c5100e1928c5a94f85485f0e322aa7 (commit)
   via  8575affa4c72e1c0d07f964d2f28eb6ddbadb291 (commit)
   via  79443e1b8b604de00d269e73a977f449bc3fcef2 (commit)
   via  6d51bea4e6ff058383e63c215ec5fb7fcab9870c (commit)
   via  0f15aee799a0af9fe1999d5c071483c9660ccf5b (commit)
   via  a0ad6fc4dc55541f66534abcf050aaf63c65033f (commit)
   via  46b6a25adaa3ce4326247263de426399be409a29 (commit)
   via  53a69c7dd47f693efec85e031b89251dd7bdef2f (commit)
   via  70b52a7113664b8b74b231d62ff798952d29ae1f (commit)
   via  7763bd72076357b986daa7e21e4bfe163f58c84a (commit)
   via  70a2bfe97c1b024bff5fa6b6537528457ca5a7f4 (commit)
   via  a15f51620ba0142e05cfa6aebd346a5cf76ca302 (commit)
  from  8a975efc94518c93124d66a7a6626d8ab13f9561 (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 -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=56c5c8e17aab80fe006d3de064d322dc31e8f25b
commit 56c5c8e17aab80fe006d3de064d322dc31e8f25b
Merge: 8a975ef 50c3ebb
Author: Brad King 
AuthorDate: Mon Nov 28 14:23:29 2016 -0500
Commit: CMake Topic Stage 
CommitDate: Mon Nov 28 14:23:29 2016 -0500

Merge topic 'cpack-tests-framework-updates'

50c3ebb9 Tests: CPack test documentation facelift
a8a47098 Tests: CPack/DEB test change prerequirements check
48456535 Tests: source CPack tests don't require build stage
d040d164 Tests: CPack test set packaging type
2cc479bd Tests: remove generator prefix from CPack test name
181e9bb6 Tests: CPack test long_filenames prerequirements
b687d2ba Tests: CPack test use same content list
ed8858ed Tests: CPack test unify expected file naming
8575affa Tests: CPack test move and merge VerifyResult
79443e1b Tests: CPack test move per test prerequirements
6d51bea4 Tests: CPack test merge generator specifics
0f15aee7 Tests: CPack test move ExpectedFiles script
a0ad6fc4 Tests: CPack test should always check test output
46b6a25a Tests: CPack test move std error files to test files
53a69c7d Tests: CPack move tests to separate dir
70b52a71 Tests: CPack test should use default package name
...


---

Summary of changes:
 Tests/RunCMake/CPack/CMakeLists.txt|   13 +-
 Tests/RunCMake/CPack/COMPONENTS_EMPTY_DIR.cmake|5 -
 Tests/RunCMake/CPack/CPackTestHelpers.cmake|   47 +++---
 Tests/RunCMake/CPack/CUSTOM_NAMES.cmake|7 -
 .../DEB/COMPONENTS_EMPTY_DIR-ExpectedFiles.cmake   |5 -
 .../CPack/DEB/CUSTOM_NAMES-ExpectedFiles.cmake |9 --
 .../CPack/DEB/CUSTOM_NAMES-specifics.cmake |6 -
 .../CPack/DEB/DEB_EXTRA-ExpectedFiles.cmake|9 --
 .../DEB/DEB_GENERATE_SHLIBS-Prerequirements.cmake  |7 -
 ..._GENERATE_SHLIBS_LDCONFIG-Prerequirements.cmake |7 -
 .../CPack/DEB/DEPENDENCIES-ExpectedFiles.cmake |   14 --
 .../CPack/DEB/DEPENDENCIES-VerifyResult.cmake  |   34 
 .../CPack/DEB/DEPENDENCIES-specifics.cmake |   23 ---
 .../CPack/DEB/EMPTY_DIR-ExpectedFiles.cmake|5 -
 Tests/RunCMake/CPack/DEB/EMPTY_DIR-specifics.cmake |2 -
 Tests/RunCMake/CPack/DEB/Helpers.cmake |   43 -
 .../CPack/DEB/LONG_FILENAMES-ExpectedFiles.cmake   |5 -
 .../CPack/DEB/LONG_FILENAMES-Prerequirements.cmake |7 -
 .../CPack/DEB/LONG_FILENAMES-specifics.cmake   |3 -
 .../RunCMake/CPack/DEB/MINIMAL-ExpectedFiles.cmake |5 -
 Tests/RunCMake/CPack/DEB/MINIMAL-specifics.cmake   |2 -
 .../DEB/PER_COMPONENT_FIELDS-ExpectedFiles.cmake   |9 --
 .../DEB/PER_COMPONENT_FIELDS-VerifyResult.cmake|   18 ---
 .../CPack/DEB/PER_COMPONENT_FIELDS-specifics.cmake |7 -
 Tests/RunCMake/CPack/DEB/Prerequirements.cmake |7 +
 ...ics.cmake => packaging_COMPONENT_default.cmake} |3 +-
 .../CPack/DEB/packaging_MONOLITHIC_default.cmake   |1 +
 Tests/RunCMake/CPack/DEPENDENCIES.cmake|   20 ---
 Tests/RunCMake/CPack/EMPTY_DIR.cmake   |4 -
 

[Cmake-commits] CMake branch, master, updated. v3.7.0-649-g4093bd4

[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  4093bd4025e65bdc75254bc7d08a675b10808a22 (commit)
   via  d0c14dfb3694d076b8115d64dc317fd686b90aa2 (commit)
   via  66a70349b5a7964c2647c41f4759fe2141ee (commit)
   via  7b4244aceb44aad117dfaccfb2287fbddbe9eca7 (commit)
   via  aeff60e44c203dd67b316a6c6eab1454a408e1f7 (commit)
  from  56c5c8e17aab80fe006d3de064d322dc31e8f25b (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 -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4093bd4025e65bdc75254bc7d08a675b10808a22
commit 4093bd4025e65bdc75254bc7d08a675b10808a22
Merge: 56c5c8e d0c14df
Author: Brad King 
AuthorDate: Mon Nov 28 14:24:07 2016 -0500
Commit: CMake Topic Stage 
CommitDate: Mon Nov 28 14:24:07 2016 -0500

Merge topic 'include-what-you-use'

d0c14dfb avoid including cmStandardIncludes.h
66a70999 iwyu: Fix VisualStudio specific issues
7b4244ac iwyu: Fix more findings
aeff60e4 iwyu: Fix OSX specific issues


---

Summary of changes:
 Source/CPack/IFW/cmCPackIFWInstaller.cxx  |8 +++--
 Source/CPack/OSXScriptLauncher.cxx|4 ++-
 Source/CPack/WiX/cmCPackWIXGenerator.cxx  |1 +
 Source/CPack/WiX/cmWIXRichTextFormatWriter.h  |3 +-
 Source/CPack/cmCPackBundleGenerator.cxx   |5 +--
 Source/CPack/cmCPackBundleGenerator.h |4 +++
 Source/CPack/cmCPackDragNDropGenerator.cxx|4 ++-
 Source/CPack/cmCPackDragNDropGenerator.h  |6 
 Source/CPack/cmCPackGenerator.cxx |   16 +-
 Source/CPack/cmCPackGenerator.h   |7 +++--
 Source/CPack/cmCPackGeneratorFactory.cxx  |   12 
 Source/CPack/cmCPackGeneratorFactory.h|2 +-
 Source/CPack/cmCPackLog.cxx   |5 +--
 Source/CPack/cmCPackLog.h |2 +-
 Source/CPack/cmCPackOSXX11Generator.cxx   |   11 +++
 Source/CPack/cmCPackOSXX11Generator.h |3 ++
 Source/CPack/cmCPackPKGGenerator.cxx  |   11 ++-
 Source/CPack/cmCPackPKGGenerator.h|4 ++-
 Source/CPack/cmCPackPackageMakerGenerator.cxx |   18 +--
 Source/CPack/cmCPackPackageMakerGenerator.h   |3 ++
 Source/CPack/cmCPackProductBuildGenerator.cxx |   11 +++
 Source/CPack/cmCPackProductBuildGenerator.h   |4 +++
 Source/CPack/cmCPackRPMGenerator.cxx  |   11 ---
 Source/CPack/cmCPackSTGZGenerator.cxx |8 ++---
 Source/CPack/cpack.cxx|   29 -
 Source/CTest/cmCTestGIT.cxx   |   13 
 Source/CTest/cmCTestGenericHandler.cxx|7 +++--
 Source/CTest/cmCTestGenericHandler.h  |8 ++---
 Source/CTest/cmCTestLaunch.cxx|   18 +--
 Source/CTest/cmCTestMemCheckCommand.cxx   |3 ++
 Source/CTest/cmCTestRunTest.h |4 ++-
 Source/CTest/cmCTestScriptHandler.cxx |   20 ++--
 Source/CTest/cmCTestSubmitHandler.cxx |   18 +--
 Source/CTest/cmCTestTestHandler.cxx   |   30 +-
 Source/CTest/cmCTestUploadCommand.cxx |5 +--
 Source/CTest/cmCTestVC.h  |5 +--
 Source/bindexplib.cxx |3 +-
 Source/bindexplib.h   |5 +--
 Source/cmCTest.h  |1 +
 Source/cmCallVisualStudioMacro.cxx|2 ++
 Source/cmCallVisualStudioMacro.h  |2 +-
 Source/cmCryptoHash.h |6 ++--
 Source/cmFileCommand.cxx  |   41 -
 Source/cmGhsMultiGpj.h|2 --
 Source/cmGlobalGhsMultiGenerator.cxx  |6 ++--
 Source/cmGlobalVisualStudio10Generator.cxx|3 +-
 Source/cmGlobalVisualStudio11Generator.cxx|1 +
 Source/cmGlobalVisualStudio11Generator.h  |   11 +++
 Source/cmGlobalVisualStudio12Generator.cxx|1 +
 Source/cmGlobalVisualStudio12Generator.h  |9 ++
 Source/cmGlobalVisualStudio14Generator.cxx|1 +
 Source/cmGlobalVisualStudio14Generator.h  |9 ++
 Source/cmGlobalVisualStudio15Generator.cxx|1 +
 Source/cmGlobalVisualStudio15Generator.h  |8 +
 Source/cmGlobalVisualStudio71Generator.cxx|3 +-
 Source/cmGlobalVisualStudio8Generator.cxx |3 +-
 Source/cmGlobalVisualStudio9Generator.cxx |3 +-
 Source/cmGlobalVisualStudioGenerator.cxx  |4 ++-
 Source/cmGlobalVisualStudioGenerator.h  

[Cmake-commits] CMake branch, master, updated. v3.7.0-624-g8a975ef

[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  8a975efc94518c93124d66a7a6626d8ab13f9561 (commit)
   via  543dcb0ada5047d789a19dbbffa9028cb1b317c7 (commit)
  from  1b22cb0a07be25bf6b8bf3afc8ffae7c928a90c9 (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 -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8a975efc94518c93124d66a7a6626d8ab13f9561
commit 8a975efc94518c93124d66a7a6626d8ab13f9561
Merge: 1b22cb0 543dcb0
Author: Brad King 
AuthorDate: Mon Nov 28 14:23:21 2016 -0500
Commit: CMake Topic Stage 
CommitDate: Mon Nov 28 14:23:21 2016 -0500

Merge topic '16449-revert-xcode-system-includes'

543dcb0a Revert "Xcode: Obey SYSTEM keyword for includes (#15687)"


---

Summary of changes:
 Source/cmGlobalXCodeGenerator.cxx  |   44 +++-
 Tests/IncludeDirectories/CMakeLists.txt|4 +-
 .../SystemIncludeDirectories/CMakeLists.txt|   15 ++-
 3 files changed, 19 insertions(+), 44 deletions(-)


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

Re: [cmake-developers] QtAutogen suggestions

[Sebastian Holtermann]

Am 28.11.2016 um 17:00 schrieb Brad King:
> On 11/28/2016 10:25 AM, Sebastian Holtermann wrote:
>> I'm going ahead then.
> 
> Thanks.  BTW, please sign up for a gitlab.kitware.com account
> (optionally via GitHub OAuth) so that we can include you in
> discussion of related issues.  For example:

https://gitlab.kitware.com/sebholt

-Sebastian
-- 

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] QtSDK integration

[Brad King]

On 11/28/2016 08:49 AM, Konstantin Podsvirov wrote:
> Anybody known where Brad King?
> 
> Or anybody can help me to review and merge !280, !281 and !282 MRs
> into 'next' for testing?

I was on vacation for the US Thanksgiving holiday.  I'll get to
these when I can.

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] VS2017 + CMake integration

[Robert Dailey]

Thanks for the feedback Marian!

If/when you rebase to CMake 3.7, how will that package be delivered to
Visual Studio customers? My real concern stems from basically our
minimum required version of CMake for our specific scripts. The
minimum is 3.7 due to the awesome Android integration added in that
version. Which means obviously I can't use the bundled version of
CMake in VS currently.

On Wed, Nov 23, 2016 at 1:57 PM, Marian Luparu  wrote:
> Thanks Robert -- this is great feedback
>
> Yes, VS ships with a patched 3.6 CMake that includes both changes to find the 
> VS 2017 installation as well as the CMake-Server functionality needed for the 
> IDE services. We have not yet started upstreaming these changes (got totally 
> sidetracked by getting the VS 2017 RC release out the door) but are 
> absolutely committed to do so. As a first step, we will be rebasing our 
> changes to the 3.7 CMake release and then start contributing these pieces.
>
> Once the changes are in PR, at a minimum, you will be able to compile your 
> own version of CMake if you wanted to, to replace the one shipping in VS. But 
> currently, to answer your other question, we have no capability of pointing 
> VS to a different version of CMake. That's primarily because of the 
> thick-coupling between VS and the custom patches we need in CMake to make the 
> end-to-end experience work.
>
> Thanks,
> Marian Luparu
> Visual C++ PM Lead
>
> -Original Message-
> From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Robert Dailey
> Sent: Tuesday, November 22, 2016 10:58 AM
> To: CMake 
> Subject: [CMake] VS2017 + CMake integration
>
> First of all, I personally find the CMake integration in Visual Studio just 
> absolutely amazing. Granted I am not doing any cross-compiling with Android 
> yet, but for just building on Windows it's phenomenal.
>
> I noticed that Visual Studio 2017 RC is actually packaging its own version of 
> CMake:
>
> E:\PROGRAM FILES (X86)\MICROSOFT VISUAL
> STUDIO\2017\PROFESSIONAL\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\CMAKE\CMake\bin\cmake.exe
>
> Is Microsoft patching the CMake code base to support what they are doing? And 
> if so, are those changes not upstream yet? Personally, I'd rather have the 
> ability to tell Visual Studio to use my external version of CMake that is on 
> PATH, rather than its own. I can understand if that isn't possible right now 
> due to custom changes, but I'm curious to learn more, assuming Kitware has 
> had a partnership with Microsoft for this integration with Visual Studio.
>
> Would anyone be able to provide more news here? Is there a way to make VS 
> 2017 use my separate install of CMake? Are the Microsoft-specific patches 
> contributed to upstream (or planned to be)?
> --
>
> Powered by 
> https://na01.safelinks.protection.outlook.com/?url=www.kitware.com=02%7C01%7Cmluparu%40microsoft.com%7C00957bc2ac4847ee794f08d413098464%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636154378985417863=Plv73v%2B4m3KwGsh6VinIPPgg1qUsCdmDlx%2F9U2urOqA%3D=0
>
> Please keep messages on-topic and check the CMake FAQ at: 
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.cmake.org%2FWiki%2FCMake_FAQ=02%7C01%7Cmluparu%40microsoft.com%7C00957bc2ac4847ee794f08d413098464%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636154378985417863=qBtWeiauHkzD7ISZxtqz3Q72SaDZZwKwdY%2F1voAI2U8%3D=0
>
> Kitware offers various services to support the CMake community. For more 
> information on each offering, please visit:
>
> CMake Support: 
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcmake.org%2Fcmake%2Fhelp%2Fsupport.html=02%7C01%7Cmluparu%40microsoft.com%7C00957bc2ac4847ee794f08d413098464%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636154378985417863=NZgcc%2BxtLPkIWXjqcIwItZr7KXAe6cqbcQaLpAMMA9Q%3D=0
> CMake Consulting: 
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcmake.org%2Fcmake%2Fhelp%2Fconsulting.html=02%7C01%7Cmluparu%40microsoft.com%7C00957bc2ac4847ee794f08d413098464%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636154378985417863=YXiCCEGtOMh3qvpKtXTgiL86czKy8xedQbUOoFaTsXA%3D=0
> CMake Training Courses: 
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcmake.org%2Fcmake%2Fhelp%2Ftraining.html=02%7C01%7Cmluparu%40microsoft.com%7C00957bc2ac4847ee794f08d413098464%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636154378985417863=Paz%2Ft%2Bm63qi1AavokeWDNrR69wIUD2Tzjuyp7gUHORk%3D=0
>
> Visit other Kitware open-source projects at 
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.kitware.com%2Fopensource%2Fopensource.html=02%7C01%7Cmluparu%40microsoft.com%7C00957bc2ac4847ee794f08d413098464%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636154378985417863=MkwbFPZ3eC9DrFysQTnnHA6CYFuNLTCt5%2FLdCrxLaXo%3D=0
>
> Follow this link to subscribe/unsubscribe:
> 

[Cmake-commits] CMake branch, next, updated. v3.7.0-1359-g398ab66

[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  398ab66bf2da85aa50a5fa9638a4cff14ec6d024 (commit)
   via  d0c14dfb3694d076b8115d64dc317fd686b90aa2 (commit)
   via  66a70349b5a7964c2647c41f4759fe2141ee (commit)
   via  7b4244aceb44aad117dfaccfb2287fbddbe9eca7 (commit)
  from  70bd7d16c57b3929f06b7faa5141efd4e4b6c031 (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 -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=398ab66bf2da85aa50a5fa9638a4cff14ec6d024
commit 398ab66bf2da85aa50a5fa9638a4cff14ec6d024
Merge: 70bd7d1 d0c14df
Author: Brad King 
AuthorDate: Mon Nov 28 14:10:07 2016 -0500
Commit: CMake Topic Stage 
CommitDate: Mon Nov 28 14:10:07 2016 -0500

Merge topic 'include-what-you-use' into next

d0c14dfb avoid including cmStandardIncludes.h
66a70999 iwyu: Fix VisualStudio specific issues
7b4244ac iwyu: Fix more findings


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d0c14dfb3694d076b8115d64dc317fd686b90aa2
commit d0c14dfb3694d076b8115d64dc317fd686b90aa2
Author: Daniel Pfeifer 
AuthorDate: Fri Nov 25 23:21:20 2016 +0100
Commit: Brad King 
CommitDate: Mon Nov 28 14:06:41 2016 -0500

avoid including cmStandardIncludes.h

diff --git a/Source/CPack/WiX/cmCPackWIXGenerator.cxx 
b/Source/CPack/WiX/cmCPackWIXGenerator.cxx
index 0c4f573..2bccf2e 100644
--- a/Source/CPack/WiX/cmCPackWIXGenerator.cxx
+++ b/Source/CPack/WiX/cmCPackWIXGenerator.cxx
@@ -4,6 +4,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/Source/CPack/WiX/cmWIXRichTextFormatWriter.h 
b/Source/CPack/WiX/cmWIXRichTextFormatWriter.h
index b535979..a3c8394 100644
--- a/Source/CPack/WiX/cmWIXRichTextFormatWriter.h
+++ b/Source/CPack/WiX/cmWIXRichTextFormatWriter.h
@@ -5,9 +5,8 @@
 
 #include 
 
-#include "cmStandardIncludes.h"
-
 #include 
+#include 
 
 /** \class cmWIXRichtTextFormatWriter
  * \brief Helper class to generate Rich Text Format (RTF) documents
diff --git a/Source/cmGhsMultiGpj.h b/Source/cmGhsMultiGpj.h
index 793d471..2c2b123 100644
--- a/Source/cmGhsMultiGpj.h
+++ b/Source/cmGhsMultiGpj.h
@@ -5,8 +5,6 @@
 
 #include 
 
-#include "cmStandardIncludes.h"
-
 class cmGeneratedFileStream;
 
 class GhsMultiGpj
diff --git a/Source/cmGlobalGhsMultiGenerator.cxx 
b/Source/cmGlobalGhsMultiGenerator.cxx
index 6bbfed5..286f375 100644
--- a/Source/cmGlobalGhsMultiGenerator.cxx
+++ b/Source/cmGlobalGhsMultiGenerator.cxx
@@ -2,14 +2,16 @@
file Copyright.txt or https://cmake.org/licensing for details.  */
 #include "cmGlobalGhsMultiGenerator.h"
 
+#include 
+
+#include "cmAlgorithms.h"
+#include "cmDocumentationEntry.h"
 #include "cmGeneratedFileStream.h"
 #include "cmGeneratorTarget.h"
 #include "cmGhsMultiTargetGenerator.h"
 #include "cmLocalGhsMultiGenerator.h"
 #include "cmMakefile.h"
 #include "cmVersion.h"
-#include 
-#include 
 
 const char* cmGlobalGhsMultiGenerator::FILE_EXTENSION = ".gpj";
 const char* cmGlobalGhsMultiGenerator::DEFAULT_MAKE_PROGRAM = "gbuild";

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=66a70349b5a7964c2647c41f4759fe2141ee
commit 66a70349b5a7964c2647c41f4759fe2141ee
Author: Daniel Pfeifer 
AuthorDate: Fri Nov 25 22:54:58 2016 +0100
Commit: Brad King 
CommitDate: Mon Nov 28 14:06:40 2016 -0500

iwyu: Fix VisualStudio specific issues

diff --git a/Source/bindexplib.cxx b/Source/bindexplib.cxx
index db97c47..eded883 100644
--- a/Source/bindexplib.cxx
+++ b/Source/bindexplib.cxx
@@ -62,11 +62,10 @@
 *--
 */
 #include "bindexplib.h"
+
 #include 
 #include 
 #include 
-#include 
-#include 
 #include 
 
 typedef struct cmANON_OBJECT_HEADER_BIGOBJ {
diff --git a/Source/bindexplib.h b/Source/bindexplib.h
index 1a0c3a3..d6900ba 100644
--- a/Source/bindexplib.h
+++ b/Source/bindexplib.h
@@ -5,8 +5,9 @@
 
 #include 
 
-#include "cmStandardIncludes.h"
-
+#include 
+#include 
+#include 
 
 class bindexplib
 {
diff --git a/Source/cmCallVisualStudioMacro.cxx 
b/Source/cmCallVisualStudioMacro.cxx
index a21a7d2..99fe587 100644
--- a/Source/cmCallVisualStudioMacro.cxx
+++ b/Source/cmCallVisualStudioMacro.cxx
@@ -2,6 +2,8 @@
file Copyright.txt or https://cmake.org/licensing for details.  */
 #include "cmCallVisualStudioMacro.h"
 
+#include 
+
 #include "cmSystemTools.h"
 
 #if defined(_MSC_VER)
diff --git a/Source/cmCallVisualStudioMacro.h b/Source/cmCallVisualStudioMacro.h
index 7ff4513..e9d34e5 100644
--- a/Source/cmCallVisualStudioMacro.h
+++ 

[Cmake-commits] CMake branch, next, updated. v3.7.0-1355-g70bd7d1

[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  70bd7d16c57b3929f06b7faa5141efd4e4b6c031 (commit)
   via  543dcb0ada5047d789a19dbbffa9028cb1b317c7 (commit)
  from  e442a1fcb60c15d270116bc45755217b47b40359 (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 -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=70bd7d16c57b3929f06b7faa5141efd4e4b6c031
commit 70bd7d16c57b3929f06b7faa5141efd4e4b6c031
Merge: e442a1f 543dcb0
Author: Brad King 
AuthorDate: Mon Nov 28 13:58:26 2016 -0500
Commit: CMake Topic Stage 
CommitDate: Mon Nov 28 13:58:26 2016 -0500

Merge topic '16449-revert-xcode-system-includes' into next

543dcb0a Revert "Xcode: Obey SYSTEM keyword for includes (#15687)"


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=543dcb0ada5047d789a19dbbffa9028cb1b317c7
commit 543dcb0ada5047d789a19dbbffa9028cb1b317c7
Author: Gregor Jasny 
AuthorDate: Wed Nov 23 18:19:54 2016 +0100
Commit: Brad King 
CommitDate: Mon Nov 28 13:42:46 2016 -0500

Revert "Xcode: Obey SYSTEM keyword for includes (#15687)"

Revert commit v3.7.0-rc1~266^2 (Xcode: Obey SYSTEM keyword for includes,
2015-08-31).  It worked for C, C++, and Swift but not for GNU Assembly
files for which Xcode has no property to set flags.

Closes: #16449

diff --git a/Source/cmGlobalXCodeGenerator.cxx 
b/Source/cmGlobalXCodeGenerator.cxx
index 4ff612d..537aa16 100644
--- a/Source/cmGlobalXCodeGenerator.cxx
+++ b/Source/cmGlobalXCodeGenerator.cxx
@@ -1894,40 +1894,24 @@ void 
cmGlobalXCodeGenerator::CreateBuildSettings(cmGeneratorTarget* gtgt,
 
   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");
 
-  if (this->XcodeVersion < 60) {
-std::vector includes;
-this->CurrentLocalGenerator->GetIncludeDirectories(includes, gtgt, "C",
-   configName);
-for (std::vector::iterator i = includes.begin();
- i != includes.end(); ++i) {
-  if (this->NameResolvesToFramework(*i)) {
-std::string frameworkDir = *i;
-frameworkDir += "/../";
-frameworkDir = cmSystemTools::CollapseFullPath(frameworkDir);
-if (emitted.insert(frameworkDir).second) {
-  fdirs.Add(this->XCodeEscapePath(frameworkDir));
-}
-  } else {
-std::string incpath = this->XCodeEscapePath(*i);
-dirs.Add(incpath);
-  }
-}
-  } else {
-for (std::set::iterator li = languages.begin();
- li != languages.end(); ++li) {
-  std::vector includes;
-  this->CurrentLocalGenerator->GetIncludeDirectories(includes, gtgt, *li,
- configName);
-  std::string includeFlags = this->CurrentLocalGenerator->GetIncludeFlags(
-includes, gtgt, *li, true, false, configName);
-
-  std::string& flags = cflags[*li];
-  if (!includeFlags.empty()) {
-flags += " " + includeFlags;
+  for (std::vector::iterator i = includes.begin();
+   i != includes.end(); ++i) {
+if (this->NameResolvesToFramework(*i)) {
+  std::string frameworkDir = *i;
+  frameworkDir += "/../";
+  frameworkDir = cmSystemTools::CollapseFullPath(frameworkDir);
+  if (emitted.insert(frameworkDir).second) {
+fdirs.Add(this->XCodeEscapePath(frameworkDir));
   }
+} else {
+  std::string incpath = this->XCodeEscapePath(*i);
+  dirs.Add(incpath);
 }
   }
   // Add framework search paths needed for linking.
diff --git a/Tests/IncludeDirectories/CMakeLists.txt 
b/Tests/IncludeDirectories/CMakeLists.txt
index db18462..4920582 100644
--- a/Tests/IncludeDirectories/CMakeLists.txt
+++ b/Tests/IncludeDirectories/CMakeLists.txt
@@ -3,9 +3,7 @@ project(IncludeDirectories)
 
 if (((CMAKE_C_COMPILER_ID STREQUAL GNU AND CMAKE_C_COMPILER_VERSION 
VERSION_GREATER 4.4)
 OR CMAKE_C_COMPILER_ID STREQUAL Clang OR CMAKE_C_COMPILER_ID STREQUAL 
AppleClang)
-AND (CMAKE_GENERATOR STREQUAL "Unix Makefiles"
-  OR CMAKE_GENERATOR STREQUAL "Ninja"
-  OR (CMAKE_GENERATOR STREQUAL "Xcode" AND NOT XCODE_VERSION VERSION_LESS 
6.0)))
+AND (CMAKE_GENERATOR STREQUAL "Unix Makefiles" OR CMAKE_GENERATOR STREQUAL 
"Ninja"))
   include(CheckCXXCompilerFlag)
   

Re: [CMake] Executing python though CMake and linking libraries

[Konstantin Tokarev]

28.11.2016, 21:53, "Matthew Woehlke" :
> On 2016-11-25 04:04, Kit Chambers wrote:
>>  I have a Cmake custom target which runs a python script:
>>
>>  add_custom_target(run
>>   COMMAND python myscript.py
>>    )
>>
>>  ...
>>
>>  To me it looks like my LD_LIBRARY_PATH and DYLD_LIBRARY_PATH are not being 
>> passed through CMake to Python so it cannot find all the necessary sub 
>> libraries. However, i cannot work out how to pass this information through.
>
> As written, your custom target will be run with whatever environment
> your build tool decides to use. *Probably* that will be the environment
> when you actually run the build tool (make, ninja, etc.), but it's
> possible some build too might monkey with the environment in which it
> runs build commands. Also, requiring people building your software to
> modify their local environment is probably not ideal.
>
> You probably want to wrap your custom target's command with
> `${CMAKE_COMMAND} -E env ...` to ensure it gets the necessary
> environment. (Also, you should probably use `${PYTHON_EXECUTABLE}`
> instead of `python`, and, similarly, note `${CMAKE_COMMAND}` instead of
> `cmake`.)
>
> (Personally, I wouldn't mind seeing CMake learn an `ENVIRONMENT` option
> to add_custom_command / add_custom_target that would set up this
> wrapping automatically.)

+1

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

-- 
Regards,
Konstantin
-- 

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] QtAutogen suggestions

[Brad King]

On 11/28/2016 10:25 AM, Sebastian Holtermann wrote:
> I'm going ahead then.

Thanks.  BTW, please sign up for a gitlab.kitware.com account
(optionally via GitHub OAuth) so that we can include you in
discussion of related issues.  For example:

* https://gitlab.kitware.com/cmake/cmake/issues/16460

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] QtAutogen suggestions

[Sebastian Holtermann]

Am 28.11.2016 um 15:57 schrieb Brad King:
> On 11/25/2016 05:37 PM, Sebastian Holtermann wrote:
>> There are some issues with QtAutogen that still bother me and
>> that I would like to change.
> 
> Great!  We currently have no dedicated maintainer for it and I have
> little understanding of the tools and use cases associated with it
> myself.  It will be useful to have your help.

Okay.

>> 1) Most files get generated in
>> ${CMAKE_CURRENT_BINARY_DIR}/${TARGETNAME}_automoc.dir
>>
>> Is the ".dir" suffix neccessary? I think is should be removed.
> 
> That suffix is the convention used for all intermediate files
> (e.g. object files) associated with a particular target of any kind.
> The _automoc targets are simply following that convention, but there
> is no strong reason this has to be the case for the generated sources.

Okay, I'm going to remove it then in this place.
It is easier to read IMO.

>> 2) Moc files that are manually included by a
>> #include "moc_.cpp"
>> statement get generated in ${CMAKE_CURRENT_BINARY_DIR}
>>
>> A better solution would be to generate the moc_.cpp files in
>> ${CMAKE_CURRENT_BINARY_DIR}/${TARGETNAME}_automoc/include.
>> AUTOMOC then should automatically add that directory to the
>> INCLUDE_DIRECTORIES of the origin target.
> 
> Yes, I think that has been discussed before but no one ever implemented it.
> 
>> 3) The mocs compilation file currently gets generated as
>> ${CMAKE_CURRENT_BINARY_DIR}/${TARGETNAME}_automoc.cpp
>>
>> The file could be generated as
>> ${CMAKE_CURRENT_BINARY_DIR}/${TARGETNAME}_automoc/compilation.cpp
> 
> Okay.
> 
>> 4) AUTOMOC AUTOUIC and AUTORCC perform different independent tasks that
>> in the current implementation get processed serially inside a single
>> custom target named ${TARGETNAME}_automoc.
>>
>> I think each of the three could be handled in an own target.
> 
> In VS IDE and Xcode each target becomes another user-visible entity so
> we try to keep generated targets to a minimum.  IIRC in some cases we
> even try to use a PRE_BUILD step in the VS targets to avoid an extra
> target altogether.  The breakdown could be made generator-specific
> to improve behavior on Ninja and Makefile generators.  In the case that
> a common target is needed it could be renamed to `_autogen` instead.

For VS tries to use PRE_BUILD when possible for all other generators
a custom target is used. I took that from the source but I'm not
familiar with VS and can't test any changes.
It safer to leave this the way is is for now.

I'm going ahead then.

-Sebastian


-- 

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] Executing python though CMake and linking libraries

[Matthew Woehlke]

On 2016-11-25 04:04, Kit Chambers wrote:
> I have a Cmake custom target which runs a python script:
> 
> add_custom_target(run
>  COMMAND python myscript.py
>   ) 
> 
> ...
> 
> To me it looks like my LD_LIBRARY_PATH and DYLD_LIBRARY_PATH are not being 
> passed through CMake to Python so it cannot find all the necessary sub 
> libraries. However, i cannot work out how to pass this information through.

As written, your custom target will be run with whatever environment
your build tool decides to use. *Probably* that will be the environment
when you actually run the build tool (make, ninja, etc.), but it's
possible some build too might monkey with the environment in which it
runs build commands. Also, requiring people building your software to
modify their local environment is probably not ideal.

You probably want to wrap your custom target's command with
`${CMAKE_COMMAND} -E env ...` to ensure it gets the necessary
environment. (Also, you should probably use `${PYTHON_EXECUTABLE}`
instead of `python`, and, similarly, note `${CMAKE_COMMAND}` instead of
`cmake`.)

(Personally, I wouldn't mind seeing CMake learn an `ENVIRONMENT` option
to add_custom_command / add_custom_target that would set up this
wrapping automatically.)

-- 
Matthew

-- 

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] FindMPI

[Chuck Atkins]

Hi Zaak,

Sorry for the first mail being so abrupt, I didn't mean to hit "send" so
soon.



> I took a look at the FindMPI CMake module, and it seems as though you can
> set MPI_HOME to a list of directories to search.
>

That's also another way of doing it, which would probably be easier than
what I iniitially suggested; the former has just become my own habbit since
MPI_HOME isn't always set.  MPI_HOME is used as a hint to search for
mpiexec.  If mpiexec is found, it then uses it's location as a basis for
locating the compiler wrappers.

That being said, if using MPI through an environment module (as is the
typical use case) then FindMPI should "just work" as the wrappers generally
end up in the path when the appropriate MPI module is loaded.  If you need
to point to an entirely external MPI not part of your environment at all
though, then using the MPI_HOME env var or MPI__COMPILER CMake vars
is the way to do it.



> Would KitWare accept a pull request or a patch that expands the
> documentation of FindMPI
>

Of course :-).  Expanding the "Usage" section in FindMPI to include using
the MPI_HOME environment variable would be a good place for that.



> and/or adds some clearer additional features to the call signature (like
> HINTS and PATHS)?
>

Could you clarify what you mean by this?  To which call signature?


- Chuck
-- 

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] QtAutogen suggestions

[Brad King]

On 11/25/2016 05:37 PM, Sebastian Holtermann wrote:
> There are some issues with QtAutogen that still bother me and
> that I would like to change.

Great!  We currently have no dedicated maintainer for it and I have
little understanding of the tools and use cases associated with it
myself.  It will be useful to have your help.

> 1) Most files get generated in
> ${CMAKE_CURRENT_BINARY_DIR}/${TARGETNAME}_automoc.dir
> 
> Is the ".dir" suffix neccessary? I think is should be removed.

That suffix is the convention used for all intermediate files
(e.g. object files) associated with a particular target of any kind.
The _automoc targets are simply following that convention, but there
is no strong reason this has to be the case for the generated sources.

> 2) Moc files that are manually included by a
> #include "moc_.cpp"
> statement get generated in ${CMAKE_CURRENT_BINARY_DIR}
> 
> A better solution would be to generate the moc_.cpp files in
> ${CMAKE_CURRENT_BINARY_DIR}/${TARGETNAME}_automoc/include.
> AUTOMOC then should automatically add that directory to the
> INCLUDE_DIRECTORIES of the origin target.

Yes, I think that has been discussed before but no one ever implemented it.

> 3) The mocs compilation file currently gets generated as
> ${CMAKE_CURRENT_BINARY_DIR}/${TARGETNAME}_automoc.cpp
> 
> The file could be generated as
> ${CMAKE_CURRENT_BINARY_DIR}/${TARGETNAME}_automoc/compilation.cpp

Okay.

> 4) AUTOMOC AUTOUIC and AUTORCC perform different independent tasks that
> in the current implementation get processed serially inside a single
> custom target named ${TARGETNAME}_automoc.
> 
> I think each of the three could be handled in an own target.

In VS IDE and Xcode each target becomes another user-visible entity so
we try to keep generated targets to a minimum.  IIRC in some cases we
even try to use a PRE_BUILD step in the VS targets to avoid an extra
target altogether.  The breakdown could be made generator-specific
to improve behavior on Ninja and Makefile generators.  In the case that
a common target is needed it could be renamed to `_autogen` instead.

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] FindMPI

[Zaak Beekman]

Thanks for the additional pointers Chuck! I am aware that it is preferred
practice to pass the actual compilers rather than the wrappers as FC etc.
but per Brad's advice I think Damian had setup the OpenCoarrays CMake build
system to accept FC=mpif90 etc. and I'm in the process of migrating to the
more normal FC=gfortran etc. approach but I don't want users who use the
old method to get caught out. I'll try setting MPI_{C,etc.}_COMPILER
(rather than MPI_HOME) before calling `find_package(MPI)` and see if that
works as well as setting MPI_HOME does.

Thanks for the tips!

On Mon, Nov 28, 2016 at 10:02 AM Chuck Atkins 
wrote:

> Hi Zaak,
>
> When using CMake, it's generally best to use the actual compiler rather
> than any compiler wrappers (with Cray being the exception).  Given that,
> set the CC, CXX, and FC environment variables to the actual compilers you
> want to use and then the MPI_{C,CXX,Fortan}_COMPILER CMake variables the
> MPI wrappers.  FindMPI will then interrogate the MPI wrappers to extract
> the appropriate include and link options.
>
> --
> Chuck Atkins
> Staff R Engineer, Scientific Computing
> Kitware, Inc.
>
>
> On Mon, Nov 28, 2016 at 9:58 AM, Chuck Atkins 
> wrote:
>
> Pass the following CMake options at configure time:
>
> -DMPI_C_COMPILER=/path/to/mpicc
> -DMPI_CXX_COMPILER=/path/to/mpiCC
> -DMPI_Fortran_COMPILER=/path/to/mpif90
>
> --
> Chuck Atkins
> Staff R Engineer, Scientific Computing
> Kitware, Inc.
>
>
> On Wed, Nov 23, 2016 at 6:05 PM, Zaak Beekman  wrote:
>
> Hi,
>
> I want to be able to pass FC=mpif90 (or FC=$(which mpif90)) and CC=mpicc
> etc. OR also be able to pass a compiler and use FindMPI to add link,
> compile and include flags. I'm encountering an issue when my MPI
> implementation is not on my PATH, I want CMake to be able to look in an
> additional location (our build script can download and build MPICH and by
> default installs it in user space) and also resolve where mpif90 is coming
> from and look there too.
>
> Whats the correct way to pass HINTS or PATHS to FindMPI? i.e., how do I
> specify additional locations to search?
>
> Using `find_package` with HINTS and PATHS means that it doesn't use
> FindMPI. I also tried setting CMAKE_SYSTEM PREFIX_PATH, but I think that's
> a cache variable set early, so it's not having an effect.
>
> It would be great if FindMPI used the realpath of mpif90 etc when passed
> as $FC.
>
> TIA
>
> --
>
> 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] FindMPI

[Chuck Atkins]

Hi Zaak,

When using CMake, it's generally best to use the actual compiler rather
than any compiler wrappers (with Cray being the exception).  Given that,
set the CC, CXX, and FC environment variables to the actual compilers you
want to use and then the MPI_{C,CXX,Fortan}_COMPILER CMake variables the
MPI wrappers.  FindMPI will then interrogate the MPI wrappers to extract
the appropriate include and link options.

--
Chuck Atkins
Staff R Engineer, Scientific Computing
Kitware, Inc.


On Mon, Nov 28, 2016 at 9:58 AM, Chuck Atkins 
wrote:

> Pass the following CMake options at configure time:
>
> -DMPI_C_COMPILER=/path/to/mpicc
> -DMPI_CXX_COMPILER=/path/to/mpiCC
> -DMPI_Fortran_COMPILER=/path/to/mpif90
>
> --
> Chuck Atkins
> Staff R Engineer, Scientific Computing
> Kitware, Inc.
>
>
> On Wed, Nov 23, 2016 at 6:05 PM, Zaak Beekman  wrote:
>
>> Hi,
>>
>> I want to be able to pass FC=mpif90 (or FC=$(which mpif90)) and CC=mpicc
>> etc. OR also be able to pass a compiler and use FindMPI to add link,
>> compile and include flags. I'm encountering an issue when my MPI
>> implementation is not on my PATH, I want CMake to be able to look in an
>> additional location (our build script can download and build MPICH and by
>> default installs it in user space) and also resolve where mpif90 is coming
>> from and look there too.
>>
>> Whats the correct way to pass HINTS or PATHS to FindMPI? i.e., how do I
>> specify additional locations to search?
>>
>> Using `find_package` with HINTS and PATHS means that it doesn't use
>> FindMPI. I also tried setting CMAKE_SYSTEM PREFIX_PATH, but I think that's
>> a cache variable set early, so it's not having an effect.
>>
>> It would be great if FindMPI used the realpath of mpif90 etc when passed
>> as $FC.
>>
>> TIA
>>
>> --
>>
>> 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] C++11/C++14 doesn't work in check_cxx_source_compiles

[Brad King]

On 11/24/2016 01:43 PM, Roman Wüger wrote:
> Shouldn't this be done by CMAKE_CXX_STANDARD?

Yes, this is a known problem with try_compile.  It needs to learn to honor
the CMAKE__STANDARD.  CMake itself works around this problem in some
cases, e.g.

* 
https://gitlab.kitware.com/cmake/cmake/blob/v3.7.0/Source/Checks/cm_cxx14_cstdio.cmake#L8

Here is a new issue for this:

* https://gitlab.kitware.com/cmake/cmake/issues/16456

-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] [cmake-developers] C++11/C++14 doesn't work in check_cxx_source_compiles

[Brad King]

On 11/24/2016 01:43 PM, Roman Wüger wrote:
> Shouldn't this be done by CMAKE_CXX_STANDARD?

Yes, this is a known problem with try_compile.  It needs to learn to honor
the CMAKE__STANDARD.  CMake itself works around this problem in some
cases, e.g.

* 
https://gitlab.kitware.com/cmake/cmake/blob/v3.7.0/Source/Checks/cm_cxx14_cstdio.cmake#L8

Here is a new issue for this:

* https://gitlab.kitware.com/cmake/cmake/issues/16456

-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

Re: [CMake] FindMPI

[Chuck Atkins]

Pass the following CMake options at configure time:

-DMPI_C_COMPILER=/path/to/mpicc
-DMPI_CXX_COMPILER=/path/to/mpiCC
-DMPI_Fortran_COMPILER=/path/to/mpif90

--
Chuck Atkins
Staff R Engineer, Scientific Computing
Kitware, Inc.


On Wed, Nov 23, 2016 at 6:05 PM, Zaak Beekman  wrote:

> Hi,
>
> I want to be able to pass FC=mpif90 (or FC=$(which mpif90)) and CC=mpicc
> etc. OR also be able to pass a compiler and use FindMPI to add link,
> compile and include flags. I'm encountering an issue when my MPI
> implementation is not on my PATH, I want CMake to be able to look in an
> additional location (our build script can download and build MPICH and by
> default installs it in user space) and also resolve where mpif90 is coming
> from and look there too.
>
> Whats the correct way to pass HINTS or PATHS to FindMPI? i.e., how do I
> specify additional locations to search?
>
> Using `find_package` with HINTS and PATHS means that it doesn't use
> FindMPI. I also tried setting CMAKE_SYSTEM PREFIX_PATH, but I think that's
> a cache variable set early, so it's not having an effect.
>
> It would be great if FindMPI used the realpath of mpif90 etc when passed
> as $FC.
>
> TIA
>
> --
>
> 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] FindMPI

[Zaak Beekman]

Chuck, thanks for the response!

The issue with your technique is that I don't want to put the burden on the
users...

I took a look at the FindMPI CMake module, and it seems as though you can
set MPI_HOME to a list of directories to search.

Would KitWare accept a pull request or a patch that expands the
documentation of FindMPI and/or adds some clearer additional features to
the call signature (like HINTS and PATHS)?

Thanks,
-Zaak

On Mon, Nov 28, 2016 at 9:58 AM Chuck Atkins 
wrote:

> Pass the following CMake options at configure time:
>
> -DMPI_C_COMPILER=/path/to/mpicc
> -DMPI_CXX_COMPILER=/path/to/mpiCC
> -DMPI_Fortran_COMPILER=/path/to/mpif90
>
> --
> Chuck Atkins
> Staff R Engineer, Scientific Computing
> Kitware, Inc.
>
>
> On Wed, Nov 23, 2016 at 6:05 PM, Zaak Beekman  wrote:
>
> Hi,
>
> I want to be able to pass FC=mpif90 (or FC=$(which mpif90)) and CC=mpicc
> etc. OR also be able to pass a compiler and use FindMPI to add link,
> compile and include flags. I'm encountering an issue when my MPI
> implementation is not on my PATH, I want CMake to be able to look in an
> additional location (our build script can download and build MPICH and by
> default installs it in user space) and also resolve where mpif90 is coming
> from and look there too.
>
> Whats the correct way to pass HINTS or PATHS to FindMPI? i.e., how do I
> specify additional locations to search?
>
> Using `find_package` with HINTS and PATHS means that it doesn't use
> FindMPI. I also tried setting CMAKE_SYSTEM PREFIX_PATH, but I think that's
> a cache variable set early, so it's not having an effect.
>
> It would be great if FindMPI used the realpath of mpif90 etc when passed
> as $FC.
>
> TIA
>
> --
>
> 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] Fwd: cmVisualStudio10TargetGenerator should not generate a rule for an ImportLibrary for executables

[Brad King]

On 11/28/2016 09:16 AM, Daniel Pfeifer wrote:
> On Mon, Nov 28, 2016 at 2:41 PM, Lode Leroy wrote:
>> The problem is that when a project contains a FOO.DLL and a FOO.EXE,
>> the cmake generator tries to build FOO.LIB for both.
>> The FOO.EXE does not need a FOO.LIB.
> Please see https://cmake.org/cmake/help/v3.7/prop_tgt/ENABLE_EXPORTS.html

Correct.  The `ImportLibrary` setting in a `.vcxproj` file only tells
the tools where to put the `.lib` file *if* there are exports.  No file
will be generated unless the project code is using `dllexport` or other
means to export a symbol from the executable.  To prevent one from showing
up, check the project code to make sure it doesn't try to export something.

-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] Fwd: cmVisualStudio10TargetGenerator should not generate a rule for an ImportLibrary for executables

[Daniel Pfeifer]

On Mon, Nov 28, 2016 at 2:41 PM, Lode Leroy  wrote:

> Please consider the following patch for inclusion in cmake.
>
> The problem is that when a project contains a FOO.DLL and a FOO.EXE,
> the cmake generator tries to build FOO.LIB for both.
> The FOO.EXE does not need a FOO.LIB.
>
> $ diff -urp CMake-3.7.0-orig/ CMake-3.7.0
> Only in CMake-3.7.0: build
> diff -urp CMake-3.7.0-orig/Source/cmVisualStudio10TargetGenerator.cxx
> CMake-3.7.0/Source/cmVisualStudio10TargetGenerator.cxx
> --- CMake-3.7.0-orig/Source/cmVisualStudio10TargetGenerator.cxx
> 2016-11-11 15:24:18.0 +0100
> +++ CMake-3.7.0/Source/cmVisualStudio10TargetGenerator.cxx
> 2016-11-28 14:28:26.344898900 +0100
> @@ -2310,7 +2310,9 @@ bool cmVisualStudio10TargetGenerator::Co
>  imLib += "/";
>  imLib += targetNameImport;
>
> -linkOptions.AddFlag("ImportLibrary", imLib.c_str());
> +if (this->GeneratorTarget->GetType() != cmState::EXECUTABLE) {
> +linkOptions.AddFlag("ImportLibrary", imLib.c_str());
> +}
>  linkOptions.AddFlag("ProgramDataBaseFile", pdb.c_str());
>
>  // A Windows Runtime component uses internal .NET metadata,
> --
>
>
I am no windows expert, but I think the import library is required when you
want to link against the executable.
Please see https://cmake.org/cmake/help/v3.7/prop_tgt/ENABLE_EXPORTS.html
-- 

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] Questions about C++ version and third party libraries

[Daniel Pfeifer]

On Sat, Nov 26, 2016 at 11:17 AM, mateusz janek 
wrote:

> Hello CMake community,
>
> First of all, I want to say "Hello" to everyone, I am new to the CMake
> developers community.
>

Hello and welcome!


> I have some questions about developing rules, before I'll start to write
> the code:
> -In which version of C++ is CMake written?
>

CMake can still be built with Visual Studio 2008. It is mostly written in
C++98 but built with C++14 where possible. We use some abstractions like
CM_NULLPTR or CM_OVERRIDE. The parts for the language server are written in
C++14.

-Am I right that it is forbidden to use third party libraries?
>

CMake uses several third party libraries. Have a look at the Utilities
directory.
-- 

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] QtSDK integration

[Konstantin Podsvirov]

Hello all!Anybody known where Brad King?Or anybody can help me to review and merge !280, !281 and !282 MRs into 'next' for testing?7:04, 17 november 2016 г., Konstantin Podsvirov :Hi, dear CMake developers! Some of us actively using the Qt technology, but remain fans of CMake. I had the idea to extend the CMake part of the QtSDK. I created proposals for appropriate changes in QtCreator: https://bugreports.qt.io/browse/QTCREATORBUG-17290 It also requires improvements in the CMake. I'm working on it here: http://git.podsvirov.pro/?p=kitware/cmake.git;a=shortlog;h=refs/heads/topic-cpack-ifw-options and here: http://git.podsvirov.pro/?p=kitware/cmake.git;a=shortlog;h=refs/heads/topic-cmake-ifw-root-component Demo repository for Windows: http://download.podsvirov.pro/online/qtsdkrepository/windows_x86/desktop/tools_cmake You can add this repository in Qt Maintenance Tool and try to install CMake as part of the QtSDK, but now QtSDK (QtCreator) does not recognize this installation automatically. How do you like this idea? What has to be installed in this case? (tools, cmake-gui?, docs?...) I'm waiting feedback from support or a reasoned rejection of this idea. --Regards,Konstantin Podsvirov -- Powered by www.kitware.comPlease keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQKitware offers various services to support the CMake community. For more information on each offering, please visit:CMake Support: http://cmake.org/cmake/help/support.htmlCMake Consulting: http://cmake.org/cmake/help/consulting.htmlCMake Training Courses: http://cmake.org/cmake/help/training.htmlVisit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.htmlFollow this link to subscribe/unsubscribe:http://public.kitware.com/mailman/listinfo/cmake-developersОтправлено из мобильной Яндекс.Почты: http://m.ya.ru/ymail
-- 

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] Fwd: cmVisualStudio10TargetGenerator should not generate a rule for an ImportLibrary for executables

[Lode Leroy]

Please consider the following patch for inclusion in cmake.

The problem is that when a project contains a FOO.DLL and a FOO.EXE,
the cmake generator tries to build FOO.LIB for both.
The FOO.EXE does not need a FOO.LIB.

$ diff -urp CMake-3.7.0-orig/ CMake-3.7.0
Only in CMake-3.7.0: build
diff -urp CMake-3.7.0-orig/Source/cmVisualStudio10TargetGenerator.cxx
CMake-3.7.0/Source/cmVisualStudio10TargetGenerator.cxx
--- CMake-3.7.0-orig/Source/cmVisualStudio10TargetGenerator.cxx
2016-11-11 15:24:18.0 +0100
+++ CMake-3.7.0/Source/cmVisualStudio10TargetGenerator.cxx
2016-11-28 14:28:26.344898900 +0100
@@ -2310,7 +2310,9 @@ bool cmVisualStudio10TargetGenerator::Co
 imLib += "/";
 imLib += targetNameImport;

-linkOptions.AddFlag("ImportLibrary", imLib.c_str());
+if (this->GeneratorTarget->GetType() != cmState::EXECUTABLE) {
+linkOptions.AddFlag("ImportLibrary", imLib.c_str());
+}
 linkOptions.AddFlag("ProgramDataBaseFile", pdb.c_str());

 // A Windows Runtime component uses internal .NET metadata,
-- 

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] Executing python though CMake and linking libraries

[Kit Chambers]

I just got this working, so am posting to the list in case this helps someone 
else in the future. Essentially you invoke the python script through CMakes -E 
command and specify your library paths so it picks up all your shared 
libraries. Something like:

add_custom_target(run
   COMMAND cmake "-E" "env"  “LD_LIBRARY_PATH=/your/library/path 
DYLD_LIBRARY_PATH=/library/path/for/mac/" “python” “./myscript.py”
WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
) 

However, I will be the first to admit this is not a particularly elegant 
solution so I would be interested to here if anyone out there has a better way 
of getting invoked commands to pick up the environment paths correctly.

Kit




> On 25 Nov 2016, at 13:23, tonka3...@gmail.com wrote:
> 
> Hey,
> 
> I think your actual working directory is wrong. I would recommend to use 
> absolute paths for the python interperter (there is a find_package module for 
> the interpreter) and maybe also for your script. The custom command support a 
> workingdirectory variable as far as i know.
> 
> Hope that help you.
> 
> Greetings
> Tonka
> 
>> Am 25.11.2016 um 10:04 schrieb Kit Chambers :
>> 
>> I have a Cmake custom target which runs a python script:
>> 
>> add_custom_target(run
>>COMMAND python myscript.py
>> ) 
>> 
>> And the script myscript.py imports a Compiled library 
>> 
>> import myproj.mylilb
>> 
>> where mylib is actually a C++ library generated with python bindings (using 
>> vtkPython). This intern links against some other C++ libraries I use etc.
>> 
>> 
>> When I run the script normally from the command line everything works fine, 
>> but if I try to run the target I get linker errors.
>> 
>> $ make run
>> 
>> Traceback (most recent call last):
>> File "myscript.py", line 8, in 
>>  import myproj.mylilb
>> ImportError: 
>> dlopen(/Users/kitchambers/Applications/ogFramework/lib/python2.7/site-packages/myproj/mylib.so,
>>  2): Library not loaded: libSpProcSupport.so
>> Referenced from: 
>> /Users/kitchambers/Applications/ogFramework/lib/python2.7/site-packages/myproj/mylib.so
>> Reason: image not found
>> 
>> To me it looks like my LD_LIBRARY_PATH and DYLD_LIBRARY_PATH are not being 
>> passed through CMake to Python so it cannot find all the necessary sub 
>> libraries. However, i cannot work out how to pass this information through.
>> 
>> Any help would be greatly appreciated.
>> 
>> Cheers
>> 
>> Kit
>> -- 
>> 
>> 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