[Cmake-commits] CMake branch, master, updated. v3.1.2-1073-gd46e1e3
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 d46e1e3f0fa386638b5a50b45783f4ec4d94bf2c (commit) via 0b8d9581c0a651f36fc5a2d0b996fd006152ce50 (commit) via 52340b904d2eed7f5f337c255486017626b01593 (commit) via 8772420e2ff1da38903162ce8e9335edbe1c3dcd (commit) via e1ce81a2cb66c70d806adf755d9ee273687ca962 (commit) from eb8acf85d0e49c8b5f5e291cab043028dd979fac (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 - --- Summary of changes: hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, release, updated. v3.1.2-1022-g0b8d958
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, release has been updated
via 0b8d9581c0a651f36fc5a2d0b996fd006152ce50 (commit)
via 3d99355b11b2509f4e16ddfd71373538410364e7 (commit)
via 8772420e2ff1da38903162ce8e9335edbe1c3dcd (commit)
via 0f870234febd9dba0df78e903b412ea19d681062 (commit)
via cd408d93fdf347ff63a8062f75f1f4ee3e898b17 (commit)
via 87be2e1427ba2b1b7697c9332487862917897dca (commit)
from cb01f1517051b577d571e8fd21d210ef303f56c9 (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 -
---
Summary of changes:
Modules/CPackRPM.cmake |2 +-
Source/CMakeLists.txt |1 +
Source/CPack/cpack.cxx |2 --
Source/CursesDialog/ccmake.cxx |3 ---
Source/cmArchiveWrite.cxx |4
Source/{cmCurl.h = cmLocale.h}| 22 --
Source/cmSystemTools.cxx |3 +++
Source/cmakemain.cxx |2 --
Source/ctest.cxx |3 ---
Tests/CMakeLib/PseudoMemcheck/memtester.cxx.in |2 --
10 files changed, 25 insertions(+), 19 deletions(-)
copy Source/{cmCurl.h = cmLocale.h} (67%)
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.1.2-1163-gf69ce95
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 f69ce957afe5631e73f2130c725474e651813623 (commit) via d46e1e3f0fa386638b5a50b45783f4ec4d94bf2c (commit) via 0b8d9581c0a651f36fc5a2d0b996fd006152ce50 (commit) via 52340b904d2eed7f5f337c255486017626b01593 (commit) via 8772420e2ff1da38903162ce8e9335edbe1c3dcd (commit) via e1ce81a2cb66c70d806adf755d9ee273687ca962 (commit) from c2edefc15ec1f2c13c64ac0b999caf1fd23f029f (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f69ce957afe5631e73f2130c725474e651813623 commit f69ce957afe5631e73f2130c725474e651813623 Merge: c2edefc d46e1e3 Author: Brad King brad.k...@kitware.com AuthorDate: Tue Feb 10 09:48:23 2015 -0500 Commit: Brad King brad.k...@kitware.com CommitDate: Tue Feb 10 09:48:23 2015 -0500 Merge branch 'master' into next --- Summary of changes: hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v3.1.2-1157-gc2edefc
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 c2edefc15ec1f2c13c64ac0b999caf1fd23f029f (commit) via eb8acf85d0e49c8b5f5e291cab043028dd979fac (commit) from 4267f43d15cd42040773c620781ab8f7926f343b (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c2edefc15ec1f2c13c64ac0b999caf1fd23f029f commit c2edefc15ec1f2c13c64ac0b999caf1fd23f029f Merge: 4267f43 eb8acf8 Author: Brad King brad.k...@kitware.com AuthorDate: Tue Feb 10 09:42:50 2015 -0500 Commit: Brad King brad.k...@kitware.com CommitDate: Tue Feb 10 09:42:50 2015 -0500 Merge branch 'master' into next --- Summary of changes: hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v3.1.2-1068-geb8acf8
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 eb8acf85d0e49c8b5f5e291cab043028dd979fac (commit) via 3d99355b11b2509f4e16ddfd71373538410364e7 (commit) from e2619c13f727504b7368e0bf156c17112ee81568 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=eb8acf85d0e49c8b5f5e291cab043028dd979fac commit eb8acf85d0e49c8b5f5e291cab043028dd979fac Merge: e2619c1 3d99355 Author: Brad King brad.k...@kitware.com AuthorDate: Tue Feb 10 09:42:21 2015 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Tue Feb 10 09:42:21 2015 -0500 Merge topic 'cpack_rpm_mulit_prefix_fixup' 3d99355b CPackRPM: Fix recognition of absolute relocation paths --- Summary of changes: Modules/CPackRPM.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, next, updated. v3.1.2-1169-g5367c0e
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 5367c0e4781644a33ce9163666a626e50efffa2c (commit) via 2fd44b082b0a8e546c73d921f9d8264a668c3b78 (commit) from 0f422f38cb7532af36b6d0a080dcf5ef4ff77748 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5367c0e4781644a33ce9163666a626e50efffa2c commit 5367c0e4781644a33ce9163666a626e50efffa2c Merge: 0f422f3 2fd44b0 Author: Brad King brad.k...@kitware.com AuthorDate: Tue Feb 10 10:10:02 2015 -0500 Commit: Brad King brad.k...@kitware.com CommitDate: Tue Feb 10 10:10:02 2015 -0500 Merge branch 'master' into next --- Summary of changes: hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v3.1.2-1167-g0f422f3
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 0f422f38cb7532af36b6d0a080dcf5ef4ff77748 (commit)
via 85fd62ee91b7a8dcb929eee36424886bd0b59592 (commit)
from 5b19ac52bb4db11dd932c2f522cdda25a19a2ba3 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0f422f38cb7532af36b6d0a080dcf5ef4ff77748
commit 0f422f38cb7532af36b6d0a080dcf5ef4ff77748
Merge: 5b19ac5 85fd62e
Author: Brad King brad.k...@kitware.com
AuthorDate: Tue Feb 10 10:07:28 2015 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue Feb 10 10:07:28 2015 -0500
Merge topic 'bootstrap-sphinx-qthelp' into next
85fd62ee bootstrap: Add --sphinx-qthelp option to enable qthelp doc
generation
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=85fd62ee91b7a8dcb929eee36424886bd0b59592
commit 85fd62ee91b7a8dcb929eee36424886bd0b59592
Author: Nuno Sucena Almeida n...@aeminium.org
AuthorDate: Sat Feb 7 17:23:28 2015 -0500
Commit: Brad King brad.k...@kitware.com
CommitDate: Tue Feb 10 10:03:10 2015 -0500
bootstrap: Add --sphinx-qthelp option to enable qthelp doc generation
diff --git a/bootstrap b/bootstrap
index a88eb6a..e7d0496 100755
--- a/bootstrap
+++ b/bootstrap
@@ -72,6 +72,7 @@ cmake_bootstrap_qt_gui=
cmake_bootstrap_qt_qmake=
cmake_sphinx_man=
cmake_sphinx_html=
+cmake_sphinx_qthelp=
cmake_sphinx_build=
# Determine whether this is a Cygwin environment.
@@ -410,6 +411,7 @@ Configuration:
--sphinx-manbuild man pages with Sphinx
--sphinx-html build html help with Sphinx
+ --sphinx-qthelp build qch help with Sphinx
--sphinx-build=sb use sb as the sphinx-build executable
Directory and file names:
@@ -646,6 +648,7 @@ while test $# != 0; do
--qt-qmake=*) cmake_bootstrap_qt_qmake=`cmake_arg $1` ;;
--sphinx-man) cmake_sphinx_man=1 ;;
--sphinx-html) cmake_sphinx_html=1 ;;
+ --sphinx-qthelp) cmake_sphinx_qthelp=1 ;;
--sphinx-build=*) cmake_sphinx_build=`cmake_arg $1` ;;
--help) cmake_usage ;;
--version) cmake_version_display ; exit 2 ;;
@@ -1661,6 +1664,11 @@ if [ x${cmake_sphinx_html} != x ]; then
set (SPHINX_HTML '${cmake_sphinx_html}' CACHE FILEPATH Build html help
with Sphinx FORCE)
' ${cmake_bootstrap_dir}/InitialCacheFlags.cmake
fi
+if [ x${cmake_sphinx_qthelp} != x ]; then
+ echo '
+set (SPHINX_QTHELP '${cmake_sphinx_qthelp}' CACHE FILEPATH Build qch help
with Sphinx FORCE)
+' ${cmake_bootstrap_dir}/InitialCacheFlags.cmake
+fi
if [ x${cmake_sphinx_build} != x ]; then
echo '
set (SPHINX_EXECUTABLE '${cmake_sphinx_build}' CACHE FILEPATH Location of
Qt sphinx-build FORCE)
---
Summary of changes:
bootstrap |8
1 file changed, 8 insertions(+)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits
Re: [cmake-developers] Fwd: [ANNOUNCE] CMake 3.1.2 Released
On 02/10/2015 07:56 AM, Robert Maynard wrote: So we can safely presume that the new features listed at https://gcc.gnu.org/gcc-5/changes.html will be the what gcc 5.0 will ship with? That's how I read things. On Mon, Feb 9, 2015 at 11:18 PM, Orion Poplawski or...@cora.nwra.com wrote: On 02/09/2015 11:08 AM, Ben Boeckel wrote: On Mon, Feb 09, 2015 at 11:09:32 -0500, Robert Maynard wrote: We are pleased to announce that CMake 3.1.2 is now available for download. I'm getting this now building cmake 3.1.2 for Fedora Rawhide with gcc 5.0.0: 32: Detecting CXX compile features - done 32: Testing feature : cxx_aggregate_default_initializers 32: Configuring 32: CMake Error at CMakeLists.txt:70 (message): 32: Feature cxx_aggregate_default_initializers expected not to work for CXX 32: GNU-5.0.0. 32: 32: Update the supported features or blacklist it. 32: Testing feature : cxx_relaxed_constexpr 32: Configuring 32: CMake Error at CMakeLists.txt:70 (message): 32: Feature cxx_relaxed_constexpr expected not to work for CXX GNU-5.0.0. 32: 32: Update the supported features or blacklist it. 32: Testing feature : cxx_variable_templates 32: Configuring 32: CMake Error at CMakeLists.txt:70 (message): 32: Feature cxx_variable_templates expected not to work for CXX GNU-5.0.0. 32: 32: Update the supported features or blacklist it. Yeah, the feature tables will need to be updated. I use Rawhide at home (was going to send an email about the tests as well) and was going to look at updating it there. However, it is still a pre-release build of GCC5, so we should probably just hold off on pushing something into master until an official release is made. --Ben According to https://fedoraproject.org/wiki/Changes/GCC5#Detailed_Description : GCC 5 is currently in stage4 - prerelease state with only regression bugfixes and documentation fixes allowed. So I think it's reasonable time to start adapting to it. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.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-developers
Re: [cmake-developers] BundleUtilities check exit code
On 02/09/2015 12:17 PM, Ruslan Baratov via cmake-developers wrote: This patch let do the check that exit code is 0, i.e. install_name_tool exits successfully. Applied with minor refactoring: BundleUtilities: Teach fixup_bundle to check install_name_tool result http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a27c13f4 Please verify that this version of the change still works for you. 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-commits] CMake branch, next, updated. v3.1.2-1173-gfa1af50
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 fa1af50e9bbe0506da14019b82cbc86fd1333e02 (commit)
via a27c13f4cad2247833d048ec5e334861943fd4d9 (commit)
from a06bd9fdc9c2ac5a921f6836454fc13c7523d060 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fa1af50e9bbe0506da14019b82cbc86fd1333e02
commit fa1af50e9bbe0506da14019b82cbc86fd1333e02
Merge: a06bd9f a27c13f
Author: Brad King brad.k...@kitware.com
AuthorDate: Tue Feb 10 11:00:39 2015 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue Feb 10 11:00:39 2015 -0500
Merge topic 'BundleUtilities-install_name_tool-exit' into next
a27c13f4 BundleUtilities: Teach fixup_bundle to check install_name_tool
result
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a27c13f4cad2247833d048ec5e334861943fd4d9
commit a27c13f4cad2247833d048ec5e334861943fd4d9
Author: Ruslan Baratov ruslan_bara...@yahoo.com
AuthorDate: Mon Feb 9 20:09:41 2015 +0300
Commit: Brad King brad.k...@kitware.com
CommitDate: Tue Feb 10 11:00:27 2015 -0500
BundleUtilities: Teach fixup_bundle to check install_name_tool result
Fail explicitly if install_name_tool fails to make an update we need.
diff --git a/Modules/BundleUtilities.cmake b/Modules/BundleUtilities.cmake
index fee0a7c..ce90f30 100644
--- a/Modules/BundleUtilities.cmake
+++ b/Modules/BundleUtilities.cmake
@@ -776,7 +776,12 @@ function(fixup_bundle_item resolved_embedded_item exepath
dirs)
# to install_name_tool:
#
if(changes)
-execute_process(COMMAND install_name_tool ${changes}
${resolved_embedded_item})
+set(cmd install_name_tool ${changes} ${resolved_embedded_item})
+execute_process(COMMAND ${cmd} RESULT_VARIABLE install_name_tool_result)
+if(NOT install_name_tool_result EQUAL 0)
+ string(REPLACE ; ' ' msg '${cmd}')
+ message(FATAL_ERROR Command failed:\n ${msg})
+endif()
endif()
endfunction()
---
Summary of changes:
Modules/BundleUtilities.cmake |7 ++-
1 file changed, 6 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.1.2-1155-g4267f43
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 4267f43d15cd42040773c620781ab8f7926f343b (commit)
via 3d99355b11b2509f4e16ddfd71373538410364e7 (commit)
from 2681102e08a5a1f3615ee0c7717e7569ee460e25 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4267f43d15cd42040773c620781ab8f7926f343b
commit 4267f43d15cd42040773c620781ab8f7926f343b
Merge: 2681102 3d99355
Author: Brad King brad.k...@kitware.com
AuthorDate: Tue Feb 10 09:42:18 2015 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue Feb 10 09:42:18 2015 -0500
Merge topic 'cpack_rpm_mulit_prefix_fixup' into next
3d99355b CPackRPM: Fix recognition of absolute relocation paths
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3d99355b11b2509f4e16ddfd71373538410364e7
commit 3d99355b11b2509f4e16ddfd71373538410364e7
Author: Domen Vrankar domen.vran...@gmail.com
AuthorDate: Sun Feb 8 20:03:53 2015 +0100
Commit: Brad King brad.k...@kitware.com
CommitDate: Tue Feb 10 09:41:37 2015 -0500
CPackRPM: Fix recognition of absolute relocation paths
Fix typo in logic added by commit 3ec02547 (CPackRPM: Allow multiple
path relocation prefixes for one package, 2015-01-21).
diff --git a/Modules/CPackRPM.cmake b/Modules/CPackRPM.cmake
index 43e3fe0..214d655 100644
--- a/Modules/CPackRPM.cmake
+++ b/Modules/CPackRPM.cmake
@@ -442,7 +442,7 @@ function(cpack_rpm_prepare_relocation_paths)
# set other path prefixes
foreach(RELOCATION_PATH ${RPM_RELOCATION_PATHS})
-if(IS_ABSOLUTE ${RELOCATE_PATH})
+if(IS_ABSOLUTE ${RELOCATION_PATH})
set(PREPARED_RELOCATION_PATH ${RELOCATION_PATH})
else()
set(PREPARED_RELOCATION_PATH ${PATH_PREFIX}/${RELOCATION_PATH})
---
Summary of changes:
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v3.1.2-1030-g06e527b
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 06e527b36ccb86078e0caad2cd2962057b0c0558 (commit) via d2fe4c420370727c644432549b7a5ca9dfef3a28 (commit) via de63ff489d25095e41deae724f499ea3df05b6cf (commit) via 9924486f8a979bf937c8fd7749aaf37c1bd762e1 (commit) from f2ae132d96e36b856f91da499800d58efc37ccf5 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=06e527b36ccb86078e0caad2cd2962057b0c0558 commit 06e527b36ccb86078e0caad2cd2962057b0c0558 Merge: f2ae132 d2fe4c4 Author: Brad King brad.k...@kitware.com AuthorDate: Tue Feb 10 09:37:46 2015 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Tue Feb 10 09:37:46 2015 -0500 Merge topic 'xcode-flags-per-language' d2fe4c42 cmGlobalXCodeGenerator: Rename variable 'lang' = 'llang' de63ff48 Xcode: Generate Intel Fortran compiler flags in project files 9924486f Xcode: Refactor generation of per-language compiler flags --- Summary of changes: Source/cmGlobalXCodeGenerator.cxx | 155 +++-- 1 file changed, 79 insertions(+), 76 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v3.1.2-1047-gc548ddc
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 c548ddc1724c9c96bab04d2f51d1740360bcb737 (commit) via 63668954e002aa41ff0287aae22caeeacdc0c356 (commit) via ae775fe8041183030c69db1714c898b6e74f1284 (commit) via 7bb50e4a31ad5a8a58fe60885014d431a887b27f (commit) via c6ada8275b680e02f50a7aee1c02b0b184cadf83 (commit) via 8521fdf56e4908676c28c6bbdda3f1fb2284d3d7 (commit) via 69ac6d27555cd4819d0c7f40e4471c6f885e23ab (commit) from 1d6f4b6fcc04620fd5f8e090381e8330dc2a4b23 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c548ddc1724c9c96bab04d2f51d1740360bcb737 commit c548ddc1724c9c96bab04d2f51d1740360bcb737 Merge: 1d6f4b6 6366895 Author: Brad King brad.k...@kitware.com AuthorDate: Tue Feb 10 09:37:55 2015 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Tue Feb 10 09:37:55 2015 -0500 Merge topic 'makefile-progress-improvements' 63668954 Help: Add notes for topic 'makefile-progress-improvements' ae775fe8 Makefile: Change link step message color to bold green 7bb50e4a Makefile: Add progress to link step messages c6ada827 Makefile: Print all color escape sequences before newline 8521fdf5 Makefile: Fix output during parallel builds (#12991) 69ac6d27 bootstrap: Enable color Makefile output diff --cc Source/cmSystemTools.cxx index 6a7467f,f50d16c..d6f8d6b --- a/Source/cmSystemTools.cxx +++ b/Source/cmSystemTools.cxx @@@ -26,9 -26,7 +26,8 @@@ #include cmsys/Encoding.hxx #if defined(CMAKE_BUILD_WITH_CMAKE) # include cmArchiveWrite.h +# include cmLocale.h # include cm_libarchive.h - # include cmsys/Terminal.h #endif #include cmsys/stl/algorithm #include cmsys/FStream.hxx --- Summary of changes: .../release/dev/makefile-progress-improvements.rst |7 ++ Source/cmGlobalUnixMakefileGenerator3.cxx | 43 +++ Source/cmLocalUnixMakefileGenerator3.cxx | 35 +++--- Source/cmLocalUnixMakefileGenerator3.h |5 +- Source/cmMakefileExecutableTargetGenerator.cxx |6 +- Source/cmMakefileLibraryTargetGenerator.cxx|6 +- Source/cmMakefileTargetGenerator.cxx | 36 +++--- Source/cmMakefileTargetGenerator.h |2 +- Source/cmSystemTools.cxx | 16 ++- Source/cmSystemTools.h |2 - Source/cmcmd.cxx | 128 bootstrap |9 +- 12 files changed, 170 insertions(+), 125 deletions(-) create mode 100644 Help/release/dev/makefile-progress-improvements.rst hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v3.1.2-1034-g80c0800
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 80c080052a123b71b69bf42fa99e01df621502bb (commit) via 1814cf744ce69ab97ce4a8fe8183b4d4f7f75cf4 (commit) via 54e900abfbbddde560a853355b448e1b86681741 (commit) via 393a45e2e1fa2f0d9657d4a686257d828cd918e4 (commit) from 06e527b36ccb86078e0caad2cd2962057b0c0558 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=80c080052a123b71b69bf42fa99e01df621502bb commit 80c080052a123b71b69bf42fa99e01df621502bb Merge: 06e527b 1814cf7 Author: Brad King brad.k...@kitware.com AuthorDate: Tue Feb 10 09:37:48 2015 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Tue Feb 10 09:37:48 2015 -0500 Merge topic 'add-CheckFortranCompilerFlag' 1814cf74 Help: Add notes for topic 'add-CheckFortranCompilerFlag' 54e900ab CheckFortranCompilerFlag: Add test case 393a45e2 CheckFortranCompilerFlag: Add module to check Fortran flag existence --- Summary of changes: Help/manual/cmake-modules.7.rst|1 + Help/module/CheckFortranCompilerFlag.rst |1 + Help/release/dev/add-CheckFortranCompilerFlag.rst |6 ++ Modules/CMakeCheckCompilerFlagCommonPatterns.cmake |5 +- Modules/CheckFortranCompilerFlag.cmake | 66 Tests/FortranOnly/CMakeLists.txt |7 +++ 6 files changed, 84 insertions(+), 2 deletions(-) create mode 100644 Help/module/CheckFortranCompilerFlag.rst create mode 100644 Help/release/dev/add-CheckFortranCompilerFlag.rst create mode 100644 Modules/CheckFortranCompilerFlag.cmake 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.1.2-1165-g5b19ac5
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 5b19ac52bb4db11dd932c2f522cdda25a19a2ba3 (commit)
via e5ef9271a1bb1a0779132beba4cf2b0bae13d6cc (commit)
from f69ce957afe5631e73f2130c725474e651813623 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5b19ac52bb4db11dd932c2f522cdda25a19a2ba3
commit 5b19ac52bb4db11dd932c2f522cdda25a19a2ba3
Merge: f69ce95 e5ef927
Author: Brad King brad.k...@kitware.com
AuthorDate: Tue Feb 10 09:56:12 2015 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue Feb 10 09:56:12 2015 -0500
Merge topic 'FindRuby-windows-x64' into next
e5ef9271 FindRuby: Fix finding 64-bit Ruby on Windows
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e5ef9271a1bb1a0779132beba4cf2b0bae13d6cc
commit e5ef9271a1bb1a0779132beba4cf2b0bae13d6cc
Author: Michael Smith michael.sm...@puppetlabs.com
AuthorDate: Fri Feb 6 12:21:51 2015 -0800
Commit: Brad King brad.k...@kitware.com
CommitDate: Tue Feb 10 09:54:21 2015 -0500
FindRuby: Fix finding 64-bit Ruby on Windows
Ruby 2.0.0 and 2.1.5 have 64-bit binaries for Windows, with x64-
prefix.
diff --git a/Modules/FindRuby.cmake b/Modules/FindRuby.cmake
index 4be16c9..e5ea210 100644
--- a/Modules/FindRuby.cmake
+++ b/Modules/FindRuby.cmake
@@ -234,11 +234,16 @@ if(WIN32)
set( _RUBY_MSVC_RUNTIME 90 )
endif()
+ set(_RUBY_ARCH_PREFIX )
+ if(CMAKE_SIZEOF_VOID_P EQUAL 8)
+ set(_RUBY_ARCH_PREFIX x64-)
+ endif()
+
list(APPEND _RUBY_POSSIBLE_LIB_NAMES
- msvcr${_RUBY_MSVC_RUNTIME}-ruby${_RUBY_NODOT_VERSION}
- msvcr${_RUBY_MSVC_RUNTIME}-ruby${_RUBY_NODOT_VERSION}-static
- msvcrt-ruby${_RUBY_NODOT_VERSION}
- msvcrt-ruby${_RUBY_NODOT_VERSION}-static )
+
${_RUBY_ARCH_PREFIX}msvcr${_RUBY_MSVC_RUNTIME}-ruby${_RUBY_NODOT_VERSION}
+
${_RUBY_ARCH_PREFIX}msvcr${_RUBY_MSVC_RUNTIME}-ruby${_RUBY_NODOT_VERSION}-static
+ ${_RUBY_ARCH_PREFIX}msvcrt-ruby${_RUBY_NODOT_VERSION}
+ ${_RUBY_ARCH_PREFIX}msvcrt-ruby${_RUBY_NODOT_VERSION}-static )
endif()
find_library(RUBY_LIBRARY NAMES ${_RUBY_POSSIBLE_LIB_NAMES} HINTS
${RUBY_POSSIBLE_LIB_DIR} )
---
Summary of changes:
Modules/FindRuby.cmake | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v3.1.2-1038-gdb9a2e8
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 db9a2e8966256d50efcd593a20ed8a2b8b9cc05e (commit)
via 0f870234febd9dba0df78e903b412ea19d681062 (commit)
via cd408d93fdf347ff63a8062f75f1f4ee3e898b17 (commit)
via 87be2e1427ba2b1b7697c9332487862917897dca (commit)
from 80c080052a123b71b69bf42fa99e01df621502bb (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=db9a2e8966256d50efcd593a20ed8a2b8b9cc05e
commit db9a2e8966256d50efcd593a20ed8a2b8b9cc05e
Merge: 80c0800 0f87023
Author: Brad King brad.k...@kitware.com
AuthorDate: Tue Feb 10 09:37:50 2015 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue Feb 10 09:37:50 2015 -0500
Merge topic 'no-global-setlocale'
0f870234 Merge branch 'backport-no-global-setlocale' into
no-global-setlocale
cd408d93 Add setlocale() calls around use of libarchive APIs (#14934,
#15377)
87be2e14 Do not call setlocale() globally in CMake applications (#15377)
---
Summary of changes:
Source/CMakeLists.txt |1 +
Source/CPack/cpack.cxx |2 --
Source/CursesDialog/ccmake.cxx |3 ---
Source/cmArchiveWrite.cxx |4
Source/{cmCurl.h = cmLocale.h}| 22 --
Source/cmSystemTools.cxx |3 +++
Source/cmakemain.cxx |2 --
Source/ctest.cxx |3 ---
Tests/CMakeLib/PseudoMemcheck/memtester.cxx.in |2 --
9 files changed, 24 insertions(+), 18 deletions(-)
copy Source/{cmCurl.h = cmLocale.h} (67%)
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.1.2-1040-g1d6f4b6
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 1d6f4b6fcc04620fd5f8e090381e8330dc2a4b23 (commit) via 220c427e84215b28ea1dd6de74e9dc6e81f7962e (commit) from db9a2e8966256d50efcd593a20ed8a2b8b9cc05e (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1d6f4b6fcc04620fd5f8e090381e8330dc2a4b23 commit 1d6f4b6fcc04620fd5f8e090381e8330dc2a4b23 Merge: db9a2e8 220c427 Author: Brad King brad.k...@kitware.com AuthorDate: Tue Feb 10 09:37:53 2015 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Tue Feb 10 09:37:53 2015 -0500 Merge topic 'try_compile-quote-module-path' 220c427e try_compile: Quote the content of CMAKE_MODULE_PATH to allow for spaces --- Summary of changes: Source/cmCoreTryCompile.cxx |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.1.2-1026-gf2ae132
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 f2ae132d96e36b856f91da499800d58efc37ccf5 (commit) via 39e0aa5390964953e1462f0efed0058c172a0a26 (commit) via 892b854f57f48381751b79bfc52048ea57bb0376 (commit) from 7ab4fb5760a03cfcf1317351ebc75c7cfd91de96 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f2ae132d96e36b856f91da499800d58efc37ccf5 commit f2ae132d96e36b856f91da499800d58efc37ccf5 Merge: 7ab4fb5 39e0aa5 Author: Brad King brad.k...@kitware.com AuthorDate: Tue Feb 10 09:37:44 2015 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Tue Feb 10 09:37:44 2015 -0500 Merge topic 'FindBoost-per-config-libraries' 39e0aa53 Help: Add notes for topic 'FindBoost-per-config-libraries' 892b854f FindBoost: Search for debug and release libraries separately (#15364) --- Summary of changes: .../release/dev/FindBoost-per-config-libraries.rst |5 + Modules/FindBoost.cmake| 156 ++-- 2 files changed, 112 insertions(+), 49 deletions(-) create mode 100644 Help/release/dev/FindBoost-per-config-libraries.rst hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v3.1.2-1153-g2681102
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 2681102e08a5a1f3615ee0c7717e7569ee460e25 (commit) via e2619c13f727504b7368e0bf156c17112ee81568 (commit) via c548ddc1724c9c96bab04d2f51d1740360bcb737 (commit) via 1d6f4b6fcc04620fd5f8e090381e8330dc2a4b23 (commit) via db9a2e8966256d50efcd593a20ed8a2b8b9cc05e (commit) via 80c080052a123b71b69bf42fa99e01df621502bb (commit) via 06e527b36ccb86078e0caad2cd2962057b0c0558 (commit) via f2ae132d96e36b856f91da499800d58efc37ccf5 (commit) from 57c6574b35a3d533e47cc8c2be131c46d2b30a99 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2681102e08a5a1f3615ee0c7717e7569ee460e25 commit 2681102e08a5a1f3615ee0c7717e7569ee460e25 Merge: 57c6574 e2619c1 Author: Brad King brad.k...@kitware.com AuthorDate: Tue Feb 10 09:38:13 2015 -0500 Commit: Brad King brad.k...@kitware.com CommitDate: Tue Feb 10 09:38:13 2015 -0500 Merge branch 'master' into next --- Summary of changes: hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v3.1.2-1066-ge2619c1
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 e2619c13f727504b7368e0bf156c17112ee81568 (commit) via d8639733a42149ca1402dcae427f2142ab0cf037 (commit) via 803317aab622e4f12e7d342be5bbb4f16b088efd (commit) via 11093a03e064e1b7ef2d5db28845b5da7b934806 (commit) via 6cd2ee9524e501a4ef9dc481b469b91f8f022dc9 (commit) via 94e993a0c170cf84da9ddb026dfec9d8d99304e0 (commit) via 69dbe51b08bd6b4564d031d78034633f55ed4593 (commit) via 683fafea088c26658283da3bdf05277aaa1a3cee (commit) via 63f584b618b3381ad93c901f691191acd48329a7 (commit) via 74c4d9d27aece9a619eaab330ad23cf4b0de2b19 (commit) via 71d47115d009983665d6db4b25ea0ef40464f365 (commit) via 39622c995c189b4e22dfdc0e9aa29c8fce5eac17 (commit) via a7fcc148bdfa5e9f2c6901b0de8192f5aa043741 (commit) via d46c4f0727acb35963dfda579cd5c9efd63aab01 (commit) via d59913f001b6eb74f9baf8bad183dc83d5e7bcd1 (commit) via 3f3db74413fc6b0afe4aa484c0ada2d5271ef0ba (commit) via bd990c803b40e1532cab6b29c75414ca6f30e782 (commit) via 5fc53f1edb2d003595ef224b31a805c3af0dc0e6 (commit) via 421eadb45b48d40aa7d0b5e42a48df4ba94b9fc0 (commit) from c548ddc1724c9c96bab04d2f51d1740360bcb737 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e2619c13f727504b7368e0bf156c17112ee81568 commit e2619c13f727504b7368e0bf156c17112ee81568 Merge: c548ddc d863973 Author: Brad King brad.k...@kitware.com AuthorDate: Tue Feb 10 09:37:57 2015 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Tue Feb 10 09:37:57 2015 -0500 Merge topic 'use-algorithms' d8639733 cmSystemTools: Remove unnecessary comparison. 803317aa cmSystemTools: Early return if size makes later comparison false. 11093a03 Replace temporary bool by inlining warning condition. 6cd2ee95 Replace loop with member algorithm. 94e993a0 cmComputeLinkDepends: Remove temporary iterator copy. 69dbe51b Replace loop with algorithm. 683fafea Replace a loop with std::transform. 63f584b6 Replace while loop with member insert. 74c4d9d2 Take a size check outside of an inner loop. 71d47115 Use insert member instead of back_inserter. 39622c99 Convert while loop to member insert. a7fcc148 Convert loop to algorithm. d46c4f07 Extract a prefix variable from loop. d59913f0 Take computation out of loop. 3f3db744 cmMakefile: Remove ExpandSourceListArguments. bd990c80 Remove use of ExpandSourceListArguments. ... --- Summary of changes: Source/CPack/OSXScriptLauncher.cxx |8 Source/CPack/cmCPackNSISGenerator.cxx|2 +- Source/CTest/cmCTestCoverageHandler.cxx |4 ++-- Source/QtDialog/CMakeSetup.cxx |6 +++--- Source/cmAddLibraryCommand.cxx |6 +- Source/cmCPluginAPI.cxx |7 +++ Source/cmComputeLinkDepends.cxx |7 +++ Source/cmFLTKWrapUICommand.cxx |7 ++- Source/cmFileCommand.cxx |4 ++-- Source/cmFindLibraryCommand.cxx |4 ++-- Source/cmInstallFilesCommand.cxx |7 ++- Source/cmLocalGenerator.cxx | 33 +++--- Source/cmLocalUnixMakefileGenerator3.cxx | 14 + Source/cmMakefile.cxx| 13 Source/cmMakefile.h | 11 -- Source/cmQTWrapCPPCommand.cxx| 10 +++-- Source/cmQTWrapUICommand.cxx | 10 +++-- Source/cmSetTargetPropertiesCommand.cxx | 15 -- Source/cmSetTestsPropertiesCommand.cxx | 15 -- Source/cmSystemTools.cxx |8 ++-- Source/cmTarget.cxx | 13 Source/cmXMLSafe.cxx |4 ++-- Source/cmXMLSafe.h |4 ++-- Source/cmake.cxx |9 24 files changed, 74 insertions(+), 147 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.1.2-1145-g57c6574
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 57c6574b35a3d533e47cc8c2be131c46d2b30a99 (commit)
via eeb2831b5f35af1ec8a65be343e754ff1c29550d (commit)
from 6818ee67a5b1f81e3e5b7db36a49774d3dde8c99 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=57c6574b35a3d533e47cc8c2be131c46d2b30a99
commit 57c6574b35a3d533e47cc8c2be131c46d2b30a99
Merge: 6818ee6 eeb2831
Author: Brad King brad.k...@kitware.com
AuthorDate: Tue Feb 10 09:27:33 2015 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue Feb 10 09:27:33 2015 -0500
Merge topic 'makefile-missing-comment' into next
eeb2831b Makefile: Fix regression in target-bound custom command COMMENT
output
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=eeb2831b5f35af1ec8a65be343e754ff1c29550d
commit eeb2831b5f35af1ec8a65be343e754ff1c29550d
Author: Nils Gladitz nilsglad...@gmail.com
AuthorDate: Tue Feb 10 12:26:56 2015 +0100
Commit: Brad King brad.k...@kitware.com
CommitDate: Tue Feb 10 09:22:05 2015 -0500
Makefile: Fix regression in target-bound custom command COMMENT output
Fix a logic typo introduced by commit v3.1.0-rc1~781^2 (Generalize
cmCustomCommandGenerator to more fields, 2014-03-10).
diff --git a/Source/cmLocalUnixMakefileGenerator3.cxx
b/Source/cmLocalUnixMakefileGenerator3.cxx
index 23513fa..280d4ab 100644
--- a/Source/cmLocalUnixMakefileGenerator3.cxx
+++ b/Source/cmLocalUnixMakefileGenerator3.cxx
@@ -1076,7 +1076,7 @@ cmLocalUnixMakefileGenerator3
if(echo_comment)
{
const char* comment = ccg.GetComment();
-if(comment !*comment)
+if(comment *comment)
{
this-AppendEcho(commands, comment,
cmLocalUnixMakefileGenerator3::EchoGenerate);
---
Summary of changes:
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits
Re: [cmake-developers] FindRuby doesn't find 64-bit Ruby on Windows
On 02/06/2015 09:10 PM, Michael Smith wrote: On Fri, Feb 6, 2015 at 4:42 PM, Ben Boeckel wrote: Doesn't work for cross-compiles. FindRuby is already querying ruby for libdir. How does that work for cross-compiles but using some of the other config doesn't? That one doesn't work either, but we shouldn't add more cases. -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] FindRuby doesn't find 64-bit Ruby on Windows
On 02/06/2015 06:00 PM, Michael Smith wrote: New patch attached. Applied, thanks: FindRuby: Fix finding 64-bit Ruby on Windows http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e5ef9271 -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: [ANNOUNCE] CMake 3.1.2 Released
So we can safely presume that the new features listed at https://gcc.gnu.org/gcc-5/changes.html will be the what gcc 5.0 will ship with? On Mon, Feb 9, 2015 at 11:18 PM, Orion Poplawski or...@cora.nwra.com wrote: On 02/09/2015 11:08 AM, Ben Boeckel wrote: On Mon, Feb 09, 2015 at 11:09:32 -0500, Robert Maynard wrote: We are pleased to announce that CMake 3.1.2 is now available for download. I'm getting this now building cmake 3.1.2 for Fedora Rawhide with gcc 5.0.0: 32: Detecting CXX compile features - done 32: Testing feature : cxx_aggregate_default_initializers 32: Configuring 32: CMake Error at CMakeLists.txt:70 (message): 32: Feature cxx_aggregate_default_initializers expected not to work for CXX 32: GNU-5.0.0. 32: 32: Update the supported features or blacklist it. 32: Testing feature : cxx_relaxed_constexpr 32: Configuring 32: CMake Error at CMakeLists.txt:70 (message): 32: Feature cxx_relaxed_constexpr expected not to work for CXX GNU-5.0.0. 32: 32: Update the supported features or blacklist it. 32: Testing feature : cxx_variable_templates 32: Configuring 32: CMake Error at CMakeLists.txt:70 (message): 32: Feature cxx_variable_templates expected not to work for CXX GNU-5.0.0. 32: 32: Update the supported features or blacklist it. Yeah, the feature tables will need to be updated. I use Rawhide at home (was going to send an email about the tests as well) and was going to look at updating it there. However, it is still a pre-release build of GCC5, so we should probably just hold off on pushing something into master until an official release is made. --Ben According to https://fedoraproject.org/wiki/Changes/GCC5#Detailed_Description : GCC 5 is currently in stage4 - prerelease state with only regression bugfixes and documentation fixes allowed. So I think it's reasonable time to start adapting to it. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.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-developers
[Cmake-commits] CMake branch, next, updated. v3.1.2-1175-g8926a09
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 8926a09dd37e32502f0ed82b5b84dda9ce686d82 (commit) via 248d74165ed6f18d130e13a19fa8a866d81fabe8 (commit) from fa1af50e9bbe0506da14019b82cbc86fd1333e02 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8926a09dd37e32502f0ed82b5b84dda9ce686d82 commit 8926a09dd37e32502f0ed82b5b84dda9ce686d82 Merge: fa1af50 248d741 Author: Zack Galbreath zack.galbre...@kitware.com AuthorDate: Tue Feb 10 11:10:02 2015 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Tue Feb 10 11:10:02 2015 -0500 Merge topic 'fix_timeout_docs' into next 248d7416 fix the name of the referenced variable. http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=248d74165ed6f18d130e13a19fa8a866d81fabe8 commit 248d74165ed6f18d130e13a19fa8a866d81fabe8 Author: Zack Galbreath zack.galbre...@kitware.com AuthorDate: Tue Feb 10 11:07:26 2015 -0500 Commit: Zack Galbreath zack.galbre...@kitware.com CommitDate: Tue Feb 10 11:07:26 2015 -0500 fix the name of the referenced variable. It's CTEST_TEST_TIMEOUT, not CTEST_TESTING_TIMEOUT. This change also adds a link to the variable's documentation. diff --git a/Help/prop_test/TIMEOUT.rst b/Help/prop_test/TIMEOUT.rst index 0b247b8..d1cb90d 100644 --- a/Help/prop_test/TIMEOUT.rst +++ b/Help/prop_test/TIMEOUT.rst @@ -6,4 +6,4 @@ How many seconds to allow for this test. This property if set will limit a test to not take more than the specified number of seconds to run. If it exceeds that the test process will be killed and ctest will move to the next test. This -setting takes precedence over CTEST_TESTING_TIMEOUT. +setting takes precedence over :variable:`CTEST_TEST_TIMEOUT`. --- Summary of changes: Help/prop_test/TIMEOUT.rst |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-developers] [CMake 0015400]: fixup_bundle does not work on cpack stage
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15400 == Reported By:Ruslan Baratov Assigned To: == Project:CMake Issue ID: 15400 Category: Modules Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2015-02-10 09:21 EST Last Modified: 2015-02-10 09:21 EST == Summary:fixup_bundle does not work on cpack stage Description: fixup_bundle works as expected if cmake installs target, but not when cpack creating a package. Steps to Reproduce: Example with Visual Studio 12, Qt and NSIS generator (see attached CMakeLists.txt and main.cpp): 1. cmake -H. -B_builds -GVisual Studio 12 2013 -DCMAKE_INSTALL_PREFIX=_install -DCPACK_GENERATOR=NSIS 2. cmake --build _builds --config Release --target install 3. dependent Qt libraries installed in local _install directory: -- fixup_bundle: copying... -- 1/14: *NOT* copying '.../_install/bin/foo.exe' -- 2/14: copying '.../bin/Qt5Core.dll' -- 3/14: copying '.../bin/Qt5Gui.dll' -- 4/14: copying '.../bin/Qt5Widgets.dll' -- 5/14: copying '.../bin/icudt53.dll' -- 6/14: copying '.../bin/icuin53.dll' -- 7/14: copying '.../bin/icuuc53.dll' -- fixup_bundle: fixing... -- 8/14: fix-up not required on this platform '.../_install/bin/foo.exe' -- 9/14: fix-up not required on this platform '.../_install/bin/Qt5Core.dll' -- 10/14: fix-up not required on this platform '.../_install/bin/Qt5Gui.dll' -- 11/14: fix-up not required on this platform '.../_install/bin/Qt5Widgets.dll' -- 12/14: fix-up not required on this platform '.../_install/bin/icudt53.dll' -- 13/14: fix-up not required on this platform '.../_install/bin/icuin53.dll' -- 14/14: fix-up not required on this platform '.../_install/bin/icuuc53.dll' 4. But not if cpack build installer: cd _builds cpack --verbose -C Release -GNSIS CPack Verbose: fixup_bundle: copying... CPack Verbose: 1/2: *NOT* copying '.../_builds/_CPack_Packages/win32/NSIS/Foo-1.0.0-win32/bin/foo.exe' CPack Verbose: fixup_bundle: fixing... CPack Verbose: 2/2: fix-up not required on this platform '.../_builds/_CPack_Packages/win32/NSIS/Foo-1.0.0-win32/bin/foo.exe' CPack Verbose: fixup_bundle: cleaning up... CPack Verbose: fixup_bundle: verifying... == Issue History Date ModifiedUsername FieldChange == 2015-02-10 09:21 Ruslan Baratov New Issue 2015-02-10 09:21 Ruslan Baratov File Added: CMakeLists.txt == -- 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.1.2-1171-ga06bd9f
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 a06bd9fdc9c2ac5a921f6836454fc13c7523d060 (commit) via f3e9eeedf43f783c02b2a2a10fc0e632eaf7cfd0 (commit) from 5367c0e4781644a33ce9163666a626e50efffa2c (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a06bd9fdc9c2ac5a921f6836454fc13c7523d060 commit a06bd9fdc9c2ac5a921f6836454fc13c7523d060 Merge: 5367c0e f3e9eee Author: Brad King brad.k...@kitware.com AuthorDate: Tue Feb 10 10:35:25 2015 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Tue Feb 10 10:35:25 2015 -0500 Merge topic 'try_compile-shorter-names' into next f3e9eeed try_compile: Use shorter test executable name with consistent length http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f3e9eeedf43f783c02b2a2a10fc0e632eaf7cfd0 commit f3e9eeedf43f783c02b2a2a10fc0e632eaf7cfd0 Author: Brad King brad.k...@kitware.com AuthorDate: Tue Feb 10 10:21:55 2015 -0500 Commit: Brad King brad.k...@kitware.com CommitDate: Tue Feb 10 10:28:41 2015 -0500 try_compile: Use shorter test executable name with consistent length Since commit v2.8.8~176^2 (try_compile: Use random executable file name, 2012-02-13) the length of the test executable name in generated try_compile projects has been longer and unpredictable. With Visual Studio on windows, the tools try to create paths like: CMakeFiles/CMakeTmp/$tgt.dir/Debug/$tgt.tlog/$tgt.lastbuildstate With the target name repeated up to 3 times, we must make it short and of consistent length to avoid overrunning the 260 character limit imposed by VS tools. diff --git a/Source/cmCoreTryCompile.cxx b/Source/cmCoreTryCompile.cxx index c414553..d9369e6 100644 --- a/Source/cmCoreTryCompile.cxx +++ b/Source/cmCoreTryCompile.cxx @@ -383,8 +383,8 @@ int cmCoreTryCompile::TryCompileCode(std::vectorstd::string const argv) /* Use a random file name to avoid rapid creation and deletion of the same executable name (some filesystems fail on that). */ -sprintf(targetNameBuf, cmTryCompileExec%u, -cmSystemTools::RandomSeed()); +sprintf(targetNameBuf, cmTC_%05x, +cmSystemTools::RandomSeed() 0xF); targetName = targetNameBuf; if (!targets.empty()) --- Summary of changes: Source/cmCoreTryCompile.cxx |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
Re: [cmake-developers] Fortran detection, issue 9220
On Tue, Feb 10, 2015 at 17:15:33 -0800, Alan W. Irwin wrote: As the originator (almost 6 years ago) of this bug report I am still very much interested in a fundamental solution to give a WARNING message rather than an error if there is any issue with a compiler. This patch makes it only an error when Ninja detects a Fortran compiler rule being written (which is where the actual incompatibility lies). Other languages error out because CMake doesn't have *any* knowledge of how to build them. Java is kinda-sorta there IIRC. I haven't used it much, but I don't remember it feeling first-class. That capability is fundamentally important for projects like PLplot that support more than one different compiled computer language (PLplot supports the compiled languages Ada, C, C++, Fortran, D, and Java) You might be interested in the first-class D support here where I've been dabbling in some personal projects: https://github.com/trentforkert/cmake Other languages would need similar efforts to be fully supported. That said, putting logic behind enable_language(OPTIONAL) would be nice. --Ben -- 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] Mixed linking
Stephen Kelly wrote:
Ah, right the platform plugin issue. This is likely the reason for not
running on OSX.
CMake 3.1 learned a new feature specifically so that this would become
easier in the future:
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/7970
qmake generates a file like the above for you and compiles it and links it
into your application for you in the static version.
With
http://www.cmake.org/cmake/help/v3.1/prop_tgt/INTERFACE_SOURCES.html
Qt can do the same, but someone would have to patch Qt to do so. Something
for the future... :)
Thanks for all the insight. I have been looking at this and quite a few posts
(mostly from you !) to try and understand. I think I get most of it.
That being said, I finally got a static executable for my application on my
mac. What I did is build my application using qmake, get the linker command and
manually find every library using cmake in order to recreate the linker command
from qmake (I don’t think it makes a difference, but I’m not sure so I even
kept the library order the same). For my application, this is what did it
ended up with (some boiler plate removed).
find_package( Qt5 COMPONENTS Widgets Sql PrintSupport REQUIRED )
find_library( DISKARBITRATION_LIBRARY DiskArbitration )
find_library( IOKIT_LIBRARY IOKit )
find_library( APPLICATIONSERVICES_LIBRARY ApplicationServices )
find_library( CORESERVICES_LIBRARY CoreServices )
find_library( COREFOUNDATION_LIBRARY CoreFoundation )
find_library( FOUNDATION_LIBRARY Foundation )
find_library( COCOA_LIBRARY Cocoa )
find_library( CARBON_LIBRARY Carbon )
find_library( OPENGL_LIBRARY OpenGL )
add_executable( calculum ${SRCS_LIST} ${UIS_LIST} ${HDRS_LIST} )
set( QT_INSTALL_DIR_GL /sw/local/qt/ )
find_library( QCOCOA qcocoa
PATHS ${QT_INSTALL_DIR_GL}/plugins/platforms )
find_library( QDDS qdds
PATHS ${QT_INSTALL_DIR_GL}/plugins/imageformats )
find_library( QICNS qicns
PATHS ${QT_INSTALL_DIR_GL}/plugins/imageformats )
find_library( QICO qico
PATHS ${QT_INSTALL_DIR_GL}/plugins/imageformats )
find_library( QJP2 qjp2
PATHS ${QT_INSTALL_DIR_GL}/plugins/imageformats )
find_library( QMNG qmng
PATHS ${QT_INSTALL_DIR_GL}/plugins/imageformats )
find_library( QTGA qtga
PATHS ${QT_INSTALL_DIR_GL}/plugins/imageformats )
find_library( QTIFF qtiff
PATHS ${QT_INSTALL_DIR_GL}/plugins/imageformats )
find_library( QWBMP qwbmp
PATHS ${QT_INSTALL_DIR_GL}/plugins/imageformats )
find_library( QWEBP qwebp
PATHS ${QT_INSTALL_DIR_GL}/plugins/imageformats” )
# Note, GL are my initials. It was just to ensure no conflicts in names.
Probably not necessary
target_link_libraries( calculum
${DISKARBITRATION_LIBRARY}
${IOKIT_LIBRARY}
${APPLICATIONSERVICES_LIBRARY}
${CORESERVICES_LIBRARY}
${COREFOUNDATION_LIBRARY}
${FOUNDATION_LIBRARY}
${COCOA_LIBRARY}
${CARBON_LIBRARY}
Qt5::Sql
${QCOCOA}
cups
/sw/local/qt/lib/libQt5PlatformSupport.a
${OPENGL_LIBRARY}
Qt5::PrintSupport
Qt5::Widgets
${QDDS}
${QICNS}
${QICO}
${QJP2}
${QMNG}
${QTGA}
${QTIFF}
${QWBMP}
${QWEBP}
Qt5::Gui
Qt5::Core
z
m )
This seems like a lot of work to get what I want… But if it does the job. The
fun part will be to see what I need on Windows and then put conditionals around
that and all.
If I misunderstood something and there is an easier way to get a static
executable from using static qt from CMake, please let me know. I am posting
this in case someone searches for information on how to link static Qt using
CMake. The title of my mail said Mixed linking, but it should probably really
say static linking Qt5 using CMake, but I don’t know how to change it (I have
seen on the list the formerly was …, but not sure if it’s appropriate or how to
do it).
Again, thanks for giving a bit of your time. Really appreciated.
Ghyslain
--
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
Re: [cmake-developers] Fortran detection, issue 9220
On 2015-02-06 10:21-0500 Ben Boeckel wrote: On Fri, Feb 06, 2015 at 07:01:55 +0100, Christoph Grüninger wrote: would you mind to tackle issue 9220 enable_language( OPTIONAL) signature does not work correctly? It's a shame that CMake cannot properly detect optional Fortran for more than 5 years! The workaround from Eigen works fine for me, but it's still embarrassing. BTW, is there a way to disable the optional Fortran by a flag to CMake? I couldn't find any... Here is a commit which I haven't worked on for a while which delays the error until you request an actual build of a Fortran object: https://github.com/mathstuf/CMake/commit/880d783bf7fbd986b8a50a712e69ff40abbcfa07 While not the OPTIONAL signature, it is more accurate. Let me know how it works for you. Some additional comments for both Christoph and Ben: This issue is for all language compilers, not just Fortran, and this issue is orthogonal to the well-known lack of support for Fortran in ninja. As the originator (almost 6 years ago) of this bug report I am still very much interested in a fundamental solution to give a WARNING message rather than an error if there is any issue with a compiler. That capability is fundamentally important for projects like PLplot that support more than one different compiled computer language (PLplot supports the compiled languages Ada, C, C++, Fortran, D, and Java) where the project developer's want users to at least have partial functionality if say the Ada compiler does not work. We do have a workaround (see early comments in http://public.kitware.com/Bug/view.php?id=9220 for details), but that approach is inefficient (you have to check compilers twice), and doesn't correctly propagate all the many different ways (e.g., environment variables, CMake cache variables) you can specify compilers and compiler flags to the special small CMake test build system used to check the compiler for each required compiled language. The most recent comment (by Brad King) at http://public.kitware.com/Bug/view.php?id=9220 states the documentation has now been changed to state that OPTIONAL is a placeholder (in enable_language) that does not work. So at least OPTIONAL has now been clearly marked as defunct. Brad also recommends an alternative approach to using OPTIONAL in enable_language. I haven't had a chance to look into that possibility yet, but I will do so because an efficient and clean solution for providing a soft landing when a compiler test fails is important for the PLplot project. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0015401]: Cmake Xcode project generation doesn't support Swift language
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15401 == Reported By:Wojciech A. Koszek Assigned To: == Project:CMake Issue ID: 15401 Category: CMake Reproducibility:always Severity: tweak Priority: low Status: new == Date Submitted: 2015-02-10 20:43 EST Last Modified: 2015-02-10 20:43 EST == Summary:Cmake Xcode project generation doesn't support Swift language Description: I successfully use CMake for Xcode project generation. So I run cmake -GXcode followed by xcodebuild. It seems like right now cmake knows how to recognize .m files, but doesn't know how to handle .swift files. It would be great to teach it that. Steps to Reproduce: Tested on MacOSX Yosemite with cmake installed from brew install cmake. CMakeLists.txt cmake_minimum_required (VERSION 2.6) project (sample) add_executable(sample ../sample.swift) cmake -GXcode [wkoszek-macbook:~/github/macb/obj] wkoszek% cmake -GXcode -- Configuring done -- Generating done CMake Error: CMake can not determine linker language for target: sample CMake Error: CMake can not determine linker language for target: sample CMake Error: CMake can not determine linker language for target: sample CMake Error: CMake can not determine linker language for target: sample CMake Error: CMake can not determine linker language for target: sample CMake Error: CMake can not determine linker language for target: sample CMake Error: CMake can not determine linker language for target: sample CMake Error: CMake can not determine linker language for target: sample -- Build files have been written to: /Users/wkoszek/github/macb/obj == Issue History Date ModifiedUsername FieldChange == 2015-02-10 20:43 Wojciech A. KoszekNew Issue == -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[Cmake-commits] CMake branch, next, updated. v3.1.2-1179-g17fef0d
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 17fef0dae571e0f745c3dd14facd90e68cf8c9db (commit) via 56cb4a6c3a71f1a3d3e0dccbdc593bc58d76c5ee (commit) from a0272926fcd2ff20b26092c789dd6ae9538fc5e5 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=17fef0dae571e0f745c3dd14facd90e68cf8c9db commit 17fef0dae571e0f745c3dd14facd90e68cf8c9db Merge: a027292 56cb4a6 Author: Brad King brad.k...@kitware.com AuthorDate: Tue Feb 10 12:59:00 2015 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Tue Feb 10 12:59:00 2015 -0500 Merge topic 'fix_timeout_docs' into next 56cb4a6c Help: Fix variable reference in TIMEOUT test property docs http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=56cb4a6c3a71f1a3d3e0dccbdc593bc58d76c5ee commit 56cb4a6c3a71f1a3d3e0dccbdc593bc58d76c5ee Author: Zack Galbreath zack.galbre...@kitware.com AuthorDate: Tue Feb 10 11:07:26 2015 -0500 Commit: Brad King brad.k...@kitware.com CommitDate: Tue Feb 10 12:58:01 2015 -0500 Help: Fix variable reference in TIMEOUT test property docs Link to 'CTEST_TEST_TIMEOUT', not 'CTEST_TESTING_TIMEOUT'. diff --git a/Help/prop_test/TIMEOUT.rst b/Help/prop_test/TIMEOUT.rst index 0b247b8..d1cb90d 100644 --- a/Help/prop_test/TIMEOUT.rst +++ b/Help/prop_test/TIMEOUT.rst @@ -6,4 +6,4 @@ How many seconds to allow for this test. This property if set will limit a test to not take more than the specified number of seconds to run. If it exceeds that the test process will be killed and ctest will move to the next test. This -setting takes precedence over CTEST_TESTING_TIMEOUT. +setting takes precedence over :variable:`CTEST_TEST_TIMEOUT`. --- Summary of changes: hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v3.1.2-1177-ga027292
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 a0272926fcd2ff20b26092c789dd6ae9538fc5e5 (commit) via cbffbf7437ea2d571e26bedee032c23be9347d94 (commit) from 8926a09dd37e32502f0ed82b5b84dda9ce686d82 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a0272926fcd2ff20b26092c789dd6ae9538fc5e5 commit a0272926fcd2ff20b26092c789dd6ae9538fc5e5 Merge: 8926a09 cbffbf7 Author: Brad King brad.k...@kitware.com AuthorDate: Tue Feb 10 12:56:22 2015 -0500 Commit: Brad King brad.k...@kitware.com CommitDate: Tue Feb 10 12:56:22 2015 -0500 Merge branch 'master' into next --- Summary of changes: hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v3.1.2-1181-g5e36f8e
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 5e36f8ee1ebf4538146f9f0cb5974426eac14249 (commit) via 918bf7fa136b79ccd4a572214b803e94a4fa5e69 (commit) from 17fef0dae571e0f745c3dd14facd90e68cf8c9db (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5e36f8ee1ebf4538146f9f0cb5974426eac14249 commit 5e36f8ee1ebf4538146f9f0cb5974426eac14249 Merge: 17fef0d 918bf7f Author: Brad King brad.k...@kitware.com AuthorDate: Tue Feb 10 13:01:40 2015 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Tue Feb 10 13:01:40 2015 -0500 Merge topic 'doc-user-interaction' into next 918bf7fa fixup! Help: Add a new user manual for user interaction. http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=918bf7fa136b79ccd4a572214b803e94a4fa5e69 commit 918bf7fa136b79ccd4a572214b803e94a4fa5e69 Author: Brad King brad.k...@kitware.com AuthorDate: Tue Feb 10 13:01:20 2015 -0500 Commit: Brad King brad.k...@kitware.com CommitDate: Tue Feb 10 13:01:20 2015 -0500 fixup! Help: Add a new user manual for user interaction. diff --git a/Help/manual/cmake-user-interaction.7.rst b/Help/manual/cmake-user-interaction.7.rst index 519c187..85e506e 100644 --- a/Help/manual/cmake-user-interaction.7.rst +++ b/Help/manual/cmake-user-interaction.7.rst @@ -25,7 +25,8 @@ to their system. Generated buildsystems should generally be treated as read-only. The CMake files as a primary artifact should completely specify the buildsystem and -there should be no reason to populate properties in an IDE for example. +there should be no reason to populate properties manually in an IDE for +example. The features and user interfaces described in this manual are available for all CMake-based build systems by virtue of providing CMake files. @@ -84,9 +85,8 @@ simply deleting the build directory. The CMake tooling may report warnings which are intended for the provider of the software, not intended for the consumer of the software. Such -warnings usually take the form of :manual:`policy cmake-policies(7)` -warnings. Users may disable such warnings by passing the ``-Wno-dev`` flag -to :manual:`cmake(1)`. +warnings end with This warning is for project developers. Users may +disable such warnings by passing the ``-Wno-dev`` flag to :manual:`cmake(1)`. Note that spaces in the path to the source directory or build directory can cause problems if the provided software is not written to carefully quote @@ -110,7 +110,7 @@ The output of ``cmake --help`` includes a list of :manual:`generators cmake-generators(7)` available for the user to choose from. -On Unix-like systems (including Apple), the :generator:`Unix Makefiles` +On Unix-like systems (including Mac OS X), the :generator:`Unix Makefiles` generator is used by default. A variant of that generator can also be used on Windows in various environments, such as the :generator:`NMake Makefiles` and :generator:`MinGW Makefiles` generator. These generators generate --- Summary of changes: Help/manual/cmake-user-interaction.7.rst | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/mailman/listinfo/cmake-commits
[CMake] overriding initial Fortran flags with PGI compiler
Hi,
we use custom compiler flags for the default build types and our
solution works fine. However, when using the PGI Fortran compiler,
some initial flags are set in the module that are always there:
(/usr/share/cmake-3.1/Modules/Compiler/PGI-Fortran.cmake)
set(CMAKE_Fortran_FLAGS_INIT ${CMAKE_Fortran_FLAGS_INIT} -Mpreprocess -Kieee)
What should I do if I don't want those flags? It seems to me that this
should be tied to a certain build type?
Because of those general initial flags, it is e.g. pointless to use an
empty build type with custom flags, as the -Mpreprocess -Kieee will
always be there.
Steven
--
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] Qt5, find ICU and ANGLE libraries
Hi,
I am using Qt 5.3 (Angle on Windows) with CMake 2.8.12. Qt 5.3 has
dependencies on ICU and ANGLE libs. I wish to copy these dlls to the build
directory. Is there any CMake variable that holds name of ICU and ANGLE
libs?
To copy other Qt libraries I am using the following sample code fragment-
GET_TARGET_PROPERTY(QT5_LIB_LOCATION Qt5::Core LOCATION_${BUILD_TYPE})
file(COPY ${QT5_LIB_LOCATION} DESTINATION
{EXECUTABLE_OUTPUT_PATH}/${BUILD_TYPE})
Here BUILD_TYPE can be Debug or Release
If it is not possible to get the lib names, I wish to get the Qt bin dir
path. Is any variable holding this value? I could find Qt5_DIR, but not a
variable pointing to the bin directory.
Thanks,
Lloyd
--
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-developers] [CMake 0015399]: cmake xml-escapes ; for visual studio generators resulting in malformed ignore default libraries
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15399 == Reported By:Florent Assigned To: == Project:CMake Issue ID: 15399 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2015-02-10 05:57 EST Last Modified: 2015-02-10 05:57 EST == Summary:cmake xml-escapes ; for visual studio generators resulting in malformed ignore default libraries Description: I have the following cmakelist : set_property(TARGET MyLibraryUsingFortranRt APPEND PROPERTY LINK_FLAGS /NODEFAULTLIB:svml_disp.lib libifcoremt.lib libcmt.lib libcmtd.lib libmmt.lib libifport.lib) this generates the following xml fragment with 3.1 (Visual 2010 generator) IgnoreSpecificDefaultLibrariessvml_disp.lib%3Blibifcoremt.lib%3Blibcmt.lib%3Blibcmtd.lib%3Blibmmt.lib%3Blibifport.lib;%(IgnoreSpecificDefaultLibraries)/IgnoreSpecificDefaultLibraries (notice how ; got correctly escaped to %3B ! ) However for this specific filed VS expect to have ; present in the xml as it is the case with 3.0 making it impossible to ignore several libraries. Additional Information: from my end-less researches, this is linked to http://www.cmake.org/Bug/view.php?id=15031 and most likely this commit : http://www.cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8fa087ab == Issue History Date ModifiedUsername FieldChange == 2015-02-10 05:57 FlorentNew Issue 2015-02-10 05:57 FlorentFile Added: VS_escaped_ignore_specific_libraries.PNG == -- 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] lib/cmake vs share/cmake/Modules
Alexander Neundorf wrote at 21:34 +0100 on Feb 9, 2015: On Monday, February 09, 2015 18:23:41 44ghnqv...@snkmail.com wrote: How does one who is making a package which installs .cmake files decide whether to put them in .../share/cmake/Modules or .../lib/cmake? Where are the docs about that? I've seen examples of 3rd party packages doing both (e.g., pulseaudio in lib/cmake/Foo opencollada - in share/cmake/Modules). architecture-independent files, i.e. which could sit on a shared NFS drive and which could be mounted from hosts with any type of CPU architecture, go into share/, i.e. basically data or text files. Files which are architecture dependend, e.g. Config.cmake files for installed libraries, go into lib/. (in doubt, lib/ is the safe choice). I'm looking for official cmake docs that explain the difference between the two locations from cmake's perspective (rather than just guidelines reiterated from hier(7)). Clearly .cmake files are architecture independent - there's no arch-dependent compiled binary version of a .cmake file (at least not yet). Based on the generic hints of hier(7), they should all be in share/cmake. But cmake supports (and encourages in cmake-packages(7)) package config files in lib/cmake. The docs for find_package in cmake-commands(7) describe the search hierarchy - it searches lib/cmake and share/cmake (at least on the unix-ish platforms) - but doesn't say why package files might be in either location. Note there exist now some config .cmake files in share/cmake and some in lib/cmake (as in the example cases I pointed out in the original post). The cmake project itself surely must have some policy written somewhere that describes what goes in each location. I just haven't found it yet. Or perhaps a lack of guidance has led to packagers picking either place without clear consensus and thus has led to some fragmentation. I'd also like to hear those opinions if people think that's the case. -- 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.1.2-1143-g6818ee6
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 6818ee67a5b1f81e3e5b7db36a49774d3dde8c99 (commit)
via 007bab6b400d1da0b4afb6a3b13fbbbe7b533361 (commit)
via 7ab4fb5760a03cfcf1317351ebc75c7cfd91de96 (commit)
from d96c269d8e899f9318ea4f30794b4b4b4f000a97 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6818ee67a5b1f81e3e5b7db36a49774d3dde8c99
commit 6818ee67a5b1f81e3e5b7db36a49774d3dde8c99
Merge: d96c269 007bab6
Author: Nils Gladitz nilsglad...@gmail.com
AuthorDate: Tue Feb 10 06:27:48 2015 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue Feb 10 06:27:48 2015 -0500
Merge topic 'makefile-missing-comment' into next
007bab6b Makefile: Fix target bound custom command COMMENT output.
7ab4fb57 CMake Nightly Date Stamp
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=007bab6b400d1da0b4afb6a3b13fbbbe7b533361
commit 007bab6b400d1da0b4afb6a3b13fbbbe7b533361
Author: Nils Gladitz nilsglad...@gmail.com
AuthorDate: Tue Feb 10 12:26:56 2015 +0100
Commit: Nils Gladitz nilsglad...@gmail.com
CommitDate: Tue Feb 10 12:26:56 2015 +0100
Makefile: Fix target bound custom command COMMENT output.
diff --git a/Source/cmLocalUnixMakefileGenerator3.cxx
b/Source/cmLocalUnixMakefileGenerator3.cxx
index fbf2140..dfa6cc9 100644
--- a/Source/cmLocalUnixMakefileGenerator3.cxx
+++ b/Source/cmLocalUnixMakefileGenerator3.cxx
@@ -1132,7 +1132,7 @@ cmLocalUnixMakefileGenerator3
if(echo_comment)
{
const char* comment = ccg.GetComment();
-if(comment !*comment)
+if(comment *comment)
{
this-AppendEcho(commands, comment,
cmLocalUnixMakefileGenerator3::EchoGenerate);
---
Summary of changes:
Source/CMakeVersion.cmake|2 +-
Source/cmLocalUnixMakefileGenerator3.cxx |2 +-
2 files 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
Re: [CMake] Problem writing on GPFS.
I want to thank Rolf here for his advice because I failed to do so in an off line reply. Shortly after I replied to Rolf's note, I received notification from IBM that the problem is related to our version of GPFS (4.1.0-2). Versions 4.1.0-3 and later apparently do not have the problem. Best regards, Phil P. A. Cheeseman a...@purdue.edu 765.496.8224 -Original Message- From: Rolf Eike Beer [mailto:e...@sf-mail.de] Sent: Tuesday, February 10, 2015 13:44 To: cmake@cmake.org; a...@purdue.edu Subject: Re: [CMake] Problem writing on GPFS. P. A. Cheeseman wrote: System: RHEL6 (2.6.32-504.8.1.el6.x86_64) Hardware: Various cluster nodes. A C code with explicit writev() calls, with a NULL pointer in the first iovec entry, also reproduces the behavior. When the NULL is part of any entry other than the first, the code runs identically for all storage. I would suggest contacting Red Hat. This sounds for me like a bug in the GPFS code, especially since the call succeeds if the (NULL, 0) pair is in a later pair. Other than that, I don't see a reason why g++ should emit such a call. Should probably be reported to the gcc guys. Or maybe this is just something in your libc, so gcc isn't at fault at all. Probably time for the Red Hat guys to investigate, too ;) Eike -- -- 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] Problem writing on GPFS.
System: RHEL6 (2.6.32-504.8.1.el6.x86_64)
Hardware: Various cluster nodes.
We recently deployed GPFS storage and have discovered that
Cmake fails when writing to files in the GPFS storage. The source
of the problem, identified by using strace(1), appears to be a NULL
pointer in the first entry of writev(2) iovec argument. The line
below is representative of what we see in the strace output.
writev(3, [{NULL, 0}, {\n#ifdef __cplusplus\n# error \A C..., 15135}], 2)
= -1 EINVAL (Invalid argument)
On non-GPFS storage, the files are written w/o problem. The
NULL pointer in the first iovec entry is silently ignored.
The failures occur for Cmake installations made using Gcc 4.4.7,
4.7.2, 4.9.2, and all Intel compilers we've tried so far.
We have worked around the problem by building Cmake 3.1.1
with PGI 11.8-0 which does not use the writev() system calls in its
run-time.
Has anyone else observed this symptom with GPFS?
Is anyone familiar enough with the Cmake code to know why
the g++ compiler run-time uses writev() in the first place? I have not
been able to reproduce the writev() system calls with a short C++
program so far.
The problem reproduces for us by attempting to build Cmake
from source with the source tree on GPFS. For instance ...
./bootstrap --prefix=someinstallpoint
with CWD at the top of the source tree, using g++.
A C code with explicit writev() calls, with a NULL pointer in
the first iovec entry, also reproduces the behavior. When the
NULL is part of any entry other than the first, the code runs
identically for all storage.
Thanks,
Phil
P. A. Cheeseman
a...@purdue.edu
765.496.8224
--
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] Problem writing on GPFS.
P. A. Cheeseman wrote: System: RHEL6 (2.6.32-504.8.1.el6.x86_64) Hardware: Various cluster nodes. A C code with explicit writev() calls, with a NULL pointer in the first iovec entry, also reproduces the behavior. When the NULL is part of any entry other than the first, the code runs identically for all storage. I would suggest contacting Red Hat. This sounds for me like a bug in the GPFS code, especially since the call succeeds if the (NULL, 0) pair is in a later pair. Other than that, I don't see a reason why g++ should emit such a call. Should probably be reported to the gcc guys. Or maybe this is just something in your libc, so gcc isn't at fault at all. Probably time for the Red Hat guys to investigate, too ;) Eike -- signature.asc Description: This is a digitally signed message part. -- 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] GCC5 and C++11 ABI
On Fri, Feb 06, 2015 at 13:15:45 -0500, Ben Boeckel wrote: Looks like compiler_feature_detection will need to normalize the _GLIBCXX_USE_CXX11_ABI preprocessor define as well: http://developerblog.redhat.com/2015/02/05/gcc5-and-the-c11-abi/ Followup (LWN comments will likely have interesting detail as well): https://lwn.net/Articles/632734/ --Ben -- 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] Problem writing on GPFS.
Phil,
Could you give me a ticket or bug number (however they track it) for GPFS
that describes this as a known bug? I will need that when submitting a
ticket to my organization's helpdesk. This problem is quite a lot larger
than CMake: all C++ programs will break.
Sincerely,
Sam Trahan
On Tue, Feb 10, 2015 at 4:09 PM, P. A. Cheeseman a...@purdue.edu wrote:
Reading into the final resolution of the IBM ticket tipped me to
where the writev() calls originate in the C++ run-time. The amount of data
has to be 1K or more before writev() is used. Then the NULL pointer in the
iovec is assured with our versions of Gcc/G++. I've just compiled and run
...
#include iostream
#include fstream
using namespace std;
main()
{
ofstream file;
std::string message;
message += Line 00\n;
message += Line 01\n;
// Enough of these to create 1K ... //
file.open(popeye,ios::binary);
file message;
file.close();
return(0);
}
to mimic what happens in cmFileCommand::HandleWriteCommand(). The
writev() calls appear in the strace after that. The workaround until GPFS
catches up would be to disrupt the approach in HandleWriteCommand by
pushing out the string(s) in parts less than 1K so the run-time will use
write() instead of marginal calls to writev() (if you care to go that far
:-)).
Another workaround is to (sigh) build off of GPFS and rsync the
installation to its final destination, patching any hard coded paths along
the way (again, sigh).
I'm not deep into the chain of handling under RedHat but I suspect
the iovec is handed down through the system from the compiler run-time
until it reaches a handler specific to the storage. I frankly wonder why
the marginal calls make it out of the compiler run-time.
In any case, the Cmake code really isn't at fault, if I'm following
things correctly. If I pursue further, I'll be seeing if the compiler
suite support and/or RedHat can explain the necessity of the NULLs :-).
Thanks to
all,
Phil
P. A.
Cheeseman
a...@purdue.edu
765.496.8224
*From:* Samuel Trahan - NOAA Affiliate [mailto:samuel.tra...@noaa.gov]
*Sent:* Tuesday, February 10, 2015 14:44
*To:* a...@purdue.edu
*Cc:* cmake@cmake.org
*Subject:* Re: [CMake] Problem writing on GPFS.
Does anyone know of a workaround for this which does not require upgrading
GPFS or changing compilers?
On Tue, Feb 10, 2015 at 2:24 PM, P. A. Cheeseman a...@purdue.edu wrote:
I want to thank Rolf here for his advice because I failed to
do so in an off line reply.
Shortly after I replied to Rolf's note, I received notification from
IBM that the problem is related to our version of GPFS (4.1.0-2).
Versions 4.1.0-3 and later apparently do not have the problem.
Best regards,
Phil
P. A. Cheeseman
a...@purdue.edu
765.496.8224
-Original Message-
From: Rolf Eike Beer [mailto:e...@sf-mail.de]
Sent: Tuesday, February 10, 2015 13:44
To: cmake@cmake.org; a...@purdue.edu
Subject: Re: [CMake] Problem writing on GPFS.
P. A. Cheeseman wrote:
System: RHEL6 (2.6.32-504.8.1.el6.x86_64)
Hardware: Various cluster nodes.
A C code with explicit writev() calls, with a NULL pointer in the
first iovec entry, also reproduces the behavior. When the NULL is
part of any entry other than the first, the code runs identically for
all storage.
I would suggest contacting Red Hat. This sounds for me like a bug in the
GPFS
code, especially since the call succeeds if the (NULL, 0) pair is in a
later pair.
Other than that, I don't see a reason why g++ should emit such a call.
Should
probably be reported to the gcc guys. Or maybe this is just something in
your
libc, so gcc isn't at fault at all. Probably time for the Red Hat guys to
investigate, too ;)
Eike
--
--
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
Re: [CMake] Problem writing on GPFS.
Reading into the final resolution of the IBM ticket tipped me to where the
writev() calls originate in the C++ run-time. The amount of data has to be 1K
or more before writev() is used. Then the NULL pointer in the iovec is assured
with our versions of Gcc/G++. I've just compiled and run ...
#include iostream
#include fstream
using namespace std;
main()
{
ofstream file;
std::string message;
message += Line 00\n;
message += Line 01\n;
// Enough of these to create 1K ... //
file.open(popeye,ios::binary);
file message;
file.close();
return(0);
}
to mimic what happens in cmFileCommand::HandleWriteCommand(). The writev()
calls appear in the strace after that. The workaround until GPFS catches up
would be to disrupt the approach in HandleWriteCommand by pushing out the
string(s) in parts less than 1K so the run-time will use write() instead of
marginal calls to writev() (if you care to go that far :-)).
Another workaround is to (sigh) build off of GPFS and rsync the
installation to its final destination, patching any hard coded paths along the
way (again, sigh).
I'm not deep into the chain of handling under RedHat but I suspect the
iovec is handed down through the system from the compiler run-time until it
reaches a handler specific to the storage. I frankly wonder why the marginal
calls make it out of the compiler run-time.
In any case, the Cmake code really isn't at fault, if I'm following things
correctly. If I pursue further, I'll be seeing if the compiler suite support
and/or RedHat can explain the necessity of the NULLs :-).
Thanks to all,
Phil
P. A. Cheeseman
a...@purdue.edu
765.496.8224
From: Samuel Trahan - NOAA Affiliate [mailto:samuel.tra...@noaa.gov]
Sent: Tuesday, February 10, 2015 14:44
To: a...@purdue.edu
Cc: cmake@cmake.org
Subject: Re: [CMake] Problem writing on GPFS.
Does anyone know of a workaround for this which does not require upgrading GPFS
or changing compilers?
On Tue, Feb 10, 2015 at 2:24 PM, P. A. Cheeseman a...@purdue.edu wrote:
I want to thank Rolf here for his advice because I failed to
do so in an off line reply.
Shortly after I replied to Rolf's note, I received notification from
IBM that the problem is related to our version of GPFS (4.1.0-2).
Versions 4.1.0-3 and later apparently do not have the problem.
Best regards,
Phil
P. A. Cheeseman
a...@purdue.edu
765.496.8224
-Original Message-
From: Rolf Eike Beer [mailto:e...@sf-mail.de]
Sent: Tuesday, February 10, 2015 13:44
To: cmake@cmake.org; a...@purdue.edu
Subject: Re: [CMake] Problem writing on GPFS.
P. A. Cheeseman wrote:
System: RHEL6 (2.6.32-504.8.1.el6.x86_64)
Hardware: Various cluster nodes.
A C code with explicit writev() calls, with a NULL pointer in the
first iovec entry, also reproduces the behavior. When the NULL is
part of any entry other than the first, the code runs identically for
all storage.
I would suggest contacting Red Hat. This sounds for me like a bug in the
GPFS
code, especially since the call succeeds if the (NULL, 0) pair is in a
later pair.
Other than that, I don't see a reason why g++ should emit such a call.
Should
probably be reported to the gcc guys. Or maybe this is just something in
your
libc, so gcc isn't at fault at all. Probably time for the Red Hat guys to
investigate, too ;)
Eike
--
--
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
Re: [CMake] lib/cmake vs share/cmake/Modules
On Tuesday, February 10, 2015 03:43:33 44ghnqv...@snkmail.com wrote: Alexander Neundorf wrote at 21:34 +0100 on Feb 9, 2015: On Monday, February 09, 2015 18:23:41 44ghnqv...@snkmail.com wrote: How does one who is making a package which installs .cmake files decide whether to put them in .../share/cmake/Modules or .../lib/cmake? Where are the docs about that? I've seen examples of 3rd party packages doing both (e.g., pulseaudio in lib/cmake/Foo opencollada - in share/cmake/Modules). architecture-independent files, i.e. which could sit on a shared NFS drive and which could be mounted from hosts with any type of CPU architecture, go into share/, i.e. basically data or text files. Files which are architecture dependend, e.g. Config.cmake files for installed libraries, go into lib/. (in doubt, lib/ is the safe choice). I'm looking for official cmake docs that explain the difference between the two locations from cmake's perspective (rather than just guidelines reiterated from hier(7)). I'm not aware for any more official docs, and if there are some, I doubt that they would contradict hier(7). So, Config.cmake files for libraries into lib/, for packages which are e.g. header only or similar share/ it is. If there are Config.cmake files for libraries which ar in shared I would consider this a bug. Alex -- 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] Problem writing on GPFS.
Does anyone know of a workaround for this which does not require upgrading GPFS or changing compilers? On Tue, Feb 10, 2015 at 2:24 PM, P. A. Cheeseman a...@purdue.edu wrote: I want to thank Rolf here for his advice because I failed to do so in an off line reply. Shortly after I replied to Rolf's note, I received notification from IBM that the problem is related to our version of GPFS (4.1.0-2). Versions 4.1.0-3 and later apparently do not have the problem. Best regards, Phil P. A. Cheeseman a...@purdue.edu 765.496.8224 -Original Message- From: Rolf Eike Beer [mailto:e...@sf-mail.de] Sent: Tuesday, February 10, 2015 13:44 To: cmake@cmake.org; a...@purdue.edu Subject: Re: [CMake] Problem writing on GPFS. P. A. Cheeseman wrote: System: RHEL6 (2.6.32-504.8.1.el6.x86_64) Hardware: Various cluster nodes. A C code with explicit writev() calls, with a NULL pointer in the first iovec entry, also reproduces the behavior. When the NULL is part of any entry other than the first, the code runs identically for all storage. I would suggest contacting Red Hat. This sounds for me like a bug in the GPFS code, especially since the call succeeds if the (NULL, 0) pair is in a later pair. Other than that, I don't see a reason why g++ should emit such a call. Should probably be reported to the gcc guys. Or maybe this is just something in your libc, so gcc isn't at fault at all. Probably time for the Red Hat guys to investigate, too ;) Eike -- -- 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] Pass GNU flags on Windows
I am attempting to run CMake and use clang for the compiler. I am on Windows 8.1. It seems to me that if CMake used gcc flags instead of vc++ flags that this would work. Any ideas how I can make this work? I use the following command: cmake -DCMAKE_C_COMPILER=clang.exe DCMAKE_CXX_COMPILER=clang++.exe -DCMAKE_RC_COMPILER=rc.exe -G Ninja ../llvm When it attempts to test the compiler I get the following results: Run Build Command:d:/llvm/ninja/ninja.exe cmTryCompileExec2377752233 [1/2] Building C object CMakeFiles\cmTryCompileExec2377752233.dir\testCCompiler.c.obj FAILED: d:\llvm\build\Release\bin\clang.exe /nologo /DWIN32 /D_WINDOWS /W3 /D_DEBUG /MDd /Zi /Ob0 /Od /RTC1 /showIncludes /FoCMakeFiles\cmTryCompileExec2377752233.dir\testCCompiler.c.obj /FdCMakeFiles\cmTryCompileExec2377752233.dir\ -c testCCompiler.c clang.exe: error: no such file or directory: '/nologo' clang.exe: error: no such file or directory: '/DWIN32' clang.exe: error: no such file or directory: '/D_WINDOWS' clang.exe: error: no such file or directory: '/W3' clang.exe: error: no such file or directory: '/D_DEBUG' clang.exe: error: no such file or directory: '/MDd' clang.exe: error: no such file or directory: '/Zi' clang.exe: error: no such file or directory: '/Ob0' clang.exe: error: no such file or directory: '/Od' clang.exe: error: no such file or directory: '/RTC1' clang.exe: error: no such file or directory: '/showIncludes' clang.exe: error: no such file or directory: '/FoCMakeFiles\cmTryCompileExec2377752233.dir\testCCompiler.c.obj' clang.exe: error: no such file or directory: '/FdCMakeFiles\cmTryCompileExec2377752233.dir\' ninja: build stopped: subcommand failed. -- 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] Problem writing on GPFS.
Do you intentionally removed or just forgot to CC the list? I failed to 'reply-all'. One additional note. Turning off optimization didn't help, among the other things I tried. My own read of the issue is that there is room to trap the bad pointer at every layer in its handling. I suspect the run-time ignores them because that was easier than watching 'working' codes break wholesale if the existing convention were to throw an error (as write(2) does). Best regards, Phil P. A. Cheeseman a...@purdue.edu 765.496.8224 -Original Message- From: Rolf Eike Beer [mailto:e...@sf-mail.de] Sent: Tuesday, February 10, 2015 14:18 To: a...@purdue.edu Subject: Re: [CMake] Problem writing on GPFS. P. A. Cheeseman wrote: RedHat and GNU support are on the todo list once I can identify what's in the Cmake source that tricks the run-time into using writev(). Several gdb(1) sessions led me to the top end source of the calls which is cmFileCommand::HandleWriteCommand(). I've not traced through the multiple layers of run-time to see where the iovec array is created from the 'file message' line. Ah, but that's a good clue. g++ may just optimize the message writing into that, or libstdc++ may. You may try with CXXFLAGS=-O0 to see it it works then. The fact that the run-time from either GNU or Redhat generates the marginal call is bothersome. I suspect the fundamental problem has existed for some time. Have also not found any reference to what is 'correct' behavior for writev() when a pointer is NULL but I'm not a dedicated student of POSIX etc. I don't know, but given the fact that it works in a latter place and on all other fs makes it look like a bug to me. Do you intentionally removed or just forgot to CC the list? Eike -- -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
[Cmake-commits] CMake branch, master, updated. v3.1.2-1082-g1979330
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 197933018863c4845262dd6fb47e4edf721445f1 (commit) from cbffbf7437ea2d571e26bedee032c23be9347d94 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=197933018863c4845262dd6fb47e4edf721445f1 commit 197933018863c4845262dd6fb47e4edf721445f1 Author: Kitware Robot kwro...@kitware.com AuthorDate: Wed Feb 11 00:01:09 2015 -0500 Commit: Kitware Robot kwro...@kitware.com CommitDate: Wed Feb 11 00:01:09 2015 -0500 CMake Nightly Date Stamp diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake index 03df29d..62cc2b6 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 2) -set(CMake_VERSION_PATCH 20150210) +set(CMake_VERSION_PATCH 20150211) #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-developers] [PATCH] CPackRPM: Fix cross-building rpms
I've finally had some time to read over the Tests section, and it is a bit overwhelming. I'm going to describe the use cases for my patch and perhaps you can give me some guidance on adding an actual test. There are three, maybe four use cases: 1) native rpm (e.g. x86_64) 2) noarch rpm (a noarch package should contain scripts, artwork, etc, but no compiled code) 3) a non-native, but compatible rpm (e.g. building x86 on a multilib x86_64 system) 4) incompatible cross-compiled package (e.g. building for arm or ppc) in each case the way you know it worked is a) make package successfully produces an rpm file b) running rpm -qip my_rpm_file.my_arch.rpm returns a description of the rpm, including the line Architecture: my_arch On Tue, Feb 3, 2015 at 11:50 PM, Domen Vrankar domen.vran...@gmail.com wrote: Add the --target argument to rpmbuild Do not add a BuildArch variable to the spec file for arch specific packages BuildArch causes rpm building to fail except for noarch packages I'm not too familiar with cross compilation problems so could you please also provide a simple test case to help with patch review? Thanks, Domen -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [CMake] Problem writing on GPFS.
Here's a start. If I post to GNU/RedHat, I'll pass that along too.
http://www-01.ibm.com/support/docview.wss?uid=isg3T1021392
I understand the problem is bigger. It's helped me to understand why I'm
having problems with C++ support for other packages. I'm still wondering how
long the compiler/run-time has produced the risky writev() calls.
Best regards,
Phil
P. A. Cheeseman
a...@purdue.edu
765.496.8224
From: Samuel Trahan - NOAA Affiliate [mailto:samuel.tra...@noaa.gov]
Sent: Tuesday, February 10, 2015 16:35
To: a...@purdue.edu
Cc: cmake@cmake.org
Subject: Re: [CMake] Problem writing on GPFS.
Phil,
Could you give me a ticket or bug number (however they track it) for GPFS that
describes this as a known bug? I will need that when submitting a ticket to my
organization's helpdesk. This problem is quite a lot larger than CMake: all
C++ programs will break.
Sincerely,
Sam Trahan
On Tue, Feb 10, 2015 at 4:09 PM, P. A. Cheeseman a...@purdue.edu wrote:
Reading into the final resolution of the IBM ticket tipped me to where the
writev() calls originate in the C++ run-time. The amount of data has to be 1K
or more before writev() is used. Then the NULL pointer in the iovec is assured
with our versions of Gcc/G++. I've just compiled and run ...
#include iostream
#include fstream
using namespace std;
main()
{
ofstream file;
std::string message;
message += Line 00\n;
message += Line 01\n;
// Enough of these to create 1K ... //
file.open(popeye,ios::binary);
file message;
file.close();
return(0);
}
to mimic what happens in cmFileCommand::HandleWriteCommand(). The writev()
calls appear in the strace after that. The workaround until GPFS catches up
would be to disrupt the approach in HandleWriteCommand by pushing out the
string(s) in parts less than 1K so the run-time will use write() instead of
marginal calls to writev() (if you care to go that far :-)).
Another workaround is to (sigh) build off of GPFS and rsync the
installation to its final destination, patching any hard coded paths along the
way (again, sigh).
I'm not deep into the chain of handling under RedHat but I suspect the
iovec is handed down through the system from the compiler run-time until it
reaches a handler specific to the storage. I frankly wonder why the marginal
calls make it out of the compiler run-time.
In any case, the Cmake code really isn't at fault, if I'm following things
correctly. If I pursue further, I'll be seeing if the compiler suite support
and/or RedHat can explain the necessity of the NULLs :-).
Thanks to all,
Phil
P. A. Cheeseman
a...@purdue.edu
765.496.8224
From: Samuel Trahan - NOAA Affiliate [mailto:samuel.tra...@noaa.gov]
Sent: Tuesday, February 10, 2015 14:44
To: a...@purdue.edu
Cc: cmake@cmake.org
Subject: Re: [CMake] Problem writing on GPFS.
Does anyone know of a workaround for this which does not require upgrading GPFS
or changing compilers?
On Tue, Feb 10, 2015 at 2:24 PM, P. A. Cheeseman a...@purdue.edu wrote:
I want to thank Rolf here for his advice because I failed to
do so in an off line reply.
Shortly after I replied to Rolf's note, I received notification from
IBM that the problem is related to our version of GPFS (4.1.0-2).
Versions 4.1.0-3 and later apparently do not have the problem.
Best regards,
Phil
P. A. Cheeseman
a...@purdue.edu
765.496.8224
-Original Message-
From: Rolf Eike Beer [mailto:e...@sf-mail.de]
Sent: Tuesday, February 10, 2015 13:44
To: cmake@cmake.org; a...@purdue.edu
Subject: Re: [CMake] Problem writing on GPFS.
P. A. Cheeseman wrote:
System: RHEL6 (2.6.32-504.8.1.el6.x86_64)
Hardware: Various cluster nodes.
A C code with explicit writev() calls, with a NULL pointer in the
first iovec entry, also reproduces the behavior. When the NULL is
part of any entry other than the first, the code runs identically for
all storage.
I would suggest contacting Red Hat. This sounds for me like a bug in the
GPFS
[Cmake-commits] CMake branch, next, updated. v3.1.2-1183-gfd2cc9a
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 fd2cc9a1071279c0e3d41c38d670d0e669ab92bb (commit)
via a06feb122e5a76f43f2cdbfe6ef5ed54ad711375 (commit)
from 5e36f8ee1ebf4538146f9f0cb5974426eac14249 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fd2cc9a1071279c0e3d41c38d670d0e669ab92bb
commit fd2cc9a1071279c0e3d41c38d670d0e669ab92bb
Merge: 5e36f8e a06feb1
Author: Domen Vrankar domen.vran...@gmail.com
AuthorDate: Tue Feb 10 17:04:53 2015 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue Feb 10 17:04:53 2015 -0500
Merge topic 'cpack_rpm_mulit_prefix_policy_version_fixup' into next
a06feb12 fixup! cpack_rpm_mulit_prefix
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a06feb122e5a76f43f2cdbfe6ef5ed54ad711375
commit a06feb122e5a76f43f2cdbfe6ef5ed54ad711375
Author: Domen Vrankar domen.vran...@gmail.com
AuthorDate: Tue Feb 10 23:03:06 2015 +0100
Commit: Domen Vrankar domen.vran...@gmail.com
CommitDate: Tue Feb 10 23:03:06 2015 +0100
fixup! cpack_rpm_mulit_prefix
Fix infinite loop with symbolic links when using minimum
required cmake version with CMP0009 policy not set in
logic added by commit 3ec02547 (CPackRPM: Allow multiple
path relocation prefixes for one package, 2015-01-21).
diff --git a/Modules/CPackRPM.cmake b/Modules/CPackRPM.cmake
index 214d655..c53caa1 100644
--- a/Modules/CPackRPM.cmake
+++ b/Modules/CPackRPM.cmake
@@ -423,6 +423,10 @@
# Author: Eric Noulard with the help of Alexander Neundorf.
+# prevent older policies from interfearing with this script
+cmake_policy(PUSH)
+cmake_policy(VERSION ${CMAKE_VERSION})
+
function(cpack_rpm_prepare_relocation_paths)
# set appropriate prefix, remove possible trailing slash and convert
backslashes to slashes
if(CPACK_RPM_${CPACK_RPM_PACKAGE_COMPONENT}_PACKAGE_PREFIX)
@@ -1308,3 +1312,6 @@ if(CPACK_RPM_PACKAGE_DESCRIPTION_)
else()
unset(CPACK_RPM_PACKAGE_DESCRIPTION)
endif()
+
+# restore previous policies
+cmake_policy(POP)
---
Summary of changes:
Modules/CPackRPM.cmake |7 +++
1 file changed, 7 insertions(+)
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.1.2-1077-g2fd44b0
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 2fd44b082b0a8e546c73d921f9d8264a668c3b78 (commit) via c0d8e715915f65196353c09d86d4d34fe100437f (commit) via 68d29f519047aeef92a0ab8fef531010c311efaa (commit) via 1c3918ff0278715e2a4ec5929f75f7812003ee97 (commit) from d46e1e3f0fa386638b5a50b45783f4ec4d94bf2c (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2fd44b082b0a8e546c73d921f9d8264a668c3b78 commit 2fd44b082b0a8e546c73d921f9d8264a668c3b78 Merge: d46e1e3 c0d8e71 Author: Brad King brad.k...@kitware.com AuthorDate: Tue Feb 10 10:09:47 2015 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Tue Feb 10 10:09:47 2015 -0500 Merge topic 'test-RunCMake-updates' c0d8e715 RunCMake: Allow specifying the stderr file for a test. 68d29f51 RunCMake: Allow specifying the directory to run tests in. 1c3918ff RunCMake: Remove unneeded files. --- Summary of changes: Tests/RunCMake/CMP0022/CMP0022-NOWARN-exe-stderr.txt |1 - .../RunCMake/CMP0022/CMP0022-NOWARN-shared-stderr.txt |1 - .../CMP0022/CMP0022-NOWARN-static-NEW-stderr.txt |1 - .../CMP0022-NOWARN-static-link_libraries-stderr.txt |1 - .../RunCMake/CMP0022/CMP0022-NOWARN-static-stderr.txt |1 - Tests/RunCMake/CMP0022/CMP0022-export-exe-stderr.txt |1 - .../CMP0026/CMP0026-CONFIG-LOCATION-OLD-stderr.txt|1 - Tests/RunCMake/CMP0026/CMP0026-IMPORTED-stderr.txt|1 - .../CMP0026/CMP0026-LOCATION-CONFIG-OLD-stderr.txt|1 - Tests/RunCMake/CMP0028/CMP0028-OLD-iface-stderr.txt |1 - Tests/RunCMake/CMP0028/CMP0028-OLD-stderr.txt |1 - .../RunCMake/CMP0037/CMP0037-OLD-reserved-stderr.txt |1 - Tests/RunCMake/CMP0037/CMP0037-OLD-space-stderr.txt |1 - Tests/RunCMake/CMP0038/CMP0038-OLD-stderr.txt |1 - Tests/RunCMake/CMP0039/CMP0039-OLD-stderr.txt |1 - .../CMP0040/CMP0040-NEW-existing-target-stderr.txt|1 - .../CMP0040/CMP0040-OLD-existing-target-stderr.txt|1 - .../CMP0040/CMP0040-OLD-missing-target-stderr.txt |1 - Tests/RunCMake/CMP0041/CMP0041-OLD-stderr.txt |1 - Tests/RunCMake/CMP0041/CMP0041-tid-OLD-stderr.txt |1 - Tests/RunCMake/CMP0042/CMP0042-NEW-stderr.txt |1 - Tests/RunCMake/CMP0042/CMP0042-OLD-stderr.txt |1 - Tests/RunCMake/CMP0043/CMP0043-NEW-stderr.txt |1 - Tests/RunCMake/CMP0043/CMP0043-OLD-stderr.txt |1 - Tests/RunCMake/CMP0045/CMP0045-OLD-stderr.txt |1 - .../CMP0046-NEW-existing-dependency-stderr.txt|1 - .../CMP0046-OLD-existing-dependency-stderr.txt|1 - .../CMP0046/CMP0046-OLD-missing-dependency-stderr.txt |1 - Tests/RunCMake/CMP0049/CMP0049-OLD-stderr.txt |1 - Tests/RunCMake/CMP0050/CMP0050-OLD-stderr.txt |1 - .../CMP0055/CMP0055-OLD-Out-of-Scope-stderr.txt |1 - .../CMP0055/CMP0055-OLD-Reject-Arguments-stderr.txt |1 - Tests/RunCMake/CMakeLists.txt | 17 ++--- .../LinkImplementationFeatureCycleSolved-stderr.txt |1 - .../DisallowedCommands/CMP0029-OLD-stderr.txt |1 - .../File_Generate/CarryPermissions-stderr.txt |1 - .../RunCMake/File_Generate/GenerateSource-stderr.txt |1 - .../OutputNameMatchesOtherSources-stderr.txt |1 - Tests/RunCMake/File_Generate/ReRunCMake-stderr.txt|1 - .../File_Generate/WriteIfDifferent-stderr.txt |1 - .../ValidTarget-TARGET_PDB_FILE-stderr.txt|1 - Tests/RunCMake/RunCMake.cmake |5 - Tests/RunCMake/Syntax/ParenNoSpace2-stderr.txt|1 - .../LinkImplementationCycle3-stderr.txt |1 - .../TargetSources/CMP0026-LOCATION-stderr.txt |1 - .../BinInInstallPrefix-CMP0052-OLD-stderr.txt |1 - .../include_directories/DirInInstallPrefix-stderr.txt |1 - .../InstallPrefixInInterface-stderr.txt |1 - .../InstallToPrefixInSrcDirInSource-stderr.txt|1 - .../InstallToPrefixInSrcDirOutOfSource-stderr.txt |1 - .../SrcInInstallPrefix-CMP0052-OLD-stderr.txt |1 - .../include_directories/export-NOWARN-stderr.txt |1 - .../install/SkipInstallRulesNoWarning1-stderr.txt |1 - .../install/SkipInstallRulesNoWarning2-stderr.txt |1 - .../RunCMake/interface_library/genex_link-stderr.txt |1 - .../interface_library/no_shared_libs-stderr.txt
Re: [cmake-developers] [PATCH] add --sphinx-qthelp command line argument to bootstrap script.
On 02/07/2015 05:23 PM, Nuno Sucena Almeida wrote: --- bootstrap | 8 1 file changed, 8 insertions(+) Thanks, applied: bootstrap: Add --sphinx-qthelp option to enable qthelp doc generation http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=85fd62ee -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] Error in Cmake Installation
Hi All, While installing cmake using below option, I am facing the error in step 3. Step1: ./bootstarp Step2: make step: make install Error after step 3: *CMake Error at cmake_install.cmake:36 (file): file INSTALL cannot set permissions on /usr/local/doc/cmake-3.1/Copyright.txt* How to overcome this issue ? -- Best Regards, Gunjan -- 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] Error in Cmake Installation
Try running: sudo make install Instead. On Feb 10, 2015, at 7:45 AM, Gunjan Gautam gunjan.gemin...@gmail.commailto:gunjan.gemin...@gmail.com wrote: Hi All, While installing cmake using below option, I am facing the error in step 3. Step1: ./bootstarp Step2: make step: make install Error after step 3: CMake Error at cmake_install.cmake:36 (file): file INSTALL cannot set permissions on /usr/local/doc/cmake-3.1/Copyright.txt How to overcome this issue ? -- Best Regards, Gunjan -- Powered by www.kitware.comhttp://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.1.2-1208-gdb0f1df
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 db0f1df7bada28ea675fb563803786e7251c42b9 (commit)
via f7e33820b628f39ae2e0ba3d25279545dfe18f73 (commit)
via 6da65b3907419df28484c570f24d0da3593a0e5a (commit)
via 736bcb9664b714b91e8a2a573451e0453716f4da (commit)
from 03d60ba97b9790ec80a22be5b51d91492235a11f (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=db0f1df7bada28ea675fb563803786e7251c42b9
commit db0f1df7bada28ea675fb563803786e7251c42b9
Merge: 03d60ba f7e3382
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Tue Feb 10 18:52:08 2015 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue Feb 10 18:52:08 2015 -0500
Merge topic 'export-interface-source-files' into next
f7e33820 Add release notes for export-interface-source-files.
6da65b39 Allow export of targets with INTERFACE_SOURCES.
736bcb96 Tests: Move IfacePaths test stderr files.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f7e33820b628f39ae2e0ba3d25279545dfe18f73
commit f7e33820b628f39ae2e0ba3d25279545dfe18f73
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Thu Feb 5 20:40:51 2015 +0100
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Wed Feb 11 00:51:35 2015 +0100
Add release notes for export-interface-source-files.
diff --git a/Help/release/dev/export-interface-source-files.rst
b/Help/release/dev/export-interface-source-files.rst
new file mode 100644
index 000..00dcd25
--- /dev/null
+++ b/Help/release/dev/export-interface-source-files.rst
@@ -0,0 +1,6 @@
+export-interface-source-files
+-
+
+* It is now possible to export targets which populate the
+ :prop_tgt:`INTERFACE_SOURCES` target property using the
+ :command:`install(EXPORT)` and :command:`export()` commands.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6da65b3907419df28484c570f24d0da3593a0e5a
commit 6da65b3907419df28484c570f24d0da3593a0e5a
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Fri Nov 28 18:58:38 2014 +0100
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Wed Feb 11 00:51:34 2015 +0100
Allow export of targets with INTERFACE_SOURCES.
Use the same rules for paths in source and binary dirs in
installed INTERFACE_SOURCES as are used for
INTERFACE_INCLUDE_DIRECTORIES.
diff --git a/Help/command/target_sources.rst b/Help/command/target_sources.rst
index 832240a..d6f148d 100644
--- a/Help/command/target_sources.rst
+++ b/Help/command/target_sources.rst
@@ -22,10 +22,6 @@ items will populate the :prop_tgt:`SOURCES` property of
following arguments specify sources. Repeated calls for the same
``target`` append items in the order called.
-Targets with :prop_tgt:`INTERFACE_SOURCES` may not be exported with the
-:command:`export` or :command:`install(EXPORT)` commands. This limitation may
be
-lifted in a future version of CMake.
-
Arguments to ``target_sources`` may use generator expressions
with the syntax ``$...``. See the :manual:`cmake-generator-expressions(7)`
manual for available expressions. See the :manual:`cmake-buildsystem(7)`
diff --git a/Help/prop_tgt/INTERFACE_SOURCES.rst
b/Help/prop_tgt/INTERFACE_SOURCES.rst
index 696ee95..a224b68 100644
--- a/Help/prop_tgt/INTERFACE_SOURCES.rst
+++ b/Help/prop_tgt/INTERFACE_SOURCES.rst
@@ -12,10 +12,6 @@ When target dependencies are specified using
:command:`target_link_libraries`,
CMake will read this property from all target dependencies to determine the
sources of the consumer.
-Targets with ``INTERFACE_SOURCES`` may not be exported with the
-:command:`export` or :command:`install(EXPORT)` commands. This limitation may
be
-lifted in a future version of CMake.
-
Contents of ``INTERFACE_SOURCES`` may use generator expressions
with the syntax ``$...``. See the :manual:`cmake-generator-expressions(7)`
manual for available expressions. See the :manual:`cmake-buildsystem(7)`
diff --git a/Source/cmExportBuildFileGenerator.cxx
b/Source/cmExportBuildFileGenerator.cxx
index a28ec48..b1203dd 100644
--- a/Source/cmExportBuildFileGenerator.cxx
+++ b/Source/cmExportBuildFileGenerator.cxx
@@ -68,16 +68,6 @@ bool
cmExportBuildFileGenerator::GenerateMainFile(std::ostream os)
tei != this-Exports.end(); ++tei)
{
cmTarget* te = *tei;
-if (te-GetProperty(INTERFACE_SOURCES))
- {
- std::ostringstream e;
- e Target \
- te-GetName()
- \ has a populated INTERFACE_SOURCES property. This is not
- currently supported.;
- cmSystemTools::Error(e.str().c_str());
- return false;
- }
[Cmake-commits] CMake branch, next, updated. v3.1.2-1204-g03d60ba
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 03d60ba97b9790ec80a22be5b51d91492235a11f (commit)
via a7c8ee44932d6983dea9a55bf18857ee9aa3e75f (commit)
via f09d355d7dd7f1d66b7f43980523b673f12f6798 (commit)
via 63dcb641c903d97f4e26a83e3efcf24acbb44f53 (commit)
via 87680637654721c4827636f571f794865c2c0a55 (commit)
via 709e3e17fbbc3fec6dc30d31c8f3a083f5e83d8e (commit)
via cc02a6647b5473d3c92318f134ffa6ef081564d7 (commit)
via 780f75dc43f754e3ad10bf48328a33c1d2173463 (commit)
via d4cee4e382e48949920b81e7219ab48f06bfc398 (commit)
via 1e57ca6f0f69efb3238a98434fb086c30f1a02f1 (commit)
via 55a11552a49c59b786feb9c229ec2d4ee84a70e7 (commit)
via 05097f44d032e65891746edf5fecc610017ef214 (commit)
via 4d3b952d7b2d4d708d823914e49c07cd9c065880 (commit)
via ee1304531efb85b41d3c2f84f32c7d2901298be7 (commit)
via b4edadd2c32f881a06c79ab7c1385a27ddc4b971 (commit)
via 7b92bdd86f6d180031d8beaf4dc971eab8d3 (commit)
via 8da80aed2d8b2d82f0bd56804fe9366ea651d516 (commit)
via 45795a9a2e8d51b72fb5f19a5de1db628c7dd2cb (commit)
via 562a3ea3d4c4ba431f7c109c6fac41decba96e50 (commit)
via 7e7d489030dbd63dfb00d407b4d61a33d55747b5 (commit)
via ac26d4b343aece40b6b9a931ab619fc88d4b9492 (commit)
from fd2cc9a1071279c0e3d41c38d670d0e669ab92bb (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=03d60ba97b9790ec80a22be5b51d91492235a11f
commit 03d60ba97b9790ec80a22be5b51d91492235a11f
Merge: fd2cc9a a7c8ee4
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Tue Feb 10 18:50:01 2015 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue Feb 10 18:50:01 2015 -0500
Merge topic 'use-cmRange' into next
a7c8ee44 Convert loop into two algorithms.
f09d355d Convert loop to the common pattern.
63dcb641 Move loop inside of condition.
87680637 Handle last element outside of the loop.
709e3e17 cmTarget: Use a sorted vector in place of a set.
cc02a664 cmSet: Replace loop with cmJoin.
780f75dc cmFindBase: Replace loop with cmJoin on range.
d4cee4e3 Convert loops to cmJoin algorithm with cmRange.
1e57ca6f cmStringCommand: Accumulate with cmJoin and range adaptors.
55a11552 cmAlgorithms: Add a range adaptor and API for adjusting a range.
05097f44 Use cmJoin to accumulate string ranges.
4d3b952d cmAlgorithms: Add a Range container and adaptor method.
ee130453 Replace common loop pattern with cmJoin
b4edadd2 Convert loops populating maybe-empty content into the common
pattern.
7b92bdd8 Convert loops into the commonly used pattern.
8da80aed cmMacroCommand: Remove counting variable.
...
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a7c8ee44932d6983dea9a55bf18857ee9aa3e75f
commit a7c8ee44932d6983dea9a55bf18857ee9aa3e75f
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Sat Jan 24 18:07:37 2015 +0100
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Wed Feb 11 00:35:15 2015 +0100
Convert loop into two algorithms.
diff --git a/Source/cmLocalUnixMakefileGenerator3.cxx
b/Source/cmLocalUnixMakefileGenerator3.cxx
index 359141a..a08c159 100644
--- a/Source/cmLocalUnixMakefileGenerator3.cxx
+++ b/Source/cmLocalUnixMakefileGenerator3.cxx
@@ -2299,16 +2299,12 @@
cmLocalUnixMakefileGenerator3::ConvertToQuotedOutputPath(const char* p,
{
// Now add the rest of the components separated by the proper slash
// direction for this platform.
- const char* sep = ;
- for(unsigned int i=1; i components.size() - 1; ++i)
-{
-if(!components[i].empty())
- {
- result += sep;
- result += components[i];
- sep = slash;
- }
-}
+ std::vectorstd::string::const_iterator compEnd
+ = std::remove(components.begin() + 1, components.end() - 1,
+ std::string());
+ std::vectorstd::string::const_iterator compStart
+ = components.begin() + 1;
+ result += cmJoin(cmRange(compStart, compEnd), slash);
// Only the last component can be empty to avoid double slashes.
result += slash;
result += components.back();
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f09d355d7dd7f1d66b7f43980523b673f12f6798
commit f09d355d7dd7f1d66b7f43980523b673f12f6798
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Fri Jan 23 01:06:40 2015 +0100
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Wed Feb 11 00:35:15 2015 +0100
Convert loop to the common
Re: [cmake-developers] old policies interfering with script provided by CPack
On 02/09/2015 05:14 PM, Domen Vrankar wrote: To get around this problem I thought about wrapping the entire script with: cmake_policy(PUSH) cmake_policy(VERSION 3.1) cmake_policy(POP) Would this be an acceptable solution? That is currently the intended way to do it. There was once some discussion of trying to scope policies automatically for modules within CMake, but currently it must be explicit. -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
