From mantis at public.kitware.com Mon Dec 1 05:23:19 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Mon, 1 Dec 2014 05:23:19 -0500 Subject: [cmake-developers] =?utf-8?b?W0NNYWtlIDAwMTUyNzJdOiDigJxGaWxlIHJl?= =?utf-8?q?ference=E2=80=9D_warnings_when_building_a_CMake_project_?= =?utf-8?q?with_resources_in_Xcode_6?= Message-ID: <9697f63de8528ac416decc7564247e0d@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15272 ====================================================================== Reported By: Jan R?egg Assigned To: ====================================================================== Project: CMake Issue ID: 15272 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-12-01 05:23 EST Last Modified: 2014-12-01 05:23 EST ====================================================================== Summary: ?File reference? warnings when building a CMake project with resources in Xcode 6 Description: Not all the warnings from http://public.kitware.com/Bug/view.php?id=15111 are fixed in CMake 3.0.2. For example, when adding a storyboard, you have to add it to the resources, and to the executable to make it work: add_executable(foo MACOSX_BUNDLE ${SOURCES} main.storyboard) set_target_properties(foo PROPERTIES RESOURCE main.storyboard) This adds two references, and the warning is back: 2014-12-01 10:43:54.083 xcodebuild[44408:1007] warning: The file reference for "main.storyboard" is a member of multiple groups ("foo" and "Resources"); this indicates a malformed project. Only the membership in one of the groups will be preserved (but membership in targets will be unaffected). If you want a reference to the same file in more than one group, please add another reference to the same path. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-12-01 05:23 Jan R?egg New Issue ====================================================================== From mantis at public.kitware.com Mon Dec 1 08:25:37 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Mon, 1 Dec 2014 08:25:37 -0500 Subject: [cmake-developers] [CMake 0015273]: file(GLOB/GLOB_RECURSE) should provide an option to set a start directory Message-ID: <63df3d0c5759500b570d9def2b5cb31b@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15273 ====================================================================== Reported By: Nils Gladitz Assigned To: ====================================================================== Project: CMake Issue ID: 15273 Category: CMake Reproducibility: always Severity: feature Priority: normal Status: new ====================================================================== Date Submitted: 2014-12-01 08:25 EST Last Modified: 2014-12-01 08:25 EST ====================================================================== Summary: file(GLOB/GLOB_RECURSE) should provide an option to set a start directory Description: Generated target export files for example use: get_filename_component(_DIR "${CMAKE_CURRENT_LIST_FILE}" PATH) file(GLOB CONFIG_FILES "${_DIR}/TdngTargets-*.cmake") This is error prone in case _DIR itself happens to use special characters interpreted by globbing. Something like: file(GLOB CONFIG_FILES START_DIRECTORY "${_DIR}" "TdngTargets-*.cmake") would be nice. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-12-01 08:25 Nils Gladitz New Issue ====================================================================== From brad.king at kitware.com Mon Dec 1 10:00:49 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 01 Dec 2014 10:00:49 -0500 Subject: [cmake-developers] [PATCH v6] continue: Add a new CMake language command for loop continuation (#14013) In-Reply-To: <1417280178-28999-2-git-send-email-gjasny@googlemail.com> References: <1417280178-28999-1-git-send-email-gjasny@googlemail.com> <1417280178-28999-2-git-send-email-gjasny@googlemail.com> Message-ID: <547C82A1.1030804@kitware.com> On 11/29/2014 11:56 AM, Gregor Jasny wrote: > Inspired-by: Doug Barbieri > Signed-off-by: Gregor Jasny Applied and merged to 'next' for testing: continue: Add a new CMake language command for loop continuation (#14013) http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0de867dd Thanks, -Brad From brad.king at kitware.com Mon Dec 1 10:03:48 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 01 Dec 2014 10:03:48 -0500 Subject: [cmake-developers] [Review request] Topic ExternalProject_TEST_EXCLUDE_FROM_MAIN In-Reply-To: <547B8E58.6070604@gmail.com> References: <547B8E58.6070604@gmail.com> Message-ID: <547C8354.8030904@kitware.com> On 11/30/2014 04:38 PM, Daniele E. Domenichelli wrote: > * ExternalProject: Add TEST_EXCLUDE_FROM_MAIN option > http://www.cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=ced29ab LGTM. Please also add a Help/release/dev/ExternalProject_TEST_EXCLUDE_FROM_MAIN.rst file with a release note advertising the feature. This step is now covered in the instructions here: http://www.cmake.org/Wiki/CMake/Git/Develop#Create_a_Topic "If your change is user-facing please create a Help/release/dev/my-topic.rst document with release notes." Thanks, -Brad From brad.king at kitware.com Mon Dec 1 10:04:35 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 01 Dec 2014 10:04:35 -0500 Subject: [cmake-developers] Fix man page description for ctest -j In-Reply-To: References: Message-ID: <547C8383.7060700@kitware.com> On 11/26/2014 11:32 PM, Christopher Dembia wrote: > Fix man page description for ctest -j Applied, thanks: Help: Add missing space to ctest -j option description http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=df53aafd -Brad From brad.king at kitware.com Mon Dec 1 10:04:45 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 01 Dec 2014 10:04:45 -0500 Subject: [cmake-developers] Patch for FindOpenSSL.cmake In-Reply-To: <54788758.8070200@ascolab.com> References: <54788758.8070200@ascolab.com> Message-ID: <547C838D.7040609@kitware.com> On 11/28/2014 09:31 AM, Hannes Mezger wrote: > some applications only need the OpenSSL crypto library and want to avoid > linking against the SSL library, this is currently not possible. This > patch adds the variables OPENSSL_CRYPTO_LIBRARY and OPENSSL_SSL_LIBRARY > which are set to the respective library; this allows to be more specific > when linking against OpenSSL. Thanks. Applied with minor tweaks: FindOpenSSL: Report crypto and ssl libraries separately http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=be9bec5d -Brad From brad.king at kitware.com Mon Dec 1 10:05:44 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 01 Dec 2014 10:05:44 -0500 Subject: [cmake-developers] Patch pull request: support for shader entry point and shader model for Visual Studio FXCompiler custom tool build In-Reply-To: References: Message-ID: <547C83C8.4060406@kitware.com> On 11/29/2014 12:51 AM, Cedric Perthuis wrote: > So, here's a patch to address this. [snip] > + if (const char* se = sf->GetProperty("VS_SHADER_ENTRY_POINT")) [snip] > + if (const char* sm = sf->GetProperty("VS_SHADER_MODEL")) Thanks. Here are some comments on the patch: * Please update the documentation too. See Help/manual/cmake-properties.7.rst Help/prop_sf/VS_SHADER_TYPE.rst for how VS_SHADER_TYPE is documented. * Please update the test. See Tests/VSWinStorePhone/CMakeLists.txt for current testing of VS_SHADER_TYPE. Thanks, -Brad From brad.king at kitware.com Mon Dec 1 10:10:32 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 01 Dec 2014 10:10:32 -0500 Subject: [cmake-developers] Support for IAR msp430 compiler needed In-Reply-To: References: Message-ID: <547C84E8.4090506@kitware.com> On 11/27/2014 02:07 AM, Petteri Lapinlampi wrote: > I'm trying to use CMake (v3.0.2) in a project utilizing the > IAR msp430 compiler (icc430.exe). Apparently CMake does not support > this compiler yet. As of CMake 2.8.12 there was some work on IAR support: Add support files for C, C++ and ASM for the IAR toolchain. http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=22fb73a0 Add Support for IAR compiler http://www.cmake.org/Bug/view.php?id=10176 I don't think anything further has been done since then. Of course we would be open to contributions of further support and happy to answer questions along the way. Thanks, -Brad From brad.king at kitware.com Mon Dec 1 10:52:14 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 01 Dec 2014 10:52:14 -0500 Subject: [cmake-developers] New command 'file(LOCK_DIRECTORY ...)' In-Reply-To: <54750FB3.6080903@yahoo.com> References: <5431B11C.3010209@yahoo.com> <54665ED3.3060300@kitware.com> <54668FEC.5020203@yahoo.com> <708024991.ylpfiUSqup@caliban.sf-tec.de> <546A0F00.3090908@kitware.com> <546A8881.5050205@yahoo.com> <5474CA82.6090509@kitware.com> <54750FB3.6080903@yahoo.com> Message-ID: <547C8EAE.9030900@kitware.com> On 11/25/2014 06:24 PM, Ruslan Baratov wrote: > updated Thanks. I squashed the commits since the addition of the files cannot be tested independently, made minor tweaks, and merged to 'next' for testing: cmSystemTools: Add StringToInt helper http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5121f118 file: Add LOCK subcommand to do file and directory locking http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fca624ca Help: Add notes for topic 'file-LOCK-command' http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ed00a808 -Brad From Gilles.Khouzam at microsoft.com Mon Dec 1 10:59:46 2014 From: Gilles.Khouzam at microsoft.com (Gilles Khouzam) Date: Mon, 1 Dec 2014 15:59:46 +0000 Subject: [cmake-developers] Patch pull request: support for shader entry point and shader model for Visual Studio FXCompiler custom tool build In-Reply-To: <547C83C8.4060406@kitware.com> References: <547C83C8.4060406@kitware.com> Message-ID: Hi Cedric Thanks for the patch, I had started adding a full set of shader property support on our fork: https://cmakems.codeplex.com/SourceControl/changeset/c5f9c207ee3490dda1e4c2a0eb647492b934fc11 I haven't asked to get this pulled in because with the number of options, it is probably better to add this support as a flag set instead of having a set of specific if statements. I haven't had a chance to complete this work though. -----Original Message----- From: Brad King [mailto:brad.king at kitware.com] Sent: Monday, December 1, 2014 07:06 To: Cedric Perthuis Cc: cmake-developers at cmake.org; Gilles Khouzam Subject: Re: [cmake-developers] Patch pull request: support for shader entry point and shader model for Visual Studio FXCompiler custom tool build On 11/29/2014 12:51 AM, Cedric Perthuis wrote: > So, here's a patch to address this. [snip] > + if (const char* se = sf->GetProperty("VS_SHADER_ENTRY_POINT")) [snip] > + if (const char* sm = sf->GetProperty("VS_SHADER_MODEL")) Thanks. Here are some comments on the patch: * Please update the documentation too. See Help/manual/cmake-properties.7.rst Help/prop_sf/VS_SHADER_TYPE.rst for how VS_SHADER_TYPE is documented. * Please update the test. See Tests/VSWinStorePhone/CMakeLists.txt for current testing of VS_SHADER_TYPE. Thanks, -Brad From daniele.domenichelli at gmail.com Mon Dec 1 11:00:51 2014 From: daniele.domenichelli at gmail.com (Daniele E. Domenichelli) Date: Mon, 01 Dec 2014 17:00:51 +0100 Subject: [cmake-developers] [Review request] Topic ExternalProject_TEST_EXCLUDE_FROM_MAIN In-Reply-To: <547C8354.8030904@kitware.com> References: <547B8E58.6070604@gmail.com> <547C8354.8030904@kitware.com> Message-ID: <547C90B3.1080607@gmail.com> On 01/12/14 16:03, Brad King wrote: > LGTM. Please also add a > > Help/release/dev/ExternalProject_TEST_EXCLUDE_FROM_MAIN.rst > > file with a release note advertising the feature. Done... squashed everything in one commit: * ExternalProject: Add TEST_EXCLUDE_FROM_MAIN option http://www.cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=695b0d3 Cheers, Daniele From eike at sf-mail.de Mon Dec 1 11:05:57 2014 From: eike at sf-mail.de (Rolf Eike Beer) Date: Mon, 01 Dec 2014 17:05:57 +0100 Subject: [cmake-developers] New command 'file(LOCK_DIRECTORY ...)' In-Reply-To: <547C8EAE.9030900@kitware.com> References: <5431B11C.3010209@yahoo.com> <54750FB3.6080903@yahoo.com> <547C8EAE.9030900@kitware.com> Message-ID: <8862399.plEbCk131l@eto> Brad King wrote: > On 11/25/2014 06:24 PM, Ruslan Baratov wrote: > > updated > > Thanks. I squashed the commits since the addition of the files > cannot be tested independently, made minor tweaks, and merged > to 'next' for testing: > > cmSystemTools: Add StringToInt helper > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5121f118 Since I hate *scanf() with passion, how about this: diff --git a/Source/cmSystemTools.cxx b/Source/cmSystemTools.cxx index 4c08e07..9852dd6 100644 --- a/Source/cmSystemTools.cxx +++ b/Source/cmSystemTools.cxx @@ -2927,7 +2927,7 @@ std::vector cmSystemTools::tokenize(const std::string& str, //---------------------------------------------------------------------------- bool cmSystemTools::StringToInt(const char* str, int* value) { - char unused; - const int result = sscanf(str, "%d%c", value, &unused); - return (result == 1); + char *endp; + *value = static_cast(strtol(str, &endp, 10)); + return (*endp == '\0') && (endp != str); } Eike -- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From brad.king at kitware.com Mon Dec 1 11:11:08 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 01 Dec 2014 11:11:08 -0500 Subject: [cmake-developers] New command 'file(LOCK_DIRECTORY ...)' In-Reply-To: <8862399.plEbCk131l@eto> References: <5431B11C.3010209@yahoo.com> <54750FB3.6080903@yahoo.com> <547C8EAE.9030900@kitware.com> <8862399.plEbCk131l@eto> Message-ID: <547C931C.6070105@kitware.com> On 12/01/2014 11:05 AM, Rolf Eike Beer wrote: > + char *endp; > + *value = static_cast(strtol(str, &endp, 10)); > + return (*endp == '\0') && (endp != str); Fine with me. Please extend the topic accordingly. I will squash it in later. Be sure to include . Thanks, -Brad From eike at sf-mail.de Mon Dec 1 11:21:01 2014 From: eike at sf-mail.de (Rolf Eike Beer) Date: Mon, 01 Dec 2014 17:21:01 +0100 Subject: [cmake-developers] New command 'file(LOCK_DIRECTORY ...)' In-Reply-To: <547C931C.6070105@kitware.com> References: <5431B11C.3010209@yahoo.com> <8862399.plEbCk131l@eto> <547C931C.6070105@kitware.com> Message-ID: <1937103.VnMLJRSfzj@eto> Brad King wrote: > On 12/01/2014 11:05 AM, Rolf Eike Beer wrote: > > + char *endp; > > + *value = static_cast(strtol(str, &endp, 10)); > > + return (*endp == '\0') && (endp != str); > > Fine with me. Please extend the topic accordingly. I will squash > it in later. Done. > Be sure to include . Already the case. Eike -- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From mantis at public.kitware.com Mon Dec 1 14:35:31 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Mon, 1 Dec 2014 14:35:31 -0500 Subject: [cmake-developers] [CMake 0015274]: CMAKE_SYSTEM_PROCESSOR not working Message-ID: <2200dd235ab14b425d9fe59e6b8e9655@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15274 ====================================================================== Reported By: santa scrooge Assigned To: ====================================================================== Project: CMake Issue ID: 15274 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-12-01 14:35 EST Last Modified: 2014-12-01 14:35 EST ====================================================================== Summary: CMAKE_SYSTEM_PROCESSOR not working Description: if(CUDA_VERSION VERSION_GREATER "5.0" AND CMAKE_CROSSCOMPILING AND ${CMAKE_SYSTEM_PROCESSOR} MATCHES "arm" AND EXISTS "${CUDA_TOOLKIT_ROOT_DIR}/targets/armv7-linux- gnueabihf") this is found in FindCUDA.cmake. It reports unspecified arguments. I check it by message() and found "CMAKE_SYSTEM_PROCESSOR" is empty. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-12-01 14:35 santa scrooge New Issue ====================================================================== From steveire at gmail.com Mon Dec 1 15:26:10 2014 From: steveire at gmail.com (Stephen Kelly) Date: Mon, 01 Dec 2014 21:26:10 +0100 Subject: [cmake-developers] New command 'file(LOCK_DIRECTORY ...)' References: <5431B11C.3010209@yahoo.com> <8862399.plEbCk131l@eto> <547C931C.6070105@kitware.com> <1937103.VnMLJRSfzj@eto> Message-ID: Rolf Eike Beer wrote: > Brad King wrote: >> On 12/01/2014 11:05 AM, Rolf Eike Beer wrote: >> > + char *endp; >> > + *value = static_cast(strtol(str, &endp, 10)); >> > + return (*endp == '\0') && (endp != str); >> >> Fine with me. Please extend the topic accordingly. I will squash >> it in later. > > Done. Existing uses of strtol also check errno. I guess your implementation should too. Then the existing users should use this new method. Thanks, Steve. From brad.king at kitware.com Mon Dec 1 15:32:40 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 01 Dec 2014 15:32:40 -0500 Subject: [cmake-developers] New command 'file(LOCK_DIRECTORY ...)' In-Reply-To: References: <5431B11C.3010209@yahoo.com> <8862399.plEbCk131l@eto> <547C931C.6070105@kitware.com> <1937103.VnMLJRSfzj@eto> Message-ID: <547CD068.9080905@kitware.com> On 12/01/2014 03:26 PM, Stephen Kelly wrote: > Existing uses of strtol also check errno. I guess your implementation should > too. Yes, IIUC it is a range check on whether the value can be represented. > Then the existing users should use this new method. In that case the type should be changed to 'long' instead of 'int', and the current call site should be updated accordingly. Thanks, -Brad From cedric.perthuis at gmail.com Tue Dec 2 05:09:12 2014 From: cedric.perthuis at gmail.com (Cedric Perthuis) Date: Tue, 2 Dec 2014 02:09:12 -0800 Subject: [cmake-developers] Patch pull request: support for shader entry point and shader model for Visual Studio FXCompiler custom tool build In-Reply-To: References: <547C83C8.4060406@kitware.com> Message-ID: Hi Brad and Gilles. I have updated the patch suggestion, please find it below. Gilles, I took your spelling for ENTRYPOINT and your documentation. Gilles' fork is more exhaustive than the minimal patch I am suggesting. What's important for me, is to have one or the other pushed as soon as possible, as the addition of the shader support without the shader model and without the entrypoint is breaking some of the projects I am working on. And I suspect that it will break many people. I leave it up to you guys to decide which patch you prefer. Thanks again for the quick answers, it's really nice to get an answer so fast! >From e92c4b804b1b253f96297fff4e4915934e5e0c59 Mon Sep 17 00:00:00 2001 From: cperthuis Date: Tue, 2 Dec 2014 01:41:10 -0800 Subject: [PATCH] added VS_SHADER_ENTRYPOINT and VS_SHADER_MODEL file properties for Visual Studio shader custom tool --- Help/manual/cmake-properties.7.rst | 2 ++ Help/prop_sf/VS_SHADER_ENTRYPOINT.rst | 5 ++++ Help/prop_sf/VS_SHADER_MODEL.rst | 5 ++++ Source/cmVisualStudio10TargetGenerator.cxx | 27 +++++++++++++++++++++- Tests/VSWinStorePhone/CMakeLists.txt | 6 +++++ .../Direct3DApp1/SimplePixelShader.hlsl | 2 +- .../Direct3DApp1/SimpleVertexShader.hlsl | 2 +- 7 files changed, 46 insertions(+), 3 deletions(-) create mode 100644 Help/prop_sf/VS_SHADER_ENTRYPOINT.rst create mode 100644 Help/prop_sf/VS_SHADER_MODEL.rst diff --git a/Help/manual/cmake-properties.7.rst b/Help/manual/cmake-properties.7.rst index bf456f5..5bbb89e 100644 --- a/Help/manual/cmake-properties.7.rst +++ b/Help/manual/cmake-properties.7.rst @@ -291,6 +291,8 @@ Properties on Source Files /prop_sf/OBJECT_OUTPUTS /prop_sf/SYMBOLIC /prop_sf/VS_DEPLOYMENT_CONTENT + /prop_sf/VS_SHADER_MODEL + /prop_sf/VS_SHADER_ENTRYPOINT /prop_sf/VS_SHADER_TYPE /prop_sf/WRAP_EXCLUDE /prop_sf/XCODE_EXPLICIT_FILE_TYPE diff --git a/Help/prop_sf/VS_SHADER_ENTRYPOINT.rst b/Help/prop_sf/VS_SHADER_ENTRYPOINT.rst new file mode 100644 index 0000000..69ff3e6 --- /dev/null +++ b/Help/prop_sf/VS_SHADER_ENTRYPOINT.rst @@ -0,0 +1,5 @@ +VS_SHADER_ENTRYPOINT +-------------- + +Specifies the name of the entry point for the shader of a ``.hlsl`` source +file. diff --git a/Help/prop_sf/VS_SHADER_MODEL.rst b/Help/prop_sf/VS_SHADER_MODEL.rst new file mode 100644 index 0000000..5adb680 --- /dev/null +++ b/Help/prop_sf/VS_SHADER_MODEL.rst @@ -0,0 +1,5 @@ +VS_SHADER_MODEL +-------------- + +Specifies the shader model of a ``.hlsl`` source file. Some shader types can +only be used with recent shader models diff --git a/Source/cmVisualStudio10TargetGenerator.cxx b/Source/cmVisualStudio10TargetGenerator.cxx index f591fc8..d1031cc 100644 --- a/Source/cmVisualStudio10TargetGenerator.cxx +++ b/Source/cmVisualStudio10TargetGenerator.cxx @@ -1203,6 +1203,8 @@ void cmVisualStudio10TargetGenerator::WriteExtraSource(cmSourceFile const* sf) bool toolHasSettings = false; std::string tool = "None"; std::string shaderType; + std::string shaderEntryPoint; + std::string shaderModel; std::string ext = cmSystemTools::LowerCase(sf->GetExtension()); if(ext == "hlsl") { @@ -1213,6 +1215,18 @@ void cmVisualStudio10TargetGenerator::WriteExtraSource(cmSourceFile const* sf) shaderType = st; toolHasSettings = true; } + // Figure out which entry point to use if any + if (const char* se = sf->GetProperty("VS_SHADER_ENTRYPOINT")) + { + shaderEntryPoint = se; + toolHasSettings = true; + } + // Figure out which entry point to use if any + if (const char* sm = sf->GetProperty("VS_SHADER_MODEL")) + { + shaderModel = sm; + toolHasSettings = true; + } } else if(ext == "jpg" || ext == "png") @@ -1295,7 +1309,18 @@ void cmVisualStudio10TargetGenerator::WriteExtraSource(cmSourceFile const* sf) (*this->BuildFileStream) << cmVS10EscapeXML(shaderType) << "\n"; } - + if(!shaderEntryPoint.empty()) + { + this->WriteString("", 3); + (*this->BuildFileStream) << cmVS10EscapeXML(shaderEntryPoint) + << "\n"; + } + if(!shaderModel.empty()) + { + this->WriteString("", 3); + (*this->BuildFileStream) << cmVS10EscapeXML(shaderModel) + << "\n"; + } this->WriteString("BuildFileStream) << tool << ">\n"; } diff --git a/Tests/VSWinStorePhone/CMakeLists.txt b/Tests/VSWinStorePhone/CMakeLists.txt index 0041c75..c6f814d 100644 --- a/Tests/VSWinStorePhone/CMakeLists.txt +++ b/Tests/VSWinStorePhone/CMakeLists.txt @@ -103,7 +103,13 @@ set_property(SOURCE ${RELEASE_CONTENT_FILES} PROPERTY VS_DEPLOYMENT_CONTENT $,$,$>) set_property(SOURCE ${PIXELSHADER_FILES} PROPERTY VS_SHADER_TYPE Pixel) +set_property(SOURCE ${PIXELSHADER_FILES} PROPERTY VS_SHADER_ENTRYPOINT mainPS) +set_property(SOURCE ${PIXELSHADER_FILES} PROPERTY VS_SHADER_MODEL 4.0_level_9_3) + set_property(SOURCE ${VERTEXSHADER_FILES} PROPERTY VS_SHADER_TYPE Vertex) +set_property(SOURCE ${VERTEXSHADER_FILES} PROPERTY VS_SHADER_ENTRYPOINT mainVS) +set_property(SOURCE ${VERTEXSHADER_FILES} PROPERTY VS_SHADER_MODEL 4.0_level_9_3) + source_group("Source Files" FILES ${SOURCE_FILES}) source_group("Header Files" FILES ${HEADER_FILES}) diff --git a/Tests/VSWinStorePhone/Direct3DApp1/SimplePixelShader.hlsl b/Tests/VSWinStorePhone/Direct3DApp1/SimplePixelShader.hlsl index d61e2c8..6796da1 100644 --- a/Tests/VSWinStorePhone/Direct3DApp1/SimplePixelShader.hlsl +++ b/Tests/VSWinStorePhone/Direct3DApp1/SimplePixelShader.hlsl @@ -4,7 +4,7 @@ struct PixelShaderInput float3 color : COLOR0; }; -float4 main(PixelShaderInput input) : SV_TARGET +float4 mainPS(PixelShaderInput input) : SV_TARGET { return float4(input.color,1.0f); } diff --git a/Tests/VSWinStorePhone/Direct3DApp1/SimpleVertexShader.hlsl b/Tests/VSWinStorePhone/Direct3DApp1/SimpleVertexShader.hlsl index 65d60e5..0963060 100644 --- a/Tests/VSWinStorePhone/Direct3DApp1/SimpleVertexShader.hlsl +++ b/Tests/VSWinStorePhone/Direct3DApp1/SimpleVertexShader.hlsl @@ -17,7 +17,7 @@ struct VertexShaderOutput float3 color : COLOR0; }; -VertexShaderOutput main(VertexShaderInput input) +VertexShaderOutput mainVS(VertexShaderInput input) { VertexShaderOutput output; float4 pos = float4(input.pos, 1.0f); -- 1.9.4.msysgit.2 On Mon, Dec 1, 2014 at 7:59 AM, Gilles Khouzam wrote: > Hi Cedric > > Thanks for the patch, > > I had started adding a full set of shader property support on our fork: > > > https://cmakems.codeplex.com/SourceControl/changeset/c5f9c207ee3490dda1e4c2a0eb647492b934fc11 > > I haven't asked to get this pulled in because with the number of options, > it is probably better to add this support as a flag set instead of having a > set of specific if statements. I haven't had a chance to complete this work > though. > > -----Original Message----- > From: Brad King [mailto:brad.king at kitware.com] > Sent: Monday, December 1, 2014 07:06 > To: Cedric Perthuis > Cc: cmake-developers at cmake.org; Gilles Khouzam > Subject: Re: [cmake-developers] Patch pull request: support for shader > entry point and shader model for Visual Studio FXCompiler custom tool build > > On 11/29/2014 12:51 AM, Cedric Perthuis wrote: > > So, here's a patch to address this. > [snip] > > + if (const char* se = sf->GetProperty("VS_SHADER_ENTRY_POINT")) > [snip] > > + if (const char* sm = sf->GetProperty("VS_SHADER_MODEL")) > > Thanks. Here are some comments on the patch: > > * Please update the documentation too. See > > Help/manual/cmake-properties.7.rst > Help/prop_sf/VS_SHADER_TYPE.rst > > for how VS_SHADER_TYPE is documented. > > * Please update the test. See > > Tests/VSWinStorePhone/CMakeLists.txt > > for current testing of VS_SHADER_TYPE. > > Thanks, > -Brad > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pascal.bach at siemens.com Tue Dec 2 07:33:42 2014 From: pascal.bach at siemens.com (Pascal Bach) Date: Tue, 2 Dec 2014 13:33:42 +0100 Subject: [cmake-developers] [PATCH] VS, WINCE: Fix entry point for Unicode builds Message-ID: <1417523622-26389-1-git-send-email-pascal.bach@siemens.com> When _UNICODE is defined VS uses wmain instead of main as the entry function. To make this correctly work on WindowsCE EntryPointSymbol needs to be set to mainWCRTStartup instead of mainWCRTStartup for console applications and to wWinMainCRTStartup instead of WinMainCRTStartup for GUI applications. Signed-off-by: Pascal Bach --- Source/cmVisualStudio10TargetGenerator.cxx | 18 ++++++++++++++++-- 1 file changed, 16 insertions(+), 2 deletions(-) diff --git a/Source/cmVisualStudio10TargetGenerator.cxx b/Source/cmVisualStudio10TargetGenerator.cxx index f591fc8..f969b91 100644 --- a/Source/cmVisualStudio10TargetGenerator.cxx +++ b/Source/cmVisualStudio10TargetGenerator.cxx @@ -2268,7 +2268,14 @@ cmVisualStudio10TargetGenerator::ComputeLinkOptions(std::string const& config) linkOptions.AddFlag("SubSystem", "WindowsCE"); if (this->Target->GetType() == cmTarget::EXECUTABLE) { - linkOptions.AddFlag("EntryPointSymbol", "WinMainCRTStartup"); + if (this->ClOptions[config]->UsingUnicode()) + { + linkOptions.AddFlag("EntryPointSymbol", "wWinMainCRTStartup"); + } + else + { + linkOptions.AddFlag("EntryPointSymbol", "WinMainCRTStartup"); + } } } else @@ -2283,7 +2290,14 @@ cmVisualStudio10TargetGenerator::ComputeLinkOptions(std::string const& config) linkOptions.AddFlag("SubSystem", "WindowsCE"); if (this->Target->GetType() == cmTarget::EXECUTABLE) { - linkOptions.AddFlag("EntryPointSymbol", "mainACRTStartup"); + if (this->ClOptions[config]->UsingUnicode()) + { + linkOptions.AddFlag("EntryPointSymbol", "mainWCRTStartup"); + } + else + { + linkOptions.AddFlag("EntryPointSymbol", "mainACRTStartup"); + } } } else -- 1.7.10.4 From ts at medical-insight.com Tue Dec 2 07:57:56 2014 From: ts at medical-insight.com (Thomas Sondergaard) Date: Tue, 02 Dec 2014 13:57:56 +0100 Subject: [cmake-developers] ctest -j 32 hanging Message-ID: Hi, I have observed twice now within the last month that ctest with -j is hanging. It seems to not notice that a test has ended and it is furthermore not reacting to the timeout given on the command line. The following output is from a jenkins log. The job invokes ctest like this: ctest --output-on-failure --timeout 10800 -C Debug -j %NUMBER_OF_PROCESSORS% where number of processors is 32. Note that it should have stopped the job well before jenkins didafter 300 minutes as 10800 seconds is only 180 minutes and the compilation that is done before running the tests takes less than 15 minutes. I logged into the machine while ctest was hanging and test job #3 mitest-test was not running any longer. > Test project F:/jenkins/workspace/personal-ts-7.0-all-tests-3/arch/win32/build > Start 1: micppunit-test > Start 2: evbase-test > Start 3: mitest-test > Start 4: tinymath-test > Start 5: mistral-test > Start 6: usg-test > Start 7: mint-test > Start 8: charls-test > Start 9: vdbclient-test > Start 10: qtutility-test > Start 11: yargnits-test > Start 12: trident-test > Start 13: sturgeon-test > Start 14: camutility-test > Start 15: general2d-test > Start 16: hl7tools-test > Start 17: session-manager-test > Start 18: libwfm-test > Start 19: common-tests > 1/19 Test #1: micppunit-test ................... Passed 1.20 sec > 2/19 Test #4: tinymath-test .................... Passed 1.89 sec > 3/19 Test #16: hl7tools-test .................... Passed 4.95 sec > 4/19 Test #7: mint-test ........................ Passed 7.71 sec > 5/19 Test #8: charls-test ...................... Passed 7.66 sec > 6/19 Test #18: libwfm-test ...................... Passed 14.21 sec > 7/19 Test #6: usg-test ......................... Passed 18.10 sec > 8/19 Test #17: session-manager-test ............. Passed 18.35 sec > 9/19 Test #13: sturgeon-test .................... Passed 19.66 sec > 10/19 Test #15: general2d-test ................... Passed 19.70 sec > 11/19 Test #10: qtutility-test ................... Passed 24.13 sec > 12/19 Test #14: camutility-test .................. Passed 33.26 sec > 13/19 Test #12: trident-test ..................... Passed 33.76 sec > 14/19 Test #11: yargnits-test .................... Passed 40.25 sec > 15/19 Test #9: vdbclient-test ................... Passed 50.64 sec > 16/19 Test #19: common-tests ..................... Passed 61.04 sec > 17/19 Test #5: mistral-test ..................... Passed 77.47 sec > 18/19 Test #2: evbase-test ...................... Passed 138.26 sec > > Build timed out (after 300 minutes). I searched the cmake bug tracker for problems with ctest hanging, but did not find any. Anyone aware of problems such as this? I grabbed a dump of the hanging ctest and I will see if I can get anything out of it. Best regards, Thomas Sondergaard From mantis at public.kitware.com Tue Dec 2 08:59:26 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 2 Dec 2014 08:59:26 -0500 Subject: [cmake-developers] [CMake 0015275]: Duplicated lines in FindPythonInterp.cmake Message-ID: <7eca92c73e0e42709266009f870664ee@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15275 ====================================================================== Reported By: Arseniy Terekhin Assigned To: ====================================================================== Project: CMake Issue ID: 15275 Category: Modules Reproducibility: have not tried Severity: trivial Priority: low Status: new ====================================================================== Date Submitted: 2014-12-02 08:59 EST Last Modified: 2014-12-02 08:59 EST ====================================================================== Summary: Duplicated lines in FindPythonInterp.cmake Description: in file `Modules\FindPythonInterp.cmake` you can find set(PYTHON_VERSION_MAJOR "1") set(PYTHON_VERSION_MAJOR "4") set(PYTHON_VERSION_MAJOR "0") ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-12-02 08:59 Arseniy TerekhinNew Issue ====================================================================== From ts at medical-insight.com Tue Dec 2 09:10:22 2014 From: ts at medical-insight.com (Thomas Sondergaard) Date: Tue, 02 Dec 2014 15:10:22 +0100 Subject: [cmake-developers] ctest -j 32 hanging In-Reply-To: References: Message-ID: On 2014-12-02 13:57, Thomas Sondergaard wrote: > Hi, > > I have observed twice now within the last month that ctest with -j is > hanging. It seems to not notice that a test has ended and it is > furthermore not reacting to the timeout given on the command line. > > The following output is from a jenkins log. The job invokes ctest like > this: > > ctest --output-on-failure --timeout 10800 -C Debug -j > %NUMBER_OF_PROCESSORS% > > where number of processors is 32. Note that it should have stopped the > job well before jenkins didafter 300 minutes as 10800 seconds is only > 180 minutes and the compilation that is done before running the tests > takes less than 15 minutes. > > I logged into the machine while ctest was hanging and test job #3 > mitest-test was not running any longer. > >> Test project >> F:/jenkins/workspace/personal-ts-7.0-all-tests-3/arch/win32/build >> Start 1: micppunit-test >> Start 2: evbase-test >> Start 3: mitest-test >> Start 4: tinymath-test >> Start 5: mistral-test >> Start 6: usg-test >> Start 7: mint-test >> Start 8: charls-test >> Start 9: vdbclient-test >> Start 10: qtutility-test >> Start 11: yargnits-test >> Start 12: trident-test >> Start 13: sturgeon-test >> Start 14: camutility-test >> Start 15: general2d-test >> Start 16: hl7tools-test >> Start 17: session-manager-test >> Start 18: libwfm-test >> Start 19: common-tests >> 1/19 Test #1: micppunit-test ................... Passed 1.20 sec >> 2/19 Test #4: tinymath-test .................... Passed 1.89 sec >> 3/19 Test #16: hl7tools-test .................... Passed 4.95 sec >> 4/19 Test #7: mint-test ........................ Passed 7.71 sec >> 5/19 Test #8: charls-test ...................... Passed 7.66 sec >> 6/19 Test #18: libwfm-test ...................... Passed 14.21 sec >> 7/19 Test #6: usg-test ......................... Passed 18.10 sec >> 8/19 Test #17: session-manager-test ............. Passed 18.35 sec >> 9/19 Test #13: sturgeon-test .................... Passed 19.66 sec >> 10/19 Test #15: general2d-test ................... Passed 19.70 sec >> 11/19 Test #10: qtutility-test ................... Passed 24.13 sec >> 12/19 Test #14: camutility-test .................. Passed 33.26 sec >> 13/19 Test #12: trident-test ..................... Passed 33.76 sec >> 14/19 Test #11: yargnits-test .................... Passed 40.25 sec >> 15/19 Test #9: vdbclient-test ................... Passed 50.64 sec >> 16/19 Test #19: common-tests ..................... Passed 61.04 sec >> 17/19 Test #5: mistral-test ..................... Passed 77.47 sec >> 18/19 Test #2: evbase-test ...................... Passed 138.26 sec >> >> Build timed out (after 300 minutes). > > I searched the cmake bug tracker for problems with ctest hanging, but > did not find any. Anyone aware of problems such as this? > > I grabbed a dump of the hanging ctest and I will see if I can get > anything out of it. > > Best regards, > Thomas Sondergaard > One of the tests spawns a dbus-daemon.exe which was leftover, once I killed that ctest.exe finished too. Is this consistent with the expected ctest behavior? Regards, Thomas From brad.king at kitware.com Tue Dec 2 09:28:57 2014 From: brad.king at kitware.com (Brad King) Date: Tue, 02 Dec 2014 09:28:57 -0500 Subject: [cmake-developers] ctest -j 32 hanging In-Reply-To: References: Message-ID: <547DCCA9.1040708@kitware.com> On 12/02/2014 09:10 AM, Thomas Sondergaard wrote: > One of the tests spawns a dbus-daemon.exe which was leftover, once I > killed that ctest.exe finished too. Is this consistent with the expected > ctest behavior? This is a known limitation of the way CTest runs processes. If a parent exits before the grandchildren, and the latter do not exit, then things get stuck because they keep pipes open that CTest is blocking on waiting to be closed. This is only a problem on Windows. This limitation is left from the way things had to be implemented way back when Windows 98 was supported to work there without polling. The infrastructure update required to fix it is non-trivial so no one has taken the time to do it yet. -Brad From brad.king at kitware.com Tue Dec 2 09:34:23 2014 From: brad.king at kitware.com (Brad King) Date: Tue, 02 Dec 2014 09:34:23 -0500 Subject: [cmake-developers] [PATCH] VS, WINCE: Fix entry point for Unicode builds In-Reply-To: <1417523622-26389-1-git-send-email-pascal.bach@siemens.com> References: <1417523622-26389-1-git-send-email-pascal.bach@siemens.com> Message-ID: <547DCDEF.2050009@kitware.com> On 12/02/2014 07:33 AM, Pascal Bach wrote: > When _UNICODE is defined VS uses wmain instead of main as the entry function. > To make this correctly work on WindowsCE EntryPointSymbol needs to be set to > mainWCRTStartup instead of mainWCRTStartup for console applications and to > wWinMainCRTStartup instead of WinMainCRTStartup for GUI applications. Thanks, applied: VS, WINCE: Fix entry point for Unicode builds http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a4962595 -Brad From brad.king at kitware.com Tue Dec 2 10:03:46 2014 From: brad.king at kitware.com (Brad King) Date: Tue, 02 Dec 2014 10:03:46 -0500 Subject: [cmake-developers] New command 'file(LOCK_DIRECTORY ...)' In-Reply-To: <547C8EAE.9030900@kitware.com> References: <5431B11C.3010209@yahoo.com> <54665ED3.3060300@kitware.com> <54668FEC.5020203@yahoo.com> <708024991.ylpfiUSqup@caliban.sf-tec.de> <546A0F00.3090908@kitware.com> <546A8881.5050205@yahoo.com> <5474CA82.6090509@kitware.com> <54750FB3.6080903@yahoo.com> <547C8EAE.9030900@kitware.com> Message-ID: <547DD4D2.4010204@kitware.com> On 12/01/2014 10:52 AM, Brad King wrote: > Thanks. I squashed the commits since the addition of the files > cannot be tested independently, made minor tweaks, and merged > to 'next' for testing: Testing went pretty well, but the RunCMake.file test fails on HP-UX in the LOCK-error-timeout case: http://open.cdash.org/testDetails.php?test=297595272&build=3594885 The relevant expect/actual lines are: > expect-err> Timeout reached\. > actual-err> Permission denied. Any idea why that might happen? Thanks, -Brad From brad.king at kitware.com Tue Dec 2 10:27:10 2014 From: brad.king at kitware.com (Brad King) Date: Tue, 02 Dec 2014 10:27:10 -0500 Subject: [cmake-developers] Patch pull request: support for shader entry point and shader model for Visual Studio FXCompiler custom tool build In-Reply-To: References: <547C83C8.4060406@kitware.com> Message-ID: <547DDA4E.4040002@kitware.com> On 12/02/2014 05:09 AM, Cedric Perthuis wrote: > I have updated the patch suggestion, please find it below. Thanks. I've applied it and merged for testing: VS: Add source file properties to set the hlsl shader entry point and model http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5ab06dcd -Brad From brad.king at kitware.com Tue Dec 2 11:36:36 2014 From: brad.king at kitware.com (Brad King) Date: Tue, 02 Dec 2014 11:36:36 -0500 Subject: [cmake-developers] New command 'file(LOCK_DIRECTORY ...)' In-Reply-To: <547DD4D2.4010204@kitware.com> References: <5431B11C.3010209@yahoo.com> <54665ED3.3060300@kitware.com> <54668FEC.5020203@yahoo.com> <708024991.ylpfiUSqup@caliban.sf-tec.de> <546A0F00.3090908@kitware.com> <546A8881.5050205@yahoo.com> <5474CA82.6090509@kitware.com> <54750FB3.6080903@yahoo.com> <547C8EAE.9030900@kitware.com> <547DD4D2.4010204@kitware.com> Message-ID: <547DEA94.9040009@kitware.com> On 12/02/2014 10:03 AM, Brad King wrote: > Testing went pretty well, but the RunCMake.file test fails on HP-UX > in the LOCK-error-timeout case: > > http://open.cdash.org/testDetails.php?test=297595272&build=3594885 > > The relevant expect/actual lines are: > >> expect-err> Timeout reached\. >> actual-err> Permission denied. > > Any idea why that might happen? This may fix it: cmFileLockUnix: Treat EACCES like EAGAIN http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=35bcecc0 According to 'man fcntl' locking an already-locked file may fail with either EACCES or EAGAIN. We were only checking the latter. Thanks, -Brad From kgt at lanl.gov Tue Dec 2 12:06:08 2014 From: kgt at lanl.gov (Thompson, KT) Date: Tue, 2 Dec 2014 17:06:08 +0000 Subject: [cmake-developers] Volunteering to maintain a new module: FindGSL.cmake Message-ID: <0458DF31F610EF42BFC78C497E806C7B3B53D0EA@ECS-EXG-P-MB03.win.lanl.gov> Hi, I have been using CMake for about 7 years now and I maintain several modules in my local projects. I am new to the cmake-developers list and I am offering a new module, FindGSL.cmake, and offering to maintain it. I have maintained and used this module for about 4 years supporting various architectures and compilers (RHEL, Xcode, Visual Studio, Blue Gene environments, Cray environments, etc.). Additionally, if all goes will with this module, I would like to begin maintaining other existing modules that no longer have 'owners.' (Ref: http://www.cmake.org/Wiki/CMake:Module_Maintainers#New_Maintainer) The GNU Scientific library (GSL) is a numerical library for C and C++ programmers and is provided with many Linux distributions. It is also available on OSX and Windows platforms. The offered module locates the GSL installation and provides cmake variables and targets that can be used for linking code to the GSL. A copy of my proposed module follows. -kt #============================================================================= #.rst # Find GSL # -------- # # Find the native GSL includes and libraries. # # The GNU Scientific Library (GSL) is a numerical library for C and # C++ programmers. It is free software under the GNU General Public # License. # # === Variables === # # This module will set the following variables per language in your # project: # # :: # # GSL_FOUND - True if GSL found on the local system # GSL_INCLUDE_DIR - Location of GSL header files. # GSL_LIBRARY - The GSL library. # GSL_CBLAS_LIBRARY - The GSL CBLAS library. # GSL_VERSION - The version of the discovered GSL install. # GSL_ROOT_DIR - The top level directory of the discovered GSL # install (useful if GSL is not in a standard location) # # It will also provide the CMake library target names gsl::gsl and # gsl::gslcblas. # # === Usage === # # To use this module, simply call FindGSL from a CMakeLists.txt file, or # run find_package(GSL), then run CMake. If you are happy with the # auto- detected configuration for your language, then you're done. If # not, you have the option of manually specifying the GSL_ROOT_DIR: # # - Set GSL_ROOT_DIR to a directory that contains a GSL install. This # script expects to find libraries at $GSL_ROOT_DIR/lib and the # GSL headers at $GSL_ROOT_DIR/include/gsl. The library directory # may optionally provide Release and Debug folders. For Unix-like # systems, this script will use $GSL_ROOT_DIR/bin/gsl-config (if found) # to aid in the discovery GSL. # # When configuration is successful, GSL_INCLUDE_DIR will be set to # the location of the GSL header files and GSL_LIBRARY and GSL_CBLAS_LIBRARY # will be set to fully qualified path locations of the GSL # libraries. Also, the imported targets gsl::gsl and gsl::gslcblas will be # available for use in your project. #============================================================================= # Copyright 2014 Kelly Thompson kgt at lanl.gov # # Distributed under the OSI-approved BSD License (the "License"); # see accompanying file Copyright.txt for details. # # This software is distributed WITHOUT ANY WARRANTY; without even the # implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. # See the License for more information. #============================================================================= # Warn about using with older versions of CMake... # - This module uses PkgConfig (since 2.8), import libraries (since # 2.6), but developed and only tested with CMake 3.0+ if(CMAKE_MINIMUM_REQUIRED_VERSION VERSION_LESS 3.0.0) message(AUTHOR_WARNING "Your project should require at least CMake 3.0.0 to use FindGSL.cmake") endif() # Include these modules to handle the QUIETLY and REQUIRED arguments. See # - http://www.cmake.org/cmake/help/v3.0/module/FindPackageHandleStandardArgs.html # - http://www.cmake.org/cmake/help/v3.0/module/GetPrerequisites.html include(FindPackageHandleStandardArgs) include(GetPrerequisites) #============================================================================= # If the user has provided $GSL_ROOT_DIR, use it! Choose items found # at this location over system locations. if( EXISTS "$ENV{GSL_ROOT_DIR}" ) file( TO_CMAKE_PATH "$ENV{GSL_ROOT_DIR}" GSL_ROOT_DIR ) set( GSL_ROOT_DIR "${GSL_ROOT_DIR}" CACHE PATH "Prefix for GSL installation." ) endif() if( NOT EXISTS "${GSL_ROOT_DIR}" ) set( GSL_USE_PKGCONFIG ON ) endif() #============================================================================= # As a first try, use the PkgConfig module. This will work on many # *NIX systems. See # http://www.cmake.org/cmake/help/v3.0/module/FindPkgConfig.html # This will return GSL_INCLUDEDIR and GSL_LIBDIR used below. if( GSL_USE_PKGCONFIG ) find_package(PkgConfig) pkg_check_modules( GSL QUIET gsl ) if( EXISTS "${GSL_INCLUDEDIR}" ) get_filename_component( GSL_ROOT_DIR "${GSL_INCLUDEDIR}" DIRECTORY CACHE) endif() endif() #============================================================================= # Set GSL_INCLUDE_DIR, GSL_LIBRARY and GSL_CBLAS_LIBRARY. # If we skipped the PkgConfig step, try to find the libraries at # $GSL_ROOT_DIR (if provided) or in standard system locations. # These find_library and find_path calls will prefer custom locations # over standard locations (HINTS). If the requested file is not found # at the HINTS location, standard system locations will be still be searched # (/usr/lib64 (Redhat), lib/i386-linux-gnu (Debian)). find_path( GSL_INCLUDE_DIR NAMES gsl/gsl_sf.h HINTS ${GSL_ROOT_DIR}/include ${GSL_INCLUDEDIR} ) find_library( GSL_LIBRARY NAMES gsl HINTS ${GSL_ROOT_DIR}/lib ${GSL_LIBDIR} PATH_SUFFIXES Release Debug ) find_library( GSL_CBLAS_LIBRARY NAMES gslcblas cblas HINTS ${GSL_ROOT_DIR}/lib ${GSL_LIBDIR} PATH_SUFFIXES Release Debug ) # Do we also have debug versions? find_library( GSL_LIBRARY_DEBUG NAMES gsl HINTS ${GSL_ROOT_DIR}/lib ${GSL_LIBDIR} PATH_SUFFIXES Debug ) find_library( GSL_CBLAS_LIBRARY_DEBUG NAMES gslcblas cblas HINTS ${GSL_ROOT_DIR}/lib ${GSL_LIBDIR} PATH_SUFFIXES Debug ) # If we didn't use PkgConfig, try to find the version via gsl-config # or by reading gsl_version.h. if( NOT GSL_VERSION ) # 1. If gsl-config exists, query for the version. find_program( GSL_CONFIG NAMES gsl-config HINTS "${GSL_ROOT_DIR}/bin" ) if( EXISTS "${GSL_CONFIG}" ) exec_program( "${GSL_CONFIG}" ARGS --version OUTPUT_VARIABLE GSL_VERSION ) endif() # 2. If gsl-config is not available, try looking in gsl/gsl_version.h if( NOT GSL_VERSION AND EXISTS "${GSL_INCLUDE_DIR}/gsl/gsl_version.h" ) file( STRINGS "${GSL_INCLUDE_DIR}/gsl/gsl_version.h" gsl_version_h_contents ) foreach( entry ${gsl_version_h_contents} ) if( ${entry} MATCHES "define GSL_VERSION") string( REGEX REPLACE ".*([0-9].[0-9][0-9]).*" "\\1" GSL_VERSION ${entry} ) endif() endforeach() endif() # might also try scraping the directory name for a regex match "gsl-X.X" endif() #============================================================================= # handle the QUIETLY and REQUIRED arguments and set GSL_FOUND to TRUE if # all listed variables are TRUE find_package_handle_standard_args( GSL FOUND_VAR GSL_FOUND REQUIRED_VARS GSL_INCLUDE_DIR GSL_LIBRARY GSL_CBLAS_LIBRARY GSL_ROOT_DIR VERSION_VAR GSL_VERSION ) mark_as_advanced( GSL_FOUND GSL_LIBRARY GSL_CBLAS_LIBRARY GSL_INCLUDE_DIR GSL_ROOT_DIR GSL_VERSION GSL_LIBRARY_DEBUG GSL_CBLAS_LIBRARY_DEBUG GSL_USE_PKGCONFIG GSL_CONFIG CACHE ) #============================================================================= # Register imported libraries: # 1. If we can find a Windows .dll file (or if we can find both Debug and # Release libraries), we will set appropriate target properties for these. # 2. However, for most systems, we will only register the import location and # include directory. # Look for dlls, or Release and Debug libraries. if(WIN32) string( REPLACE ".lib" ".dll" GSL_LIBRARY_DLL "${GSL_LIBRARY}" ) string( REPLACE ".lib" ".dll" GSL_CBLAS_LIBRARY_DLL "${GSL_CBLAS_LIBRARY}" ) string( REPLACE ".lib" ".dll" GSL_LIBRARY_DEBUG_DLL "${GSL_LIBRARY_DEBUG}" ) string( REPLACE ".lib" ".dll" GSL_CBLAS_LIBRARY_DEBUG_DLL "${GSL_CBLAS_LIBRARY_DEBUG}" ) endif() if( GSL_FOUND ) if( EXISTS "${GSL_LIBRARY_DLL}" AND EXISTS "${GSL_CBLAS_LIBRARY_DLL}") # Windows systems with dll libraries. add_library( gsl::gsl SHARED IMPORTED ) add_library( gsl::gslcblas SHARED IMPORTED ) # Windows with dlls, but only Release libraries. set_target_properties( gsl::gslcblas PROPERTIES IMPORTED_LOCATION "${GSL_CBLAS_LIBRARY_DLL}" IMPORTED_IMPLIB "${GSL_CBLAS_LIBRARY}" INTERFACE_INCLUDE_DIRECTORIES "${GSL_INCLUDE_DIR}" IMPORTED_LINK_INTERFACE_LANGUAGES "C" ) set_target_properties( gsl::gsl PROPERTIES IMPORTED_LOCATION "${GSL_LIBRARY_DLL}" IMPORTED_IMPLIB "${GSL_LIBRARY}" INTERFACE_INCLUDE_DIRECTORIES "${GSL_INCLUDE_DIR}" IMPORTED_LINK_INTERFACE_LANGUAGES "C" IMPORTED_LINK_INTERFACE_LIBRARIES gsl::gslcblas ) # If we have both Debug and Release libraries if( EXISTS "${GSL_LIBRARY_DEBUG_DLL}" AND EXISTS "${GSL_CBLAS_LIBRARY_DEBUG_DLL}") set_target_properties( gsl::gslcblas PROPERTIES IMPORTED_LOCATION_DEBUG "${GSL_CBLAS_LIBRARY_DEBUG_DLL}" IMPORTED_IMPLIB_DEBUG "${GSL_CBLAS_LIBRARY_DEBUG}" ) set_target_properties( gsl::gsl PROPERTIES IMPORTED_LOCATION_DEBUG "${GSL_LIBRARY_DEBUG_DLL}" IMPORTED_IMPLIB_DEBUG "${GSL_LIBRARY_DEBUG}" ) endif() else() # If this platform doesn't support shared libraries (e.g. cross # compiling), assume static. This suppresses CMake (3.0.0) warnings # of the form: # "ADD_LIBRARY called with MODULE option but the target platform # does not support dynamic linking. Building a STATIC library # instead. This may lead to problems." if( TARGET_SUPPORTS_SHARED_LIBS ) # *NIX systems or simple installs. add_library( gsl::gsl UNKNOWN IMPORTED ) add_library( gsl::gslcblas UNKNOWN IMPORTED ) else() # cross compiling or platform only supports static libs. add_library( gsl::gsl STATIC IMPORTED ) add_library( gsl::gslcblas STATIC IMPORTED ) endif() set_target_properties( gsl::gslcblas PROPERTIES IMPORTED_LOCATION "${GSL_CBLAS_LIBRARY}" INTERFACE_INCLUDE_DIRECTORIES "${GSL_INCLUDE_DIR}" IMPORTED_LINK_INTERFACE_LANGUAGES "C" ) set_target_properties( gsl::gsl PROPERTIES IMPORTED_LOCATION "${GSL_LIBRARY}" INTERFACE_INCLUDE_DIRECTORIES "${GSL_INCLUDE_DIR}" IMPORTED_LINK_INTERFACE_LANGUAGES "C" IMPORTED_LINK_INTERFACE_LIBRARIES gsl::gslcblas ) endif() endif() #============================================================================= # Include some information that can be printed by the build system. include( FeatureSummary ) set_package_properties( GSL PROPERTIES DESCRIPTION "Gnu Scientific Library" URL "www.gnu.org/software/gsl" PURPOSE "The GNU Scientific Library (GSL) is a numerical library for C and C++ programmers." ) #============================================================================= # References: # - http://www.cmake.org/cmake/help/git-master/manual/cmake-developer.7.html#modules #============================================================================= -------------- next part -------------- An HTML attachment was scrubbed... URL: From mantis at public.kitware.com Tue Dec 2 12:07:27 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 2 Dec 2014 12:07:27 -0500 Subject: [cmake-developers] [CMake 0015276]: Cannot set Toolchain Version, Ant Build Root Path, Android Manifest Location and Java Source Directory in Android VS project Message-ID: The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15276 ====================================================================== Reported By: deathicon Assigned To: ====================================================================== Project: CMake Issue ID: 15276 Category: CMake Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2014-12-02 12:07 EST Last Modified: 2014-12-02 12:07 EST ====================================================================== Summary: Cannot set Toolchain Version, Ant Build Root Path, Android Manifest Location and Java Source Directory in Android VS project Description: When generating Visual Studio projects for Tegra-Android using the latest CMake 3.1-rc2, there is no options to allow us to set the following project properties: - Project Defaults -> Toolchain Version - Ant Build -> Ant Build Root Path - Ant Build -> Android Manifest Location - Ant Build -> Java Source Directory The Toolchain Version would allow us to specify 'Default Clang' or 'Default GCC', which is very useful to have. The Ant Build options are currently guessed by CMake to point to the ${PROJECT_SOURCE_DIR}, which is annoying if we want to put these files somewhere else... especially the Java Source Directory. In the target properties, we currently have ANDROID_API and ANDROID_GUI. Can we add the missing properties? Thanks. Steps to Reproduce: Generate any simple Tegra-Android projects for Visual Studio, see we can't control these properties. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-12-02 12:07 deathicon New Issue ====================================================================== From brad.king at kitware.com Tue Dec 2 13:37:28 2014 From: brad.king at kitware.com (Brad King) Date: Tue, 02 Dec 2014 13:37:28 -0500 Subject: [cmake-developers] Volunteering to maintain a new module: FindGSL.cmake In-Reply-To: <0458DF31F610EF42BFC78C497E806C7B3B53D0EA@ECS-EXG-P-MB03.win.lanl.gov> References: <0458DF31F610EF42BFC78C497E806C7B3B53D0EA@ECS-EXG-P-MB03.win.lanl.gov> Message-ID: <547E06E8.1050400@kitware.com> On 12/02/2014 12:06 PM, Thompson, KT wrote: > A copy of my proposed module follows. Great, thanks. Here are some comments. > #============================================================================= This line should be dropped. > # GSL_INCLUDE_DIR - Location of GSL header files. > # GSL_LIBRARY - The GSL library. > # GSL_CBLAS_LIBRARY - The GSL CBLAS library. Please read the section of the developer manual on variable names. The singular names used for cache entries referring to individual files should not be presented as results. Instead they should be presented in non-cached variables with plural names: GSL_INCLUDE_DIRS GSL_LIBRARIES GSL_CBLAS_LIBRARIES > # GSL_ROOT_DIR - The top level directory of the discovered GSL > # install (useful if GSL is not in a standard location) This and the other singular names should be documented as variables that are used as hints or to record results. > # It will also provide the CMake library target names gsl::gsl and > # gsl::gslcblas. Please have a dedicated documentation section for the imported targets and use a definition list for them. Also the convention that has been established in a few other find modules is to use the "::" namespace for modules where "" matches what users put in "find_package()" calls. That would be "GSL::" for FindGSL. > # Warn about using with older versions of CMake... > # - This module uses PkgConfig (since 2.8), import libraries (since > # 2.6), but developed and only tested with CMake 3.0+ > if(CMAKE_MINIMUM_REQUIRED_VERSION VERSION_LESS 3.0.0) > message(AUTHOR_WARNING > "Your project should require at least CMake 3.0.0 to use FindGSL.cmake") > endif() This section is not needed when the module comes with CMake. > include(FindPackageHandleStandardArgs) Use a full path to include dependencies: include(${CMAKE_CURRENT_LIST_DIR}/FindPackageHandleStandardArgs.cmake) > include(GetPrerequisites) This module is used for packaging and should not be needed for find modules in general. > # http://www.cmake.org/cmake/help/v3.0/module/FindPkgConfig.html Links like this should not be present for modules in upstream CMake. > exec_program( "${GSL_CONFIG}" > ARGS --version > OUTPUT_VARIABLE GSL_VERSION ) Please use execute_process instead. It has options to strip whitespace too. > mark_as_advanced( GSL_FOUND GSL_LIBRARY GSL_CBLAS_LIBRARY > GSL_INCLUDE_DIR GSL_ROOT_DIR GSL_VERSION GSL_LIBRARY_DEBUG > GSL_CBLAS_LIBRARY_DEBUG GSL_USE_PKGCONFIG GSL_CONFIG CACHE ) There is no CACHE option to mark_as_advanced. GSL_FOUND should not be cached so it does not need to be marked. > set_target_properties( gsl::gslcblas PROPERTIES > IMPORTED_LOCATION "${GSL_CBLAS_LIBRARY_DLL}" > IMPORTED_IMPLIB "${GSL_CBLAS_LIBRARY}" > INTERFACE_INCLUDE_DIRECTORIES "${GSL_INCLUDE_DIR}" > IMPORTED_LINK_INTERFACE_LANGUAGES "C" ) > set_target_properties( gsl::gsl PROPERTIES > IMPORTED_LOCATION "${GSL_LIBRARY_DLL}" > IMPORTED_IMPLIB "${GSL_LIBRARY}" > INTERFACE_INCLUDE_DIRECTORIES "${GSL_INCLUDE_DIR}" > IMPORTED_LINK_INTERFACE_LANGUAGES "C" > IMPORTED_LINK_INTERFACE_LIBRARIES gsl::gslcblas ) See CMP0022 and use INTERFACE_LINK_LIBRARIES instead of IMPORTED_LINK_INTERFACE_LIBRARIES. > if( TARGET_SUPPORTS_SHARED_LIBS ) This is not a variable, but a global property that needs to be read with get_property. Also there is not much reason not to just use UNKNOWN all the time. > set_target_properties( gsl::gslcblas PROPERTIES > IMPORTED_LOCATION "${GSL_CBLAS_LIBRARY}" > INTERFACE_INCLUDE_DIRECTORIES "${GSL_INCLUDE_DIR}" > IMPORTED_LINK_INTERFACE_LANGUAGES "C" ) > set_target_properties( gsl::gsl PROPERTIES > IMPORTED_LOCATION "${GSL_LIBRARY}" > INTERFACE_INCLUDE_DIRECTORIES "${GSL_INCLUDE_DIR}" > IMPORTED_LINK_INTERFACE_LANGUAGES "C" > IMPORTED_LINK_INTERFACE_LIBRARIES gsl::gslcblas ) See above comment about CMP0022. > include( FeatureSummary ) > set_package_properties( GSL PROPERTIES > DESCRIPTION "Gnu Scientific Library" > URL "www.gnu.org/software/gsl" > PURPOSE "The GNU Scientific Library (GSL) is a numerical library for C and C++ programmers." > ) The FeatureSummary module is for applications, not find modules. Thanks, -Brad From eike at sf-mail.de Tue Dec 2 14:08:30 2014 From: eike at sf-mail.de (Rolf Eike Beer) Date: Tue, 02 Dec 2014 20:08:30 +0100 Subject: [cmake-developers] Volunteering to maintain a new module: FindGSL.cmake In-Reply-To: <547E06E8.1050400@kitware.com> References: <0458DF31F610EF42BFC78C497E806C7B3B53D0EA@ECS-EXG-P-MB03.win.lanl.gov> <547E06E8.1050400@kitware.com> Message-ID: <4760202.me6IPvkdsO@eto> Brad King wrote: > On 12/02/2014 12:06 PM, Thompson, KT wrote: > > # GSL_ROOT_DIR - The top level directory of the discovered GSL > > # install (useful if GSL is not in a standard > > location) > This and the other singular names should be documented as variables > that are used as hints or to record results. I wonder if this is needed at all. Isn't CMAKE_PREFIX_PATH enough? Eike -- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From brad.king at kitware.com Tue Dec 2 14:19:39 2014 From: brad.king at kitware.com (Brad King) Date: Tue, 02 Dec 2014 14:19:39 -0500 Subject: [cmake-developers] CMAKE_PREFIX_PATH v. _ROOT_DIR (was: Volunteering to maintain a new module: FindGSL.cmake) In-Reply-To: <4760202.me6IPvkdsO@eto> References: <0458DF31F610EF42BFC78C497E806C7B3B53D0EA@ECS-EXG-P-MB03.win.lanl.gov> <547E06E8.1050400@kitware.com> <4760202.me6IPvkdsO@eto> Message-ID: <547E10CB.6070505@kitware.com> On 12/02/2014 02:08 PM, Rolf Eike Beer wrote: > Brad King wrote: >> On 12/02/2014 12:06 PM, Thompson, KT wrote: > >>> # GSL_ROOT_DIR - The top level directory of the discovered GSL >>> # install (useful if GSL is not in a standard >>> location) >> This and the other singular names should be documented as variables >> that are used as hints or to record results. > > I wonder if this is needed at all. Isn't CMAKE_PREFIX_PATH enough? I've long touted CMAKE_PREFIX_PATH as a generic solution that avoids the need for per-package _ROOT_DIR variables. However, it was originally intended just to provide a way to configure user-specific search prefixes. This makes sense when lots of packages are installed into a few user-specific prefixes. On platforms like Windows, though, it is very common to have a separate prefix for every package. It is less convenient to pass a whole list of package roots to CMAKE_PREFIX_PATH than it is to specify separate _ROOT_DIR variables for each package. This is especially true in cmake-gui when a dialog can be used to find a single root directory. I think this is why people tend to create _ROOT_DIR variables in their find modules. -Brad From ts at medical-insight.com Tue Dec 2 15:07:12 2014 From: ts at medical-insight.com (Thomas Sondergaard) Date: Tue, 02 Dec 2014 21:07:12 +0100 Subject: [cmake-developers] ctest -j 32 hanging In-Reply-To: <547DCCA9.1040708@kitware.com> References: <547DCCA9.1040708@kitware.com> Message-ID: On 2014-12-02 15:28, Brad King wrote: > On 12/02/2014 09:10 AM, Thomas Sondergaard wrote: >> One of the tests spawns a dbus-daemon.exe which was leftover, once I >> killed that ctest.exe finished too. Is this consistent with the expected >> ctest behavior? > > This is a known limitation of the way CTest runs processes. If a > parent exits before the grandchildren, and the latter do not exit, > then things get stuck because they keep pipes open that CTest is > blocking on waiting to be closed. This is only a problem on Windows. > > This limitation is left from the way things had to be implemented > way back when Windows 98 was supported to work there without polling. > The infrastructure update required to fix it is non-trivial so no one > has taken the time to do it yet. > > -Brad OK, thanks. The test is not supposed to leave processes after it exits, so fixing the test should avoid the problem. Thomas From Robert.Goulet at autodesk.com Tue Dec 2 14:24:31 2014 From: Robert.Goulet at autodesk.com (Robert Goulet) Date: Tue, 2 Dec 2014 19:24:31 +0000 Subject: [cmake-developers] CMake 3.1 Android - generator expressions and output names Message-ID: Perhaps it would be nice to have a generator expression that refers to the .apk file produced when compiling for Android? Also, it would make sense that the .apk output name respect the names that we set using the target properties OUTPUT_NAME_. Right now it uses the project's name for the .apk, while the .so does indeed respect the output name set. Thoughts? While discussing about CMake Android support... is there a way to set the Visual Studio property C/C++ -> Language -> C++ Language Standard to other values than Default? I would like to set it to C++11. Unfortunately, setting -std=c++11 on the command line generates the error "invalid argument '-std=c++11' not allowed with 'C/ObjC'", and it would be super annoying to go and set this flag for each cpp files manually because we are using a lot of projects. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Tue Dec 2 15:45:27 2014 From: brad.king at kitware.com (Brad King) Date: Tue, 02 Dec 2014 15:45:27 -0500 Subject: [cmake-developers] CMake 3.1 Android - generator expressions and output names In-Reply-To: References: Message-ID: <547E24E7.8040109@kitware.com> Hi Robert, Thanks for trying out the Nsight Tegra generator support. It is brand new so we are just at the beginning of the maturation process. We would appreciate any help you can provide. On 12/02/2014 02:24 PM, Robert Goulet wrote: > Perhaps it would be nice to have a generator expression that > refers to the .apk file produced when compiling for Android? This may be possible, but first we should work out the output name and location settings as discussed next. > Also, it would make sense that the .apk output name respect > the names that we set using the target properties > OUTPUT_NAME_. Right now it uses the project's name for the > .apk, while the .so does indeed respect the output name set. Is it possible to configure the .apk name through the IDE? If so, CMake could be taught to add the corresponding setting to the .vcxproj file. If not, then Nsight Tegra itself would have to be modified by NVIDIA to support such a setting. Some output directory settings may be needed too. We have RUNTIME_OUTPUT_DIRECTORY, LIBRARY_OUTPUT_DIRECTORY, and ARCHIVE_OUTPUT_DIRECTORY already. I'm not sure if one of these should apply to the .apk, or if another setting would be needed. Also the availability of Nsight Tegra settings for this needs to be investigated. > C++ Language Standard to other values than Default? I don't think there is currently. The commit adding the original support was: VS: Teach vcxproj generation about the Tegra-Android platform http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ef0fd4f0 The commit message documents many of the limitations. Only the last bullet (ANDROID_GUI prop) and part of the second bullet (ANDROID_API prop) have been addressed so far. The lack of a flag table or other controls for the rest of the project settings is currently the main limitation. -Brad From brad.king at kitware.com Tue Dec 2 15:54:05 2014 From: brad.king at kitware.com (Brad King) Date: Tue, 02 Dec 2014 15:54:05 -0500 Subject: [cmake-developers] [PATCH] CPack IFW updates In-Reply-To: <1095311417553379@web12m.yandex.ru> References: <1095311417553379@web12m.yandex.ru> Message-ID: <547E26ED.3080107@kitware.com> On 12/02/2014 03:49 PM, Konstantin Podsvirov wrote: > I made a few edits to the documentation of the module. Applied, thanks: CPackIFW: Correction of the module documentation http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4c07a00f I've queued it for inclusion in the next 3.1 release candidate. -Brad From konstantin at podsvirov.pro Tue Dec 2 15:49:39 2014 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Tue, 02 Dec 2014 23:49:39 +0300 Subject: [cmake-developers] [PATCH] CPack IFW updates Message-ID: <1095311417553379@web12m.yandex.ru> Hi, Brad! I made a few edits to the documentation of the module. Changed only one file. Here is the link to the commit: http://git.podsvirov.pro/?p=kitware/cmake.git;a=commit;h=0abd322c3c0db64fc39f9cd6182ba81739c2fc6b Please accept my changes. -- Regards, Konstantin Podsvirov From Robert.Goulet at autodesk.com Tue Dec 2 16:28:14 2014 From: Robert.Goulet at autodesk.com (Robert Goulet) Date: Tue, 2 Dec 2014 21:28:14 +0000 Subject: [cmake-developers] CMake 3.1 Android - generator expressions and output names In-Reply-To: <547E24E7.8040109@kitware.com> References: <547E24E7.8040109@kitware.com> Message-ID: I can't find any options to set the .apk name from the IDE, but I find it interesting that it uses the project's name instead of the output file name set in the IDE. Hence why I wonder if its CMake result or if its NVidia's Tegra toolkit? But I have a work-around for that, using add_custom_command to do a copy using ${CMAKE_COMMAND} -E copy. So my only issue left is the fact that I will have to use set_source_properties to pass the -std=c++11 flag instead of being able to set the "C++ Language Standard" option. That is a bit annoying, is there a better work-around? Thanks! -----Original Message----- From: Brad King [mailto:brad.king at kitware.com] Sent: Tuesday, December 2, 2014 3:45 PM To: Robert Goulet Cc: cmake-developers at cmake.org Subject: Re: [cmake-developers] CMake 3.1 Android - generator expressions and output names Hi Robert, Thanks for trying out the Nsight Tegra generator support. It is brand new so we are just at the beginning of the maturation process. We would appreciate any help you can provide. On 12/02/2014 02:24 PM, Robert Goulet wrote: > Perhaps it would be nice to have a generator expression that refers to > the .apk file produced when compiling for Android? This may be possible, but first we should work out the output name and location settings as discussed next. > Also, it would make sense that the .apk output name respect the names > that we set using the target properties OUTPUT_NAME_. Right > now it uses the project's name for the .apk, while the .so does indeed > respect the output name set. Is it possible to configure the .apk name through the IDE? If so, CMake could be taught to add the corresponding setting to the .vcxproj file. If not, then Nsight Tegra itself would have to be modified by NVIDIA to support such a setting. Some output directory settings may be needed too. We have RUNTIME_OUTPUT_DIRECTORY, LIBRARY_OUTPUT_DIRECTORY, and ARCHIVE_OUTPUT_DIRECTORY already. I'm not sure if one of these should apply to the .apk, or if another setting would be needed. Also the availability of Nsight Tegra settings for this needs to be investigated. > C++ Language Standard to other values than Default? I don't think there is currently. The commit adding the original support was: VS: Teach vcxproj generation about the Tegra-Android platform http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ef0fd4f0 The commit message documents many of the limitations. Only the last bullet (ANDROID_GUI prop) and part of the second bullet (ANDROID_API prop) have been addressed so far. The lack of a flag table or other controls for the rest of the project settings is currently the main limitation. -Brad From Gilles.Khouzam at microsoft.com Tue Dec 2 16:41:24 2014 From: Gilles.Khouzam at microsoft.com (Gilles Khouzam) Date: Tue, 2 Dec 2014 21:41:24 +0000 Subject: [cmake-developers] Patch to allow content file location to be specified Message-ID: I'd like a patch to allow the location of content files to be specified. We added the VS_DEPLOYMENT_CONTENT property to mark source files as content. This will allow to specify where the files end up in the application package. Documentation and tests have been updated. Gilles Khouzam Senior Development Lead Microsoft OSG -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: VS_DEPLOYMENT_LOCATION.patch Type: application/octet-stream Size: 9529 bytes Desc: VS_DEPLOYMENT_LOCATION.patch URL: From konstantin at podsvirov.pro Tue Dec 2 16:50:52 2014 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Wed, 03 Dec 2014 00:50:52 +0300 Subject: [cmake-developers] [DISCUSSION] Using COMPONENTs for CMake install(...)? Message-ID: <50071417557052@web29o.yandex.ru> CMake is being developed for a long time, but does not use COMPONENTs during installation. Why? The command install(...) allows you to specify the COMPONENT. Why this feature is not used by CMake? Is it possible to split the install CMake on COMPONENTs? Further it can be used when creating redistributable packages. Your questions and suggestions! -- Regards, Konstantin Podsvirov From kgt at lanl.gov Tue Dec 2 19:52:38 2014 From: kgt at lanl.gov (Thompson, KT) Date: Wed, 3 Dec 2014 00:52:38 +0000 Subject: [cmake-developers] Volunteering to maintain a new module: FindGSL.cmake In-Reply-To: <547E06E8.1050400@kitware.com> References: <0458DF31F610EF42BFC78C497E806C7B3B53D0EA@ECS-EXG-P-MB03.win.lanl.gov>, <547E06E8.1050400@kitware.com> Message-ID: <0458DF31F610EF42BFC78C497E806C7B3B53D2B1@ECS-EXG-P-MB03.win.lanl.gov> Brad, Thank you very much for the constructive comments concerning my submitted FindGSL.cmake module. I believe I have addressed nearly all of your concerns in the version shown below. I have two comments that may be useful: 1. The command "add_library(GSL::gsl UNKOWN IMPORTED)" generates warnings on platforms that do not support shared libraries. For example on the Cray XE6 (I think I also get this on BlueGene, but I didn't test it today): FindGSL.cmake:223 (add_library): ADD_LIBRARY called with MODULE option but the target platform does not support dynamic linking. Building a STATIC library instead. This may lead to problems. I have added a query for the value of TARGET_SUPPORTS_SHARED_LIBS and will use the library type "STATIC" when this property is FALSE. 2. I understand the concerns with setting GSL_ROOT_DIR that you and Rolf raised. Personally, I like using GSL_ROOT_DIR because it plays nicely with our use of modules (modules.sourceforge.net) or dotkit (computing.llnl.gov/?set=jobs&page=dotkit) and the revised FindGSL.cmake continues to use GSL_ROOT_DIR. The decision to eliminate XXX_ROOT_DIR type variables from all cmake modules is beyond the scope of my submission and I will not comment further except to say that I could use CMAKE_PREFIX_PATH just as easily. Again -- thank you for your help. -kt #.rst # Find GSL # -------- # # Find the native GSL includes and libraries. # # The GNU Scientific Library (GSL) is a numerical library for C and C++ # programmers. It is free software under the GNU General Public License. # # === Imported Targets === # # If GSL is found, this module defines the following :prop_tgt:`IMPORTED` targets # # :: # # ``GSL::gsl`` - The main GSL library. # ``GSL::gslcblas`` - The CBLAS support library used by GSL. # # === Result Variables === # # This module will set the following variables per language in your project: # # :: # # GSL_FOUND - True if GSL found on the local system # GSL_INCLUDE_DIRS - Location of GSL header files. # GSL_LIBRARIES - The GSL libraries. # GSL_VERSION - The version of the discovered GSL install. # GSL_ROOT_DIR - The top level directory of the discovered GSL # install (useful if GSL is not in a standard location) # # === Hints === # # Set ``GSL_ROOT_DIR`` to a directory that contains a GSL installation. # # This script expects to find libraries at $GSL_ROOT_DIR/lib and the GSL headers # at $GSL_ROOT_DIR/include/gsl. The library directory may optionally provide # Release and Debug folders. For Unix-like systems, this script will use # $GSL_ROOT_DIR/bin/gsl-config (if found) to aid in the discovery GSL. # # === Usage === # # To use this module, simply call FindGSL from a CMakeLists.txt file, or run # find_package(GSL), then run CMake. If you are happy with the auto-detected # configuration for your language, then you're done. If not, you have the # option of manually specifying the ``GSL_ROOT_DIR``. # # This module may set the following variables depending on platform and type # of GSL installation discovered. These variables may optionally be set to # help this module find the correct files. # # :: # # GSL_CLBAS_LIBRARY - Location of the GSL CBLAS library. # GSL_CBLAS_LIBRARY_DEBUG - Location of the debug GSL CBLAS library (if any). # GSL_CONFIG - Location of the ``gsl-config`` script (if any). # GSL_LIBRARY - Location of the GSL library. # GSL_LIBRARY_DEBUG - Location of the debug GSL library (if any). #============================================================================= # Copyright 2014 Kelly Thompson kgt at lanl.gov # # Distributed under the OSI-approved BSD License (the "License"); # see accompanying file Copyright.txt for details. # # This software is distributed WITHOUT ANY WARRANTY; without even the implied # warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # License for more information. # ============================================================================= # Include these modules to handle the QUIETLY and REQUIRED arguments. See # http://www.cmake.org/cmake/help/v3.0/module/FindPackageHandleStandardArgs.html include(${CMAKE_CURRENT_LIST_DIR}/FindPackageHandleStandardArgs.cmake) #============================================================================= # If the user has provided ``GSL_ROOT_DIR``, use it! Choose items found # at this location over system locations. if( EXISTS "$ENV{GSL_ROOT_DIR}" ) file( TO_CMAKE_PATH "$ENV{GSL_ROOT_DIR}" GSL_ROOT_DIR ) set( GSL_ROOT_DIR "${GSL_ROOT_DIR}" CACHE PATH "Prefix for GSL installation." ) endif() if( NOT EXISTS "${GSL_ROOT_DIR}" ) set( GSL_USE_PKGCONFIG ON ) endif() #============================================================================= # As a first try, use the PkgConfig module. This will work on many # *NIX systems. See :module:`findpkgconfig` # This will return ``GSL_INCLUDEDIR`` and ``GSL_LIBDIR`` used below. if( GSL_USE_PKGCONFIG ) find_package(PkgConfig) pkg_check_modules( GSL QUIET gsl ) if( EXISTS "${GSL_INCLUDEDIR}" ) get_filename_component( GSL_ROOT_DIR "${GSL_INCLUDEDIR}" DIRECTORY CACHE) endif() endif() #============================================================================= # Set GSL_INCLUDE_DIRS and GSL_LIBRARIES. If we skipped the PkgConfig step, try # to find the libraries at $GSL_ROOT_DIR (if provided) or in standard system # locations. These find_library and find_path calls will prefer custom # locations over standard locations (HINTS). If the requested file is not found # at the HINTS location, standard system locations will be still be searched # (/usr/lib64 (Redhat), lib/i386-linux-gnu (Debian)). find_path( GSL_INCLUDE_DIRS NAMES gsl/gsl_sf.h HINTS ${GSL_ROOT_DIR}/include ${GSL_INCLUDEDIR} ) find_library( GSL_LIBRARY NAMES gsl HINTS ${GSL_ROOT_DIR}/lib ${GSL_LIBDIR} PATH_SUFFIXES Release Debug ) find_library( GSL_CBLAS_LIBRARY NAMES gslcblas cblas HINTS ${GSL_ROOT_DIR}/lib ${GSL_LIBDIR} PATH_SUFFIXES Release Debug ) # Do we also have debug versions? find_library( GSL_LIBRARY_DEBUG NAMES gsl HINTS ${GSL_ROOT_DIR}/lib ${GSL_LIBDIR} PATH_SUFFIXES Debug ) find_library( GSL_CBLAS_LIBRARY_DEBUG NAMES gslcblas cblas HINTS ${GSL_ROOT_DIR}/lib ${GSL_LIBDIR} PATH_SUFFIXES Debug ) set( GSL_LIBRARIES ${GSL_LIBRARY};${GSL_CBLAS_LIBRARY} CACHE PATH "GSL libraries." ) # If we didn't use PkgConfig, try to find the version via gsl-config or by # reading gsl_version.h. if( NOT GSL_VERSION ) # 1. If gsl-config exists, query for the version. find_program( GSL_CONFIG NAMES gsl-config HINTS "${GSL_ROOT_DIR}/bin" ) if( EXISTS "${GSL_CONFIG}" ) execute_process( COMMAND "${GSL_CONFIG}" --version OUTPUT_VARIABLE GSL_VERSION OUTPUT_STRIP_TRAILING_WHITESPACE ) endif() # 2. If gsl-config is not available, try looking in gsl/gsl_version.h if( NOT GSL_VERSION AND EXISTS "${GSL_INCLUDE_DIRS}/gsl/gsl_version.h" ) file( STRINGS "${GSL_INCLUDE_DIRS}/gsl/gsl_version.h" gsl_version_h_contents ) foreach( entry ${gsl_version_h_contents} ) if( ${entry} MATCHES "define GSL_VERSION") string( REGEX REPLACE ".*([0-9].[0-9][0-9]).*" "\\1" GSL_VERSION ${entry} ) endif() endforeach() endif() # might also try scraping the directory name for a regex match "gsl-X.X" endif() #============================================================================= # handle the QUIETLY and REQUIRED arguments and set GSL_FOUND to TRUE if all # listed variables are TRUE find_package_handle_standard_args( GSL FOUND_VAR GSL_FOUND REQUIRED_VARS GSL_INCLUDE_DIRS GSL_LIBRARIES GSL_ROOT_DIR VERSION_VAR GSL_VERSION ) mark_as_advanced( GSL_LIBRARIES GSL_INCLUDE_DIRS GSL_ROOT_DIR GSL_VERSION GSL_LIBRARY GSL_CBLAS_LIBRARY GSL_LIBRARY_DEBUG GSL_CBLAS_LIBRARY_DEBUG GSL_USE_PKGCONFIG GSL_CONFIG ) #============================================================================= # Register imported libraries: # 1. If we can find a Windows .dll file (or if we can find both Debug and # Release libraries), we will set appropriate target properties for these. # 2. However, for most systems, we will only register the import location and # include directory. # Look for dlls, or Release and Debug libraries. if(WIN32) string( REPLACE ".lib" ".dll" GSL_LIBRARY_DLL "${GSL_LIBRARY}" ) string( REPLACE ".lib" ".dll" GSL_CBLAS_LIBRARY_DLL "${GSL_CBLAS_LIBRARY}" ) string( REPLACE ".lib" ".dll" GSL_LIBRARY_DEBUG_DLL "${GSL_LIBRARY_DEBUG}" ) string( REPLACE ".lib" ".dll" GSL_CBLAS_LIBRARY_DEBUG_DLL "${GSL_CBLAS_LIBRARY_DEBUG}" ) endif() if( GSL_FOUND ) if( EXISTS "${GSL_LIBRARY_DLL}" AND EXISTS "${GSL_CBLAS_LIBRARY_DLL}") # Windows systems with dll libraries. add_library( GSL::gsl SHARED IMPORTED ) add_library( GSL::gslcblas SHARED IMPORTED ) # Windows with dlls, but only Release libraries. set_target_properties( GSL::gslcblas PROPERTIES IMPORTED_LOCATION "${GSL_CBLAS_LIBRARY_DLL}" IMPORTED_IMPLIB "${GSL_CBLAS_LIBRARY}" INTERFACE_INCLUDE_DIRECTORIES "${GSL_INCLUDE_DIRS}" IMPORTED_LINK_INTERFACE_LANGUAGES "C" ) set_target_properties( GSL::gsl PROPERTIES IMPORTED_LOCATION "${GSL_LIBRARY_DLL}" IMPORTED_IMPLIB "${GSL_LIBRARY}" INTERFACE_INCLUDE_DIRECTORIES "${GSL_INCLUDE_DIRS}" IMPORTED_LINK_INTERFACE_LANGUAGES "C" INTERFACE_LINK_LIBRARIES GSL::gslcblas ) # If we have both Debug and Release libraries if( EXISTS "${GSL_LIBRARY_DEBUG_DLL}" AND EXISTS "${GSL_CBLAS_LIBRARY_DEBUG_DLL}") set_target_properties( GSL::gslcblas PROPERTIES IMPORTED_LOCATION_DEBUG "${GSL_CBLAS_LIBRARY_DEBUG_DLL}" IMPORTED_IMPLIB_DEBUG "${GSL_CBLAS_LIBRARY_DEBUG}" ) set_target_properties( GSL::gsl PROPERTIES IMPORTED_LOCATION_DEBUG "${GSL_LIBRARY_DEBUG_DLL}" IMPORTED_IMPLIB_DEBUG "${GSL_LIBRARY_DEBUG}" ) endif() else() # If this platform doesn't support shared libraries (i.e.: Cray XE6 or Blue # Gene) suppress the CMake warning of the form: # "ADD_LIBRARY called with MODULE option but the target platform # does not support dynamic linking. Building a STATIC library # instead. This may lead to problems." # by setting the library type to STATIC instead of UNKNOWN get_property( os_supports_shared GLOBAL PROPERTY TARGET_SUPPORTS_SHARED_LIBS ) if( ${os_supports_shared} ) set( library_type UNKNOWN ) else() set( library_type STATIC ) endif() # Create the imported library targets add_library( GSL::gsl ${library_type} IMPORTED ) add_library( GSL::gslcblas ${library_type} IMPORTED ) set_target_properties( GSL::gslcblas PROPERTIES IMPORTED_LOCATION "${GSL_CBLAS_LIBRARY}" INTERFACE_INCLUDE_DIRECTORIES "${GSL_INCLUDE_DIRS}" IMPORTED_LINK_INTERFACE_LANGUAGES "C" ) set_target_properties( GSL::gsl PROPERTIES IMPORTED_LOCATION "${GSL_LIBRARY}" INTERFACE_INCLUDE_DIRECTORIES "${GSL_INCLUDE_DIRS}" IMPORTED_LINK_INTERFACE_LANGUAGES "C" INTERFACE_LINK_LIBRARIES GSL::gslcblas ) endif() endif() #============================================================================= # References: # - http://www.cmake.org/cmake/help/git-master/manual/cmake-developer.7.html#modules From mantis at public.kitware.com Wed Dec 3 05:20:44 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 3 Dec 2014 05:20:44 -0500 Subject: [cmake-developers] [CMake 0015277]: Nvidia Nsight (eclipse cdt for CUDA) error parsing broken Message-ID: <87516c7adb789a2c60089416e481fd5e@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15277 ====================================================================== Reported By: Georg Altmann Assigned To: ====================================================================== Project: CMake Issue ID: 15277 Category: CMake Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2014-12-03 05:20 EST Last Modified: 2014-12-03 05:20 EST ====================================================================== Summary: Nvidia Nsight (eclipse cdt for CUDA) error parsing broken Description: When using cmake -G"Eclipse CDT4 - Unix Makefiles" with the FindCUDA.cmake module for generating Eclipse projects for NVidia Nsight, error parsing does not work in Eclipse. NVidia Nsight is a beefed up version of Elcipse CDT. Enabling the "nvcc error parser" in "project->properties->C/C++ Make Project->Error Parsers" and moving it to the top of the list in the project properties has no effect. Tested cmake versions: cmake version 2.8.12.2 (Ubuntu 14.04.1 LTS) cmake version 3.1.0-rc2 (built from source) CUDA 6.5 Nsight Eclipse Edition 6.5 Eclipse C/C++ Development Tools Version: 8.1.2.nvidia-qualifier Steps to Reproduce: System Requirements: Have GCC/g++, CUDA and Nsight installed. 1. Download cudaproj.tar.gz from this bug. 2. Extract cudaproj.tar.gz 3. mkdir cudaproj-build && cd cudaproj-build 4. cmake -G"Eclipse CDT4 - Unix Makefiles" ../cudaproj 5. Import the project from cudaproj-build into Nsight, 6. Build the project. 7. In the console the compiler error ".../cudaproj/regular.cpp:3:2: error: ?C? was not declared in this scope" is highlighted, double-clicking on it opens regular.cpp and the cursor is on line 3. 8. In the console the compiler error "cudaproj.cu(4): error: identifier "syntax" is undefined" is _not_ highlighted while it should be. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-12-03 05:20 Georg Altmann New Issue 2014-12-03 05:20 Georg Altmann File Added: cudaproj.tar.gz ====================================================================== From mantis at public.kitware.com Wed Dec 3 09:07:06 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 3 Dec 2014 09:07:06 -0500 Subject: [cmake-developers] [CMake 0015278]: Ninja generator breaks when creating archives with GNU 'ar' in Windows Message-ID: The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15278 ====================================================================== Reported By: bogdanm Assigned To: ====================================================================== Project: CMake Issue ID: 15278 Category: CMake Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2014-12-03 09:07 EST Last Modified: 2014-12-03 09:07 EST ====================================================================== Summary: Ninja generator breaks when creating archives with GNU 'ar' in Windows Description: When creating an archive in Windows, the Ninja generator doesn't list all the archive members on the command line; instead, it creates a file with a list of all the archive members and gives that to 'ar' using '@file'. That in itself is a very good idea; unfortunately, backslashes in @file are interpreted as escape sequences, which effectively disregards the Windows path separator '\'. This can be fixed by using '\\' instead of '\' in @file. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-12-03 09:07 bogdanm New Issue ====================================================================== From brad.king at kitware.com Wed Dec 3 10:10:04 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 03 Dec 2014 10:10:04 -0500 Subject: [cmake-developers] New command 'file(LOCK_DIRECTORY ...)' In-Reply-To: <547C8EAE.9030900@kitware.com> References: <5431B11C.3010209@yahoo.com> <54665ED3.3060300@kitware.com> <54668FEC.5020203@yahoo.com> <708024991.ylpfiUSqup@caliban.sf-tec.de> <546A0F00.3090908@kitware.com> <546A8881.5050205@yahoo.com> <5474CA82.6090509@kitware.com> <54750FB3.6080903@yahoo.com> <547C8EAE.9030900@kitware.com> Message-ID: <547F27CC.3030209@kitware.com> On 12/01/2014 10:52 AM, Brad King wrote: > cmSystemTools: Add StringToInt helper > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5121f118 > > file: Add LOCK subcommand to do file and directory locking > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fca624ca > > Help: Add notes for topic 'file-LOCK-command' > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ed00a808 After some revisions: cmSystemTools: Add StringToInt helper http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=05d6531c file: Add LOCK subcommand to do file and directory locking http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e6db4c5a Help: Add notes for topic 'file-LOCK-command' http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=93017828 -Brad From brad.king at kitware.com Wed Dec 3 10:12:07 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 03 Dec 2014 10:12:07 -0500 Subject: [cmake-developers] [PATCH] VS, WINCE: Fix entry point for Unicode builds In-Reply-To: <547DCDEF.2050009@kitware.com> References: <1417523622-26389-1-git-send-email-pascal.bach@siemens.com> <547DCDEF.2050009@kitware.com> Message-ID: <547F2847.9060703@kitware.com> On 12/02/2014 09:34 AM, Brad King wrote: > VS, WINCE: Fix entry point for Unicode builds > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a4962595 Fixed typo in commit message: VS, WINCE: Fix entry point for Unicode builds http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=681cda02 -Brad From brad.king at kitware.com Wed Dec 3 10:12:36 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 03 Dec 2014 10:12:36 -0500 Subject: [cmake-developers] Patch pull request: support for shader entry point and shader model for Visual Studio FXCompiler custom tool build In-Reply-To: <547DDA4E.4040002@kitware.com> References: <547C83C8.4060406@kitware.com> <547DDA4E.4040002@kitware.com> Message-ID: <547F2864.2010606@kitware.com> On 12/02/2014 10:27 AM, Brad King wrote: > VS: Add source file properties to set the hlsl shader entry point and model > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5ab06dcd I updated the patch to sort the cmake-properties manual list in order: VS: Add source file properties to set the hlsl shader entry point and model http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2a224b4c I've queued this for inclusion in the next 3.1 release candidate because otherwise the new hlsl feature it not very useful. Thanks, -Brad From brad.king at kitware.com Wed Dec 3 10:15:25 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 03 Dec 2014 10:15:25 -0500 Subject: [cmake-developers] Patch to allow content file location to be specified In-Reply-To: References: Message-ID: <547F290D.5080708@kitware.com> On 12/02/2014 04:41 PM, Gilles Khouzam wrote: > I'd like a patch to allow the location of content files to be specified. Applied and merged for testing, thanks: VS: Add source file property to specify Windows App deployment location http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=352f246f I've queued this for inclusion in the next 3.1 release candidate because otherwise the new VS_DEPLOYMENT_CONTENT feature is not very useful. -Brad From brad.king at kitware.com Wed Dec 3 10:17:30 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 03 Dec 2014 10:17:30 -0500 Subject: [cmake-developers] [DISCUSSION] Using COMPONENTs for CMake install(...)? In-Reply-To: <50071417557052@web29o.yandex.ru> References: <50071417557052@web29o.yandex.ru> Message-ID: <547F298A.8020002@kitware.com> On 12/02/2014 04:50 PM, Konstantin Podsvirov wrote: > The command install(...) allows you to specify the COMPONENT. > Why this feature is not used by CMake? It simply never came up before. There is no reason not to define components for CMake's installation. What set of components do you propose? -Brad From dpolyanitsa at nvidia.com Wed Dec 3 10:46:17 2014 From: dpolyanitsa at nvidia.com (Dmitry Polyanitsa) Date: Wed, 3 Dec 2014 15:46:17 +0000 Subject: [cmake-developers] CMake 3.1 Android - generator expressions and output names In-Reply-To: References: <547E24E7.8040109@kitware.com> Message-ID: Hi Robert, I'm Dmitry from the Nsight Tegra team. Currently, we do not allow changing the APK name, so copying/moving the outputs is the best you can do. As for the language standard override, latest Nsight Tegra uses C++11 by default, why would you want to set it explicitly? -Dmitry -----Original Message----- From: Robert Goulet [mailto:Robert.Goulet at autodesk.com] Sent: Wednesday, December 3, 2014 12:28 AM To: Brad King Cc: cmake-developers at cmake.org Subject: RE: [cmake-developers] CMake 3.1 Android - generator expressions and output names I can't find any options to set the .apk name from the IDE, but I find it interesting that it uses the project's name instead of the output file name set in the IDE. Hence why I wonder if its CMake result or if its NVidia's Tegra toolkit? But I have a work-around for that, using add_custom_command to do a copy using ${CMAKE_COMMAND} -E copy. So my only issue left is the fact that I will have to use set_source_properties to pass the -std=c++11 flag instead of being able to set the "C++ Language Standard" option. That is a bit annoying, is there a better work-around? Thanks! -----Original Message----- From: Brad King [mailto:brad.king at kitware.com] Sent: Tuesday, December 2, 2014 3:45 PM To: Robert Goulet Cc: cmake-developers at cmake.org Subject: Re: [cmake-developers] CMake 3.1 Android - generator expressions and output names Hi Robert, Thanks for trying out the Nsight Tegra generator support. It is brand new so we are just at the beginning of the maturation process. We would appreciate any help you can provide. On 12/02/2014 02:24 PM, Robert Goulet wrote: > Perhaps it would be nice to have a generator expression that refers to > the .apk file produced when compiling for Android? This may be possible, but first we should work out the output name and location settings as discussed next. > Also, it would make sense that the .apk output name respect the names > that we set using the target properties OUTPUT_NAME_. Right > now it uses the project's name for the .apk, while the .so does indeed > respect the output name set. Is it possible to configure the .apk name through the IDE? If so, CMake could be taught to add the corresponding setting to the .vcxproj file. If not, then Nsight Tegra itself would have to be modified by NVIDIA to support such a setting. Some output directory settings may be needed too. We have RUNTIME_OUTPUT_DIRECTORY, LIBRARY_OUTPUT_DIRECTORY, and ARCHIVE_OUTPUT_DIRECTORY already. I'm not sure if one of these should apply to the .apk, or if another setting would be needed. Also the availability of Nsight Tegra settings for this needs to be investigated. > C++ Language Standard to other values than Default? I don't think there is currently. The commit adding the original support was: VS: Teach vcxproj generation about the Tegra-Android platform http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ef0fd4f0 The commit message documents many of the limitations. Only the last bullet (ANDROID_GUI prop) and part of the second bullet (ANDROID_API prop) have been addressed so far. The lack of a flag table or other controls for the rest of the project settings is currently the main limitation. -Brad ----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ----------------------------------------------------------------------------------- From Robert.Goulet at autodesk.com Wed Dec 3 10:57:02 2014 From: Robert.Goulet at autodesk.com (Robert Goulet) Date: Wed, 3 Dec 2014 15:57:02 +0000 Subject: [cmake-developers] Bad handling of /STACK:reserve[, commit] linker flag Message-ID: Hello, When trying to pass the linker flag "/STACK:reserve[,commit]" via CMake to the Visual Studio linker, the optional argument 'commit' is not passed correctly. It just ends up on the same argument as the 'reserve' argument as if it was a single argument, which is an error for Visual Studio linker. Visual Studio linker requires us to pass the 'commit' argument like this: /STACK:"2048"",1024" In CMake script, I tried every combination possible to get this string passed correctly to Visual Studio, but it always end up being passed as: /STACK:"2048,1024" Someone reported the same issue some time ago in this thread: http://cmake.3232098.n2.nabble.com/CMake-2-8-12-2-Visual-Studio-10-generator-Bad-handling-of-STACK-reserve-commit-compilation-flag-td7587920.html Is there a work-around for this? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From Robert.Goulet at autodesk.com Wed Dec 3 11:02:42 2014 From: Robert.Goulet at autodesk.com (Robert Goulet) Date: Wed, 3 Dec 2014 16:02:42 +0000 Subject: [cmake-developers] CMake 3.1 Android - generator expressions and output names In-Reply-To: References: <547E24E7.8040109@kitware.com> Message-ID: We are currently using 3.0-r3, and I am guessing this version doesn't use C++11 by default. You are saying that the latest release should fix this, because it defaults to C++11? I am not sure what are the implications of upgrading our engine with this new version. Should we expect the transition to go smoothly? We have to decide on a final version for the release, what's your thoughts on this? Thanks! -----Original Message----- From: Dmitry Polyanitsa [mailto:dpolyanitsa at nvidia.com] Sent: Wednesday, December 3, 2014 10:46 AM To: Robert Goulet; Brad King Cc: cmake-developers at cmake.org Subject: RE: [cmake-developers] CMake 3.1 Android - generator expressions and output names Hi Robert, I'm Dmitry from the Nsight Tegra team. Currently, we do not allow changing the APK name, so copying/moving the outputs is the best you can do. As for the language standard override, latest Nsight Tegra uses C++11 by default, why would you want to set it explicitly? -Dmitry -----Original Message----- From: Robert Goulet [mailto:Robert.Goulet at autodesk.com] Sent: Wednesday, December 3, 2014 12:28 AM To: Brad King Cc: cmake-developers at cmake.org Subject: RE: [cmake-developers] CMake 3.1 Android - generator expressions and output names I can't find any options to set the .apk name from the IDE, but I find it interesting that it uses the project's name instead of the output file name set in the IDE. Hence why I wonder if its CMake result or if its NVidia's Tegra toolkit? But I have a work-around for that, using add_custom_command to do a copy using ${CMAKE_COMMAND} -E copy. So my only issue left is the fact that I will have to use set_source_properties to pass the -std=c++11 flag instead of being able to set the "C++ Language Standard" option. That is a bit annoying, is there a better work-around? Thanks! -----Original Message----- From: Brad King [mailto:brad.king at kitware.com] Sent: Tuesday, December 2, 2014 3:45 PM To: Robert Goulet Cc: cmake-developers at cmake.org Subject: Re: [cmake-developers] CMake 3.1 Android - generator expressions and output names Hi Robert, Thanks for trying out the Nsight Tegra generator support. It is brand new so we are just at the beginning of the maturation process. We would appreciate any help you can provide. On 12/02/2014 02:24 PM, Robert Goulet wrote: > Perhaps it would be nice to have a generator expression that refers to > the .apk file produced when compiling for Android? This may be possible, but first we should work out the output name and location settings as discussed next. > Also, it would make sense that the .apk output name respect the names > that we set using the target properties OUTPUT_NAME_. Right > now it uses the project's name for the .apk, while the .so does indeed > respect the output name set. Is it possible to configure the .apk name through the IDE? If so, CMake could be taught to add the corresponding setting to the .vcxproj file. If not, then Nsight Tegra itself would have to be modified by NVIDIA to support such a setting. Some output directory settings may be needed too. We have RUNTIME_OUTPUT_DIRECTORY, LIBRARY_OUTPUT_DIRECTORY, and ARCHIVE_OUTPUT_DIRECTORY already. I'm not sure if one of these should apply to the .apk, or if another setting would be needed. Also the availability of Nsight Tegra settings for this needs to be investigated. > C++ Language Standard to other values than Default? I don't think there is currently. The commit adding the original support was: VS: Teach vcxproj generation about the Tegra-Android platform http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ef0fd4f0 The commit message documents many of the limitations. Only the last bullet (ANDROID_GUI prop) and part of the second bullet (ANDROID_API prop) have been addressed so far. The lack of a flag table or other controls for the rest of the project settings is currently the main limitation. -Brad ----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ----------------------------------------------------------------------------------- From dpolyanitsa at nvidia.com Wed Dec 3 11:13:47 2014 From: dpolyanitsa at nvidia.com (Dmitry Polyanitsa) Date: Wed, 3 Dec 2014 16:13:47 +0000 Subject: [cmake-developers] CMake 3.1 Android - generator expressions and output names In-Reply-To: References: <547E24E7.8040109@kitware.com> Message-ID: We usually advise to upgrade to the latest version. The transition should be smooth, but you may want to install TADP 3.0r4 on one of the machines first to check all's good before updating it everywhere. In case of any issues or questions you can contact me directly via email. -Dmitry -----Original Message----- From: Robert Goulet [mailto:Robert.Goulet at autodesk.com] Sent: Wednesday, December 3, 2014 7:03 PM To: Dmitry Polyanitsa; Brad King Cc: cmake-developers at cmake.org Subject: RE: [cmake-developers] CMake 3.1 Android - generator expressions and output names We are currently using 3.0-r3, and I am guessing this version doesn't use C++11 by default. You are saying that the latest release should fix this, because it defaults to C++11? I am not sure what are the implications of upgrading our engine with this new version. Should we expect the transition to go smoothly? We have to decide on a final version for the release, what's your thoughts on this? Thanks! -----Original Message----- From: Dmitry Polyanitsa [mailto:dpolyanitsa at nvidia.com] Sent: Wednesday, December 3, 2014 10:46 AM To: Robert Goulet; Brad King Cc: cmake-developers at cmake.org Subject: RE: [cmake-developers] CMake 3.1 Android - generator expressions and output names Hi Robert, I'm Dmitry from the Nsight Tegra team. Currently, we do not allow changing the APK name, so copying/moving the outputs is the best you can do. As for the language standard override, latest Nsight Tegra uses C++11 by default, why would you want to set it explicitly? -Dmitry -----Original Message----- From: Robert Goulet [mailto:Robert.Goulet at autodesk.com] Sent: Wednesday, December 3, 2014 12:28 AM To: Brad King Cc: cmake-developers at cmake.org Subject: RE: [cmake-developers] CMake 3.1 Android - generator expressions and output names I can't find any options to set the .apk name from the IDE, but I find it interesting that it uses the project's name instead of the output file name set in the IDE. Hence why I wonder if its CMake result or if its NVidia's Tegra toolkit? But I have a work-around for that, using add_custom_command to do a copy using ${CMAKE_COMMAND} -E copy. So my only issue left is the fact that I will have to use set_source_properties to pass the -std=c++11 flag instead of being able to set the "C++ Language Standard" option. That is a bit annoying, is there a better work-around? Thanks! -----Original Message----- From: Brad King [mailto:brad.king at kitware.com] Sent: Tuesday, December 2, 2014 3:45 PM To: Robert Goulet Cc: cmake-developers at cmake.org Subject: Re: [cmake-developers] CMake 3.1 Android - generator expressions and output names Hi Robert, Thanks for trying out the Nsight Tegra generator support. It is brand new so we are just at the beginning of the maturation process. We would appreciate any help you can provide. On 12/02/2014 02:24 PM, Robert Goulet wrote: > Perhaps it would be nice to have a generator expression that refers to > the .apk file produced when compiling for Android? This may be possible, but first we should work out the output name and location settings as discussed next. > Also, it would make sense that the .apk output name respect the names > that we set using the target properties OUTPUT_NAME_. Right > now it uses the project's name for the .apk, while the .so does indeed > respect the output name set. Is it possible to configure the .apk name through the IDE? If so, CMake could be taught to add the corresponding setting to the .vcxproj file. If not, then Nsight Tegra itself would have to be modified by NVIDIA to support such a setting. Some output directory settings may be needed too. We have RUNTIME_OUTPUT_DIRECTORY, LIBRARY_OUTPUT_DIRECTORY, and ARCHIVE_OUTPUT_DIRECTORY already. I'm not sure if one of these should apply to the .apk, or if another setting would be needed. Also the availability of Nsight Tegra settings for this needs to be investigated. > C++ Language Standard to other values than Default? I don't think there is currently. The commit adding the original support was: VS: Teach vcxproj generation about the Tegra-Android platform http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ef0fd4f0 The commit message documents many of the limitations. Only the last bullet (ANDROID_GUI prop) and part of the second bullet (ANDROID_API prop) have been addressed so far. The lack of a flag table or other controls for the rest of the project settings is currently the main limitation. -Brad ----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ----------------------------------------------------------------------------------- From brad.king at kitware.com Wed Dec 3 11:43:46 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 03 Dec 2014 11:43:46 -0500 Subject: [cmake-developers] Bad handling of /STACK:reserve[, commit] linker flag In-Reply-To: References: Message-ID: <547F3DC2.3010708@kitware.com> On 12/03/2014 10:57 AM, Robert Goulet wrote: > trying to pass the linker flag "/STACK:reserve[,commit]" [snip] > Visual Studio linker requires us to pass the 'commit' argument like this: > > /STACK:"2048"",1024" For the VS generators CMake needs to parse the arguments and transform them into the proper IDE project property settings. At the time this was designed almost all MS tool flags conformed to a simple pattern. It is parsed here: http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmIDEOptions.cxx;hb=v3.0.2#l33 and mapped through a lookup table to get the IDE setting. The entry for "/STACK:" is here: http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmVS10LinkFlagTable.h;hb=v3.0.2#l263 and maps to StackReserveSize. Note the comment about StackCommitSize not being supported currently. However, some flags do not conform to this pattern and need special hard-coded handling in the parser. The StoreUnknownFlag method does this: http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmVisualStudioGeneratorOptions.cxx;hb=v3.0.2#l176 Someone will have to remove /STACK: from the standard flag tables and add explicit handling to StoreUnknownFlag to split the value into the separate StackReserveSize and StackCommitSize properties. -Brad From brad.king at kitware.com Wed Dec 3 12:32:41 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 03 Dec 2014 12:32:41 -0500 Subject: [cmake-developers] Volunteering to maintain a new module: FindGSL.cmake In-Reply-To: <0458DF31F610EF42BFC78C497E806C7B3B53D2B1@ECS-EXG-P-MB03.win.lanl.gov> References: <0458DF31F610EF42BFC78C497E806C7B3B53D0EA@ECS-EXG-P-MB03.win.lanl.gov>, <547E06E8.1050400@kitware.com> <0458DF31F610EF42BFC78C497E806C7B3B53D2B1@ECS-EXG-P-MB03.win.lanl.gov> Message-ID: <547F4939.30107@kitware.com> On 12/02/2014 07:52 PM, Thompson, KT wrote: > 1. The command "add_library(GSL::gsl UNKOWN IMPORTED)" generates > warnings on platforms that do not support shared libraries. That is a bug in the warning. Fixed: add_library: Fix target type check for non-shared-lib platforms http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bd360ee3 The check can be dropped from the version of FindGSL that goes in CMake. > revised FindGSL.cmake continues to use GSL_ROOT_DIR. That is fine. The discussion Eike and I had was heading toward using them. > The decision to eliminate XXX_ROOT_DIR type variables from all It was not so much a decision to eliminate as an historical tendency to not add them in the first place. Some modules already have them anyway though. > # === Imported Targets === Please try installing sphinx and enabling the SPHINX_HTML build option of CMake. Then look at the Utilities/Sphinx/html documentation generated for this module. Update the reST syntax accordingly. > # GSL_ROOT_DIR - The top level directory of the discovered GSL > # install (useful if GSL is not in a standard location) My comment was not about removing GSL_ROOT_DIR altogether, but about not documenting it as a guaranteed result variable that applications can use. Instead it should be treated as an input/hint variable that may not be set but will be used if it is set. It's just a matter of which section documents it. > file( STRINGS "${GSL_INCLUDE_DIRS}/gsl/gsl_version.h" gsl_version_h_contents ) You could use the REGEX option to file(STRINGS) to shorten the amount of data loaded. > if( ${entry} MATCHES "define GSL_VERSION") > string( REGEX REPLACE ".*([0-9].[0-9][0-9]).*" "\\1" GSL_VERSION ${entry} ) > endif() With the proper expression in the if(MATCHES) test you can get the results from CMAKE_MATCH_1, CMAKE_MATCH_2, etc. variables without a separate string(REGEX) command. > REQUIRED_VARS > GSL_INCLUDE_DIRS > GSL_LIBRARIES The singular names (find_* command results) should be listed here because the error messages generated when they are not set are intended to ask the user to set the values in the cache. The plural names are not what the user would set. > GSL_ROOT_DIR The GSL_ROOT_DIR should not be required as mentioned above. Thanks, -Brad From cedric.perthuis at gmail.com Wed Dec 3 14:08:29 2014 From: cedric.perthuis at gmail.com (Cedric Perthuis) Date: Wed, 3 Dec 2014 11:08:29 -0800 Subject: [cmake-developers] Patch pull request: support for shader entry point and shader model for Visual Studio FXCompiler custom tool build In-Reply-To: <547F2864.2010606@kitware.com> References: <547C83C8.4060406@kitware.com> <547DDA4E.4040002@kitware.com> <547F2864.2010606@kitware.com> Message-ID: That sounds great, thanks Brad! On Wed, Dec 3, 2014 at 7:12 AM, Brad King wrote: > On 12/02/2014 10:27 AM, Brad King wrote: > > VS: Add source file properties to set the hlsl shader entry point and > model > > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5ab06dcd > > I updated the patch to sort the cmake-properties manual list in order: > > VS: Add source file properties to set the hlsl shader entry point and > model > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2a224b4c > > I've queued this for inclusion in the next 3.1 release candidate because > otherwise the new hlsl feature it not very useful. > > Thanks, > -Brad > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cedric.perthuis at gmail.com Wed Dec 3 14:10:19 2014 From: cedric.perthuis at gmail.com (Cedric Perthuis) Date: Wed, 3 Dec 2014 11:10:19 -0800 Subject: [cmake-developers] Patch pull request: support for shader entry point and shader model for Visual Studio FXCompiler custom tool build In-Reply-To: References: <547C83C8.4060406@kitware.com> <547DDA4E.4040002@kitware.com> <547F2864.2010606@kitware.com> Message-ID: Minor feedback, this comment should say "which shader model to use" instead of "which entry point to use" + // Figure out which entry point to use if any + if (const char* sm = sf->GetProperty("VS_SHADER_MODEL")) On Wed, Dec 3, 2014 at 11:08 AM, Cedric Perthuis wrote: > That sounds great, thanks Brad! > > On Wed, Dec 3, 2014 at 7:12 AM, Brad King wrote: > >> On 12/02/2014 10:27 AM, Brad King wrote: >> > VS: Add source file properties to set the hlsl shader entry point and >> model >> > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5ab06dcd >> >> I updated the patch to sort the cmake-properties manual list in order: >> >> VS: Add source file properties to set the hlsl shader entry point and >> model >> http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2a224b4c >> >> I've queued this for inclusion in the next 3.1 release candidate because >> otherwise the new hlsl feature it not very useful. >> >> Thanks, >> -Brad >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Wed Dec 3 14:14:16 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 03 Dec 2014 14:14:16 -0500 Subject: [cmake-developers] Patch pull request: support for shader entry point and shader model for Visual Studio FXCompiler custom tool build In-Reply-To: References: <547C83C8.4060406@kitware.com> <547DDA4E.4040002@kitware.com> <547F2864.2010606@kitware.com> Message-ID: <547F6108.3050207@kitware.com> On 12/03/2014 02:10 PM, Cedric Perthuis wrote: > Minor feedback, this comment should say "which shader model to use" instead of "which entry point to use" > > + // Figure out which entry point to use if any > + if (const char* sm = sf->GetProperty("VS_SHADER_MODEL")) Fixed: VS: Fix typo in VS_SHADER_MODEL lookup comment http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=955fbf29 Thanks, -Brad From neundorf at kde.org Wed Dec 3 15:20:43 2014 From: neundorf at kde.org (Alexander Neundorf) Date: Wed, 03 Dec 2014 21:20:43 +0100 Subject: [cmake-developers] [DISCUSSION] Using COMPONENTs for CMake install(...)? In-Reply-To: <50071417557052@web29o.yandex.ru> References: <50071417557052@web29o.yandex.ru> Message-ID: <7090987.jKSlXuqmNJ@tuxedo.neundorf.net> On Wednesday, December 03, 2014 00:50:52 Konstantin Podsvirov wrote: > CMake is being developed for a long time, but does not use COMPONENTs during > installation. Why? > > The command install(...) allows you to specify the COMPONENT. Why this > feature is not used by CMake? > > Is it possible to split the install CMake on COMPONENTs? Further it can be > used when creating redistributable packages. you can use them when calling the cmake_install.cmake manually, instead of calling "make install": cmake -DCOMPONENT="MyComponent" -P cmake_install.cmake I think at least some of the package generators support the components too. Alex From daniele.domenichelli at gmail.com Wed Dec 3 15:35:57 2014 From: daniele.domenichelli at gmail.com (Daniele E. Domenichelli) Date: Wed, 03 Dec 2014 21:35:57 +0100 Subject: [cmake-developers] [Review request] Topic ExternalProject_TEST_EXCLUDE_FROM_MAIN In-Reply-To: <547C90B3.1080607@gmail.com> References: <547B8E58.6070604@gmail.com> <547C8354.8030904@kitware.com> <547C90B3.1080607@gmail.com> Message-ID: <547F742D.5080802@gmail.com> [off-list] Hello Brad, On 01/12/14 17:00, Daniele E. Domenichelli wrote: > On 01/12/14 16:03, Brad King wrote: >> LGTM. Please also add a >> >> Help/release/dev/ExternalProject_TEST_EXCLUDE_FROM_MAIN.rst >> >> file with a release note advertising the feature. > > Done... squashed everything in one commit: > > * ExternalProject: Add TEST_EXCLUDE_FROM_MAIN option > http://www.cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=695b0d3 Is it ok if I merge it to next? Cheers, Daniele From brad.king at kitware.com Wed Dec 3 15:36:18 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 03 Dec 2014 15:36:18 -0500 Subject: [cmake-developers] [DISCUSSION] Using COMPONENTs for CMake install(...)? In-Reply-To: <7090987.jKSlXuqmNJ@tuxedo.neundorf.net> References: <50071417557052@web29o.yandex.ru> <7090987.jKSlXuqmNJ@tuxedo.neundorf.net> Message-ID: <547F7442.4080201@kitware.com> On 12/03/2014 03:20 PM, Alexander Neundorf wrote: > you can use them when calling the cmake_install.cmake manually, instead of > calling "make install": cmake -DCOMPONENT="MyComponent" -P cmake_install.cmake > > I think at least some of the package generators support the components too. I don't think the question is about how to use install components in general, but instead about teaching CMake's own source tree to use them. See my sibling response. -Brad From brad.king at kitware.com Wed Dec 3 15:38:41 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 03 Dec 2014 15:38:41 -0500 Subject: [cmake-developers] [Review request] Topic ExternalProject_TEST_EXCLUDE_FROM_MAIN In-Reply-To: <547F742D.5080802@gmail.com> References: <547B8E58.6070604@gmail.com> <547C8354.8030904@kitware.com> <547C90B3.1080607@gmail.com> <547F742D.5080802@gmail.com> Message-ID: <547F74D1.1070408@kitware.com> On 12/03/2014 03:35 PM, Daniele E. Domenichelli wrote: >> Done... squashed everything in one commit: >> >> * ExternalProject: Add TEST_EXCLUDE_FROM_MAIN option >> http://www.cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=695b0d3 > > Is it ok if I merge it to next? Yes. Sorry I neglected to say so explicitly in the first review. Thanks, -Brad From mantis at public.kitware.com Wed Dec 3 16:41:51 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 3 Dec 2014 16:41:51 -0500 Subject: [cmake-developers] [CMake 0015279]: CMake fails with OpenWatcom in default install location Message-ID: The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15279 ====================================================================== Reported By: Alex Lamaison Assigned To: ====================================================================== Project: CMake Issue ID: 15279 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-12-03 16:41 EST Last Modified: 2014-12-03 16:41 EST ====================================================================== Summary: CMake fails with OpenWatcom in default install location Description: A fix was committed for this issue but I don't think it works: http://www.cmake.org/Bug/view.php?id=12548 Recap: The OpenWatcom compiler fails to compile any configure checks if CMake is installed in the default location on Windows (C:\Program Files (x86)\CMake) because of the parentheses (or maybe the spaces). I'm still seeing the problem in CMake 3.1-rc2 on Windows 8 (64-bit). The problem goes away if I install CMake in a path without spaces/parentheses. Steps to Reproduce: Configure a project with Watcom Generator. Notice 'Detecting C compiler ABI info' fail. Additional Information: An example log from a failed run: Detecting C compiler ABI info failed to compile with the following output: Change Dir: C:/Users/Alexander/Projects/libssh2/bin/watcom/CMakeFiles/CMakeTmp Run Build Command:"wmake" "cmTryCompileExec3677462268\fast" Open Watcom Make Version 1.9 Portions Copyright (c) 1988-2002 Sybase, Inc. All Rights Reserved. Source code is available under the Sybase Open Watcom Public License. See http://www.openwatcom.org/ for details. C:\WATCOM\BINNT\wmake.exe -f CMakeFiles\cmTryCompileExec3677462268.dir\build.make -h CMakeFiles\cmTryCompileExec3677462268.dir\build C:\PROGRA~2\CMake\bin\cmake.exe -E cmake_progress_report C:\Users\Alexander\Projects\libssh2\bin\watcom\CMakeFiles\CMakeTmp\CMakeFiles 1 Building C object CMakeFiles/cmTryCompileExec3677462268.dir/CMakeCCompilerABI.c.obj C:\WATCOM\binnt\wcl386.exe -zq -bt=nt -w3 -dWIN32 -br -bm -d2 -d+ -foCMakeFiles\cmTryCompileExec3677462268.dir\CMakeCCompilerABI.c.obj -c -cc "C:\Program Files (x86)\CMake\share\cmake-3.1\Modules\CMakeCCompilerABI.c" Open Watcom C32 Optimizing Compiler Version 1.9 Portions Copyright (c) 1984-2002 Sybase, Inc. All Rights Reserved. Source code is available under the Sybase Open Watcom Public License. See http://www.openwatcom.org/ for details. Error! E1139: Command line contains more than one file to compile Error! E1139: Command line contains more than one file to compile Error! Unable to open '(x86)\CMake\share\cmake-3.1\Modules\CMakeCCompilerABI.c' Error: Compiler returned a bad status compiling "C:\Program Files (x86)\CMake\share\cmake-3.1\Modules\CMakeCCompilerABI.c" Error(E42): Last command making (CMakeFiles\cmTryCompileExec3677462268.dir\CMakeCCompilerABI.c.obj) returned a bad status Error(E02): Make execution terminated Error(E42): Last command making (cmTryCompileExec3677462268\fast) returned a bad status Error(E02): Make execution terminated ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-12-03 16:41 Alex Lamaison New Issue ====================================================================== From mantis at public.kitware.com Wed Dec 3 18:46:38 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 4 Dec 2014 00:46:38 +0100 Subject: [cmake-developers] [CMake 0015280]: FindZLIB module should find debug and release variants Message-ID: <7b4e30532711ba880f4b754a6a55a694@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15280 ====================================================================== Reported By: Stephen Kelly Assigned To: ====================================================================== Project: CMake Issue ID: 15280 Category: (No Category) Reproducibility: have not tried Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-12-04 00:46 CET Last Modified: 2014-12-04 00:46 CET ====================================================================== Summary: FindZLIB module should find debug and release variants Description: The IMPORTED target could be populated with both, creating a uniform interface and use-story. http://stackoverflow.com/questions/27274085/cmake-different-library-for-release-and-debug-zlib-libpng ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-12-04 00:46 Stephen Kelly New Issue ====================================================================== From steveire at gmail.com Wed Dec 3 19:05:30 2014 From: steveire at gmail.com (Stephen Kelly) Date: Thu, 04 Dec 2014 01:05:30 +0100 Subject: [cmake-developers] Volunteering to maintain a new module: FindGSL.cmake References: <0458DF31F610EF42BFC78C497E806C7B3B53D0EA@ECS-EXG-P-MB03.win.lanl.gov> <547E06E8.1050400@kitware.com> <0458DF31F610EF42BFC78C497E806C7B3B53D2B1@ECS-EXG-P-MB03.win.lanl.gov> Message-ID: Thompson, KT wrote: > # GSL_INCLUDE_DIRS - Location of GSL header files. > # GSL_LIBRARIES - The GSL libraries. I'm curious: Given that you provide IMPORTED targets, what would a user need these variables for? Do you have a particular use-case that needs them? > # Windows with dlls, but only Release libraries. > # If we have both Debug and Release libraries You should populate the IMPORTED_CONFIGURATIONS target property to record configurations which have a corresponding location. See the files shipped with Qt5 or the files generated by CMake itself when exporting targets for example. Is it possible/reasonable to determine if a particular GSL package has a dependency? On ATLAS, for example. Thanks, Steve. From mantis at public.kitware.com Wed Dec 3 19:09:16 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 4 Dec 2014 01:09:16 +0100 Subject: [cmake-developers] [CMake 0015283]: StringToInt helper should use errno and should use long in its API Message-ID: <37235094383f7ced312c903edd351b56@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15283 ====================================================================== Reported By: Stephen Kelly Assigned To: ====================================================================== Project: CMake Issue ID: 15283 Category: (No Category) Reproducibility: have not tried Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-12-04 01:09 CET Last Modified: 2014-12-04 01:09 CET ====================================================================== Summary: StringToInt helper should use errno and should use long in its API Description: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/11219/focus=11772 This will allow using it in other contexts. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-12-04 01:09 Stephen Kelly New Issue ====================================================================== From konstantin at podsvirov.pro Thu Dec 4 00:59:50 2014 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Thu, 04 Dec 2014 08:59:50 +0300 Subject: [cmake-developers] [DISCUSSION] Using COMPONENTs for CMake install(...)? In-Reply-To: <547F298A.8020002@kitware.com> References: <50071417557052@web29o.yandex.ru> <547F298A.8020002@kitware.com> Message-ID: <2931041417672790@web24g.yandex.ru> Hi, Brad! You always understand me right :-) 03.12.2014, 18:48, "Brad King" : > On 12/02/2014 04:50 PM, Konstantin Podsvirov wrote: >> The command install(...) allows you to specify the COMPONENT. >> Why this feature is not used by CMake? > > It simply never came up before. There is no reason not to > define components for CMake''s installation. What set of > components do you propose? > > -Brad I wondered at the expense of use of the components. I thought that there might be problems with some CPack generators. Well, that is no problem. The idea of splitting into components appeared when creating a graphical installer for CMake. Although CMake now does not use IFW generator for distribution, I'm working on improving it. 03.12.2014, 23:36, "Brad King" : > On 12/03/2014 03:20 PM, Alexander Neundorf wrote: >> you can use them when calling the cmake_install.cmake manually, instead of >> calling "make install": cmake-DCOMPONENT="MyComponent" -P cmake_install.cmake >> >> I think at least some of the package generators support the components too. > > I don't think the question is about how to use install components > in general, but instead about teaching CMake''s own source tree to > use them. See my response sibling. Yes! In the source tree, you can see some of the components. For example: -- tools - cmake - cpack - ctest -- scripts - modules - templates -- documentation - manual * html version * man pages -- according to - Qt (only necessary) In the graphical installer, the user will be able to see the components of which consists CMake set. The user will not be able to install an optional component, if it is not needed (such as manual). Also I suggest to add in CMakeLists.txt option to control the installation of dependencies with CMake. For example the Qt library. This happens on Windows and Mac, but I think it is not always necessary in Linux. Regards, Konstantin Podsvirov From d3ck0r at gmail.com Thu Dec 4 03:52:41 2014 From: d3ck0r at gmail.com (J Decker) Date: Thu, 4 Dec 2014 00:52:41 -0800 Subject: [cmake-developers] [CMake 0015279]: CMake fails with OpenWatcom in default install location In-Reply-To: References: Message-ID: found this old bug related to the same thing... https://www.cmake.org/Bug/view.php?id=12548#c27706 ... and the fix? http://www.cmake.org/gitweb?p=cmake.git;a=commitdiff;h=23381d83 On Wed, Dec 3, 2014 at 1:41 PM, Mantis Bug Tracker < mantis at public.kitware.com> wrote: > > The following issue has been SUBMITTED. > ====================================================================== > http://www.cmake.org/Bug/view.php?id=15279 > ====================================================================== > Reported By: Alex Lamaison > Assigned To: > ====================================================================== > Project: CMake > Issue ID: 15279 > Category: CMake > Reproducibility: always > Severity: minor > Priority: normal > Status: new > ====================================================================== > Date Submitted: 2014-12-03 16:41 EST > Last Modified: 2014-12-03 16:41 EST > ====================================================================== > Summary: CMake fails with OpenWatcom in default install > location > Description: > A fix was committed for this issue but I don't think it works: > http://www.cmake.org/Bug/view.php?id=12548 > > Recap: The OpenWatcom compiler fails to compile any configure checks if > CMake is > installed in the default location on Windows (C:\Program Files (x86)\CMake) > because of the parentheses (or maybe the spaces). > > I'm still seeing the problem in CMake 3.1-rc2 on Windows 8 (64-bit). The > problem goes away if I install CMake in a path without spaces/parentheses. > > Steps to Reproduce: > Configure a project with Watcom Generator. > > Notice 'Detecting C compiler ABI info' fail. > > > Additional Information: > An example log from a failed run: > > Detecting C compiler ABI info failed to compile with the following output: > Change Dir: > C:/Users/Alexander/Projects/libssh2/bin/watcom/CMakeFiles/CMakeTmp > > Run Build Command:"wmake" "cmTryCompileExec3677462268\fast" > Open Watcom Make Version 1.9 > > Portions Copyright (c) 1988-2002 Sybase, Inc. All Rights Reserved. > > Source code is available under the Sybase Open Watcom Public License. > > See http://www.openwatcom.org/ for details. > > C:\WATCOM\BINNT\wmake.exe -f > CMakeFiles\cmTryCompileExec3677462268.dir\build.make -h > CMakeFiles\cmTryCompileExec3677462268.dir\build > > C:\PROGRA~2\CMake\bin\cmake.exe -E cmake_progress_report > C:\Users\Alexander\Projects\libssh2\bin\watcom\CMakeFiles\CMakeTmp\CMakeFiles > 1 > > Building C object > CMakeFiles/cmTryCompileExec3677462268.dir/CMakeCCompilerABI.c.obj > > C:\WATCOM\binnt\wcl386.exe -zq -bt=nt -w3 -dWIN32 -br -bm -d2 -d+ > -foCMakeFiles\cmTryCompileExec3677462268.dir\CMakeCCompilerABI.c.obj -c -cc > "C:\Program Files (x86)\CMake\share\cmake-3.1\Modules\CMakeCCompilerABI.c" > > Open Watcom C32 Optimizing Compiler Version 1.9 > > Portions Copyright (c) 1984-2002 Sybase, Inc. All Rights Reserved. > > Source code is available under the Sybase Open Watcom Public License. > > See http://www.openwatcom.org/ for details. > > Error! E1139: Command line contains more than one file to compile > > Error! E1139: Command line contains more than one file to compile > > Error! Unable to open > '(x86)\CMake\share\cmake-3.1\Modules\CMakeCCompilerABI.c' > > Error: Compiler returned a bad status compiling "C:\Program Files > (x86)\CMake\share\cmake-3.1\Modules\CMakeCCompilerABI.c" > > Error(E42): Last command making > (CMakeFiles\cmTryCompileExec3677462268.dir\CMakeCCompilerABI.c.obj) > returned a > bad status > > Error(E02): Make execution terminated > > Error(E42): Last command making (cmTryCompileExec3677462268\fast) returned > a bad > status > > Error(E02): Make execution terminated > > ====================================================================== > > Issue History > Date Modified Username Field Change > ====================================================================== > 2014-12-03 16:41 Alex Lamaison New Issue > ====================================================================== > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake-developers > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alinm.elena at gmail.com Thu Dec 4 05:16:15 2014 From: alinm.elena at gmail.com (Alin Marin Elena) Date: Thu, 4 Dec 2014 10:16:15 +0000 Subject: [cmake-developers] FindMPI and Intel MPI Message-ID: Hi, I try to use findMPI with the new intel mpi 5.0.2 and their compilers. Unfortunately it seems to fail to correctly find the include paths. what I see at the moment [10:07:03 alin at abaddon:~/playground/findmpi/a]: FC=mpiifort cmake ../ -- The Fortran compiler identification is Intel -- Check for working Fortran compiler: /opt/intel/impi_5.0.2/intel64/bin/mpiifort -- Check for working Fortran compiler: /opt/intel/impi_5.0.2/intel64/bin/mpiifort -- works -- Detecting Fortran compiler ABI info -- Detecting Fortran compiler ABI info - done -- Checking whether /opt/intel/impi_5.0.2/intel64/bin/mpiifort supports Fortran 90 -- Checking whether /opt/intel/impi_5.0.2/intel64/bin/mpiifort supports Fortran 90 -- yes -- Found MPI_Fortran: /opt/intel/impi_5.0.2/intel64/lib/libmpifort.so;/opt/intel/impi_5.0.2/intel64/lib/release_mt/libmpi.so;/opt/intel/im pi_5.0.2/intel64/lib/libmpigi.a;/usr/lib64/libdl.so;/usr/lib64/librt.so;/usr/lib64/libpthread.so -- MPI_Fortran_INCLUDE_PATH /opt/intel/impi_5.0.2/intel64/include/gfortran/4.8.0;/opt/intel/impi_5.0.2/intel64/include -- MPI_Fortran_LINK_FLAGS -- MPI_Fortran_LIBRARIES /opt/intel/impi_5.0.2/intel64/lib/libmpifort.so;/opt/intel/impi_5.0.2/intel64/lib/release_mt/libmpi.so;/opt/intel /impi_5.0.2/intel64/lib/libmpigi.a;/usr/lib64/libdl.so;/usr/lib64/librt.so;/usr/lib64/libpthread.so the same if I use FC=ifort and let FindMPI do its job The direct issue is that the include path is wrongly set... practically gets the gfortran path (mpif90 -show) rather the correct intel one. of course any Use mpi will fail. To ensure this fails one may change the example. or if mod gets found an example with it shall be compiled. The second issue I have seen is more a design issue. In the first scenario I used directly the wrapper, I think FindMPI shall test it and if whatever is in FC produces a proper mpi binary shall go ahead. the logic in lines 570-621 I think shall be changed, any comments? I will try to work on it and propose a patch but I would wecome some feedback. regards, Alin Without Questions there are no Answers! ______________________________________________________________________ Dr. Alin Marin ELENA http://alin.elenaworld.net/ ______________________________________________________________________ From brad.king at kitware.com Thu Dec 4 08:48:03 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 04 Dec 2014 08:48:03 -0500 Subject: [cmake-developers] FindMPI and Intel MPI In-Reply-To: References: Message-ID: <54806613.9090109@kitware.com> On 12/04/2014 05:16 AM, Alin Marin Elena wrote: > I try to use findMPI with the new intel mpi 5.0.2 and their compilers. > Unfortunately it seems to fail to correctly find the include paths. There is also discussion of that here: FindMPI.cmake fails to properly detect Intel MPI 5.0.1 http://www.cmake.org/Bug/view.php?id=15182 I've posted a link to this thread in that issue. There is also a link to a proposed patch in another thread on this list. That may be a good starting point to pick up. IIRC the problem is that this Intel MPI compiler does not return non-zero even in some error cases. > The second issue I have seen is more a design issue. In the first > scenario I used directly the wrapper, I think FindMPI shall test it > and if whatever is in FC produces a proper mpi binary shall go ahead. > the logic in lines 570-621 I think shall be changed, any comments? If CMAKE__COMPILER is already the mpi compiler then of course it makes sense to use it instead of searching for another one. > I will try to work on it and propose a patch Great. If you work on it please address the Intel MPI problem first. Then the design improvement can be added as a separate change. Thanks, -Brad From brad.king at kitware.com Thu Dec 4 09:42:31 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 04 Dec 2014 09:42:31 -0500 Subject: [cmake-developers] [Review request] Topic ExternalProject_TEST_EXCLUDE_FROM_MAIN In-Reply-To: <547F74D1.1070408@kitware.com> References: <547B8E58.6070604@gmail.com> <547C8354.8030904@kitware.com> <547C90B3.1080607@gmail.com> <547F742D.5080802@gmail.com> <547F74D1.1070408@kitware.com> Message-ID: <548072D7.5040902@kitware.com> On 12/03/2014 03:38 PM, Brad King wrote: >> Is it ok if I merge it to next? > > Yes. This fails the ExternalProjectLocal test with: CMake Error at cmake_install.cmake:42 (file): file INSTALL cannot copy file ".../Tests/ExternalProjectLocal/CMakeExternals/Build/TutorialStep5-Local-TestExcludeFromMainAfter/Tutorial" to "/usr/local/bin/Tutorial". Please take a look. Thanks, -Brad From erik.sjolund at gmail.com Thu Dec 4 10:09:52 2014 From: erik.sjolund at gmail.com (=?UTF-8?Q?Erik_Sj=C3=B6lund?=) Date: Thu, 4 Dec 2014 16:09:52 +0100 Subject: [cmake-developers] suggestion: rename FindXerces to FindXercesC Message-ID: As there are two implementations of Xerces, one in C++ http://xerces.apache.org/xerces-c/ and one in Java http://xerces.apache.org/xerces-j/ I think it is a good idea to rename FindXerces to FindXercesC or something similar, just to indicate that is about the C++ implementation. cheers, Erik Sj?lund From brad.king at kitware.com Thu Dec 4 10:18:32 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 04 Dec 2014 10:18:32 -0500 Subject: [cmake-developers] [Review request] Topic ExternalProject_TEST_EXCLUDE_FROM_MAIN In-Reply-To: <548072D7.5040902@kitware.com> References: <547B8E58.6070604@gmail.com> <547C8354.8030904@kitware.com> <547C90B3.1080607@gmail.com> <547F742D.5080802@gmail.com> <547F74D1.1070408@kitware.com> <548072D7.5040902@kitware.com> Message-ID: <54807B48.50903@kitware.com> On 12/04/2014 09:42 AM, Brad King wrote: > This fails the ExternalProjectLocal test > > Please take a look. Actually there was also a problem with Utilities/Sphinx/cmake.py that was exposed by this change. I've fixed that: Utilities/Sphinx: Fix link targets for mixed-case command names http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=607b39dc Please rebase on 'master' to get it. Since a fix and rebase are both needed anyway, I reverted your topic for now. Please restore and merge to 'next' again when the test fix is ready. Thanks, -Brad From kgt at lanl.gov Thu Dec 4 10:28:27 2014 From: kgt at lanl.gov (Thompson, KT) Date: Thu, 4 Dec 2014 15:28:27 +0000 Subject: [cmake-developers] Volunteering to maintain a new module: FindGSL.cmake Message-ID: <0458DF31F610EF42BFC78C497E806C7B3B53D6B0@ECS-EXG-P-MB03.win.lanl.gov> Stephen Kelly wrote: >> # GSL_INCLUDE_DIRS - Location of GSL header files. >> # GSL_LIBRARIES - The GSL libraries. > I'm curious: Given that you provide IMPORTED targets, what would a user need > these variables for? Do you have a particular use-case that needs them? These are defined mostly as a courtesy for folks who don't use imported targets yet. Additionally, the CMake documentation for developers::Modules (http://www.cmake.org/cmake/help/v3.0/manual/cmake-developer.7.html#modules) mentions these as typical outputs from FindXXX.cmake modules. In my own projects, I use these to provide informational output during the configuration. I suppose I could query the imported targets for the same information. After thinking about this for a couple of minutes, I don't have a strong opinion on it. However, I will leave them in place (to make this module have similar behavior to other incorporated modules) unless I hear a strong consensus from this list to remove them. >> # Windows with dlls, but only Release libraries. >> # If we have both Debug and Release libraries > You should populate the IMPORTED_CONFIGURATIONS target property to record > configurations which have a corresponding location. See the files shipped > with Qt5 or the files generated by CMake itself when exporting targets for > example. I've added this target property for the "Windows with dlls" case. I will be responding to comments that Brad King made yesterday in my next email to the list. Can you review my updated implementation as presented in that email? > Is it possible/reasonable to determine if a particular GSL package has a > dependency? On ATLAS, for example. You can certainly build GSL against any BLAS implementation, but I've never seen that done in production. If a custom BLAS is used, the pkgconfig script will correctly report the alternate BLAS library (Unix/Linux platforms). For other types of installations, I'm not sure how to query for the BLAS using when compiling GSL (e.g. Windows). If the GSL is a shred library, I might be able to use system tools to inspect the rpath - but I'm not sure that level of complexity is required for this simple module. In this case, the user of FindGSL might need to manually specify GSL_CBLAS_LIBRARY before calling find_package. -kt -------------- next part -------------- An HTML attachment was scrubbed... URL: From kgt at lanl.gov Thu Dec 4 10:28:30 2014 From: kgt at lanl.gov (Thompson, KT) Date: Thu, 4 Dec 2014 15:28:30 +0000 Subject: [cmake-developers] Volunteering to maintain a new module: FindGSL.cmake Message-ID: <0458DF31F610EF42BFC78C497E806C7B3B53D6B8@ECS-EXG-P-MB03.win.lanl.gov> Brad, Here is a repeat and reformatted version of the email I sent off list (sorry about that). The attached file also addresses comments from Stephen Kelly concerning IMPORTED_CONFIGURATIONS. Brad King wrote: > > The command "add_library(GSL::gsl UNKOWN IMPORTED)" generates > > warnings on platforms that do not support shared libraries. > That is a bug in the warning. Fixed: > add_library: Fix target type check for non-shared-lib platforms > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bd360ee3 > The check can be dropped from the version of FindGSL that goes in > CMake. I rebased to the git HEAD to test your fix (bd360ee3 works for my systems) and removed the unnecessary code that checked if the system supported shared libraries. > Please try installing sphinx and enabling the SPHINX_HTML build > option of CMake. Then look at the Utilities/Sphinx/html > documentation generated for this module. Update the reST > syntax accordingly. I corrected the documentation formatting after building it with Sphinx. I will comment that I had a little trouble installing Sphinx since we do not have root access to our Linux machines. I can only install software that I can install at $HOME. (Can you point me to any instructions for installing Sphynx w/o root access?) However, I was able to get it working on a Windows machine and was able to clean up the documentation a bit. I also modified Help/manual/cmake-modules.7.rst and added Help/module/FindGSL.rst as required. > My comment was not about removing GSL_ROOT_DIR altogether, but > about not documenting it as a guaranteed result variable that > applications can use. Instead it should be treated as an > input/hint variable that may not be set but will be used if it > is set. It's just a matter of which section documents it. Comments about GSL_ROOT_DIR were moved to the HINTS section only. I also removed this variable from find_package_handle_standard_args's REQUIRED_VARS section. (I understand your comment now). > You could use the REGEX option to file(STRINGS) to shorten the > amount of data loaded. I simplified the search for GSL_VERSION as you suggested. Thanks for the pointer, this code was copied from some very old cmake scripts w/o much thought -- but your way is clearly better. > > REQUIRED_VARS > > GSL_INCLUDE_DIRS > > GSL_LIBRARIES > The singular names (find_* command results) should be listed > here because the error messages generated when they are not set > are intended to ask the user to set the values in the cache. > The plural names are not what the user would set. I have a better understanding of the REQUIRED_VARS section of find_package_handle_standard_args now and have made the updates that you recommended. A new versions of FindGSL is attached. The other modified files are very simple and I will not bother you with those changes. -kt -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: FindGSL.cmake Type: application/octet-stream Size: 9878 bytes Desc: FindGSL.cmake URL: From brad.king at kitware.com Thu Dec 4 10:32:53 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 04 Dec 2014 10:32:53 -0500 Subject: [cmake-developers] suggestion: rename FindXerces to FindXercesC In-Reply-To: References: Message-ID: <54807EA5.2060600@kitware.com> On 12/04/2014 10:09 AM, Erik Sj?lund wrote: > I think it is a good idea to rename FindXerces to FindXercesC or > something similar, just to indicate that is about the C++ > implementation. Thanks for pointing out the distinct implementations. The module is new in CMake 3.1 so our last chance to rename it now before the final release of that version. Actually it looks like we're missing a release note for it too. The documentation of the module starts off with: "Find the Apache Xerces-C++ validating XML parser..." which is pretty clear, though that is not visible at the call sites of find_package(Xerces). Roger, as the contributor of this module do you have any reason not to change the name? Thanks, -Brad From kgt at lanl.gov Thu Dec 4 10:38:50 2014 From: kgt at lanl.gov (Thompson, KT) Date: Thu, 4 Dec 2014 15:38:50 +0000 Subject: [cmake-developers] Volunteering to maintain a new module: FindGSL.cmake Message-ID: <0458DF31F610EF42BFC78C497E806C7B3B53D706@ECS-EXG-P-MB03.win.lanl.gov> It looks like the mailing list doesn't like attachments (is that correct?). Here's my updated FindGSL.cmake: -kt #.rst: # FindGSL # -------- # # Find the native GSL includes and libraries. # # The GNU Scientific Library (GSL) is a numerical library for C and C++ # programmers. It is free software under the GNU General Public License. # # Imported Targets # ^^^^^^^^^^^^^^^^ # # If GSL is found, this module defines the following :prop_tgt:`IMPORTED` targets # # :: # # GSL::gsl - The main GSL library. # GSL::gslcblas - The CBLAS support library used by GSL. # # Result Variables # ^^^^^^^^^^^^^^^^ # # This module will set the following variables per language in your project: # # :: # # GSL_FOUND - True if GSL found on the local system # GSL_INCLUDE_DIRS - Location of GSL header files. # GSL_LIBRARIES - The GSL libraries. # GSL_VERSION - The version of the discovered GSL install. # # Hints # ^^^^^ # # Set ``GSL_ROOT_DIR`` to a directory that contains a GSL installation. # # This script expects to find libraries at $GSL_ROOT_DIR/lib and the GSL headers # at $GSL_ROOT_DIR/include/gsl. The library directory may optionally provide # Release and Debug folders. For Unix-like systems, this script will use # $GSL_ROOT_DIR/bin/gsl-config (if found) to aid in the discovery GSL. # # Usage # ^^^^^ # # To use this module, simply call FindGSL from a CMakeLists.txt file, or run # find_package(GSL), then run CMake. If you are happy with the auto-detected # configuration for your language, then you're done. If not, you have the # option of manually specifying the ``GSL_ROOT_DIR``. # # This module may set the following variables depending on platform and type # of GSL installation discovered. These variables may optionally be set to # help this module find the correct files. # # :: # # GSL_CLBAS_LIBRARY - Location of the GSL CBLAS library. # GSL_CBLAS_LIBRARY_DEBUG - Location of the debug GSL CBLAS library (if any). # GSL_CONFIG - Location of the ``gsl-config`` script (if any). # GSL_LIBRARY - Location of the GSL library. # GSL_LIBRARY_DEBUG - Location of the debug GSL library (if any). # #============================================================================= # Copyright 2014 Kelly Thompson kgt at lanl.gov # # Distributed under the OSI-approved BSD License (the "License"); # see accompanying file Copyright.txt for details. # # This software is distributed WITHOUT ANY WARRANTY; without even the implied # warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # License for more information. # ============================================================================= # Include these modules to handle the QUIETLY and REQUIRED arguments. See # http://www.cmake.org/cmake/help/v3.0/module/FindPackageHandleStandardArgs.html include(${CMAKE_CURRENT_LIST_DIR}/FindPackageHandleStandardArgs.cmake) #============================================================================= # If the user has provided ``GSL_ROOT_DIR``, use it! Choose items found # at this location over system locations. if( EXISTS "$ENV{GSL_ROOT_DIR}" ) file( TO_CMAKE_PATH "$ENV{GSL_ROOT_DIR}" GSL_ROOT_DIR ) set( GSL_ROOT_DIR "${GSL_ROOT_DIR}" CACHE PATH "Prefix for GSL installation." ) endif() if( NOT EXISTS "${GSL_ROOT_DIR}" ) set( GSL_USE_PKGCONFIG ON ) endif() #============================================================================= # As a first try, use the PkgConfig module. This will work on many # *NIX systems. See :module:`findpkgconfig` # This will return ``GSL_INCLUDEDIR`` and ``GSL_LIBDIR`` used below. if( GSL_USE_PKGCONFIG ) find_package(PkgConfig) pkg_check_modules( GSL QUIET gsl ) if( EXISTS "${GSL_INCLUDEDIR}" ) get_filename_component( GSL_ROOT_DIR "${GSL_INCLUDEDIR}" DIRECTORY CACHE) endif() endif() #============================================================================= # Set GSL_INCLUDE_DIRS and GSL_LIBRARIES. If we skipped the PkgConfig step, try # to find the libraries at $GSL_ROOT_DIR (if provided) or in standard system # locations. These find_library and find_path calls will prefer custom # locations over standard locations (HINTS). If the requested file is not found # at the HINTS location, standard system locations will be still be searched # (/usr/lib64 (Redhat), lib/i386-linux-gnu (Debian)). find_path( GSL_INCLUDE_DIR NAMES gsl/gsl_sf.h HINTS ${GSL_ROOT_DIR}/include ${GSL_INCLUDEDIR} ) find_library( GSL_LIBRARY NAMES gsl HINTS ${GSL_ROOT_DIR}/lib ${GSL_LIBDIR} PATH_SUFFIXES Release Debug ) find_library( GSL_CBLAS_LIBRARY NAMES gslcblas cblas HINTS ${GSL_ROOT_DIR}/lib ${GSL_LIBDIR} PATH_SUFFIXES Release Debug ) # Do we also have debug versions? find_library( GSL_LIBRARY_DEBUG NAMES gsl HINTS ${GSL_ROOT_DIR}/lib ${GSL_LIBDIR} PATH_SUFFIXES Debug ) find_library( GSL_CBLAS_LIBRARY_DEBUG NAMES gslcblas cblas HINTS ${GSL_ROOT_DIR}/lib ${GSL_LIBDIR} PATH_SUFFIXES Debug ) set( GSL_INCLUDE_DIRS ${GSL_INCLUDE_DIR} CACHE PATH "Location of GSL include directives." ) set( GSL_LIBRARIES ${GSL_LIBRARY};${GSL_CBLAS_LIBRARY} CACHE PATH "GSL libraries." ) # If we didn't use PkgConfig, try to find the version via gsl-config or by # reading gsl_version.h. if( NOT GSL_VERSION ) # 1. If gsl-config exists, query for the version. find_program( GSL_CONFIG NAMES gsl-config HINTS "${GSL_ROOT_DIR}/bin" ) if( EXISTS "${GSL_CONFIG}" ) execute_process( COMMAND "${GSL_CONFIG}" --version OUTPUT_VARIABLE GSL_VERSION OUTPUT_STRIP_TRAILING_WHITESPACE ) endif() # 2. If gsl-config is not available, try looking in gsl/gsl_version.h if( NOT GSL_VERSION AND EXISTS "${GSL_INCLUDE_DIRS}/gsl/gsl_version.h" ) file( STRINGS "${GSL_INCLUDE_DIRS}/gsl/gsl_version.h" gsl_version_h_contents REGEX "define GSL_VERSION" ) string( REGEX REPLACE ".*([0-9].[0-9][0-9]).*" "\\1" GSL_VERSION ${gsl_version_h_contents} ) endif() # might also try scraping the directory name for a regex match "gsl-X.X" endif() #============================================================================= # handle the QUIETLY and REQUIRED arguments and set GSL_FOUND to TRUE if all # listed variables are TRUE find_package_handle_standard_args( GSL FOUND_VAR GSL_FOUND REQUIRED_VARS GSL_INCLUDE_DIR GSL_LIBRARY GSL_CBLAS_LIBRARY VERSION_VAR GSL_VERSION ) mark_as_advanced( GSL_LIBRARIES GSL_INCLUDE_DIRS GSL_ROOT_DIR GSL_VERSION GSL_LIBRARY GSL_CBLAS_LIBRARY GSL_LIBRARY_DEBUG GSL_CBLAS_LIBRARY_DEBUG GSL_USE_PKGCONFIG GSL_CONFIG ) #============================================================================= # Register imported libraries: # 1. If we can find a Windows .dll file (or if we can find both Debug and # Release libraries), we will set appropriate target properties for these. # 2. However, for most systems, we will only register the import location and # include directory. # Look for dlls, or Release and Debug libraries. if(WIN32) string( REPLACE ".lib" ".dll" GSL_LIBRARY_DLL "${GSL_LIBRARY}" ) string( REPLACE ".lib" ".dll" GSL_CBLAS_LIBRARY_DLL "${GSL_CBLAS_LIBRARY}" ) string( REPLACE ".lib" ".dll" GSL_LIBRARY_DEBUG_DLL "${GSL_LIBRARY_DEBUG}" ) string( REPLACE ".lib" ".dll" GSL_CBLAS_LIBRARY_DEBUG_DLL "${GSL_CBLAS_LIBRARY_DEBUG}" ) endif() if( GSL_FOUND ) if( EXISTS "${GSL_LIBRARY_DLL}" AND EXISTS "${GSL_CBLAS_LIBRARY_DLL}") # Windows systems with dll libraries. add_library( GSL::gsl SHARED IMPORTED ) add_library( GSL::gslcblas SHARED IMPORTED ) # Windows with dlls, but only Release libraries. set_target_properties( GSL::gslcblas PROPERTIES IMPORTED_LOCATION "${GSL_CBLAS_LIBRARY_DLL}" IMPORTED_IMPLIB "${GSL_CBLAS_LIBRARY}" INTERFACE_INCLUDE_DIRECTORIES "${GSL_INCLUDE_DIRS}" IMPORTED_CONFIGURATIONS Release IMPORTED_LINK_INTERFACE_LANGUAGES "C" ) set_target_properties( GSL::gsl PROPERTIES IMPORTED_LOCATION "${GSL_LIBRARY_DLL}" IMPORTED_IMPLIB "${GSL_LIBRARY}" INTERFACE_INCLUDE_DIRECTORIES "${GSL_INCLUDE_DIRS}" IMPORTED_CONFIGURATIONS Release IMPORTED_LINK_INTERFACE_LANGUAGES "C" INTERFACE_LINK_LIBRARIES GSL::gslcblas ) # If we have both Debug and Release libraries if( EXISTS "${GSL_LIBRARY_DEBUG_DLL}" AND EXISTS "${GSL_CBLAS_LIBRARY_DEBUG_DLL}") set_property( TARGET GSL:gslcblas APPEND PROPERTY IMPORTED_CONFIGURATIONS Debug ) set_target_properties( GSL::gslcblas PROPERTIES IMPORTED_LOCATION_DEBUG "${GSL_CBLAS_LIBRARY_DEBUG_DLL}" IMPORTED_IMPLIB_DEBUG "${GSL_CBLAS_LIBRARY_DEBUG}" ) set_property( TARGET GSL:gsl APPEND PROPERTY IMPORTED_CONFIGURATIONS Debug ) set_target_properties( GSL::gsl PROPERTIES IMPORTED_LOCATION_DEBUG "${GSL_LIBRARY_DEBUG_DLL}" IMPORTED_IMPLIB_DEBUG "${GSL_LIBRARY_DEBUG}" ) endif() else() # For all other environments (ones without dll libraries), create # the imported library targets. add_library( GSL::gsl UNKNOWN IMPORTED ) add_library( GSL::gslcblas UNKNOWN IMPORTED ) set_target_properties( GSL::gslcblas PROPERTIES IMPORTED_LOCATION "${GSL_CBLAS_LIBRARY}" INTERFACE_INCLUDE_DIRECTORIES "${GSL_INCLUDE_DIRS}" IMPORTED_LINK_INTERFACE_LANGUAGES "C" ) set_target_properties( GSL::gsl PROPERTIES IMPORTED_LOCATION "${GSL_LIBRARY}" INTERFACE_INCLUDE_DIRECTORIES "${GSL_INCLUDE_DIRS}" IMPORTED_LINK_INTERFACE_LANGUAGES "C" INTERFACE_LINK_LIBRARIES GSL::gslcblas ) endif() endif() #============================================================================= # References: # - http://www.cmake.org/cmake/help/git-master/manual/cmake-developer.7.html#modules -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Thu Dec 4 10:52:18 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 04 Dec 2014 10:52:18 -0500 Subject: [cmake-developers] suggestion: rename FindXerces to FindXercesC In-Reply-To: <54807EA5.2060600@kitware.com> References: <54807EA5.2060600@kitware.com> Message-ID: <54808332.2030404@kitware.com> On 12/04/2014 10:32 AM, Brad King wrote: > Roger, as the contributor of this module do you have any reason > not to change the name? I've constructed a commit to perform the rename and merged to 'next' for testing: Modules: Rename FindXerces to FindXercesC http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=27141eed Please let me know if it works. I'd like to get feedback before merging to 'master' or 'release'. Thanks, -Brad From Geoffrey.Viola at asirobots.com Thu Dec 4 11:24:14 2014 From: Geoffrey.Viola at asirobots.com (Geoffrey Viola) Date: Thu, 4 Dec 2014 16:24:14 +0000 Subject: [cmake-developers] Initial Attempt at Green Hill MULTI IDE Generator Support In-Reply-To: <5474E132.2010705@kitware.com> References: <0543633b28c7431f93808182fc1e26e1@CO1PR07MB208.namprd07.prod.outlook.com> <543D2BBC.1010306@kitware.com> <0b5b33c4d1f0472782e260f9e5bce980@CO1PR07MB208.namprd07.prod.outlook.com> <544E4C9F.3050408@kitware.com> <64abd7ba273245b686146aa67acb7e8a@DM2PR0701MB1020.namprd07.prod.outlook.com> <545A7C44.6040305@kitware.com> <5474E132.2010705@kitware.com> Message-ID: Thanks for the feedback. Sorry for the late response. I won't be able to make another patch for another 3 weeks. I would like to take care of some bugs first. There is a bug where GHS MULTI is not recompiling executables and libraries, when compiling a .elf file. Also, the generator will need to be able to set the output filename and use the output directory. It's good to hear that there are tests. I'm not sure how I missed them. Geoffrey Viola SOFTWARE ENGINEER T +1.435.755.2980 ext 1077 M +1.215.896.6521 asirobots.com -----Original Message----- From: Brad King [mailto:brad.king at kitware.com] Sent: Tuesday, November 25, 2014 1:06 PM To: Geoffrey Viola Cc: cmake-developers at cmake.org Subject: Re: [cmake-developers] Initial Attempt at Green Hill MULTI IDE Generator Support On 11/17/2014 05:16 PM, Geoffrey Viola wrote: > I made some changes and rebased on the trunk. Thanks. Here are a few minor comments: * The hunk in Modules/CMakeDetermineCompilerId.cmake is now just a whitespace change, so please drop it. * Please ensure C++ sources do not have lines exceeding 79 columns. * Please avoid trailing whitespace on source lines. Next we need to add tests. Since CMake won't build with this generator we need to add tests using the generator as part of the test suite when the needed tools are available. Look in Tests/CMakeLists.txt for uses of add_test_VSWinStorePhone as an example of how this is done for another target platform. You can either add a new test directory with dedicated code covering capabilities of the generator, or re-use some of the existing tests to see if they build under the new generator, or both. Once you get tests working, please look at submitting an experimental build to our dashboard and posting a link to it. You can do that from the build tree of CMake with ctest -C Debug -D Experimental (or with whatever configuration you built locally). Thanks, -Brad This message contains confidential information and is intended only for the recipient. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately if you have received this e-mail by mistake and delete this e-mail from your system. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. From steveire at gmail.com Thu Dec 4 14:29:25 2014 From: steveire at gmail.com (Stephen Kelly) Date: Thu, 04 Dec 2014 20:29:25 +0100 Subject: [cmake-developers] Volunteering to maintain a new module: FindGSL.cmake References: <0458DF31F610EF42BFC78C497E806C7B3B53D6B0@ECS-EXG-P-MB03.win.lanl.gov> Message-ID: Thompson, KT wrote: > Stephen Kelly wrote: > >>> # GSL_INCLUDE_DIRS - Location of GSL header files. >>> # GSL_LIBRARIES - The GSL libraries. > >> I'm curious: Given that you provide IMPORTED targets, what would a user >> need these variables for? Do you have a particular use-case that needs >> them? > > These are defined mostly as a courtesy for folks who don't use imported > targets yet. Additionally, the CMake documentation for > developers::Modules > (http://www.cmake.org/cmake/help/v3.0/manual/cmake-developer.7.html#modules) > mentions these as typical outputs from FindXXX.cmake modules. Yes. They are useful at least when a FindXXX does not provide IMPORTED targets. The presence of those variables though indicates to users that they have to add include_directories(${Xxx_INCLUDE_DIRS}) to their projects which * Is not necessary/Is redundant * Is noisy * Is directory scoped, rather than target scoped, as they get for free already with IMPORTED targets. There is a mind-set change needed to avoid lines like that. CMake does not have to be noisy anymore :). I don't see a hard need for new modules which provide IMPORTED targets need to provide such variables. As you write below, you only use them for informational purposes. > In my own > projects, I use these to provide informational output during the > configuration. I suppose I could query the imported targets for the same > information. If the informational output is general enough, maybe we can add a module to CMake to simplify getting this output for IMPORTED targets. > After thinking about this for a couple of minutes, I don't have a strong > opinion on it. However, I will leave them in place (to make this module > have similar behavior to other incorporated modules) unless I hear a > strong consensus from this list to remove them. The similarity to other modules keeps alive the illusion that they are needed or are a part of mysterious body of 'I have to do this to make it work' boiler plate which people accumulate and forget about in their CMake code. > I will > be responding to comments that Brad King made yesterday in my next email > to the list. Can you review my updated implementation as presented in > that email? Sure, thanks for the update. >> Is it possible/reasonable to determine if a particular GSL package has a >> dependency? On ATLAS, for example. > > You can certainly build GSL against any BLAS implementation, but I've > never seen that done in production. If a custom BLAS is used, the > pkgconfig script will correctly report the alternate BLAS library > (Unix/Linux platforms). For other types of installations, I'm not sure > how to query for the BLAS using when compiling GSL (e.g. Windows). If the > GSL is a shred library, I might be able to use system tools to inspect the > rpath - but I'm not sure that level of complexity is required for this > simple module. I agree that that level of complexity is not needed. But I wondered if GSL had build output which contains that information. Or gsl-config.exe or whatever. Thanks, Steve. From mantis at public.kitware.com Thu Dec 4 14:33:49 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 4 Dec 2014 14:33:49 -0500 Subject: [cmake-developers] [CMake 0015284]: /wd flags in source COMPILE_FLAGS replace /wd flags from other sources in Visual Studio generator Message-ID: The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15284 ====================================================================== Reported By: Braden McDaniel Assigned To: ====================================================================== Project: CMake Issue ID: 15284 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-12-04 14:33 EST Last Modified: 2014-12-04 14:33 EST ====================================================================== Summary: /wd flags in source COMPILE_FLAGS replace /wd flags from other sources in Visual Studio generator Description: If /wdXXXX flags (i.e., flags to disable specific warnings) are added via the source property COMPILE_FLAGS, these flags replace (rather than complement) any /wdXXXX flags added from other sources (e.g., the CMAKE_CXX_FLAGS variable or the directory COMPILE_FLAGS property). This is the case, at least, when using the Visual Studio 2013 generator. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-12-04 14:33 Braden McDanielNew Issue ====================================================================== From mantis at public.kitware.com Thu Dec 4 14:41:38 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 4 Dec 2014 14:41:38 -0500 Subject: [cmake-developers] [CMake 0015285]: Cannot escape "#" in add_compile_options Message-ID: <0100c36f663e2d33a809a63da8eaa128@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15285 ====================================================================== Reported By: Braden McDaniel Assigned To: ====================================================================== Project: CMake Issue ID: 15285 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-12-04 14:41 EST Last Modified: 2014-12-04 14:41 EST ====================================================================== Summary: Cannot escape "#" in add_compile_options Description: I've found no way to escape the "#" character when it needs to occur in an compiler option in the add_compile_options command. When adding such an option to, for instance, the CMAKE_CXX_FLAGS variable, it can be escaped with a backslash ("\"); but this does not appear to work when using add_compile_options. Steps to Reproduce: For example: add_compile_options(-Wno-\#pragma-messages) In the generated output (using the Unix Makefile generator), this string is added to the command line: "-Wno- Additional Information: This is workable; but does not use add_compile_options: set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wno-\\#pragma-messages") ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-12-04 14:41 Braden McDanielNew Issue ====================================================================== From brad.king at kitware.com Thu Dec 4 14:41:53 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 04 Dec 2014 14:41:53 -0500 Subject: [cmake-developers] Volunteering to maintain a new module: FindGSL.cmake In-Reply-To: References: <0458DF31F610EF42BFC78C497E806C7B3B53D6B0@ECS-EXG-P-MB03.win.lanl.gov> Message-ID: <5480B901.6030007@kitware.com> On 12/04/2014 02:29 PM, Stephen Kelly wrote: >>>> # GSL_INCLUDE_DIRS - Location of GSL header files. >>>> # GSL_LIBRARIES - The GSL libraries. >> >> These are defined mostly as a courtesy for folks who don't use imported >> targets yet. > > Yes. They are useful at least when a FindXXX does not provide IMPORTED > targets. I think we should keep them for now, even in new modules. > There is a mind-set change needed to avoid lines like that. CMake does not > have to be noisy anymore :). I don't see a hard need for new modules which > provide IMPORTED targets need to provide such variables. IMO we're not ready to make that call yet. Only when there is a dedicated and sweeping effort to make imported targets the norm for most of the find modules that come with CMake should we stop adding the variables to new modules. We're still learning the process of providing imported targets from find modules. As evidenced by the recent trouble with FindOpenGL: http://www.cmake.org/Bug/view.php?id=15267 they cannot be the norm yet. -Brad From rleigh at codelibre.net Thu Dec 4 17:54:35 2014 From: rleigh at codelibre.net (Roger Leigh) Date: Thu, 4 Dec 2014 22:54:35 +0000 Subject: [cmake-developers] suggestion: rename FindXerces to FindXercesC In-Reply-To: <54807EA5.2060600@kitware.com> References: <54807EA5.2060600@kitware.com> Message-ID: <20141204225434.GU1657@codelibre.net> On Thu, Dec 04, 2014 at 10:32:53AM -0500, Brad King wrote: > On 12/04/2014 10:09 AM, Erik Sj?lund wrote: > > I think it is a good idea to rename FindXerces to FindXercesC or > > something similar, just to indicate that is about the C++ > > implementation. > > Thanks for pointing out the distinct implementations. The module > is new in CMake 3.1 so our last chance to rename it now before the > final release of that version. Actually it looks like we're missing > a release note for it too. > > The documentation of the module starts off with: > > "Find the Apache Xerces-C++ validating XML parser..." > > which is pretty clear, though that is not visible at the call > sites of find_package(Xerces). > > Roger, as the contributor of this module do you have any reason > not to change the name? No. Either is fine with me; I didn't expect this to be problematic to omit the C suffix, but happy to have it added if it will avoid confusion. I just saw your other mail saying you'd made a patch. Do you need me to do anything else? Thanks, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 From steveire at gmail.com Thu Dec 4 18:00:05 2014 From: steveire at gmail.com (Stephen Kelly) Date: Fri, 05 Dec 2014 00:00:05 +0100 Subject: [cmake-developers] Volunteering to maintain a new module: FindGSL.cmake References: <0458DF31F610EF42BFC78C497E806C7B3B53D706@ECS-EXG-P-MB03.win.lanl.gov> Message-ID: Thompson, KT wrote: > It looks like the mailing list doesn't like attachments (is that > correct?). The attachment seems to have worked too: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/11783/focus=11829 > # These variables may optionally be set > # to help this module find the correct files. > # > # :: > # > # GSL_CONFIG - Location of the ``gsl-config`` script (if > # any). This looks like it needs a suffix. GSL_CONFIG_EXECUTABLE would seem appropriate. > # Windows with dlls, but only Release libraries. > set_target_properties( GSL::gslcblas PROPERTIES > IMPORTED_LOCATION "${GSL_CBLAS_LIBRARY_DLL}" This should be IMPORTED_LOCATION_RELEASE I noticed that the Find module documentation didn't give any information about this or the IMPORTED_CONFIGURATIONS property, so I added some along with some other fixes to that cmake-developer manual section. http://www.cmake.org/gitweb?p=cmake.git;a=commitdiff;h=656167c3 Thanks, Steve. From steveire at gmail.com Thu Dec 4 18:06:31 2014 From: steveire at gmail.com (Stephen Kelly) Date: Fri, 05 Dec 2014 00:06:31 +0100 Subject: [cmake-developers] Volunteering to maintain a new module: FindGSL.cmake References: <0458DF31F610EF42BFC78C497E806C7B3B53D6B0@ECS-EXG-P-MB03.win.lanl.gov> <5480B901.6030007@kitware.com> Message-ID: Brad King wrote: > We're still learning the process of providing imported targets from > find modules. As evidenced by the recent trouble with FindOpenGL: I think the 'normal' case of them is well understood, at least as evidenced by the Qt4 and GTK2 imported targets, which are the most-complete implementations. The SDK library case is not well-handled yet indeed, but I don't find that discouraging for the normal case, or something to discourage use of imported targets from find modules in the normal case. Thanks, Steve. From foss at grueninger.de Fri Dec 5 02:35:33 2014 From: foss at grueninger.de (=?UTF-8?B?Q2hyaXN0b3BoIEdyw7xuaW5nZXI=?=) Date: Fri, 05 Dec 2014 08:35:33 +0100 Subject: [cmake-developers] Which binaries should be required in FindLATEX? Message-ID: <54816045.5070306@grueninger.de> Hi CMake developers, yesterday I created a pull request with the attached patch. It was rejected because it was not clear, whether we should really require all these LaTeX related binaries. FindLATEX tries to find, and I wanted to make them all required, these binaries: LATEX_COMPILER PDFLATEX_COMPILER BIBTEX_COMPILER MAKEINDEX_COMPILER DVIPS_CONVERTER PS2PDF_CONVERTER LATEX2HTML_CONVERTER I am unsure whether Brad is right or not. For users it would be great to simply have all these binaries. I cannot imagine someone is installing LaTeX without BibTeX or makeindex, as it does not make sense. The minimal set I would test would be LATEX_COMPILER PDFLATEX_COMPILER BIBTEX_COMPILER MAKEINDEX_COMPILER If this is still to restrictive, I propose to only test for the LaTeX compiler and let the user check for the other binaries (with if(MAKEINDEX_COMPILER) ) In any case, I'll have to clarify this in the documentation for my next patch. Bye Christoph -------------- next part -------------- A non-text attachment was scrubbed... Name: FPHSA-for-FindLATEX.patch Type: text/x-patch Size: 1221 bytes Desc: not available URL: From erik.sjolund at gmail.com Fri Dec 5 04:28:43 2014 From: erik.sjolund at gmail.com (=?UTF-8?Q?Erik_Sj=C3=B6lund?=) Date: Fri, 5 Dec 2014 10:28:43 +0100 Subject: [cmake-developers] why does the order of the options in file(GENERATE) matter? Message-ID: I tried this out: file(GENERATE INPUT ${CMAKE_CURRENT_SOURCE_DIR}/script.sh OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/script.sh) but CMake failed with this error message: "file Incorrect arguments to GENERATE subcommand." If I reverse the order of the options INPUT and OUTPUT it works just fine. file(GENERATE OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/script.sh) INPUT ${CMAKE_CURRENT_SOURCE_DIR}/script.sh) The CMake documentation doesn't mention that the order matters: http://www.cmake.org/cmake/help/v3.1/command/file.html#command:file Why does the order of the options in file(GENERATE) matter? cheers, Erik Sj?lund From erik.sjolund at gmail.com Fri Dec 5 05:56:49 2014 From: erik.sjolund at gmail.com (=?UTF-8?Q?Erik_Sj=C3=B6lund?=) Date: Fri, 5 Dec 2014 11:56:49 +0100 Subject: [cmake-developers] suggestion: rename FindXerces to FindXercesC In-Reply-To: <54808332.2030404@kitware.com> References: <54807EA5.2060600@kitware.com> <54808332.2030404@kitware.com> Message-ID: The patch worked for me. cheers, Erik Sj?lund On Thu, Dec 4, 2014 at 4:52 PM, Brad King wrote: > On 12/04/2014 10:32 AM, Brad King wrote: >> Roger, as the contributor of this module do you have any reason >> not to change the name? > > I've constructed a commit to perform the rename and merged to 'next' > for testing: > > Modules: Rename FindXerces to FindXercesC > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=27141eed > > Please let me know if it works. I'd like to get feedback before > merging to 'master' or 'release'. > > Thanks, > -Brad > From mantis at public.kitware.com Fri Dec 5 08:57:53 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Fri, 5 Dec 2014 08:57:53 -0500 Subject: [cmake-developers] [CMake 0015286]: ExternalProject double build with parallel make and multiple targets Message-ID: <97264ed9fcf0e429811da3c9bd76fdb8@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15286 ====================================================================== Reported By: Jaak Ristioja Assigned To: ====================================================================== Project: CMake Issue ID: 15286 Category: CMake Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2014-12-05 08:57 EST Last Modified: 2014-12-05 08:57 EST ====================================================================== Summary: ExternalProject double build with parallel make and multiple targets Description: Given a project like this: cmake_minimum_required(VERSION 2.8.12) project(bad NONE) include(ExternalProject) ExternalProject_Add(a DOWNLOAD_COMMAND sleep 1 CONFIGURE_COMMAND sleep 1 BUILD_COMMAND sleep 1 INSTALL_COMMAND date +%N | tee a) ExternalProject_Add(b DOWNLOAD_COMMAND sleep 1 CONFIGURE_COMMAND sleep 1 BUILD_COMMAND sleep 1 INSTALL_COMMAND touch b DEPENDS a) Running something like "make -j2 a b" causes target "a" to be built twice: [ 12%] [ 12%] Creating directories for 'a' Creating directories for 'a' [ 25%] [ 25%] Performing download step for 'a' Performing download step for 'a' [ 50%] [ 50%] [ 50%] [ 50%] No patch step for 'a' No update step for 'a' No update step for 'a' No patch step for 'a' [ 62%] [ 62%] Performing configure step for 'a' Performing configure step for 'a' [ 75%] [ 75%] Performing build step for 'a' Performing build step for 'a' [ 87%] [ 87%] Performing install step for 'a' Performing install step for 'a' 506615761 506738194 [100%] [100%] Completed 'a' Completed 'a' [100%] [100%] Built target a Built target a Creating directories for 'b' Performing download step for 'b' No patch step for 'b' No update step for 'b' Performing configure step for 'b' Performing build step for 'b' Performing install step for 'b' Completed 'b' Built target b Additional Information: Using CMake 2.8.12 and GNU make 4.0. This issue also seems to be have been reported in the mailing list: http://public.kitware.com/pipermail/cmake/2013-July/055214.html ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-12-05 08:57 Jaak Ristioja New Issue ====================================================================== From ruslan_baratov at yahoo.com Fri Dec 5 09:03:41 2014 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Fri, 05 Dec 2014 17:03:41 +0300 Subject: [cmake-developers] New command 'file(LOCK_DIRECTORY ...)' In-Reply-To: <547CD068.9080905@kitware.com> References: <5431B11C.3010209@yahoo.com> <8862399.plEbCk131l@eto> <547C931C.6070105@kitware.com> <1937103.VnMLJRSfzj@eto> <547CD068.9080905@kitware.com> Message-ID: <5481BB3D.5020208@yahoo.com> On 01-Dec-14 23:32, Brad King wrote: > On 12/01/2014 03:26 PM, Stephen Kelly wrote: >> Existing uses of strtol also check errno. I guess your implementation should >> too. > Yes, IIUC it is a range check on whether the value can be represented. I think also you need to zero errno before strtol since errno is not zeroed on successful conversion. > >> Then the existing users should use this new method. > In that case the type should be changed to 'long' instead of 'int', > and the current call site should be updated accordingly. Actually why not use 'strtoll' and 'long long' ? Sending patch with 'strtoll', 'long long' and 'errno=0'. Ruslo -------------- next part -------------- >From bd907fa4e4bd1e6f17c946ab54aa17beb1fd23e8 Mon Sep 17 00:00:00 2001 From: Ruslan Baratov Date: Fri, 5 Dec 2014 15:10:32 +0300 Subject: [PATCH] Use 'long long' for StringToInt --- Source/cmFileCommand.cxx | 6 +++--- Source/cmFileLock.cxx | 4 ++-- Source/cmFileLock.h | 6 ++++-- Source/cmFileLockPool.cxx | 8 ++++---- Source/cmFileLockPool.h | 10 ++++++---- Source/cmFileLockUnix.cxx | 2 +- Source/cmFileLockWin32.cxx | 2 +- Source/cmSystemTools.cxx | 7 ++++--- Source/cmSystemTools.h | 4 ++-- 9 files changed, 27 insertions(+), 22 deletions(-) diff --git a/Source/cmFileCommand.cxx b/Source/cmFileCommand.cxx index a6eb8c4..c86b768 100644 --- a/Source/cmFileCommand.cxx +++ b/Source/cmFileCommand.cxx @@ -3521,7 +3521,7 @@ bool cmFileCommand::HandleLockCommand( }; Guard guard = GUARD_PROCESS; std::string resultVariable; - unsigned timeout = static_cast(-1); + unsigned long long timeout = static_cast(-1); // Parse arguments if(args.size() < 2) @@ -3597,7 +3597,7 @@ bool cmFileCommand::HandleLockCommand( "expected timeout value after TIMEOUT"); return false; } - int scanned; + long long scanned; if(!cmSystemTools::StringToInt(args[i].c_str(), &scanned) || scanned < 0) { cmOStringStream e; @@ -3605,7 +3605,7 @@ bool cmFileCommand::HandleLockCommand( this->Makefile->IssueMessage(cmake::FATAL_ERROR, e.str()); return false; } - timeout = static_cast(scanned); + timeout = static_cast(scanned); } else { diff --git a/Source/cmFileLock.cxx b/Source/cmFileLock.cxx index 5f75637..f891105 100644 --- a/Source/cmFileLock.cxx +++ b/Source/cmFileLock.cxx @@ -28,7 +28,7 @@ cmFileLock::~cmFileLock() } cmFileLockResult cmFileLock::Lock( - const std::string& filename, unsigned timeout) + const std::string& filename, unsigned long long timeout) { if (filename.empty()) { @@ -48,7 +48,7 @@ cmFileLockResult cmFileLock::Lock( cmFileLockResult result = this->OpenFile(); if (result.IsOk()) { - if (timeout == static_cast(-1)) + if (timeout == static_cast(-1)) { result = this->LockWithoutTimeout(); } diff --git a/Source/cmFileLock.h b/Source/cmFileLock.h index 4d922a0..7a8e6db 100644 --- a/Source/cmFileLock.h +++ b/Source/cmFileLock.h @@ -37,7 +37,9 @@ class cmFileLock * @brief Lock the file. * @param timeoutSec Lock timeout. If -1 try until success or fatal error. */ - cmFileLockResult Lock(const std::string& filename, unsigned timeoutSec); + cmFileLockResult Lock( + const std::string& filename, unsigned long long timeoutSec + ); /** * @brief Unlock the file. @@ -57,7 +59,7 @@ class cmFileLock cmFileLockResult OpenFile(); cmFileLockResult LockWithoutTimeout(); - cmFileLockResult LockWithTimeout(unsigned timeoutSec); + cmFileLockResult LockWithTimeout(unsigned long long timeoutSec); #if defined(_WIN32) typedef HANDLE FileId; diff --git a/Source/cmFileLockPool.cxx b/Source/cmFileLockPool.cxx index e84e71a..862f44c 100644 --- a/Source/cmFileLockPool.cxx +++ b/Source/cmFileLockPool.cxx @@ -60,7 +60,7 @@ void cmFileLockPool::PopFileScope() } cmFileLockResult cmFileLockPool::LockFunctionScope( - const std::string& filename, unsigned timeoutSec) + const std::string& filename, unsigned long long timeoutSec) { if (this->IsAlreadyLocked(filename)) { @@ -74,7 +74,7 @@ cmFileLockResult cmFileLockPool::LockFunctionScope( } cmFileLockResult cmFileLockPool::LockFileScope( - const std::string& filename, unsigned timeoutSec) + const std::string& filename, unsigned long long timeoutSec) { if (this->IsAlreadyLocked(filename)) { @@ -85,7 +85,7 @@ cmFileLockResult cmFileLockPool::LockFileScope( } cmFileLockResult cmFileLockPool::LockProcessScope( - const std::string& filename, unsigned timeoutSec) + const std::string& filename, unsigned long long timeoutSec) { if (this->IsAlreadyLocked(filename)) { @@ -155,7 +155,7 @@ cmFileLockPool::ScopePool::~ScopePool() } cmFileLockResult cmFileLockPool::ScopePool::Lock( - const std::string& filename, unsigned timeoutSec) + const std::string& filename, unsigned long long timeoutSec) { cmFileLock *lock = new cmFileLock(); const cmFileLockResult result = lock->Lock(filename, timeoutSec); diff --git a/Source/cmFileLockPool.h b/Source/cmFileLockPool.h index a63540c..1d7d73c 100644 --- a/Source/cmFileLockPool.h +++ b/Source/cmFileLockPool.h @@ -45,13 +45,13 @@ class cmFileLockPool * @param timeoutSec Lock timeout. If -1 try until success or fatal error. */ cmFileLockResult LockFunctionScope( - const std::string& filename, unsigned timeoutSec + const std::string& filename, unsigned long long timeoutSec ); cmFileLockResult LockFileScope( - const std::string& filename, unsigned timeoutSec + const std::string& filename, unsigned long long timeoutSec ); cmFileLockResult LockProcessScope( - const std::string& filename, unsigned timeoutSec + const std::string& filename, unsigned long long timeoutSec ); //@} @@ -72,7 +72,9 @@ class cmFileLockPool ScopePool(); ~ScopePool(); - cmFileLockResult Lock(const std::string& filename, unsigned timeoutSec); + cmFileLockResult Lock( + const std::string& filename, unsigned long long timeoutSec + ); cmFileLockResult Release(const std::string& filename); bool IsAlreadyLocked(const std::string& filename) const; diff --git a/Source/cmFileLockUnix.cxx b/Source/cmFileLockUnix.cxx index 038011e..d9af0b0 100644 --- a/Source/cmFileLockUnix.cxx +++ b/Source/cmFileLockUnix.cxx @@ -66,7 +66,7 @@ cmFileLockResult cmFileLock::LockWithoutTimeout() } } -cmFileLockResult cmFileLock::LockWithTimeout(unsigned seconds) +cmFileLockResult cmFileLock::LockWithTimeout(unsigned long long seconds) { while (true) { diff --git a/Source/cmFileLockWin32.cxx b/Source/cmFileLockWin32.cxx index 17231ea..457f2df 100644 --- a/Source/cmFileLockWin32.cxx +++ b/Source/cmFileLockWin32.cxx @@ -86,7 +86,7 @@ cmFileLockResult cmFileLock::LockWithoutTimeout() } } -cmFileLockResult cmFileLock::LockWithTimeout(unsigned seconds) +cmFileLockResult cmFileLock::LockWithTimeout(unsigned long long seconds) { const DWORD flags = LOCKFILE_EXCLUSIVE_LOCK | LOCKFILE_FAIL_IMMEDIATELY; while (true) diff --git a/Source/cmSystemTools.cxx b/Source/cmSystemTools.cxx index 9852dd6..def2c26 100644 --- a/Source/cmSystemTools.cxx +++ b/Source/cmSystemTools.cxx @@ -2925,9 +2925,10 @@ std::vector cmSystemTools::tokenize(const std::string& str, } //---------------------------------------------------------------------------- -bool cmSystemTools::StringToInt(const char* str, int* value) +bool cmSystemTools::StringToInt(const char* str, long long* value) { + errno = 0; char *endp; - *value = static_cast(strtol(str, &endp, 10)); - return (*endp == '\0') && (endp != str); + *value = strtoll(str, &endp, 10); + return (*endp == '\0') && (endp != str) && (errno == 0); } diff --git a/Source/cmSystemTools.h b/Source/cmSystemTools.h index 763389b..b4d3177 100644 --- a/Source/cmSystemTools.h +++ b/Source/cmSystemTools.h @@ -458,8 +458,8 @@ public: static std::vector tokenize(const std::string& str, const std::string& sep); - /** Convert string to int. Expected that the whole string is an integer */ - static bool StringToInt(const char* str, int* value); + /** Convert string to integer. Expected that the whole string is an integer */ + static bool StringToInt(const char* str, long long* value); #ifdef _WIN32 struct WindowsFileRetry -- 2.1.1 From brad.king at kitware.com Fri Dec 5 09:04:19 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 05 Dec 2014 09:04:19 -0500 Subject: [cmake-developers] suggestion: rename FindXerces to FindXercesC In-Reply-To: <20141204225434.GU1657@codelibre.net> References: <54807EA5.2060600@kitware.com> <20141204225434.GU1657@codelibre.net> Message-ID: <5481BB63.3080604@kitware.com> On 12/04/2014 05:54 PM, Roger Leigh wrote: > No. Either is fine with me; I didn't expect this to be problematic > to omit the C suffix, but happy to have it added if it will avoid > confusion. > > I just saw your other mail saying you'd made a patch. Do you need me > to do anything else? Please just test the renamed module to verify it still works for your original use case (besides the name change). With Erik's confirmation I will merge this for the next 3.1 release candidate anyway, but more testing is better ;) Thanks, -Brad From brad.king at kitware.com Fri Dec 5 09:09:03 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 05 Dec 2014 09:09:03 -0500 Subject: [cmake-developers] New command 'file(LOCK_DIRECTORY ...)' In-Reply-To: <5481BB3D.5020208@yahoo.com> References: <5431B11C.3010209@yahoo.com> <8862399.plEbCk131l@eto> <547C931C.6070105@kitware.com> <1937103.VnMLJRSfzj@eto> <547CD068.9080905@kitware.com> <5481BB3D.5020208@yahoo.com> Message-ID: <5481BC7F.8080701@kitware.com> On 12/05/2014 09:03 AM, Ruslan Baratov wrote: > Actually why not use 'strtoll' and 'long long' ? I'm not sure that function or type exists portably on some of the older host platforms we support. The "long" type should be plenty big for timeout values, and there are other strtol call sites that already use "long" and could be converted to use a StringToLong helper too. Actually for the lock timeout use case would it make sense to change to a floating point value so timeouts can be more granular? Some use cases may not want to block for a whole second between lock attempts. Thanks, -Brad From ruslan_baratov at yahoo.com Fri Dec 5 09:10:33 2014 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Fri, 05 Dec 2014 17:10:33 +0300 Subject: [cmake-developers] New command 'file(LOCK_DIRECTORY ...)' In-Reply-To: <547F27CC.3030209@kitware.com> References: <5431B11C.3010209@yahoo.com> <54665ED3.3060300@kitware.com> <54668FEC.5020203@yahoo.com> <708024991.ylpfiUSqup@caliban.sf-tec.de> <546A0F00.3090908@kitware.com> <546A8881.5050205@yahoo.com> <5474CA82.6090509@kitware.com> <54750FB3.6080903@yahoo.com> <547C8EAE.9030900@kitware.com> <547F27CC.3030209@kitware.com> Message-ID: <5481BCD9.6030105@yahoo.com> On 03-Dec-14 18:10, Brad King wrote: > On 12/01/2014 10:52 AM, Brad King wrote: >> cmSystemTools: Add StringToInt helper >> http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5121f118 >> >> file: Add LOCK subcommand to do file and directory locking >> http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fca624ca >> >> Help: Add notes for topic 'file-LOCK-command' >> http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ed00a808 > After some revisions: > > cmSystemTools: Add StringToInt helper > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=05d6531c > > file: Add LOCK subcommand to do file and directory locking > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e6db4c5a > > Help: Add notes for topic 'file-LOCK-command' > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=93017828 > > -Brad Great, thank you! So will this be applied to cmake 3.1.0? From brad.king at kitware.com Fri Dec 5 09:12:04 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 05 Dec 2014 09:12:04 -0500 Subject: [cmake-developers] New command 'file(LOCK_DIRECTORY ...)' In-Reply-To: <5481BCD9.6030105@yahoo.com> References: <5431B11C.3010209@yahoo.com> <54665ED3.3060300@kitware.com> <54668FEC.5020203@yahoo.com> <708024991.ylpfiUSqup@caliban.sf-tec.de> <546A0F00.3090908@kitware.com> <546A8881.5050205@yahoo.com> <5474CA82.6090509@kitware.com> <54750FB3.6080903@yahoo.com> <547C8EAE.9030900@kitware.com> <547F27CC.3030209@kitware.com> <5481BCD9.6030105@yahoo.com> Message-ID: <5481BD34.6080506@kitware.com> On 12/05/2014 09:10 AM, Ruslan Baratov wrote: >> file: Add LOCK subcommand to do file and directory locking >> http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e6db4c5a >> > Great, thank you! So will this be applied to cmake 3.1.0? No, sorry. The feature deadline for that was almost 2 months ago. The release candidate period has been pretty drawn out this time :( -Brad From ruslan_baratov at yahoo.com Fri Dec 5 09:38:49 2014 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Fri, 05 Dec 2014 17:38:49 +0300 Subject: [cmake-developers] New command 'file(LOCK_DIRECTORY ...)' In-Reply-To: <5481BD34.6080506@kitware.com> References: <5431B11C.3010209@yahoo.com> <54665ED3.3060300@kitware.com> <54668FEC.5020203@yahoo.com> <708024991.ylpfiUSqup@caliban.sf-tec.de> <546A0F00.3090908@kitware.com> <546A8881.5050205@yahoo.com> <5474CA82.6090509@kitware.com> <54750FB3.6080903@yahoo.com> <547C8EAE.9030900@kitware.com> <547F27CC.3030209@kitware.com> <5481BCD9.6030105@yahoo.com> <5481BD34.6080506@kitware.com> Message-ID: <5481C379.4010508@yahoo.com> On 05-Dec-14 17:12, Brad King wrote: > On 12/05/2014 09:10 AM, Ruslan Baratov wrote: >>> file: Add LOCK subcommand to do file and directory locking >>> http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e6db4c5a >>> >> Great, thank you! So will this be applied to cmake 3.1.0? > No, sorry. The feature deadline for that was almost 2 months ago. > The release candidate period has been pretty drawn out this time :( > > -Brad > Okay, just curious what version it will be? Ruslo From brad.king at kitware.com Fri Dec 5 09:42:13 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 05 Dec 2014 09:42:13 -0500 Subject: [cmake-developers] New command 'file(LOCK_DIRECTORY ...)' In-Reply-To: <5481C379.4010508@yahoo.com> References: <5431B11C.3010209@yahoo.com> <54665ED3.3060300@kitware.com> <54668FEC.5020203@yahoo.com> <708024991.ylpfiUSqup@caliban.sf-tec.de> <546A0F00.3090908@kitware.com> <546A8881.5050205@yahoo.com> <5474CA82.6090509@kitware.com> <54750FB3.6080903@yahoo.com> <547C8EAE.9030900@kitware.com> <547F27CC.3030209@kitware.com> <5481BCD9.6030105@yahoo.com> <5481BD34.6080506@kitware.com> <5481C379.4010508@yahoo.com> Message-ID: <5481C445.9050907@kitware.com> On 12/05/2014 09:38 AM, Ruslan Baratov wrote: > Okay, just curious what version it will be? 3.2. There is a roadmap here: http://www.cmake.org/Bug/roadmap_page.php with tentative dates. -Brad From ruslan_baratov at yahoo.com Fri Dec 5 09:51:32 2014 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Fri, 05 Dec 2014 17:51:32 +0300 Subject: [cmake-developers] New command 'file(LOCK_DIRECTORY ...)' In-Reply-To: <5481BC7F.8080701@kitware.com> References: <5431B11C.3010209@yahoo.com> <8862399.plEbCk131l@eto> <547C931C.6070105@kitware.com> <1937103.VnMLJRSfzj@eto> <547CD068.9080905@kitware.com> <5481BB3D.5020208@yahoo.com> <5481BC7F.8080701@kitware.com> Message-ID: <5481C674.2020707@yahoo.com> On 05-Dec-14 17:09, Brad King wrote: > On 12/05/2014 09:03 AM, Ruslan Baratov wrote: >> Actually why not use 'strtoll' and 'long long' ? > I'm not sure that function or type exists portably on some of the > older host platforms we support. The "long" type should be plenty > big for timeout values, and there are other strtol call sites that > already use "long" and could be converted to use a StringToLong > helper too. Sending patch with 'long'. > Actually for the lock timeout use case would it make sense to change > to a floating point value so timeouts can be more granular? Some > use cases may not want to block for a whole second between lock > attempts. > What granularity you think is appropriate, 100 ms? 10 ms? (It will be value in `cmSystemTools::Delay(...);`) Ruslo -------------- next part -------------- >From 3ed0ad891c6108fa2a03834f9fe109ee5d628847 Mon Sep 17 00:00:00 2001 From: Ruslan Baratov Date: Fri, 5 Dec 2014 17:18:11 +0300 Subject: [PATCH] Use 'long' for StringToInt --- Source/cmFileCommand.cxx | 6 +++--- Source/cmFileLock.cxx | 4 ++-- Source/cmFileLock.h | 4 ++-- Source/cmFileLockPool.cxx | 8 ++++---- Source/cmFileLockPool.h | 10 ++++++---- Source/cmFileLockUnix.cxx | 2 +- Source/cmFileLockWin32.cxx | 2 +- Source/cmSystemTools.cxx | 7 ++++--- Source/cmSystemTools.h | 4 ++-- 9 files changed, 25 insertions(+), 22 deletions(-) diff --git a/Source/cmFileCommand.cxx b/Source/cmFileCommand.cxx index a6eb8c4..42cd132 100644 --- a/Source/cmFileCommand.cxx +++ b/Source/cmFileCommand.cxx @@ -3521,7 +3521,7 @@ bool cmFileCommand::HandleLockCommand( }; Guard guard = GUARD_PROCESS; std::string resultVariable; - unsigned timeout = static_cast(-1); + unsigned long timeout = static_cast(-1); // Parse arguments if(args.size() < 2) @@ -3597,7 +3597,7 @@ bool cmFileCommand::HandleLockCommand( "expected timeout value after TIMEOUT"); return false; } - int scanned; + long scanned; if(!cmSystemTools::StringToInt(args[i].c_str(), &scanned) || scanned < 0) { cmOStringStream e; @@ -3605,7 +3605,7 @@ bool cmFileCommand::HandleLockCommand( this->Makefile->IssueMessage(cmake::FATAL_ERROR, e.str()); return false; } - timeout = static_cast(scanned); + timeout = static_cast(scanned); } else { diff --git a/Source/cmFileLock.cxx b/Source/cmFileLock.cxx index 5f75637..e6aa5f4 100644 --- a/Source/cmFileLock.cxx +++ b/Source/cmFileLock.cxx @@ -28,7 +28,7 @@ cmFileLock::~cmFileLock() } cmFileLockResult cmFileLock::Lock( - const std::string& filename, unsigned timeout) + const std::string& filename, unsigned long timeout) { if (filename.empty()) { @@ -48,7 +48,7 @@ cmFileLockResult cmFileLock::Lock( cmFileLockResult result = this->OpenFile(); if (result.IsOk()) { - if (timeout == static_cast(-1)) + if (timeout == static_cast(-1)) { result = this->LockWithoutTimeout(); } diff --git a/Source/cmFileLock.h b/Source/cmFileLock.h index 4d922a0..dd959a7 100644 --- a/Source/cmFileLock.h +++ b/Source/cmFileLock.h @@ -37,7 +37,7 @@ class cmFileLock * @brief Lock the file. * @param timeoutSec Lock timeout. If -1 try until success or fatal error. */ - cmFileLockResult Lock(const std::string& filename, unsigned timeoutSec); + cmFileLockResult Lock(const std::string& filename, unsigned long timeoutSec); /** * @brief Unlock the file. @@ -57,7 +57,7 @@ class cmFileLock cmFileLockResult OpenFile(); cmFileLockResult LockWithoutTimeout(); - cmFileLockResult LockWithTimeout(unsigned timeoutSec); + cmFileLockResult LockWithTimeout(unsigned long timeoutSec); #if defined(_WIN32) typedef HANDLE FileId; diff --git a/Source/cmFileLockPool.cxx b/Source/cmFileLockPool.cxx index e84e71a..551a75a 100644 --- a/Source/cmFileLockPool.cxx +++ b/Source/cmFileLockPool.cxx @@ -60,7 +60,7 @@ void cmFileLockPool::PopFileScope() } cmFileLockResult cmFileLockPool::LockFunctionScope( - const std::string& filename, unsigned timeoutSec) + const std::string& filename, unsigned long timeoutSec) { if (this->IsAlreadyLocked(filename)) { @@ -74,7 +74,7 @@ cmFileLockResult cmFileLockPool::LockFunctionScope( } cmFileLockResult cmFileLockPool::LockFileScope( - const std::string& filename, unsigned timeoutSec) + const std::string& filename, unsigned long timeoutSec) { if (this->IsAlreadyLocked(filename)) { @@ -85,7 +85,7 @@ cmFileLockResult cmFileLockPool::LockFileScope( } cmFileLockResult cmFileLockPool::LockProcessScope( - const std::string& filename, unsigned timeoutSec) + const std::string& filename, unsigned long timeoutSec) { if (this->IsAlreadyLocked(filename)) { @@ -155,7 +155,7 @@ cmFileLockPool::ScopePool::~ScopePool() } cmFileLockResult cmFileLockPool::ScopePool::Lock( - const std::string& filename, unsigned timeoutSec) + const std::string& filename, unsigned long timeoutSec) { cmFileLock *lock = new cmFileLock(); const cmFileLockResult result = lock->Lock(filename, timeoutSec); diff --git a/Source/cmFileLockPool.h b/Source/cmFileLockPool.h index a63540c..baef310 100644 --- a/Source/cmFileLockPool.h +++ b/Source/cmFileLockPool.h @@ -45,13 +45,13 @@ class cmFileLockPool * @param timeoutSec Lock timeout. If -1 try until success or fatal error. */ cmFileLockResult LockFunctionScope( - const std::string& filename, unsigned timeoutSec + const std::string& filename, unsigned long timeoutSec ); cmFileLockResult LockFileScope( - const std::string& filename, unsigned timeoutSec + const std::string& filename, unsigned long timeoutSec ); cmFileLockResult LockProcessScope( - const std::string& filename, unsigned timeoutSec + const std::string& filename, unsigned long timeoutSec ); //@} @@ -72,7 +72,9 @@ class cmFileLockPool ScopePool(); ~ScopePool(); - cmFileLockResult Lock(const std::string& filename, unsigned timeoutSec); + cmFileLockResult Lock( + const std::string& filename, unsigned long timeoutSec + ); cmFileLockResult Release(const std::string& filename); bool IsAlreadyLocked(const std::string& filename) const; diff --git a/Source/cmFileLockUnix.cxx b/Source/cmFileLockUnix.cxx index 038011e..fc18a64 100644 --- a/Source/cmFileLockUnix.cxx +++ b/Source/cmFileLockUnix.cxx @@ -66,7 +66,7 @@ cmFileLockResult cmFileLock::LockWithoutTimeout() } } -cmFileLockResult cmFileLock::LockWithTimeout(unsigned seconds) +cmFileLockResult cmFileLock::LockWithTimeout(unsigned long seconds) { while (true) { diff --git a/Source/cmFileLockWin32.cxx b/Source/cmFileLockWin32.cxx index 17231ea..4691689 100644 --- a/Source/cmFileLockWin32.cxx +++ b/Source/cmFileLockWin32.cxx @@ -86,7 +86,7 @@ cmFileLockResult cmFileLock::LockWithoutTimeout() } } -cmFileLockResult cmFileLock::LockWithTimeout(unsigned seconds) +cmFileLockResult cmFileLock::LockWithTimeout(unsigned long seconds) { const DWORD flags = LOCKFILE_EXCLUSIVE_LOCK | LOCKFILE_FAIL_IMMEDIATELY; while (true) diff --git a/Source/cmSystemTools.cxx b/Source/cmSystemTools.cxx index 9852dd6..09a3452 100644 --- a/Source/cmSystemTools.cxx +++ b/Source/cmSystemTools.cxx @@ -2925,9 +2925,10 @@ std::vector cmSystemTools::tokenize(const std::string& str, } //---------------------------------------------------------------------------- -bool cmSystemTools::StringToInt(const char* str, int* value) +bool cmSystemTools::StringToInt(const char* str, long* value) { + errno = 0; char *endp; - *value = static_cast(strtol(str, &endp, 10)); - return (*endp == '\0') && (endp != str); + *value = strtol(str, &endp, 10); + return (*endp == '\0') && (endp != str) && (errno == 0); } diff --git a/Source/cmSystemTools.h b/Source/cmSystemTools.h index 763389b..2687bd9 100644 --- a/Source/cmSystemTools.h +++ b/Source/cmSystemTools.h @@ -458,8 +458,8 @@ public: static std::vector tokenize(const std::string& str, const std::string& sep); - /** Convert string to int. Expected that the whole string is an integer */ - static bool StringToInt(const char* str, int* value); + /** Convert string to long. Expected that the whole string is an integer */ + static bool StringToInt(const char* str, long* value); #ifdef _WIN32 struct WindowsFileRetry -- 2.1.1 From brad.king at kitware.com Fri Dec 5 13:04:49 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 05 Dec 2014 13:04:49 -0500 Subject: [cmake-developers] New command 'file(LOCK_DIRECTORY ...)' In-Reply-To: <5481C674.2020707@yahoo.com> References: <5431B11C.3010209@yahoo.com> <8862399.plEbCk131l@eto> <547C931C.6070105@kitware.com> <1937103.VnMLJRSfzj@eto> <547CD068.9080905@kitware.com> <5481BB3D.5020208@yahoo.com> <5481BC7F.8080701@kitware.com> <5481C674.2020707@yahoo.com> Message-ID: <5481F3C1.4050201@kitware.com> On 12/05/2014 09:51 AM, Ruslan Baratov wrote: > Sending patch with 'long'. Applied while also renaming to StringToLong, thanks: file: Use 'long' to represent the parsed LOCK TIMEOUT value http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=97841dad > What granularity you think is appropriate, 100 ms? 10 ms? (It will be > value in `cmSystemTools::Delay(...);`) On second thought, it is easy to change this later if a case comes up that really needs it, so let's stay with 1s for now. Thanks, -Brad From brad.king at kitware.com Fri Dec 5 13:32:15 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 05 Dec 2014 13:32:15 -0500 Subject: [cmake-developers] why does the order of the options in file(GENERATE) matter? In-Reply-To: References: Message-ID: <5481FA2F.6060303@kitware.com> On 12/05/2014 04:28 AM, Erik Sj?lund wrote: > The CMake documentation doesn't mention that the order matters: > http://www.cmake.org/cmake/help/v3.1/command/file.html#command:file > > Why does the order of the options in file(GENERATE) matter? It was always implemented that way: http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmFileCommand.cxx;hb=v3.1.0-rc2#l3421 but the order was dropped from the documentation by accident during reformatting. I've fixed the documentation: Help: Document file(GENERATE) signature option order http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fe21580b -Brad From brad.king at kitware.com Fri Dec 5 13:55:34 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 05 Dec 2014 13:55:34 -0500 Subject: [cmake-developers] Which binaries should be required in FindLATEX? In-Reply-To: <54816045.5070306@grueninger.de> References: <54816045.5070306@grueninger.de> Message-ID: <5481FFA6.5080004@kitware.com> Hi Christoph, Thanks for working on this. On 12/05/2014 02:35 AM, Christoph Gr?ninger wrote: > For users it would be great to simply have all these binaries. I don't have all the converters installed but can still build PDF books. The varying tools do not all come in the same package on Linux distros. Of course most projects will want most or all of the tools. For this I think the FindLATEX module should implement support for the find_package COMPONENTS option. Then projects can specify what they need: find_package(LATEX COMPONENTS latex pdflatex bibtex ...) and the module will compute the proper LATEX_FOUND value based on the availability of all the requested components. > If this is still to restrictive, I propose to only test for the LaTeX > compiler and let the user check for the other binaries (with > if(MAKEINDEX_COMPILER) ) With proper component support I think that proposal makes sense. If no components are listed then LATEX_FOUND should be based only on LATEX_COMPILER. If components are listed then all of them must be found. Of course this approach can be implemented first to get FPHSA working and component support added later. Any components listed would just be added to the list given to the REQUIRED_VARS option of FPHSA. > In any case, I'll have to clarify this in the documentation for my next > patch. In the next revision please also add your name to the author field instead of the Github user id. Thanks, -Brad From brad.king at kitware.com Fri Dec 5 14:33:41 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 05 Dec 2014 14:33:41 -0500 Subject: [cmake-developers] [DISCUSSION] Using COMPONENTs for CMake install(...)? In-Reply-To: <2931041417672790@web24g.yandex.ru> References: <50071417557052@web29o.yandex.ru> <547F298A.8020002@kitware.com> <2931041417672790@web24g.yandex.ru> Message-ID: <54820895.40900@kitware.com> On 12/04/2014 12:59 AM, Konstantin Podsvirov wrote: > In the source tree, you can see some of the components. The Debian packaging can serve as a good reference: cmake - cross-platform, open-source make system cmake-curses-gui - curses based user interface for CMake (ccmake) cmake-data - CMake data files (modules, templates and documentation) cmake-doc - extended documentation in various formats for CMake cmake-qt-gui - Qt4 based user interface for CMake (cmake-gui) > For example: > -- tools > - cmake > - cpack > - ctest Yes. > -- scripts > - modules > - templates These are the Debian "cmake-data" package. > -- documentation > - manual > * html version > * man pages Debian packages the tool man pages with the tools due to their policy of having documentation available for all commands. Other manuals are in the separate cmake-doc package. For interactive installers I think we can keep all the docs in their own packages separate from the tools since the doc format could be made selectable. The html and man pages could be placed in separate install components too. > -- according to > - Qt (only necessary) Separate components for each of the "ccmake" and "cmake-gui" interactive dialogs makes sense. With the above guidance please go ahead and work on the patch if you want. All the install() calls will need to be updated with the proper COMPONENT option(s). > Also I suggest to add in CMakeLists.txt option to control the > installation of dependencies with CMake. > For example the Qt library. This happens on Windows and Mac, > but I think it is not always necessary in Linux. This is a separate task, so let's focus on the components first. -Brad From erik.sjolund at gmail.com Fri Dec 5 15:11:36 2014 From: erik.sjolund at gmail.com (=?UTF-8?Q?Erik_Sj=C3=B6lund?=) Date: Fri, 5 Dec 2014 21:11:36 +0100 Subject: [cmake-developers] why does the order of the options in file(GENERATE) matter? In-Reply-To: <5481FA2F.6060303@kitware.com> References: <5481FA2F.6060303@kitware.com> Message-ID: I see, thanks. cheers, Erik Sj?lund On Fri, Dec 5, 2014 at 7:32 PM, Brad King wrote: > On 12/05/2014 04:28 AM, Erik Sj?lund wrote: >> The CMake documentation doesn't mention that the order matters: >> http://www.cmake.org/cmake/help/v3.1/command/file.html#command:file >> >> Why does the order of the options in file(GENERATE) matter? > > It was always implemented that way: > > http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmFileCommand.cxx;hb=v3.1.0-rc2#l3421 > > but the order was dropped from the documentation by accident during > reformatting. I've fixed the documentation: > > Help: Document file(GENERATE) signature option order > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fe21580b > > -Brad > From konstantin at podsvirov.pro Fri Dec 5 15:13:38 2014 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Fri, 05 Dec 2014 23:13:38 +0300 Subject: [cmake-developers] [DISCUSSION] Using COMPONENTs for CMake install(...)? In-Reply-To: <54820895.40900@kitware.com> References: <50071417557052@web29o.yandex.ru> <547F298A.8020002@kitware.com> <2931041417672790@web24g.yandex.ru> <54820895.40900@kitware.com> Message-ID: <158731417810418@web3o.yandex.ru> Hi, Brad! 05.12.2014, 22:33, "Brad King" : > On 12/04/2014 12:59 AM, Konstantin Podsvirov wrote: >> In the source tree, you can see some of the components. > > The Debian packaging can serve as a good reference: > > cmake - cross-platform, open-source make system > cmake-curses-gui - curses based user interface for CMake (ccmake) > cmake-data CMake data files (modules, templates and documentation) > cmake-doc - extended documentation in various formats for CMake > cmake-qt-gui - Qt4 based user interface for CMake (cmake-gui) I agree. My way of studying operating systems started with Windows and I spend a lot of time here. Then I was introduced to Linux and chose Debian. >> For example: >> -- tools >> - cmake >> - cpack >> - ctest > > Yes. >> -- scripts >> - modules >> - templates > > These are the Debian "cmake-data" package. >> -- documentation >> - manual >> * html version >> * man pages > > Debian packages the tool man pages with the tools due to their > policy of having documentation available for all commands. > Other manuals are in the separate cmake-doc package. For > interactive installers I think we can keep all the docs in > their own separate packages from the tools since the doc > format could be made selectable. It is understandable. > The html and man pages could be placed in separate install > components too. >> -- according to >> - Qt (only necessary) > > Separate components for each of the "ccmake" and "cmake-gui" > interactive dialogs makes sense. > > With the above guidance please go ahead and work on the patch > if you want. All the install() calls will need to be updated > with the proper COMPONENT option(s). I am interested this task. Perhaps I will start working on my server in a separate branch. I will try to create a graphical installers using CPack IFW generator. At first I plan to submit for debugging and testing the compiled version in Debian stable, and Windows 7. Unfortunately I have no way to test this for Mac. :-( Brad what desktop do you use? >> Also I suggest to add in CMakeLists.txt option to control the >> installation of dependencies with CMake >> For example the Qt library. This happens on Windows and Mac >> but I think it is not always necessary in Linux. > > This is a separate task, so let's focus on the components first. > > -Brad Well. A separate task separate from the main :-) Thank you for writing this letter. I was waiting for him. Regards, Konstantin Podsvirov From rleigh at codelibre.net Sun Dec 7 07:44:37 2014 From: rleigh at codelibre.net (Roger Leigh) Date: Sun, 7 Dec 2014 12:44:37 +0000 Subject: [cmake-developers] suggestion: rename FindXerces to FindXercesC In-Reply-To: <5481BB63.3080604@kitware.com> References: <54807EA5.2060600@kitware.com> <20141204225434.GU1657@codelibre.net> <5481BB63.3080604@kitware.com> Message-ID: <20141207124437.GY1657@codelibre.net> On Fri, Dec 05, 2014 at 09:04:19AM -0500, Brad King wrote: > On 12/04/2014 05:54 PM, Roger Leigh wrote: > > No. Either is fine with me; I didn't expect this to be problematic > > to omit the C suffix, but happy to have it added if it will avoid > > confusion. > > > > I just saw your other mail saying you'd made a patch. Do you need me > > to do anything else? > > Please just test the renamed module to verify it still works for your > original use case (besides the name change). With Erik's confirmation > I will merge this for the next 3.1 release candidate anyway, but more > testing is better ;) I've tested it and it's all working fine, so good to merge from me! -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 From mantis at public.kitware.com Sun Dec 7 17:17:02 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sun, 7 Dec 2014 17:17:02 -0500 Subject: [cmake-developers] [CMake 0015287]: ExternalProject commands do not support generator expressions Message-ID: The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15287 ====================================================================== Reported By: Zachary Sims Assigned To: ====================================================================== Project: CMake Issue ID: 15287 Category: CMake Reproducibility: N/A Severity: feature Priority: normal Status: new ====================================================================== Date Submitted: 2014-12-07 17:17 EST Last Modified: 2014-12-07 17:17 EST ====================================================================== Summary: ExternalProject commands do not support generator expressions Description: ExternalProject_* does not support generator expressions. For projects such as boost, "variant" can be set to debug or release. However, ${CONFIG} will be either Debug or Release (note case). Example being: ExternalProject_Add( boost DOWNLOAD_COMMAND snip SOURCE_DIR # snip BUILD_IN_SOURCE 1 UPDATE_COMMAND "" PATCH_COMMAND "" CONFIGURE_COMMAND ${BOOST_BOOTSTRAP_COMMAND} BUILD_COMMAND b2 variant=$> INSTALL_COMMAND "" LOG_DOWNLOAD 1 LOG_CONFIGURE 1 LOG_BUILD 1 ) It's true the generator expressions might not always be sufficient, but would certainly help. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-12-07 17:17 Zachary Sims New Issue ====================================================================== From konstantin at podsvirov.pro Sun Dec 7 17:34:18 2014 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Mon, 08 Dec 2014 01:34:18 +0300 Subject: [cmake-developers] [DISCUSSION] Using COMPONENTs for CMake install(...)? In-Reply-To: <158731417810418@web3o.yandex.ru> References: <50071417557052@web29o.yandex.ru> <547F298A.8020002@kitware.com> <2931041417672790@web24g.yandex.ru> <54820895.40900@kitware.com> <158731417810418@web3o.yandex.ru> Message-ID: <93911417991658@web27m.yandex.ru> Well, work has started! Here are the first results: http://ifw.podsvirov.pro/cmake/dev/cmake-3.1.20141205-gb0273e-Linux-x86_64.run http://ifw.podsvirov.pro/cmake/dev/cmake-3.1.20141205-g14c9bc-win32-x86.exe The links can be tested offline installers for Linux and Windows. Developments on the subject will post at: http://ifw.podsvirov.pro/cmake/dev The last code in the branch "cmake-install-components" on my server. http://git.podsvirov.pro/?p=kitware/cmake.git;a=shortlog;h=refs/heads/cmake-install-components Added components: - cmake - ctest - cpack - cmake-gui - ccmake - data - sphinx-html - sphinx-singlehtml - sphinx-qthelp CPack IFW generator already knows how to work with these components. Look at the screenshots in this letter, or test the installers to see what group includes these components. There are new tasks: 1. It is necessary to expand the list of components and approve the set with them resources. 2. You must specify the communication between components. 3. For each component you want to specify the display name (short) and description (a little more) 4. You must teach other generators packages to work with components. The first experience has shown that the issues raised in the discussion the question requires centralized control and description. Offer to develop the documentation generated Doxygen is a great basis for creating documentation for developers CMake. In Doxygen, you can create a page with a description of the components. Developers are responsible for creating installers CMake will be able to read this page and to coordinate their actions. Thank you read to the end of the letter. Expect your questions and suggestions! Regards, Konstantin Podsvirov -------------- next part -------------- A non-text attachment was scrubbed... Name: cmake-3.1.20141205-g14c9bc-win32-x86.png Type: image/png Size: 66908 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cmake-3.1.20141205-gb0273e-Linux-x86_64.png Type: image/png Size: 49130 bytes Desc: not available URL: From petteri.lapinlampi at gmail.com Mon Dec 8 00:25:56 2014 From: petteri.lapinlampi at gmail.com (Petteri Lapinlampi) Date: Mon, 8 Dec 2014 07:25:56 +0200 Subject: [cmake-developers] Support for IAR msp430 compiler needed In-Reply-To: <547C84E8.4090506@kitware.com> References: <547C84E8.4090506@kitware.com> Message-ID: On Mon, Dec 1, 2014 at 5:10 PM, Brad King wrote: > On 11/27/2014 02:07 AM, Petteri Lapinlampi wrote: > > I'm trying to use CMake (v3.0.2) in a project utilizing the > > IAR msp430 compiler (icc430.exe). Apparently CMake does not support > > this compiler yet. > > As of CMake 2.8.12 there was some work on IAR support: > > Add support files for C, C++ and ASM for the IAR toolchain. > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=22fb73a0 > > Add Support for IAR compiler > http://www.cmake.org/Bug/view.php?id=10176 > > I don't think anything further has been done since then. Of course > we would be open to contributions of further support and happy to > answer questions along the way. > > Thanks, > -Brad > Thanks, I drafted some changes to the IAR definitions and I'll try to submit a patch after testing that everything works as expected. Cheers, Petteri -------------- next part -------------- An HTML attachment was scrubbed... URL: From mantis at public.kitware.com Mon Dec 8 07:45:04 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Mon, 8 Dec 2014 07:45:04 -0500 Subject: [cmake-developers] [CMake 0015288]: Add XCTest support to Xcode generator Message-ID: <8c91e90cc335b21866133926672ed98b@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15288 ====================================================================== Reported By: Gregor Jasny Assigned To: ====================================================================== Project: CMake Issue ID: 15288 Category: CMake Reproducibility: N/A Severity: feature Priority: normal Status: new ====================================================================== Date Submitted: 2014-12-08 07:45 EST Last Modified: 2014-12-08 07:45 EST ====================================================================== Summary: Add XCTest support to Xcode generator Description: Hello, this prove of concept patch adds support to generate xctest bundles for Xcode. Missing: * Proper error handling * automatic declaration of dependency from xctest -> app * TEST_HOST variable review Thanks, Gregor Steps to Reproduce: {{{ cd Tests/CocoaExample ../../../bin/cmake -G Xcode .. open Project.xcodeproj # to generate Schema Files xcodebuild -project Project.xcodeproj -scheme CocoaExample -destination 'platform=OS X,arch=x86_64' build xcodebuild -project Project.xcodeproj -scheme CocoaExample -destination 'platform=OS X,arch=x86_64' test }}} {{{ Test Suite 'All tests' started at 2014-12-08 12:43:00 +0000 Test Suite 'CocoaExampleTest.xctest' started at 2014-12-08 12:43:00 +0000 Test Suite 'CocoaExampleTests' started at 2014-12-08 12:43:00 +0000 Test Case '-[CocoaExampleTests testExample]' started. Test Case '-[CocoaExampleTests testExample]' passed (0.000 seconds). Test Case '-[CocoaExampleTests testPerformanceExample]' started. /Users/jasny/src/cmake/Tests/CocoaExample/CocoaExampleTests/CocoaExampleTests.m:35: Test Case '-[CocoaExampleTests testPerformanceExample]' measured [Time, seconds] average: 0.000, relative standard deviation: 90.500%, values: [0.000003, 0.000001, 0.000001, 0.000001, 0.000001, 0.000001, 0.000001, 0.000001, 0.000001, 0.000001], performanceMetricID:com.apple.XCTPerformanceMetric_WallClockTime, baselineName: "", baselineAverage: , maxPercentRegression: 10.000%, maxPercentRelativeStandardDeviation: 10.000%, maxRegression: 0.100, maxStandardDeviation: 0.100 Test Case '-[CocoaExampleTests testPerformanceExample]' passed (0.293 seconds). Test Suite 'CocoaExampleTests' passed at 2014-12-08 12:43:00 +0000. Executed 2 tests, with 0 failures (0 unexpected) in 0.293 (0.293) seconds Test Suite 'CocoaExampleTest.xctest' passed at 2014-12-08 12:43:00 +0000. Executed 2 tests, with 0 failures (0 unexpected) in 0.293 (0.294) seconds Test Suite 'All tests' passed at 2014-12-08 12:43:00 +0000. Executed 2 tests, with 0 failures (0 unexpected) in 0.293 (0.295) seconds ** TEST SUCCEEDED ** }}} ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-12-08 07:45 Gregor Jasny New Issue 2014-12-08 07:45 Gregor Jasny File Added: 0002-POC-for-adding-XCTest-targets.patch ====================================================================== From gjasny at googlemail.com Mon Dec 8 07:58:34 2014 From: gjasny at googlemail.com (Gregor Jasny) Date: Mon, 08 Dec 2014 13:58:34 +0100 Subject: [cmake-developers] [CMake 0015288]: Add XCTest support to Xcode generator In-Reply-To: <8c91e90cc335b21866133926672ed98b@www.cmake.org> References: <8c91e90cc335b21866133926672ed98b@www.cmake.org> Message-ID: <5485A07A.9080206@googlemail.com> Hello, what do you think would be the best way to add an XCTest bundle? So far one has to write the following which is error prone: add_library(CocoaExampleTest MODULE ...) set_target_properties(CocoaExampleTest PROPERTIES BUNDLE_EXTENSION xctest BUNDLE TRUE XCTEST TRUE TEST_HOST CocoaExample ) Thanks, Gregor From brad.king at kitware.com Mon Dec 8 09:25:58 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 08 Dec 2014 09:25:58 -0500 Subject: [cmake-developers] [DISCUSSION] Using COMPONENTs for CMake install(...)? In-Reply-To: <93911417991658@web27m.yandex.ru> References: <50071417557052@web29o.yandex.ru> <547F298A.8020002@kitware.com> <2931041417672790@web24g.yandex.ru> <54820895.40900@kitware.com> <158731417810418@web3o.yandex.ru> <93911417991658@web27m.yandex.ru> Message-ID: <5485B4F6.2040104@kitware.com> On 12/07/2014 05:34 PM, Konstantin Podsvirov wrote: > Well, work has started! Good work so far. Please reorganize the commits to have the first one add the install COMPONENT options and the second one add the CPack configuration. > Added components: > - cmake > - ctest > - cpack > - cmake-gui > - ccmake > - data > - sphinx-html > - sphinx-singlehtml > - sphinx-qthelp That looks good, except that "cmake/ctest/cpack" must all be in one component. Each of those three binaries has logic that assumes the other two exist. There should also be a "sphinx-man" group for the man pages. Thanks, -Brad From brad.king at kitware.com Mon Dec 8 09:32:29 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 08 Dec 2014 09:32:29 -0500 Subject: [cmake-developers] [CMake 0015288]: Add XCTest support to Xcode generator In-Reply-To: <5485A07A.9080206@googlemail.com> References: <8c91e90cc335b21866133926672ed98b@www.cmake.org> <5485A07A.9080206@googlemail.com> Message-ID: <5485B67D.7040106@kitware.com> On 12/08/2014 07:58 AM, Gregor Jasny wrote: > what do you think would be the best way to add an XCTest bundle? I'm not very familiar with Xcode-specific things like xctest binaries. Please briefly explain their purpose, how they work, and how developers might use them. How should they be treated on non-Apple platforms? So far I've only xctest in Modules/CMakeDetermineCompilerId.cmake for the compiler identification project for iPhone platforms: Xcode: Fix compiler id detection for iOS tools (#15214) http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c48f6e12 > add_library(CocoaExampleTest MODULE ...) Why is it a MODULE? > BUNDLE_EXTENSION xctest > BUNDLE TRUE These two could be implied by XCTEST as needed. > XCTEST TRUE > TEST_HOST CocoaExample Please explain what each of these does. Thanks, -Brad From mantis at public.kitware.com Mon Dec 8 10:08:07 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Mon, 8 Dec 2014 10:08:07 -0500 Subject: [cmake-developers] [CMake 0015291]: The ExternalProject should use the --depth option when working with git Message-ID: <743f7a1aa6f1840a9641197bc24cf1a7@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15291 ====================================================================== Reported By: Ilya Assigned To: ====================================================================== Project: CMake Issue ID: 15291 Category: CMake Reproducibility: have not tried Severity: feature Priority: normal Status: new ====================================================================== Date Submitted: 2014-12-08 10:08 EST Last Modified: 2014-12-08 10:08 EST ====================================================================== Summary: The ExternalProject should use the --depth option when working with git Description: Right now ExternalProject does full clone of both main repo and its submodules. It doesn't make sense since we're only interested in either most recent version of branch or specific commit. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-12-08 10:08 Ilya New Issue ====================================================================== From mantis at public.kitware.com Mon Dec 8 11:26:09 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Mon, 8 Dec 2014 11:26:09 -0500 Subject: [cmake-developers] [CMake 0015293]: FIND_LIBRARY not working consistently Message-ID: <4f12a39988552b003a05fc5d37e3ff8e@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15293 ====================================================================== Reported By: Gavriloaie Eugen-Andrei Assigned To: ====================================================================== Project: CMake Issue ID: 15293 Category: CMake Reproducibility: always Severity: major Priority: urgent Status: new ====================================================================== Date Submitted: 2014-12-08 11:26 EST Last Modified: 2014-12-08 11:26 EST ====================================================================== Summary: FIND_LIBRARY not working consistently Description: I have a cmake-based project and as part of it I need to build and install a 3rd party library. For this purpose, I have created a shell script which builds and install that library in a certain location. This 3rd party library is autohell based (autotools, autoconf, etc). Logical steps performed inside my cmake script are as follows: 1. Try to use FIND_PATH to locate the header files and FIND_LIBRARY to locate the library. Tolerate the not-found errors at this step 2. If http://public.kitware.com/Bug/view.php?id=1 fails, than I execute that install script which properly installs the 3rd party lib in that location. I can clearly see the headers and the libs under that target folder 3. execute http://public.kitware.com/Bug/view.php?id=1 again, this time not tolerating the errors. Now, FIND_PATH succeeded for the headers files but FIND_LIBRARY fails. Again, the *.a is in place. Further more, if I delete all intermediate files generated by cmake (leaving the 3rd party lib intact) and execute cmake again, http://public.kitware.com/Bug/view.php?id=1 is a success. I suspect that cmake somehow caches the result of FIND_LIBRARY at http://public.kitware.com/Bug/view.php?id=1 and uses it directly at http://public.kitware.com/Bug/view.php?id=3, without really doing any search Steps to Reproduce: I have attached the file which is doing the detect/install/detect-again steps ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-12-08 11:26 Gavriloaie Eugen-AndreiNew Issue 2014-12-08 11:26 Gavriloaie Eugen-AndreiFile Added: Find_usrsctp.cmake ====================================================================== From arekm at maven.pl Mon Dec 8 14:17:53 2014 From: arekm at maven.pl (Arkadiusz =?utf-8?q?Mi=C5=9Bkiewicz?=) Date: Mon, 8 Dec 2014 20:17:53 +0100 Subject: [cmake-developers] [CMake 0015258]: 3.0.2-3.1rc2: _IMPORT_PREFIX always used even if absolute paths are in use - thus breaking build In-Reply-To: <4218505f543a9f127ce918a253fc9bc2@public.kitware.com> References: <4218505f543a9f127ce918a253fc9bc2@public.kitware.com> Message-ID: <201412082017.53522.arekm@maven.pl> On Monday 08 of December 2014, Mantis Bug Tracker wrote: > ---------------------------------------------------------------------- > (0037414) Stephen Kelly (developer) - 2014-12-08 19:46 > http://public.kitware.com/Bug/view.php?id=15258#c37414 > ---------------------------------------------------------------------- > The problem is that you change some relative paths to absolute paths by > setting some variables them on the command line, but you don't set all > necessary paths. You need to set the include dir to an absolute path too. So if I want to override single path then I need to set all of them, always? Also question - /usr/lib64/cmake/KF5CoreAddons/KF5CoreAddonsTargets.cmake comes from package A. Assume that A was built using relative paths. Now there is separate package B that wants to use KF5CoreAddonsTargets.cmake but it also wants to use absolute paths. Is that forbidden (A build using relative, B absolute) then ? If I understand your comment correctly - the way A was built forces the same way on all other software that uses As cmake files. > I added a new diagnostic to recognize this in CMake 3.2. Could you point me to commit, so I'll try to backport? > Removing CMAKE_INSTALL_LIBDIR from your command line might also cause the > correct files to be generated (why are you setting that?). To ensure correct libdir gets used/set the one defined in rpm (package manager), not some kde/cmake one. Also user that uses rpm to build the package is allowed to redefine it like rpm --define '_libdir /blagblah', rpm passes that to cmake at cmdline. > You might want > to discuss some of this stuff on the kde mailing list because apparently > those paths and variables are quite a mess. I'm more interested in corectness from cmake point of view than from kde point of view. Thanks, -- Arkadiusz Mi?kiewicz, arekm / ( maven.pl | pld-linux.org ) From steveire at gmail.com Mon Dec 8 14:38:30 2014 From: steveire at gmail.com (Stephen Kelly) Date: Mon, 08 Dec 2014 20:38:30 +0100 Subject: [cmake-developers] [CMake 0015258]: 3.0.2-3.1rc2: _IMPORT_PREFIX always used even if absolute paths are in use - thus breaking build References: <4218505f543a9f127ce918a253fc9bc2@public.kitware.com> <201412082017.53522.arekm@maven.pl> Message-ID: Arkadiusz Mi?kiewicz wrote: > On Monday 08 of December 2014, Mantis Bug Tracker wrote: > >> ---------------------------------------------------------------------- >> (0037414) Stephen Kelly (developer) - 2014-12-08 19:46 >> http://public.kitware.com/Bug/view.php?id=15258#c37414 >> ---------------------------------------------------------------------- >> The problem is that you change some relative paths to absolute paths by >> setting some variables them on the command line, but you don't set all >> necessary paths. You need to set the include dir to an absolute path too. > > So if I want to override single path then I need to set all of them, > always? The details of this depend on the variables used by the KDE frameworks, eg KDEInstallDirs.cmake. The KDE mailing list might have advice for packagers based on the contents of that file. > Also question - /usr/lib64/cmake/KF5CoreAddons/KF5CoreAddonsTargets.cmake > comes from package A. > > Assume that A was built using relative paths. > > Now there is separate package B that wants to use > KF5CoreAddonsTargets.cmake but it also wants to use absolute paths. That is not a problem. This no-mixing requirement is per-package. > Is > that forbidden (A build using relative, B absolute) then ? If I understand > your comment correctly - the way A was built forces the same way on all > other software that uses As cmake files. This is something you might have to investigate with the KDE list. CMake has no problem with it in principle. >> I added a new diagnostic to recognize this in CMake 3.2. > > Could you point me to commit, so I'll try to backport? You should wait until it is in master, so there's no stable commit to point you to yet. The details of messages etc are being tweaked. > >> Removing CMAKE_INSTALL_LIBDIR from your command line might also cause the >> correct files to be generated (why are you setting that?). > > To ensure correct libdir gets used/set the one defined in rpm (package > manager), not some kde/cmake one. Also user that uses rpm to build the > package is allowed to redefine it like rpm --define '_libdir /blagblah', > rpm passes that to cmake at cmdline. Is there something equivalent for include dirs? > >> You might want >> to discuss some of this stuff on the kde mailing list because apparently >> those paths and variables are quite a mess. > > I'm more interested in corectness from cmake point of view than from kde > point of view. I hope that answers some of your questions. Thanks, Steve. From brad.king at kitware.com Mon Dec 8 14:45:12 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 08 Dec 2014 14:45:12 -0500 Subject: [cmake-developers] [CMake 0015258]: 3.0.2-3.1rc2: _IMPORT_PREFIX always used even if absolute paths are in use - thus breaking build In-Reply-To: References: <4218505f543a9f127ce918a253fc9bc2@public.kitware.com> <201412082017.53522.arekm@maven.pl> Message-ID: <5485FFC8.6020003@kitware.com> On 12/08/2014 02:38 PM, Stephen Kelly wrote: > Arkadiusz Mi?kiewicz wrote: >> On Monday 08 of December 2014, Mantis Bug Tracker wrote: >>> I added a new diagnostic to recognize this in CMake 3.2. >> >> Could you point me to commit, so I'll try to backport? > > You should wait until it is in master, so there's no stable commit to point > you to yet. The details of messages etc are being tweaked. The full change involves a new diagnostic and a new policy. Neither will be considered for backport to 3.1 upstream. Packagers should not backport the new policy but could potentially backport the new warning-only diagnostic if the topic were organized to add the warning first and policy/error in a separate commit. -Brad From arekm at maven.pl Mon Dec 8 17:16:52 2014 From: arekm at maven.pl (Arkadiusz =?utf-8?q?Mi=C5=9Bkiewicz?=) Date: Mon, 8 Dec 2014 23:16:52 +0100 Subject: [cmake-developers] [CMake 0015258]: 3.0.2-3.1rc2: _IMPORT_PREFIX always used even if absolute paths are in use - thus breaking build In-Reply-To: References: <4218505f543a9f127ce918a253fc9bc2@public.kitware.com> <201412082017.53522.arekm@maven.pl> Message-ID: <201412082316.52248.arekm@maven.pl> On Monday 08 of December 2014, Stephen Kelly wrote: > Arkadiusz Mi?kiewicz wrote: > > >> Removing CMAKE_INSTALL_LIBDIR from your command line might also cause > >> the correct files to be generated (why are you setting that?). > > > > To ensure correct libdir gets used/set the one defined in rpm (package > > manager), not some kde/cmake one. Also user that uses rpm to build the > > package is allowed to redefine it like rpm --define '_libdir /blagblah', > > rpm passes that to cmake at cmdline. > > Is there something equivalent for include dirs? Yes, there is but it's not currently passed to cmake. libdir was passed because of lib vs lib64 issue and problems related to it in the past. I could set includedir too but probably there is some other xxxdir that I'm not overriding and the whole problem will appear again, right? (unless there is some way to ensure that all required dirs were set at cmdline time). > >> You might want > >> to discuss some of this stuff on the kde mailing list because apparently > >> those paths and variables are quite a mess. > > > > I'm more interested in corectness from cmake point of view than from kde > > point of view. > > I hope that answers some of your questions. Yes it does. Thanks. > Thanks, > > Steve. -- Arkadiusz Mi?kiewicz, arekm / ( maven.pl | pld-linux.org ) From alex.merry at kde.org Mon Dec 8 17:25:18 2014 From: alex.merry at kde.org (Alex Merry) Date: Mon, 08 Dec 2014 22:25:18 +0000 Subject: [cmake-developers] [CMake 0015258]: 3.0.2-3.1rc2: _IMPORT_PREFIX always used even if absolute paths are in use - thus breaking build In-Reply-To: <201412082316.52248.arekm@maven.pl> References: <4218505f543a9f127ce918a253fc9bc2@public.kitware.com> <201412082316.52248.arekm@maven.pl> Message-ID: <2227143.g7WqfagZKd@kyoshi> On Monday 08 December 2014 23:16:52 Arkadiusz Mi?kiewicz wrote: > On Monday 08 of December 2014, Stephen Kelly wrote: > > Arkadiusz Mi?kiewicz wrote: > > >> Removing CMAKE_INSTALL_LIBDIR from your command line might also cause > > >> the correct files to be generated (why are you setting that?). > > > > > > To ensure correct libdir gets used/set the one defined in rpm (package > > > manager), not some kde/cmake one. Also user that uses rpm to build the > > > package is allowed to redefine it like rpm --define '_libdir /blagblah', > > > rpm passes that to cmake at cmdline. > > > > Is there something equivalent for include dirs? > > Yes, there is but it's not currently passed to cmake. libdir was passed > because of lib vs lib64 issue and problems related to it in the past. > > I could set includedir too but probably there is some other xxxdir that I'm > not overriding and the whole problem will appear again, right? (unless there > is some way to ensure that all required dirs were set at cmdline time). A simpler fix would be to specify a relative path for the libdir (- DCMAKE_INSTALL_LIBDIR=lib64 should work, I believe). If you file a bug against extra-cmake-modules[0], I will investigate issuing a warning in KDEInstallDirs.cmake if you set some of BINDIR, LIBDIR and INCLUDEDIR to relative and some to absolute paths. I should also note the issue in the KDEInstallDirs.cmake documentation. Alex [0]: https://bugs.kde.org/enter_bug.cgi?product=extra-cmake-modules&format=guided From steveire at gmail.com Mon Dec 8 17:42:58 2014 From: steveire at gmail.com (Stephen Kelly) Date: Mon, 08 Dec 2014 23:42:58 +0100 Subject: [cmake-developers] [CMake 0015258]: 3.0.2-3.1rc2: _IMPORT_PREFIX always used even if absolute paths are in use - thus breaking build References: <4218505f543a9f127ce918a253fc9bc2@public.kitware.com> <201412082017.53522.arekm@maven.pl> <201412082316.52248.arekm@maven.pl> Message-ID: Arkadiusz Mi?kiewicz wrote: > On Monday 08 of December 2014, Stephen Kelly wrote: >> Arkadiusz Mi?kiewicz wrote: >> >> >> Removing CMAKE_INSTALL_LIBDIR from your command line might also cause >> >> the correct files to be generated (why are you setting that?). >> > >> > To ensure correct libdir gets used/set the one defined in rpm (package >> > manager), not some kde/cmake one. Also user that uses rpm to build the >> > package is allowed to redefine it like rpm --define '_libdir >> > /blagblah', rpm passes that to cmake at cmdline. >> >> Is there something equivalent for include dirs? > > Yes, there is but it's not currently passed to cmake. libdir was passed > because of lib vs lib64 issue and problems related to it in the past. You also pass -DLIB_SUFFIX=64. *Something* is redundant. > I could set includedir too but probably there is some other xxxdir that > I'm not overriding and the whole problem will appear again, right? Please help my understanding: You justify passing the value of libdir because a user should be allowed to set it with rpm --define and you want to pass it along. However, if the user uses rpm --define to set the includedir, you don't pass it along, correct? Why not? I don't know if the problem would appear again with other paths/options. It is probably decreasingly likely after fixing the includedir. INTERFACE_INCLUDE_DIRECTORIES in IMPORTED targets is quite a new concept, but it will likely get widespread use. Are there guidelines for creating rpms? Eg, can you point me to a guideline which says users should be able to pass 'rpm --define libdir ...'? Or is that kind of guideline only learned by doing but not written down? Thanks, Steve. From mantis at public.kitware.com Mon Dec 8 20:50:28 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Mon, 8 Dec 2014 20:50:28 -0500 Subject: [cmake-developers] [CMake 0015294]: FASTBuild generator Message-ID: <6dd46804997b4450d354a458655fbd6b@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15294 ====================================================================== Reported By: Jeremie Delaitre Assigned To: ====================================================================== Project: CMake Issue ID: 15294 Category: CMake Reproducibility: N/A Severity: feature Priority: low Status: new ====================================================================== Date Submitted: 2014-12-08 20:50 EST Last Modified: 2014-12-08 20:50 EST ====================================================================== Summary: FASTBuild generator Description: I just discovered FASTBuild (http://www.fastbuild.org) after watching the CPPcon talk: https://www.youtube.com/watch?v=qYN6eduU06s It seems to dramatically increase build time on Windows (and hopefully soon on other OSes...) using several different features like: - "unity" builds (pack several cpp files in one) - distributed build - cache I saw a question on the ML asking if a generator for FASTBuild is on the work but I thought having a proper feature request in the tracker would be better ;) ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-12-08 20:50 Jeremie DelaitreNew Issue ====================================================================== From arekm at maven.pl Tue Dec 9 02:34:23 2014 From: arekm at maven.pl (Arkadiusz =?utf-8?q?Mi=C5=9Bkiewicz?=) Date: Tue, 9 Dec 2014 08:34:23 +0100 Subject: [cmake-developers] [CMake 0015258]: 3.0.2-3.1rc2: _IMPORT_PREFIX always used even if absolute paths are in use - thus breaking build In-Reply-To: References: <4218505f543a9f127ce918a253fc9bc2@public.kitware.com> <201412082316.52248.arekm@maven.pl> Message-ID: <201412090834.23677.arekm@maven.pl> On Monday 08 of December 2014, Stephen Kelly wrote: > Arkadiusz Mi?kiewicz wrote: > > On Monday 08 of December 2014, Stephen Kelly wrote: > >> Arkadiusz Mi?kiewicz wrote: > >> >> Removing CMAKE_INSTALL_LIBDIR from your command line might also cause > >> >> the correct files to be generated (why are you setting that?). > >> > > >> > To ensure correct libdir gets used/set the one defined in rpm (package > >> > manager), not some kde/cmake one. Also user that uses rpm to build the > >> > package is allowed to redefine it like rpm --define '_libdir > >> > /blagblah', rpm passes that to cmake at cmdline. > >> > >> Is there something equivalent for include dirs? > > > > Yes, there is but it's not currently passed to cmake. libdir was passed > > because of lib vs lib64 issue and problems related to it in the past. > > You also pass -DLIB_SUFFIX=64. *Something* is redundant. This is "one fits for all" type of setting. I remember that there were apps that used LIBDIR but didn't use LIB_SUFFIX while the other apps were using LIB_SUFFIX. So setting both defines made both apps happy. > > I could set includedir too but probably there is some other xxxdir that > > I'm not overriding and the whole problem will appear again, right? > > Please help my understanding: > > You justify passing the value of libdir because a user should be allowed to > set it with rpm --define and you want to pass it along. However, if the > user uses rpm --define to set the includedir, you don't pass it along, > correct? > > Why not? libdir setting was needed due to lib vs lib64 issues there was no such issues with includedir. That's the only reason why libdir is set using rpm macro while includedir is not. But you are right, this is not consistent and user trying to set includedir using rpm --define would fail for cmake case. > I don't know if the problem would appear again with other paths/options. It > is probably decreasingly likely after fixing the includedir. > INTERFACE_INCLUDE_DIRECTORIES in IMPORTED targets is quite a new concept, > but it will likely get widespread use. > > Are there guidelines for creating rpms? Eg, can you point me to a guideline > which says users should be able to pass 'rpm --define libdir ...'? Or is > that kind of guideline only learned by doing but not written down? There are no guidelines regarding rpm macros unfortunately. Every distro uses these in their own way. With autoconf for example there is much more set from rpm side like: [...]/configure %{_target_platform} --prefix=%{_prefix} --exec- prefix=%{_exec_prefix} --bindir=%{_bindir} --sbindir=%{_sbindir} -- sysconfdir=%{_sysconfdir} --datadir=%{_datadir} --includedir=%{_includedir} -- libdir=%{_libdir} --libexecdir=%{_libexecdir} -- localstatedir=%{_localstatedir} --sharedstatedir=%{_sharedstatedir} -- mandir=%{_mandir} --infodir=%{_infodir} Not sure while cmake got only few dirs set here: %{__cmake} \ -DCMAKE_VERBOSE_MAKEFILE=ON \ -DCMAKE_BUILD_TYPE=%{!?debug:PLD}%{?debug:Debug} \ -DCMAKE_INSTALL_LIBDIR:PATH=%{_libdir} \ -DCMAKE_INSTALL_PREFIX:PATH=%{_prefix} \ -DSYSCONF_INSTALL_DIR:PATH=%{_sysconfdir} \ -DCMAKE_CXX_FLAGS_PLD="${CXXFLAGS:-%{rpmcxxflags} -DNDEBUG - DQT_NO_DEBUG}" \ -DCMAKE_C_FLAGS_PLD="${CFLAGS:-%{rpmcflags} -DNDEBUG -DQT_NO_DEBUG}" \ -DCMAKE_Fortran_FLAGS_PLD="${CFLAGS:-%{rpmcflags} -DNDEBUG - DQT_NO_DEBUG}" \ -DCMAKE_EXE_LINKER_FLAGS_PLD="${LDFLAGS:-%{rpmldflags}}" \ -DCMAKE_SHARED_LINKER_FLAGS_PLD="${LDFLAGS:-%{rpmldflags}}" \ -DCMAKE_MODULE_LINKER_FLAGS_PLD="${LDFLAGS:-%{rpmldflags}}" \ %if "%{_lib}" == "lib64" -DLIB_SUFFIX=64 \ %endif -DBUILD_SHARED_LIBS:BOOL=ON \ %{nil} Anyway I'm closer to solving this here in generic and hopefuly correct way. > Thanks, > Steve. Thanks, -- Arkadiusz Mi?kiewicz, arekm / ( maven.pl | pld-linux.org ) From mantis at public.kitware.com Tue Dec 9 05:30:25 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 9 Dec 2014 05:30:25 -0500 Subject: [cmake-developers] [CMake 0015295]: CMake should not concatenate commands for cmd.exe Message-ID: <4a2a5070834de3f25efadd0e398f0df4@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15295 ====================================================================== Reported By: Ilya Assigned To: ====================================================================== Project: CMake Issue ID: 15295 Category: CMake Reproducibility: always Severity: major Priority: high Status: new ====================================================================== Date Submitted: 2014-12-09 05:30 EST Last Modified: 2014-12-09 05:30 EST ====================================================================== Summary: CMake should not concatenate commands for cmd.exe Description: Commands like add_custom_target allows to specify many COMMAND parameters. On windows it concatenates all values into one big command and then passes to cmd.exe Unfortunately cmd.exe has limit of the length of a command that can be passed: 8192. Therefore CMake should not attempt to concatenate but pass commands to cmd.exe one by one. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-12-09 05:30 Ilya New Issue ====================================================================== From gjasny at googlemail.com Tue Dec 9 06:02:23 2014 From: gjasny at googlemail.com (Gregor Jasny) Date: Tue, 9 Dec 2014 12:02:23 +0100 Subject: [cmake-developers] [PATCH 0/2] XCTest support In-Reply-To: <5485B67D.7040106@kitware.com> References: <5485B67D.7040106@kitware.com> Message-ID: Hi Brad, > I'm not very familiar with Xcode-specific things like xctest binaries. > Please briefly explain their purpose, how they work, and how developers > might use them. How should they be treated on non-Apple platforms? XCTest is Apples latest idea of how to write Unit Tests for App Bundles and Frameworks. Xcode itself provides nice integration within the IDE to run and examine tests. There are also some 3rd party drivers for Google Test available. See: https://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/testing_with_xcode/ XCTest bundles are regular CFBundles with a special product type and suffix. They contain just the Unit Test code and get loaded directly into the target under test (the test host). On non-Apple platforms and Xcode < 5.0 those XCTest bundles are pretty useless. >> add_library(CocoaExampleTest MODULE ...) > Why is it a MODULE? Because they need to be a Bundle. And you need to build a MODULE library to get that. >> BUNDLE_EXTENSION xctest >> BUNDLE TRUE > These two could be implied by XCTEST as needed. Done. >> XCTEST TRUE >> XCTEST_HOST CocoaExample > Please explain what each of these does. XCTEST is just the property to mark a MODULE library as an XCTest Bundle. XCTEST_HOST is the target name of the App Bundle or Framework this test is intended for. I made the observation that if you omit the TEST_HOST and BUNDLE_LOADER properties in the Xcode project file, then Xcode is not very fault tolerant and crashes. That's why I enforce them or error out. Note: It is currently not possible to run the tests without opening Xcode once to (auto) generate the Schema files. Otherwise calling "xcodebuild test -scheme CocoaExample" will not recognise the scheme. Thanks, Gregor Gregor Jasny (2): Add handling for XCTest bundles Add XCTest Example Help/manual/cmake-properties.7.rst | 2 + Help/prop_tgt/XCTEST.rst | 9 + Help/prop_tgt/XCTEST_HOST.rst | 5 + Source/cmGlobalXCodeGenerator.cxx | 62 +- Source/cmTarget.cxx | 19 +- Source/cmTarget.h | 3 + Tests/CocoaExample/CMakeLists.txt | 25 + Tests/CocoaExample/CocoaExample/AppDelegate.h | 7 + Tests/CocoaExample/CocoaExample/AppDelegate.m | 18 + Tests/CocoaExample/CocoaExample/Info.plist.in | 32 + Tests/CocoaExample/CocoaExample/MainMenu.xib | 680 +++++++++++++++++++++ Tests/CocoaExample/CocoaExample/main.m | 5 + .../CocoaExampleTests/CocoaExampleTests.m | 13 + 13 files changed, 875 insertions(+), 5 deletions(-) create mode 100644 Help/prop_tgt/XCTEST.rst create mode 100644 Help/prop_tgt/XCTEST_HOST.rst create mode 100644 Tests/CocoaExample/CMakeLists.txt create mode 100644 Tests/CocoaExample/CocoaExample/AppDelegate.h create mode 100644 Tests/CocoaExample/CocoaExample/AppDelegate.m create mode 100644 Tests/CocoaExample/CocoaExample/Info.plist.in create mode 100644 Tests/CocoaExample/CocoaExample/MainMenu.xib create mode 100644 Tests/CocoaExample/CocoaExample/main.m create mode 100644 Tests/CocoaExample/CocoaExampleTests/CocoaExampleTests.m -- 1.9.3 (Apple Git-50) From gjasny at googlemail.com Tue Dec 9 06:02:24 2014 From: gjasny at googlemail.com (Gregor Jasny) Date: Tue, 9 Dec 2014 12:02:24 +0100 Subject: [cmake-developers] [PATCH 1/2] Add handling for XCTest bundles In-Reply-To: References: Message-ID: <1ecf805f8d938a1272e2827b2760fd68eb4bcc54.1418121897.git.gjasny@googlemail.com> An XCTest bundle is a CFBundle with a special product-type and bundle extension. It gets loaded directly into the AppBundle or Framework it should test. For more information about XCTest visit the Mac Developer library at: http://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/testing_with_xcode/ To build a XCTest bundle, you need to create a CFBundle and set the XCTEST property. Additionally you need to specify the application or framework target to test within the XCTEST_HOST property. CMake and Xcode will then setup the correct target dependencies. add_library(CocoaExampleTest MODULE ...) set_target_properties(CocoaExampleTest PROPERTIES XCTEST TRUE XCTEST_HOST CocoaExample) Signed-off-by: Gregor Jasny --- Help/manual/cmake-properties.7.rst | 2 ++ Help/prop_tgt/XCTEST.rst | 9 ++++++ Help/prop_tgt/XCTEST_HOST.rst | 5 +++ Source/cmGlobalXCodeGenerator.cxx | 62 ++++++++++++++++++++++++++++++++++++-- Source/cmTarget.cxx | 19 ++++++++++-- Source/cmTarget.h | 3 ++ 6 files changed, 95 insertions(+), 5 deletions(-) create mode 100644 Help/prop_tgt/XCTEST.rst create mode 100644 Help/prop_tgt/XCTEST_HOST.rst diff --git a/Help/manual/cmake-properties.7.rst b/Help/manual/cmake-properties.7.rst index cca6d28..7b8aa66 100644 --- a/Help/manual/cmake-properties.7.rst +++ b/Help/manual/cmake-properties.7.rst @@ -242,6 +242,8 @@ Properties on Targets /prop_tgt/VS_WINRT_REFERENCES /prop_tgt/WIN32_EXECUTABLE /prop_tgt/XCODE_ATTRIBUTE_an-attribute + /prop_tgt/XCTEST + /prop_tgt/XCTEST_HOST Properties on Tests =================== diff --git a/Help/prop_tgt/XCTEST.rst b/Help/prop_tgt/XCTEST.rst new file mode 100644 index 0000000..8a60ad8 --- /dev/null +++ b/Help/prop_tgt/XCTEST.rst @@ -0,0 +1,9 @@ +XCTEST +------ + +This target is a XCTest CFBundle on the Mac. + +If a module library target has this property set to true it will be +built as a CFBundle when built on the mac. It will have the directory +structure required for a CFBundle and will be suitable to be used for +creating Browser Plugins or other application resources. diff --git a/Help/prop_tgt/XCTEST_HOST.rst b/Help/prop_tgt/XCTEST_HOST.rst new file mode 100644 index 0000000..064dbf7 --- /dev/null +++ b/Help/prop_tgt/XCTEST_HOST.rst @@ -0,0 +1,5 @@ +XCTEST_HOST +----------- + +XCTest works by injecting an XCTest CFBundle directly into an AppBundle +or Framework. This property names this destination target under test. \ No newline at end of file diff --git a/Source/cmGlobalXCodeGenerator.cxx b/Source/cmGlobalXCodeGenerator.cxx index d222288..a88350f 100644 --- a/Source/cmGlobalXCodeGenerator.cxx +++ b/Source/cmGlobalXCodeGenerator.cxx @@ -493,6 +493,15 @@ cmGlobalXCodeGenerator::AddExtraTargets(cmLocalGenerator* root, allbuild->AddUtility(target.GetName()); } + if(target.IsXCTestOnApple()) + { + const char *testHostName = target.GetProperty("XCTEST_HOST"); + if(testHostName && this->CurrentMakefile->FindTargetToUse(testHostName)) + { + target.AddUtility(testHostName); + } + } + // Refer to the build configuration file for easy editing. listfile = lg->GetMakefile()->GetStartDirectory(); listfile += "/"; @@ -761,6 +770,10 @@ GetSourcecodeValueFromFileExtension(const std::string& _ext, { sourcecode = "compiled.mach-o.objfile"; } + else if(ext == "xctest") + { + sourcecode = "wrapper.cfbundle"; + } else if(ext == "xib") { keepLastKnownFileType = true; @@ -1964,7 +1977,7 @@ void cmGlobalXCodeGenerator::CreateBuildSettings(cmTarget& target, { buildSettings->AddAttribute("LIBRARY_STYLE", this->CreateString("BUNDLE")); - if (target.GetPropertyAsBool("BUNDLE")) + if (target.IsCFBundleOnApple()) { // It turns out that a BUNDLE is basically the same // in many ways as an application bundle, as far as @@ -2360,6 +2373,45 @@ void cmGlobalXCodeGenerator::CreateBuildSettings(cmTarget& target, buildSettings->AddAttribute("DYLIB_COMPATIBILITY_VERSION", this->CreateString(vso.str().c_str())); } + + if(target.IsXCTestOnApple()) + { + if(this->XcodeVersion < 50) + { + this->CurrentMakefile->IssueMessage(cmake::WARNING, + "Xcode 5.0 or later is required for XCTEST support."); + } + + const char *testHostName = target.GetProperty("XCTEST_HOST"); + if(!testHostName) + { + cmSystemTools::Error("target has XCTEST property " + "but no XCTEST_HOST one."); + return; + } + + cmTarget *testHostTarget = + this->CurrentMakefile->FindTargetToUse(testHostName); + if(!testHostTarget) + { + cmSystemTools::Error("Cannot find XCTEST_HOST target: ", testHostName); + return; + } + + if (!testHostTarget->IsAppBundleOnApple() && + !testHostTarget->IsFrameworkOnApple()) + { + cmSystemTools::Error("XCTEST_HOST target is not a Framework " + "or App Bundle: ", testHostName); + return; + } + + buildSettings->AddAttribute("BUNDLE_LOADER", + this->CreateString("$(TEST_HOST)")); + buildSettings->AddAttribute("TEST_HOST", + this->CreateString(testHostTarget->GetLocationForBuild())); + } + // put this last so it can override existing settings // Convert "XCODE_ATTRIBUTE_*" properties directly. { @@ -2558,7 +2610,9 @@ const char* cmGlobalXCodeGenerator::GetTargetFileType(cmTarget& cmtarget) case cmTarget::STATIC_LIBRARY: return "archive.ar"; case cmTarget::MODULE_LIBRARY: - if (cmtarget.IsCFBundleOnApple()) + if (cmtarget.IsXCTestOnApple()) + return "wrapper.cfbundle"; + else if (cmtarget.IsCFBundleOnApple()) return "wrapper.plug-in"; else return ((this->XcodeVersion >= 22)? @@ -2582,7 +2636,9 @@ const char* cmGlobalXCodeGenerator::GetTargetProductType(cmTarget& cmtarget) case cmTarget::STATIC_LIBRARY: return "com.apple.product-type.library.static"; case cmTarget::MODULE_LIBRARY: - if (cmtarget.IsCFBundleOnApple()) + if (cmtarget.IsXCTestOnApple()) + return "com.apple.product-type.bundle.unit-test"; + else if (cmtarget.IsCFBundleOnApple()) return "com.apple.product-type.bundle"; else return ((this->XcodeVersion >= 22)? diff --git a/Source/cmTarget.cxx b/Source/cmTarget.cxx index f0957d0..ff52d4a 100644 --- a/Source/cmTarget.cxx +++ b/Source/cmTarget.cxx @@ -624,7 +624,15 @@ bool cmTarget::IsCFBundleOnApple() const { return (this->GetType() == cmTarget::MODULE_LIBRARY && this->Makefile->IsOn("APPLE") && - this->GetPropertyAsBool("BUNDLE")); + (this->GetPropertyAsBool("BUNDLE") || + this->GetPropertyAsBool("XCTEST"))); +} + +//---------------------------------------------------------------------------- +bool cmTarget::IsXCTestOnApple() const +{ + return (this->IsCFBundleOnApple() && + this->GetPropertyAsBool("XCTEST")); } //---------------------------------------------------------------------------- @@ -4061,7 +4069,14 @@ void cmTarget::GetFullNameInternal(const std::string& config, const char *ext = this->GetProperty("BUNDLE_EXTENSION"); if (!ext) { - ext = "bundle"; + if (this->IsXCTestOnApple()) + { + ext = "xctest"; + } + else + { + ext = "bundle"; + } } fw_prefix += ext; fw_prefix += "/Contents/MacOS/"; diff --git a/Source/cmTarget.h b/Source/cmTarget.h index a3ecca0..5786d78 100644 --- a/Source/cmTarget.h +++ b/Source/cmTarget.h @@ -526,6 +526,9 @@ public: /** Return whether this target is a CFBundle (plugin) on Apple. */ bool IsCFBundleOnApple() const; + /** Return whether this target is a XCTest on Apple. */ + bool IsXCTestOnApple() const; + /** Return whether this target is an executable Bundle on Apple. */ bool IsAppBundleOnApple() const; -- 1.9.3 (Apple Git-50) From gjasny at googlemail.com Tue Dec 9 06:02:25 2014 From: gjasny at googlemail.com (Gregor Jasny) Date: Tue, 9 Dec 2014 12:02:25 +0100 Subject: [cmake-developers] [PATCH 2/2] Add XCTest Example In-Reply-To: References: Message-ID: <2b40c4939134f97104bcb913d407ecdda6f02fd8.1418121897.git.gjasny@googlemail.com> This test builds an trivial Cocoa App Bundle and an XCTest Bundle. After project generation open it in Xcode and 'Test' the project. Signed-off-by: Gregor Jasny --- Tests/CocoaExample/CMakeLists.txt | 25 + Tests/CocoaExample/CocoaExample/AppDelegate.h | 7 + Tests/CocoaExample/CocoaExample/AppDelegate.m | 18 + Tests/CocoaExample/CocoaExample/Info.plist.in | 32 + Tests/CocoaExample/CocoaExample/MainMenu.xib | 680 +++++++++++++++++++++ Tests/CocoaExample/CocoaExample/main.m | 5 + .../CocoaExampleTests/CocoaExampleTests.m | 13 + 7 files changed, 780 insertions(+) create mode 100644 Tests/CocoaExample/CMakeLists.txt create mode 100644 Tests/CocoaExample/CocoaExample/AppDelegate.h create mode 100644 Tests/CocoaExample/CocoaExample/AppDelegate.m create mode 100644 Tests/CocoaExample/CocoaExample/Info.plist.in create mode 100644 Tests/CocoaExample/CocoaExample/MainMenu.xib create mode 100644 Tests/CocoaExample/CocoaExample/main.m create mode 100644 Tests/CocoaExample/CocoaExampleTests/CocoaExampleTests.m diff --git a/Tests/CocoaExample/CMakeLists.txt b/Tests/CocoaExample/CMakeLists.txt new file mode 100644 index 0000000..b254a85 --- /dev/null +++ b/Tests/CocoaExample/CMakeLists.txt @@ -0,0 +1,25 @@ +cmake_minimum_required(VERSION 3.1) + +project(CocoaExample) + +add_executable(CocoaExample MACOSX_BUNDLE + CocoaExample/main.m + CocoaExample/AppDelegate.m + CocoaExample/AppDelegate.h + CocoaExample/MainMenu.xib +) + +target_link_libraries(CocoaExample "-framework Foundation" "-framework AppKit") + +set_target_properties(CocoaExample PROPERTIES + MACOSX_BUNDLE_INFO_PLIST ${CMAKE_CURRENT_SOURCE_DIR}/CocoaExample/Info.plist.in + RESOURCE "CocoaExample/MainMenu.xib") + +add_library(CocoaExampleTest MODULE + CocoaExampleTests/CocoaExampleTests.m +) + +set_target_properties(CocoaExampleTest PROPERTIES + XCTEST TRUE + XCTEST_HOST CocoaExample +) diff --git a/Tests/CocoaExample/CocoaExample/AppDelegate.h b/Tests/CocoaExample/CocoaExample/AppDelegate.h new file mode 100644 index 0000000..69b6e0f --- /dev/null +++ b/Tests/CocoaExample/CocoaExample/AppDelegate.h @@ -0,0 +1,7 @@ +#import + + at interface AppDelegate : NSObject + + + at end + diff --git a/Tests/CocoaExample/CocoaExample/AppDelegate.m b/Tests/CocoaExample/CocoaExample/AppDelegate.m new file mode 100644 index 0000000..07af62f --- /dev/null +++ b/Tests/CocoaExample/CocoaExample/AppDelegate.m @@ -0,0 +1,18 @@ +#import "AppDelegate.h" + + at interface AppDelegate () + + at property (assign) IBOutlet NSWindow *window; + at end + + at implementation AppDelegate + +- (void)applicationDidFinishLaunching:(NSNotification *)aNotification { + // Insert code here to initialize your application +} + +- (void)applicationWillTerminate:(NSNotification *)aNotification { + // Insert code here to tear down your application +} + + at end diff --git a/Tests/CocoaExample/CocoaExample/Info.plist.in b/Tests/CocoaExample/CocoaExample/Info.plist.in new file mode 100644 index 0000000..3814d1d --- /dev/null +++ b/Tests/CocoaExample/CocoaExample/Info.plist.in @@ -0,0 +1,32 @@ + + + + + CFBundleDevelopmentRegion + en + CFBundleExecutable + $(EXECUTABLE_NAME) + CFBundleIconFile + + CFBundleIdentifier + org.cmake.test.$(PRODUCT_NAME:rfc1034identifier) + CFBundleInfoDictionaryVersion + 6.0 + CFBundleName + $(PRODUCT_NAME) + CFBundlePackageType + APPL + CFBundleShortVersionString + 1.0 + CFBundleSignature + ???? + CFBundleVersion + 1 + LSMinimumSystemVersion + $(MACOSX_DEPLOYMENT_TARGET) + NSMainNibFile + MainMenu + NSPrincipalClass + NSApplication + + diff --git a/Tests/CocoaExample/CocoaExample/MainMenu.xib b/Tests/CocoaExample/CocoaExample/MainMenu.xib new file mode 100644 index 0000000..9498a0a --- /dev/null +++ b/Tests/CocoaExample/CocoaExample/MainMenu.xib @@ -0,0 +1,680 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Default + + + + + + + Left to Right + + + + + + + Right to Left + + + + + + + + + + + Default + + + + + + + Left to Right + + + + + + + Right to Left + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/Tests/CocoaExample/CocoaExample/main.m b/Tests/CocoaExample/CocoaExample/main.m new file mode 100644 index 0000000..8a6799b --- /dev/null +++ b/Tests/CocoaExample/CocoaExample/main.m @@ -0,0 +1,5 @@ +#import + +int main(int argc, const char * argv[]) { + return NSApplicationMain(argc, argv); +} diff --git a/Tests/CocoaExample/CocoaExampleTests/CocoaExampleTests.m b/Tests/CocoaExample/CocoaExampleTests/CocoaExampleTests.m new file mode 100644 index 0000000..70d61d6 --- /dev/null +++ b/Tests/CocoaExample/CocoaExampleTests/CocoaExampleTests.m @@ -0,0 +1,13 @@ +#import + + at interface CocoaExampleTests : XCTestCase + + at end + + at implementation CocoaExampleTests + +- (void)testExample { + XCTAssert(YES, @"Pass"); +} + + at end -- 1.9.3 (Apple Git-50) From alinm.elena at gmail.com Tue Dec 9 06:59:15 2014 From: alinm.elena at gmail.com (Alin Marin Elena) Date: Tue, 9 Dec 2014 11:59:15 +0000 Subject: [cmake-developers] FindMPI take 2 Message-ID: Dear All, recently I have run into some issues with FindMPI and intel mpi[1], more intel mpi issue rather than cmake. The original issue reported in[1] was solved. However in the process I made few points related mainly to FindMPI, that I summarise in here: 1. the linker information is not parsed, see below 2. Failure to use the wrapper as a compiler. 3. Using wrong wrappers to interrogate for intel mpi and intel compilers. eg. mpif90 instead of mpiifort (NB: If a user uses I_MPI_F90=ifort, or c/c++ equivalents this issue is somehow mittigated) 1. Linker issue -- MPI_C_INCLUDE_PATH /ichec/packages/intel/intel-cluster-studio-2015/impi_5.0.1/intel64/include -- MPI_C_LINK_FLAGS -- MPI_C_LIBRARIES /ichec/packages/intel/intel-cluster-studio-2015/impi_5.0.1/intel64/lib/libmpifort.so;/ichec/packages/intel/intel-cluster-studio-2015/impi_5.0.1/intel64/lib/release/libmpi.so;/ichec/packages/intel/intel-cluster-studio-2015/impi_5.0.1/intel64/lib/libmpigi.a;/usr/lib64/libdl.so;/usr/lib64/librt.so;/usr/lib64/libpthread.so -- Configuring done -- Generating done -- Build files have been written to: /ichec/home/staff/alin/findmpi/5.0.1 [alin at fionn2:~/findmpi/5.0.1]: mpicc -compile-info gcc -I/ichec/packages/intel/intel-cluster-studio-2015/impi_5.0.1/intel64/include -L/ichec/packages/intel/intel-cluster-studio-2015/impi_5.0.1/intel64/lib/release -L/ichec/packages/intel/intel-cluster-studio-2015/impi_5.0.1/intel64/lib -Xlinker --enable-new-dtags -Xlinker -rpath -Xlinker /ichec/packages/intel/intel-cluster-studio-2015/impi_5.0.1/intel64/lib/release -Xlinker -rpath -Xlinker /ichec/packages/intel/intel-cluster-studio-2015/impi_5.0.1/intel64/lib -Xlinker -rpath -Xlinker /opt/intel/mpi-rt/5.0/intel64/lib/release -Xlinker -rpath -Xlinker /opt/intel/mpi-rt/5.0/intel64/lib -lmpifort -lmpi -lmpigi -ldl -lrt -lpthread Patch attached 0001-correctly-detect-MPI-linker-flags-for-Intel-MPI-mayb.patch 2. We first use whatever is provided in FC to detect the libs/includes/linker flags. I think the correct order shall be first check if what is provided in FC build mpi binaries, if fails go to interrogation. patch attached 0002-first-try-to-see-if-what-user-provided-produces-an-m.patch 3. This is a more complex issue and my understanding is that FindMPI was designed with mpicc/mpicxx/mpif90 being the workhorse wrappers for MPI. While I do not propose to change that I think that implementing the change at 2. will somehow mitigate the case of multiple wrappers and compilers. [1] http://www.cmake.org/Bug/view.php?id=15182 Without Questions there are no Answers! ______________________________________________________________________ Dr. Alin Marin ELENA http://alin.elenaworld.net/ ______________________________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-correctly-detect-MPI-linker-flags-for-Intel-MPI-mayb.patch Type: text/x-diff Size: 1277 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-first-try-to-see-if-what-user-provided-produces-an-m.patch Type: text/x-diff Size: 2341 bytes Desc: not available URL: From daniel at constexpr.org Tue Dec 9 09:40:45 2014 From: daniel at constexpr.org (Daniel Scharrer) Date: Tue, 09 Dec 2014 15:40:45 +0100 Subject: [cmake-developers] [PATCH] FindQt4: Fix handling of QT_VERSION_MAJOR mismatch Message-ID: <548709ED.7060604@constexpr.org> This caused find_package(Qt4) to appear successful when it was not. Note that the legacy QT4_FOUND variable is unconditionally overwritten at the end of the file with the value of Qt4_FOUND. --- Modules/FindQt4.cmake | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Modules/FindQt4.cmake b/Modules/FindQt4.cmake index a79246a..11091b5 100644 --- a/Modules/FindQt4.cmake +++ b/Modules/FindQt4.cmake @@ -1321,7 +1321,7 @@ endif() if (NOT QT_VERSION_MAJOR EQUAL 4) set(VERSION_MSG "Found unsuitable Qt version \"${QTVERSION}\" from ${QT_QMAKE_EXECUTABLE}") - set(QT4_FOUND FALSE) + set(Qt4_FOUND FALSE) if(Qt4_FIND_REQUIRED) message( FATAL_ERROR "${VERSION_MSG}, this code requires Qt 4.x") else() -- 2.2.0 From pascal.bach at siemens.com Tue Dec 9 09:45:48 2014 From: pascal.bach at siemens.com (Bach, Pascal) Date: Tue, 9 Dec 2014 14:45:48 +0000 Subject: [cmake-developers] [PATCH] VS, WINCE: Fix entry point for Unicode builds In-Reply-To: <547F2847.9060703@kitware.com> References: <1417523622-26389-1-git-send-email-pascal.bach@siemens.com> <547DCDEF.2050009@kitware.com> <547F2847.9060703@kitware.com> Message-ID: <355BE46A91031048906B695426A8D8E616B0E3B6@DEFTHW99EH4MSX.ww902.siemens.net> > Fixed typo in commit message: > > VS, WINCE: Fix entry point for Unicode builds > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=681cda02 > I figured out that the combination /ENTRY:mainCRTStartup is also possible even if UNICODE is enabled. The question is now what should CMake do as default. 1) With the patch applied the behavior is as follows: The default entry points are mainCRTStartup (non Unicode) and mainWCRTStartup (for Unicode). So this means as soon as "UNICODE" is set the default Visual Studio is looking for wmain instead of main. If the user wants to change back to main he has to do something like this: set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} /ENTRY:mainCRTStartup" ) 2) Without my patch: The default entry point is mainCRTStartup (for both non Unicode and Unicode). So if UNICODE is set this doesn't change anything. If the user wants to use wmain he has to do something like this: set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} /ENTRY:mainWCRTStartup" ) I'm not sure what is better. I almost think the old behavior was better. The user should then be able to set the entry point independent of the UNICODE setting via a target property. This would be similar to how WIN32_EXECUTABLE selects WinMain as startup. Any thoughts on this? Pascal From brad.king at kitware.com Tue Dec 9 10:40:05 2014 From: brad.king at kitware.com (Brad King) Date: Tue, 09 Dec 2014 10:40:05 -0500 Subject: [cmake-developers] [PATCH] VS, WINCE: Fix entry point for Unicode builds In-Reply-To: <355BE46A91031048906B695426A8D8E616B0E3B6@DEFTHW99EH4MSX.ww902.siemens.net> References: <1417523622-26389-1-git-send-email-pascal.bach@siemens.com> <547DCDEF.2050009@kitware.com> <547F2847.9060703@kitware.com> <355BE46A91031048906B695426A8D8E616B0E3B6@DEFTHW99EH4MSX.ww902.siemens.net> Message-ID: <548717D5.5010601@kitware.com> On 12/09/2014 09:45 AM, Bach, Pascal wrote: > the old behavior was better. The user should then be able to set the > entry point independent of the UNICODE setting via a target property. > This would be similar to how WIN32_EXECUTABLE selects WinMain as startup. Good catch. They are orthogonal settings. I've reverted the change: Revert "VS, WINCE: Fix entry point for Unicode builds" http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=df01a380 Unfortunately original change is in the v3.1.0-rc3 tag. This is why I don't like taking non-regression changes after the feature freeze for a release. I took it because I thought it was a bug in the new WinCE support. Now we need to revert it from the release branch too. Still, better than finding this after the release and needing a policy to fix it. Thanks, -Brad From brad.king at kitware.com Tue Dec 9 10:45:16 2014 From: brad.king at kitware.com (Brad King) Date: Tue, 09 Dec 2014 10:45:16 -0500 Subject: [cmake-developers] [PATCH] FindQt4: Fix handling of QT_VERSION_MAJOR mismatch In-Reply-To: <548709ED.7060604@constexpr.org> References: <548709ED.7060604@constexpr.org> Message-ID: <5487190C.1090200@kitware.com> On 12/09/2014 09:40 AM, Daniel Scharrer wrote: > This caused find_package(Qt4) to appear successful when it was not. > Note that the legacy QT4_FOUND variable is unconditionally overwritten > at the end of the file with the value of Qt4_FOUND. Applied with slightly modified commit message: FindQt4: Fix handling of QT_VERSION_MAJOR mismatch http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=009c1865 Thanks, -Brad From pascal.bach at siemens.com Tue Dec 9 10:46:31 2014 From: pascal.bach at siemens.com (Bach, Pascal) Date: Tue, 9 Dec 2014 15:46:31 +0000 Subject: [cmake-developers] [PATCH] VS, WINCE: Fix entry point for Unicode builds In-Reply-To: <548717D5.5010601@kitware.com> References: <1417523622-26389-1-git-send-email-pascal.bach@siemens.com> <547DCDEF.2050009@kitware.com> <547F2847.9060703@kitware.com> <355BE46A91031048906B695426A8D8E616B0E3B6@DEFTHW99EH4MSX.ww902.siemens.net> <548717D5.5010601@kitware.com> Message-ID: <355BE46A91031048906B695426A8D8E616B0E563@DEFTHW99EH4MSX.ww902.siemens.net> > On 12/09/2014 09:45 AM, Bach, Pascal wrote: > > the old behavior was better. The user should then be able to set the > > entry point independent of the UNICODE setting via a target property. > > This would be similar to how WIN32_EXECUTABLE selects WinMain as > startup. > > Good catch. They are orthogonal settings. I've reverted the change: > > Revert "VS, WINCE: Fix entry point for Unicode builds" > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=df01a380 > > Unfortunately original change is in the v3.1.0-rc3 tag. This is > why I don't like taking non-regression changes after the feature > freeze for a release. I took it because I thought it was a bug > in the new WinCE support. Now we need to revert it from the > release branch too. Still, better than finding this after the > release and needing a policy to fix it. Sorry for that. I thought of it as a bug too. Just after a discussion today with a colleague I realized it is not really the case. Is there a place where we could document things like this in the CMake documentation? Something like a platform specific collection of best practice and commonly required tasks. Maybe the Wiki would also be a good place for that. Pascal From brad.king at kitware.com Tue Dec 9 10:50:34 2014 From: brad.king at kitware.com (Brad King) Date: Tue, 09 Dec 2014 10:50:34 -0500 Subject: [cmake-developers] [PATCH] VS, WINCE: Fix entry point for Unicode builds In-Reply-To: <355BE46A91031048906B695426A8D8E616B0E563@DEFTHW99EH4MSX.ww902.siemens.net> References: <1417523622-26389-1-git-send-email-pascal.bach@siemens.com> <547DCDEF.2050009@kitware.com> <547F2847.9060703@kitware.com> <355BE46A91031048906B695426A8D8E616B0E3B6@DEFTHW99EH4MSX.ww902.siemens.net> <548717D5.5010601@kitware.com> <355BE46A91031048906B695426A8D8E616B0E563@DEFTHW99EH4MSX.ww902.siemens.net> Message-ID: <54871A4A.4000604@kitware.com> On 12/09/2014 10:46 AM, Bach, Pascal wrote: > Is there a place where we could document things like this in the > CMake documentation? Something like a platform specific collection > of best practice and commonly required tasks. The closest place to something like that is here: http://www.cmake.org/cmake/help/v3.1/manual/cmake-toolchains.7.html#cross-compiling-for-windows-ce However, in this case isn't a new target property needed to provide a clean way to set the entry point? That property would at least have the reference documentation. -Brad From pascal.bach at siemens.com Tue Dec 9 10:57:36 2014 From: pascal.bach at siemens.com (Bach, Pascal) Date: Tue, 9 Dec 2014 15:57:36 +0000 Subject: [cmake-developers] [PATCH] VS, WINCE: Fix entry point for Unicode builds In-Reply-To: <54871A4A.4000604@kitware.com> References: <1417523622-26389-1-git-send-email-pascal.bach@siemens.com> <547DCDEF.2050009@kitware.com> <547F2847.9060703@kitware.com> <355BE46A91031048906B695426A8D8E616B0E3B6@DEFTHW99EH4MSX.ww902.siemens.net> <548717D5.5010601@kitware.com> <355BE46A91031048906B695426A8D8E616B0E563@DEFTHW99EH4MSX.ww902.siemens.net> <54871A4A.4000604@kitware.com> Message-ID: <355BE46A91031048906B695426A8D8E616B0E57E@DEFTHW99EH4MSX.ww902.siemens.net> > The closest place to something like that is here: > > http://www.cmake.org/cmake/help/v3.1/manual/cmake- > toolchains.7.html#cross-compiling-for-windows-ce > > However, in this case isn't a new target property needed to provide > a clean way to set the entry point? That property would at least have > the reference documentation. The new property is not strictly necessary. Setting: set_target_properties(target PROPERTIES LINK_FLAGS "/ENTRY:mainCRTStartup") would also work because it is a link flag for MSVC. On the other hand instead of setting WIN32_EXECUTABLE it would also be possible to just set: set_target_properties(target PROPERTIES LINK_FLAGS "/SUBSYSTEM:WINDOWS") but the former is more convenient for the end user. I don't know what would be better? For consistency reason there could be something like a WIN32_ENTRYPOINT property. Pascal From brad.king at kitware.com Tue Dec 9 11:07:42 2014 From: brad.king at kitware.com (Brad King) Date: Tue, 09 Dec 2014 11:07:42 -0500 Subject: [cmake-developers] FindMPI take 2 In-Reply-To: References: Message-ID: <54871E4E.6090308@kitware.com> On 12/09/2014 06:59 AM, Alin Marin Elena wrote: > 0001-correctly-detect-MPI-linker-flags-for-Intel-MPI-mayb.patch Thanks. That adds a block much like one above it. Can the preceding block be modified to match both -Wl, and -Xlinker? Something like: - string(REGEX MATCHALL "(^| )-Wl,([^\" ]+|\"[^\"]+\")" MPI_ALL_LINK_FLAGS "${MPI_LINK_CMDLINE}") + string(REGEX MATCHALL "(^| )(-Wl,|-Xlinker )([^\" ]+|\"[^\"]+\")" MPI_ALL_LINK_FLAGS "${MPI_LINK_CMDLINE}") may work (untested). > 0002-first-try-to-see-if-what-user-provided-produces-an-m.patch The check for whether the CMAKE__COMPILER is already a MPI compiler requires a try_compile. Is there some other way to check to see if there is any chance before the full test? Also I'm not sure we fully support using a MPI compiler as the main compiler. I can't think of anything that definitely won't work, but we don't have nightly testing for the case. Generally I've viewed the MPI compiler interrogation to be much like using pkg-config or $pkg-config tools to get the info needed to use a package. Once that is done then MPI should be treated like any other library. > 3. This is a more complex issue and my understanding is that FindMPI > was designed with mpicc/mpicxx/mpif90 being the workhorse wrappers for > MPI. While I do not propose to change that I think that implementing > the change at 2. will somehow mitigate the case of multiple wrappers > and compilers. The user should be able to specify MPI__COMPILER explicitly. Perhaps it could be initialized by ENV{MPICC}, ENV{MPICXX}, and ENV{MPIFC} environment variables? This selection is much like picking the primary compiler in the first place. Thanks, -Brad From brad.king at kitware.com Tue Dec 9 11:10:47 2014 From: brad.king at kitware.com (Brad King) Date: Tue, 09 Dec 2014 11:10:47 -0500 Subject: [cmake-developers] [PATCH] VS, WINCE: Fix entry point for Unicode builds In-Reply-To: <355BE46A91031048906B695426A8D8E616B0E57E@DEFTHW99EH4MSX.ww902.siemens.net> References: <1417523622-26389-1-git-send-email-pascal.bach@siemens.com> <547DCDEF.2050009@kitware.com> <547F2847.9060703@kitware.com> <355BE46A91031048906B695426A8D8E616B0E3B6@DEFTHW99EH4MSX.ww902.siemens.net> <548717D5.5010601@kitware.com> <355BE46A91031048906B695426A8D8E616B0E563@DEFTHW99EH4MSX.ww902.siemens.net> <54871A4A.4000604@kitware.com> <355BE46A91031048906B695426A8D8E616B0E57E@DEFTHW99EH4MSX.ww902.siemens.net> Message-ID: <54871F07.4010902@kitware.com> On 12/09/2014 10:57 AM, Bach, Pascal wrote: > set_target_properties(target PROPERTIES LINK_FLAGS "/ENTRY:mainCRTStartup") I prefer to use LINK_FLAGS only as a last resort. For common settings we should provide a first-class setting. > For consistency reason there could be something like a > WIN32_ENTRYPOINT property. I think that would be the best approach. If you work on it, please ensure the implementation supports all Windows toolchains on all generators, or at least those combinations that already support WIN32_EXECUTABLE. Thanks, -Brad From konstantin at podsvirov.pro Tue Dec 9 13:39:21 2014 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Tue, 09 Dec 2014 21:39:21 +0300 Subject: [cmake-developers] [DISCUSSION] Using COMPONENTs for CMake install(...)? In-Reply-To: <5485B4F6.2040104@kitware.com> References: <50071417557052@web29o.yandex.ru> <547F298A.8020002@kitware.com> <2931041417672790@web24g.yandex.ru> <54820895.40900@kitware.com> <158731417810418@web3o.yandex.ru> <93911417991658@web27m.yandex.ru> <5485B4F6.2040104@kitware.com> Message-ID: <727251418150361@web27m.yandex.ru> 08.12.2014, 17:26, "Brad King" : > On 12/07/2014 05:34 PM, Konstantin Podsvirov wrote: >> Well, work has started! > Good work so far. I tried :-) > Please reorganize the commits to have the first one add the install > COMPONENT options and the second one add the CPack configuration. >> Added components: >> - cmake >> - ctest >> - cpack >> - cmake-gui >> - ccmake >> - data >> - sphinx-html >> - sphinx-singlehtml >> - sphinx-qthelp > That looks good, except that "cmake/ctest/cpack" must all be in > one component. Each of those three binaries has logic that assumes > the other two exist. This ground for discussion. By default CPack generators must create one package for each component group. In addition, you can specify whether the component is required and can be specified as any of the components referenced by this component. > There should also be a "sphinx-man group for the man pages. It is not difficult. I will add. I want to clarify: sphinx-man is the documentation that must be installed together with tools in Linux? > Thanks, > -Brad What other components can be identified? I already wrote about this, but where can I get NAME and DESCRIPTION for each component? (something you can find in sphinx documentation, but this is not all). I have some difficulties with the English language and help here would be appropriate. I'm working on a graphical installer (CPack IFW generator), which can install CMake on Windows, Linux and Mac in graphics mode. Graphical installer allows you to acquaint the user with the structure of CMake in the installation process. The installer may include optional components. It is possible to create online installers, where all or some of the components are downloaded and installed as needed. Regards, Konstantin Podsvirov From imrnbdshiscool at yahoo.co.in Tue Dec 9 15:03:07 2014 From: imrnbdshiscool at yahoo.co.in (imran lala) Date: Tue, 9 Dec 2014 20:03:07 +0000 (UTC) Subject: [cmake-developers] Qt5 Message-ID: <1942904358.4581351.1418155387127.JavaMail.yahoo@jws10929.mail.sg3.yahoo.com> Hi, is there an easy way to compile Qt 5.2.1 using CMake? Thanks,Imran -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Tue Dec 9 15:40:47 2014 From: brad.king at kitware.com (Brad King) Date: Tue, 09 Dec 2014 15:40:47 -0500 Subject: [cmake-developers] [PATCH 0/2] XCTest support In-Reply-To: References: <5485B67D.7040106@kitware.com> Message-ID: <54875E4F.7050301@kitware.com> On 12/9/2014 6:02 AM, Gregor Jasny wrote: > See: https://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/testing_with_xcode/ Thanks. > On non-Apple platforms and Xcode < 5.0 those XCTest bundles are pretty > useless. What should CMake do on those platforms? The fact that an add_library call has occurred means it needs to do something with the target. Should it be an error to ensure that the project adds such targets only conditionally? > Note: It is currently not possible to run the tests without opening Xcode > once to (auto) generate the Schema files. Otherwise calling > "xcodebuild test -scheme CocoaExample" will not recognise the scheme. Does this mean we can't automatically setup testing? > Tests/CocoaExample/CMakeLists.txt | 25 + We'll need a way for this to actually run as part of nightly testing. If manual interaction is needed then we could have an option that the user could set to activate this on automated builds after taking care of the manual step on the local machine. Thanks, -Brad From brad.king at kitware.com Tue Dec 9 15:41:06 2014 From: brad.king at kitware.com (Brad King) Date: Tue, 09 Dec 2014 15:41:06 -0500 Subject: [cmake-developers] [PATCH 1/2] Add handling for XCTest bundles In-Reply-To: <1ecf805f8d938a1272e2827b2760fd68eb4bcc54.1418121897.git.gjasny@googlemail.com> References: <1ecf805f8d938a1272e2827b2760fd68eb4bcc54.1418121897.git.gjasny@googlemail.com> Message-ID: <54875E62.2050100@kitware.com> On 12/9/2014 6:02 AM, Gregor Jasny wrote: > +XCTEST_HOST > +----------- > + > +XCTest works by injecting an XCTest CFBundle directly into an AppBundle > +or Framework. This property names this destination target under test. Please add mention of :prop_tgt:`XCTEST` here. > \ No newline at end of file Please end all sources with a newline. > - if (target.GetPropertyAsBool("BUNDLE")) > + if (target.IsCFBundleOnApple()) Please factor this refactoring hunk (and others like it, if any) into a preceding commit with a message explaining the individual part of the change. > + cmSystemTools::Error("target has XCTEST property " > + "but no XCTEST_HOST one."); [snip] > + cmSystemTools::Error("Cannot find XCTEST_HOST target: ", testHostName); [snip] > + cmSystemTools::Error("XCTEST_HOST target is not a Framework " > + "or App Bundle: ", testHostName); These should use IssueMessage too, please. Use the signature that takes an explicit backtrace and pass target.GetBacktrace() to provide some context. Thanks, -Brad From brad.king at kitware.com Tue Dec 9 15:48:21 2014 From: brad.king at kitware.com (Brad King) Date: Tue, 09 Dec 2014 15:48:21 -0500 Subject: [cmake-developers] [DISCUSSION] Using COMPONENTs for CMake install(...)? In-Reply-To: <727251418150361@web27m.yandex.ru> References: <50071417557052@web29o.yandex.ru> <547F298A.8020002@kitware.com> <2931041417672790@web24g.yandex.ru> <54820895.40900@kitware.com> <158731417810418@web3o.yandex.ru> <93911417991658@web27m.yandex.ru> <5485B4F6.2040104@kitware.com> <727251418150361@web27m.yandex.ru> Message-ID: <54876015.3090806@kitware.com> On 12/9/2014 1:39 PM, Konstantin Podsvirov wrote: >> That looks good, except that "cmake/ctest/cpack" must all be in >> one component. > > specify whether the component is required and can be specified as > any of the components referenced by this component. I suppose they can be separate components as long as all three are required. We already separate the "data" component but it is also required. Only cmake-gui, ccmake, and the documentation components are optional. > I want to clarify: sphinx-man is the documentation that must be > installed together with tools in Linux? No, my comments on that were just to distinguish our use case from Debian's policy. I think sphinx-man can be just like sphinx-html except for covering the man-format documentation. > where can I get NAME and DESCRIPTION for each component? Once we identify the final set of components I can help draft the description text for them. Thanks, -Brad From robert.maynard at kitware.com Tue Dec 9 17:01:28 2014 From: robert.maynard at kitware.com (Robert Maynard) Date: Tue, 9 Dec 2014 17:01:28 -0500 Subject: [cmake-developers] [ANNOUNCE] CMake 3.1.0-rc3 is now ready! Message-ID: I am proud to announce the CMake 3.1 third release candidate. Sources and binaries are available at: http://www.cmake.org/files/v3.1/?C=M;O=D Documentation is available at: http://www.cmake.org/cmake/help/v3.1 Release notes appear below and are also published at http://www.cmake.org/cmake/help/v3.1/release/3.1.0.html Some of the more significant features of CMake 3.1 are: * Windows Phone and Windows Store support has been added to Visual Studio 11 (2012) and above Generators. * NVIDIA Nsight Tegra support has been added to Visual Studio 10 (2010) and above Generators. * New "target_compile_features" command allows populating target based compile features. CMake uses this information to ensure that the compiler in use is capable of building the target, and to add any necessary compile flags such as -std=gnu++11 to support language features. More information on this is found at: - http://www.cmake.org/cmake/help/v3.1/manual/cmake-compile-features.7.html * The syntax for *Variable References* and *Escape Sequences* was simplified in order to allow a much faster implementation. See policy "CMP0053". * The "if" command no longer automatically dereferences variables named in quoted or bracket arguments. See policy "CMP0054". * The target property "SOURCES" now generally supports "Generator Expressions". The generator expressions may be used in the "add_library" and "add_executable" commands. * It is now possible to write and append to the target property "SOURCES". The variable "CMAKE_DEBUG_TARGET_PROPERTIES" can be used to trace the origin of sources. * CPack gained "7Z" and "TXZ" generators supporting lzma-compressed archives. * The ExternalProject module has learned to support lzma-compressed source tarballs with ".7z", ".tar.xz", and ".txz" extensions. * The ExternalProject module ExternalProject_Add command learned a new BUILD_ALWAYS option to cause the external project build step to run every time the host project is built. * The ctest_coverage command learned to support Intel coverage files with the "codecov" tool. * The ctest_memcheck command learned to support sanitizer modes, including "AddressSanitizer", "MemorySanitizer", "ThreadSanitizer", and "UndefinedBehaviorSanitizer". Deprecated and Removed Features: * In CMake 3.0 the "target_link_libraries" command accidentally began allowing unquoted arguments to use Generator Expressions containing a semicolon separated list within them. For example: set(libs B C) target_link_libraries(A PUBLIC $) This is equivalent to writing: target_link_libraries(A PUBLIC $) and was never intended to work. It did not work in CMake 2.8.12. Such generator expressions should be in quoted arguments: set(libs B C) target_link_libraries(A PUBLIC "$") CMake 3.1 again requires the quotes for this to work correctly. CMake 3.1.0 Release Notes ************************* Changes made since CMake 3.0.0 include the following. Documentation Changes ===================== * A new "cmake-compile-features(7)" manual was added. New Features ============ Generators ---------- * The "Visual Studio 14 2015" generator was added. Windows Phone and Windows Store ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * Generators for Visual Studio 11 (2012) and above learned to generate projects for Windows Phone and Windows Store. One may set the "CMAKE_SYSTEM_NAME" variable to "WindowsPhone" or "WindowsStore" on the "cmake(1)" command-line or in a "CMAKE_TOOLCHAIN_FILE" to activate these platforms. Also set "CMAKE_SYSTEM_VERSION" to "8.0" or "8.1" to specify the version of Windows to be targeted. NVIDIA Nsight Tegra ~~~~~~~~~~~~~~~~~~~ * Generators for Visual Studio 10 (2010) and above learned to generate projects for NVIDIA Nsight Tegra Visual Studio Edition. One may set the "CMAKE_SYSTEM_NAME" variable to "Android" on the "cmake(1)" command-line or in a "CMAKE_TOOLCHAIN_FILE" to activate this platform. Syntax ------ * The "cmake-language(7)" syntax for *Variable References* and *Escape Sequences* was simplified in order to allow a much faster implementation. See policy "CMP0053". * The "if()" command no longer automatically dereferences variables named in quoted or bracket arguments. See policy "CMP0054". Commands -------- * The "add_custom_command()" command learned to interpret "cmake- generator-expressions(7)" in arguments to "DEPENDS". * The "export(PACKAGE)" command learned to check the "CMAKE_EXPORT_NO_PACKAGE_REGISTRY" variable to skip exporting the package. * The "file(STRINGS)" command gained a new "ENCODING" option to enable extraction of "UTF-8" strings. * The "find_package()" command learned to check the "CMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY" and "CMAKE_FIND_PACKAGE_NO_SYSTEM_PACKAGE_REGISTRY" variables to skip searching the package registries. * The "get_property()" command learned a new "INSTALL" scope for properties. * The "install()" command learned a "MESSAGE_NEVER" option to avoid output during installation. * The "set_property()" command learned a new "INSTALL" scope for properties. * The "string()" command learned a new "GENEX_STRIP" subcommand which removes "generator expression". * The "string()" command learned a new "UUID" subcommand to generate a univerally unique identifier. * New "target_compile_features()" command allows populating the "COMPILE_FEATURES" target property, just like any other build variable. * The "target_sources()" command was added to add to the "SOURCES" target property. Variables --------- * The Visual Studio generators for versions 8 (2005) and above learned to read the target platform name from a new "CMAKE_GENERATOR_PLATFORM" variable when it is not specified as part of the generator name. The platform name may be specified on the "cmake(1)" command line with the "-A" option, e.g. "-G "Visual Studio 12 2013" -A x64". * The "CMAKE_GENERATOR_TOOLSET" variable may now be initialized in a toolchain file specified by the "CMAKE_TOOLCHAIN_FILE" variable. This is useful when cross-compiling with the Xcode or Visual Studio generators. * The "CMAKE_INSTALL_MESSAGE" variable was introduced to optionally reduce output installation. Properties ---------- * New "CXX_STANDARD" and "CXX_EXTENSIONS" target properties may specify values which CMake uses to compute required compile options such as "-std=c++11" or "-std=gnu++11". The "CMAKE_CXX_STANDARD" and "CMAKE_CXX_EXTENSIONS" variables may be set to initialize the target properties. * New "C_STANDARD" and "C_EXTENSIONS" target properties may specify values which CMake uses to compute required compile options such as "-std=c11" or "-std=gnu11". The "CMAKE_C_STANDARD" and "CMAKE_C_EXTENSIONS" variables may be set to initialize the target properties. * New "COMPILE_FEATURES" target property may contain a list of features required to compile a target. CMake uses this information to ensure that the compiler in use is capable of building the target, and to add any necessary compile flags to support language features. * New "COMPILE_PDB_NAME" and "COMPILE_PDB_OUTPUT_DIRECTORY" target properties were introduced to specify the MSVC compiler program database file location ("cl /Fd"). This complements the existing "PDB_NAME" and "PDB_OUTPUT_DIRECTORY" target properties that specify the linker program database file location ("link /pdb"). * The "INTERFACE_LINK_LIBRARIES" target property now supports a "$" "generator expression". * A new "INTERFACE_SOURCES" target property was introduced. This is consumed by dependent targets, which compile and link the listed sources. * The "SOURCES" target property now contains "generator expression" such as "TARGET_OBJECTS" when read at configure time, if policy "CMP0051" is "NEW". * The "SOURCES" target property now generally supports "generator expression". The generator expressions may be used in the "add_library()" and "add_executable()" commands. * It is now possible to write and append to the "SOURCES" target property. The "CMAKE_DEBUG_TARGET_PROPERTIES" variable may be used to trace the origin of sources. * A "VS_DEPLOYMENT_CONTENT" source file property was added to tell the Visual Studio generators to mark content for deployment in Windows Phone and Windows Store projects. * The "VS_WINRT_COMPONENT" target property was created to tell Visual Studio generators to compile a shared library as a Windows Runtime (WinRT) component. * A "VS_DEPLOYMENT_LOCATION" source file property was added to tell the Visual Studio generators the relative location of content marked for deployment in Windows Phone and Windows Store projects. * The "Xcode" generator learned to check source file properties "XCODE_EXPLICIT_FILE_TYPE" and "XCODE_LAST_KNOWN_FILE_TYPE" for a custom Xcode file reference type. Modules ------- * The "BundleUtilities" module learned to resolve and replace "@rpath" placeholders on OS X to correctly bundle applications using them. * The "CMakePackageConfigHelpers" module "configure_package_config_file()" command learned a new "INSTALL_PREFIX" option to generate package configuration files meant for a prefix other than "CMAKE_INSTALL_PREFIX". * The "CheckFortranSourceCompiles" module was added to provide a "CHECK_Fortran_SOURCE_COMPILES" macro. * The "ExternalData" module learned to tolerate a "DATA{}" reference to a missing source file with a warning instead of rejecting it with an error. This helps developers write new "DATA{}" references to test reference outputs that have not yet been created. * The "ExternalProject" module learned to support lzma-compressed source tarballs with ".7z", ".tar.xz", and ".txz" extensions. * The "ExternalProject" module "ExternalProject_Add" command learned a new "BUILD_ALWAYS" option to cause the external project build step to run every time the host project is built. * The "ExternalProject" module "ExternalProject_Add" command learned a new "EXCLUDE_FROM_ALL" option to cause the external project target to have the "EXCLUDE_FROM_ALL" target property set. * The "ExternalProject" module "ExternalProject_Add_Step" command learned a new "EXCLUDE_FROM_MAIN" option to cause the step to not be a direct dependency of the main external project target. * The "ExternalProject" module "ExternalProject_Add" command learned a new "DOWNLOAD_NO_PROGRESS" option to disable progress output while downloading the source tarball. * The "FeatureSummary" module "feature_summary" API learned to accept multiple values for the "WHAT" option and combine them appropriately. * The "FindCUDA" module learned to support "fatbin" and "cubin" modules. * The "FindGTest" module "gtest_add_tests" macro learned a new "AUTO" option to automatically read the "SOURCES" target property of the test executable and scan the source files for tests to be added. * The "FindGLEW" module now provides imported targets. * The "FindGLUT" module now provides imported targets. * The "FindHg" module gained a new "Hg_WC_INFO" macro to help run "hg" to extract information about a Mercurial work copy. * The "FindOpenCL" module was introduced. * The "FindOpenMP" module learned to support Fortran. * The "FindPkgConfig" module learned to use the "PKG_CONFIG" environment variable value as the "pkg-config" executable, if set. * The "FindXercesC" module was introduced. * The "FindZLIB" module now provides imported targets. * The "GenerateExportHeader" module "generate_export_header" function learned to allow use with *Object Libraries*. * The "InstallRequiredSystemLibraries" module gained a new "CMAKE_INSTALL_OPENMP_LIBRARIES" option to install MSVC OpenMP runtime libraries. * The "UseSWIG" module learned to detect the module name from ".i" source files if possible to avoid the need to set the "SWIG_MODULE_NAME" source file property explicitly. * The "WriteCompilerDetectionHeader" module was added to allow creation of a portable header file for compiler optional feature detection. Generator Expressions --------------------- * New "COMPILE_FEATURES" "generator expression" allows setting build properties based on available compiler features. CTest ----- * The "ctest_coverage()" command learned to read variable "CTEST_COVERAGE_EXTRA_FLAGS" to set "CoverageExtraFlags". * The "ctest_coverage()" command learned to support Intel coverage files with the "codecov" tool. * The "ctest_memcheck()" command learned to support sanitizer modes, including "AddressSanitizer", "MemorySanitizer", "ThreadSanitizer", and "UndefinedBehaviorSanitizer". Options may be set using the new "CTEST_MEMORYCHECK_SANITIZER_OPTIONS" variable. CPack ----- * "cpack(1)" gained an "IFW" generator to package using Qt Framework Installer tools. See the "CPackIFW" module. * "cpack(1)" gained "7Z" and "TXZ" generators supporting lzma- compressed archives. * The "CPackDeb" module learned a new "CPACK_DEBIAN_COMPRESSION_TYPE" variable to set the tarball compression type. * The "cpack(1)" "WiX" generator learned to support a "CPACK_WIX_ACL" installed file property to specify an Access Control List. Other ----- * The "cmake(1)" "-E" option learned a new "env" command. * The "cmake(1)" "-E tar" command learned to support lzma-compressed files. * *Object Libraries* may now have extra sources that do not compile to object files so long as they would not affect linking of a normal library (e.g. ".dat" is okay but not ".def"). * Visual Studio generators for VS 8 and later learned to support the "ASM_MASM" language. * The Visual Studio generators learned to treat ".hlsl" source files as High Level Shading Language sources (using "FXCompile" in ".vcxproj" files). Source file properties "VS_SHADER_TYPE", "VS_SHADER_MODEL", and "VS_SHADER_ENTRYPOINT" were added added to specify the shader type, model, and entry point name. New Diagnostics =============== * Policy "CMP0052" introduced to control directories in the "INTERFACE_INCLUDE_DIRECTORIES" of exported targets. Deprecated and Removed Features =============================== * In CMake 3.0 the "target_link_libraries()" command accidentally began allowing unquoted arguments to use "generator expressions" containing a (";" separated) list within them. For example: set(libs B C) target_link_libraries(A PUBLIC $) This is equivalent to writing: target_link_libraries(A PUBLIC $) and was never intended to work. It did not work in CMake 2.8.12. Such generator expressions should be in quoted arguments: set(libs B C) target_link_libraries(A PUBLIC "$") CMake 3.1 again requires the quotes for this to work correctly. * Callbacks established by the "variable_watch()" command will no longer receive the "ALLOWED_UNKNOWN_READ_ACCESS" access type when the undocumented "CMAKE_ALLOW_UNKNOWN_VARIABLE_READ_ACCESS" variable is set. Uninitialized variable accesses will always be reported as "UNKNOWN_READ_ACCESS". * The "CMakeDetermineVSServicePack" module now warns that it is deprecated and should not longer be used. Use the "CMAKE__COMPILER_VERSION" variable instead. * The "FindITK" module has been removed altogether. It was a thin- wrapper around "find_package(ITK ... NO_MODULE)". This produces much clearer error messages when ITK is not found. * The "FindVTK" module has been removed altogether. It was a thin- wrapper around "find_package(VTK ... NO_MODULE)". This produces much clearer error messages when VTK is not found. The module also provided compatibility support for finding VTK 4.0. This capability has been dropped. Other Changes ============= * The "cmake-gui(1)" learned to capture output from child processes started by the "execute_process()" command and display it in the output window. * The "cmake-language(7)" internal implementation of generator expression and list expansion parsers have been optimized and shows non-trivial speedup on large projects. * The Makefile generators learned to use response files with GNU tools on Windows to pass library directories and names to the linker. * When generating linker command-lines, CMake now avoids repeating items corresponding to SHARED library targets. * Support for the Open Watcom compiler has been overhauled. The "CMAKE__COMPILER_ID" is now "OpenWatcom", and the "CMAKE__COMPILER_VERSION" now uses the Open Watcom external version numbering. The external version numbers are lower than the internal version number by 11. * The "cmake-mode.el" major Emacs editing mode no longer treats "_" as part of words, making it more consistent with other major modes. ------------------------------------------------------------------- Changes made since CMake 3.1.0-rc2: Ben Boeckel (1): Revert "ClearMatches: Only clear matches which were actually set" (#15261) Brad King (18): Help: Document COMPONENT option of install(SCRIPT/CODE) (#14956) Do not use just-built CMake to install itself when cross-compiling (#15248) KWSys SharedForward: Hard-code the ldpath buffer size to below VS 14 limit VS: Rename VS 14 generator to 'Visual Studio 14 2015' Help: target_include_directories does not allow target names Utilities/Sphinx: Add missing call to note_explicit_target FindJava: Do not accept OS X stub 'java' as Java Fix lookup of source names after conversion to their actual case (#15259) Help: Format set_property and get_property command docs Help: Add 3.1 release notes for INSTALL property scope CMakeParseImplicitLinkInfo: Fix implicit library logging Makefile: Do not create an empty linker response file FindOpenGL: Revert support for imported targets (#15267) Help: Document Nsight Tegra toolchain configuration (#15276) Utilities/Sphinx: Fix link targets for mixed-case command names Modules: Rename FindXerces to FindXercesC Help: Document file(GENERATE) signature option order CMake 3.1.0-rc3 Cedric Perthuis (1): VS: Add source file properties to set the hlsl shader entry point and model Christoph Gr?ninger (1): Help: Remove duplicate '#' in CMP0053 valid character list Christopher Dembia (1): Help: Add missing space to ctest -j option description Christopher Gittner (1): FindwxWidgets: Add versions 3.0.1 and 3.0.2 David Demelier (2): Help: Fix typo in cmake-compile-features(7) manual Help: Fix typo in CMAKE_CXX_KNOWN_FEATURES docs Dmitry Polyanitsa (1): VS: Change Nsight Tegra 2.0 Project Revision Number from 8 to 9 Fraser Hutchison (1): Avoid if() quoted auto-dereference when checking for "MSVC" Gilles Khouzam (3): VS: Improve error messages when compiler is not detected (#15228) VS: Do not produce WinMD file for OBJECT libraries (#15228) VS: Add source file property to specify Windows App deployment location Konstantin Podsvirov (1): CPackIFW: Correction of the module documentation Nils Gladitz (2): FindOpenMP: Use fixed form Fortran test program Help: Document installed file property API Pascal Bach (1): VS, WINCE: Fix entry point for Unicode builds Rolf Eike Beer (1): FindPythonInterp: fix version component variables for Python 1.4 (#15275) Stephen Kelly (12): Features: Don't record for AppleClang Features: Test the CXX compiler only if it has features. Features: Fix references to CXX compiler version in Clang-C.cmake. Features: Record C++11 dialect switch only for GNU 4.7 and later. Features: Fix the default C dialect for Clang and GNU. Fix the test for running the CxxDialog unit test. WCDH: Don't imply that MSVC is supported by the module. WCDH: Make the header -Wundef safe for the C language. Genex: Fix evaluation context propagation for TARGET_OBJECTS. cmTarget: Don't allow relative paths in INTERFACE_SOURCES Export: Disallow export of targets with INTERFACE_SOURCES Help: Document the export limitation of INTERFACE_SOURCES. From konstantin at podsvirov.pro Tue Dec 9 17:03:29 2014 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Wed, 10 Dec 2014 01:03:29 +0300 Subject: [cmake-developers] [DISCUSSION] Using COMPONENTs for CMake install(...)? In-Reply-To: <54876015.3090806@kitware.com> References: <50071417557052@web29o.yandex.ru> <547F298A.8020002@kitware.com> <2931041417672790@web24g.yandex.ru> <54820895.40900@kitware.com> <158731417810418@web3o.yandex.ru> <93911417991658@web27m.yandex.ru> <5485B4F6.2040104@kitware.com> <727251418150361@web27m.yandex.ru> <54876015.3090806@kitware.com> Message-ID: <1162201418162609@web1m.yandex.ru> 09.12.2014, 23:48, "Brad King" : > On 12/9/2014 1:39 PM, Konstantin Podsvirov wrote: >>> That looks good, except that "cmake/ctest/cpack" must all be in >>> one component. >> specify whether the component is required and can be specified as >> any of the components referenced by this component. > > I suppose they can be separate components as long as all three are > required. We already separate the "data" component but it is also > required. Only cmake-gui, ccmake, and the documentation components > are optional. Well. Leave them as separate components and make mandatory. The data now includes subfolders Help, Modules and Templates. Why are Help (the rst set of files)? As they are used after installation? >> I want to clarify: sphinx-man is the documentation that must be >> installed together with tools in Linux? > > No, my comments on that were just to distinguish our use case from > Debian's policy. I think sphinx-man can be just like sphinx-html > except for covering the man-format documentation. It is understandable. >> where can I get NAME and DESCRIPTION for each component? > > Once we identify the final set of components I can help draft the > description text for them. Thank you. > Thanks, > -Brad There are a series of resources that have not been specified. Please look at the files in the folder: http://ifw.podsvirov.pro/cmake/dev/unspecified/ What components to include these files? For example, files with different licenses? And yet. In addition to the list of components must be approved and the list of groups. Regards, Konstantin Podsvirov From kgt at lanl.gov Tue Dec 9 17:56:54 2014 From: kgt at lanl.gov (Thompson, KT) Date: Tue, 9 Dec 2014 22:56:54 +0000 Subject: [cmake-developers] Volunteering to maintain a new module: FindGSL.cmake In-Reply-To: References: <0458DF31F610EF42BFC78C497E806C7B3B53D706@ECS-EXG-P-MB03.win.lanl.gov> Message-ID: <0458DF31F610EF42BFC78C497E806C7B3B5435CE@ECS-EXG-P-MB03.win.lanl.gov> Stephen Kelly wrote: > This looks like it needs a suffix. GSL_CONFIG_EXECUTABLE would seem > appropriate. >> # Windows with dlls, but only Release libraries. >> set_target_properties( GSL::gslcblas PROPERTIES >> IMPORTED_LOCATION "${GSL_CBLAS_LIBRARY_DLL}" > This should be IMPORTED_LOCATION_RELEASE I made both of these recommended changes. I also fixed a single instead of a double colon typo in the dll section (GSL:gsl -> GSL::gsl). The updated file is attached. How does cmake provide tests for modules like this? How is the correctness of the module checked before a release? Do you simply rely on release candidates? -kt -------------- next part -------------- A non-text attachment was scrubbed... Name: FindGSL.cmake Type: application/octet-stream Size: 9664 bytes Desc: FindGSL.cmake URL: From kgt at lanl.gov Tue Dec 9 19:03:06 2014 From: kgt at lanl.gov (Thompson, KT) Date: Wed, 10 Dec 2014 00:03:06 +0000 Subject: [cmake-developers] FindMPI take 2 In-Reply-To: <54871E4E.6090308@kitware.com> References: <54871E4E.6090308@kitware.com> Message-ID: <0458DF31F610EF42BFC78C497E806C7B3B543625@ECS-EXG-P-MB03.win.lanl.gov> Brad King wrote: >> 0002-first-try-to-see-if-what-user-provided-produces-an-m.patch > The check for whether the CMAKE__COMPILER is already a > MPI compiler requires a try_compile. Is there some other way > to check to see if there is any chance before the full test? I have been looking into this. For my setup, I found it useful to compare the CMAKE__COMPILER to the list of known mpi wrapper names and prepend _MPI_${lang}_COMPILER_NAMES with CMAKE__COMPILER so that the remaining logic in FindMPI.cmake chooses the user supplied compiler/mpi-wrapper over any of the other choices. Something like this: # append vendor-specific compilers to the list if we either don't know the compiler id, # or if we know it matches the regular compiler. foreach (lang C CXX Fortran) foreach (id GNU Intel PGI XL) if (NOT CMAKE_${lang}_COMPILER_ID OR CMAKE_${lang}_COMPILER_ID STREQUAL id) list(APPEND _MPI_${lang}_COMPILER_NAMES ${_MPI_${id}_${lang}_COMPILER_NAMES}) endif() unset(_MPI_${id}_${lang}_COMPILER_NAMES) # clean up the namespace here endforeach() + # If cmake_$lang_compiler matches a known mpi compiler wrapper name, + # prefer the provided value. + get_filename_component( compiler_wo_path "${CMAKE_${lang}_COMPILER}" NAME ) + set( ${lang}_compiler_is_mpiwrapper false ) + foreach( mpiwrapper ${_MPI_${lang}_COMPILER_NAMES} ) + if( "${mpiwrapper}" STREQUAL "${compiler_wo_path}" ) + set( ${lang}_compiler_is_mpiwrapper true ) + endif() + endforeach() + if( ${lang}_compiler_is_mpiwrapper ) + list( REMOVE_ITEM _MPI_${lang}_COMPILER_NAMES ${compiler_wo_path} ) + list( INSERT _MPI_${lang}_COMPILER_NAMES 0 ${compiler_wo_path} ) + endif() endforeach() There is probably a better way to do this, but you get the idea. In my setup, I'm trying to get FindMPI.cmake to select mpiicpc over mpicc without manually setting the MPI_${lang}_COMPILER manually. > Also I'm not sure we fully support using a MPI compiler > as the main compiler. I can't think of anything that > definitely won't work, but we don't have nightly testing > for the case. My project does nightly regressions with and without the use of MPI compiler wrappers. I have never had a problem using the compiler wrappers (e.g.: mpicc, mpiicpc, Cray's CC). Additionally, I think Trilinos (trilinos.org) requires the use of compiler wrappers to build their code (cmake build system). -kt From mantis at public.kitware.com Wed Dec 10 07:02:22 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 10 Dec 2014 07:02:22 -0500 Subject: [cmake-developers] [CMake 0015296]: External Project improperly handles updates from VCS Message-ID: The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15296 ====================================================================== Reported By: Ilya Assigned To: ====================================================================== Project: CMake Issue ID: 15296 Category: CMake Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2014-12-10 07:02 EST Last Modified: 2014-12-10 07:02 EST ====================================================================== Summary: External Project improperly handles updates from VCS Description: When External Project is configured to get sources from git repo from a branch it improperly handles changes. When generator is Ninja, it simply ignores changes and do not rebuild. When generator is UNIX Makefiles it always rebuilds despite whether there were changes or not. Probably this is also true for other VCS sources. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-12-10 07:02 Ilya New Issue ====================================================================== From mantis at public.kitware.com Wed Dec 10 09:30:03 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 10 Dec 2014 09:30:03 -0500 Subject: [cmake-developers] [CMake 0015297]: External Project cannot set SOURCE_DIR to subfolder of another External Project Message-ID: The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15297 ====================================================================== Reported By: Ilya Assigned To: ====================================================================== Project: CMake Issue ID: 15297 Category: CMake Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2014-12-10 09:30 EST Last Modified: 2014-12-10 09:30 EST ====================================================================== Summary: External Project cannot set SOURCE_DIR to subfolder of another External Project Description: I have an External Project that fetches sources from git repo. This repo has submodules. I want another External Project to refer this directory. However it does not work: build script generated by cmake fails on first start. If SOURCE_DIR for dependent External Project refers to SOURCE_DIR of main External Project it works. It looks like build system generated by CMake attempts to validate directory, but it cannot simply because there is no way CMake could now of project structure. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-12-10 09:30 Ilya New Issue ====================================================================== From ben.boeckel at kitware.com Wed Dec 10 09:38:56 2014 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 10 Dec 2014 09:38:56 -0500 Subject: [cmake-developers] OpenBSD and srand()/rand() changes Message-ID: <20141210143856.GA25671@megas.kitwarein.com> Hi, It appears[1] as though OpenBSD has changed srand and rand which we use in CMake for string(RANDOM) and with the change, RANDOM_SEED will be a no-op there. Do we want to use rand_deterministic and srand_determinitic or does it not matter? --Ben [1]http://marc.info/?l=openbsd-cvs&m=141807513728073&w=2 From eike at sf-mail.de Wed Dec 10 09:50:36 2014 From: eike at sf-mail.de (Rolf Eike Beer) Date: Wed, 10 Dec 2014 15:50:36 +0100 Subject: [cmake-developers] OpenBSD and srand()/rand() changes In-Reply-To: <20141210143856.GA25671@megas.kitwarein.com> References: <20141210143856.GA25671@megas.kitwarein.com> Message-ID: Am 10.12.2014 15:38, schrieb Ben Boeckel: > Hi, > > It appears[1] as though OpenBSD has changed srand and rand which we use > in CMake for string(RANDOM) and with the change, RANDOM_SEED will be a > no-op there. > > Do we want to use rand_deterministic and srand_determinitic or does it > not matter? From what I see there we want to use the deterministic variants. May also get us rid of some warnings on OpenBSD. Eike From mantis at public.kitware.com Wed Dec 10 15:49:46 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 10 Dec 2014 15:49:46 -0500 Subject: [cmake-developers] [CMake 0015298]: Generate Eclipse Workspace instead of Project Message-ID: The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15298 ====================================================================== Reported By: Gregory Kramida Assigned To: ====================================================================== Project: CMake Issue ID: 15298 Category: CMake Reproducibility: N/A Severity: feature Priority: normal Status: new ====================================================================== Date Submitted: 2014-12-10 15:49 EST Last Modified: 2014-12-10 15:49 EST ====================================================================== Summary: Generate Eclipse Workspace instead of Project Description: CMake generates entire solutions for Visual Studio, with multiple targets becoming separate projects. In Eclipse, a "Workspace" is equivalent to a Visual Studio "Solution", within which you have multiple projects. It's unclear to me why CMake by original design generates only a single project for eclipse, not an entire workspace(=solution) with separate projects for each target, which, in my view, would be much more intuitive and would make separate target compilation much simpler from the get-go. I thought it prudent to bring this issue / feature request to the table for discussion. In my view, the right solution would be to deprecate the current mode of "single-project" generation (yet leave it available as a legacy option for backward-compatibility, perhaps simply as a separate generator entry), while changing the default behavior to generating an entire eclipse Workspace. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-12-10 15:49 Gregory KramidaNew Issue ====================================================================== From alinm.elena at gmail.com Thu Dec 11 05:08:21 2014 From: alinm.elena at gmail.com (Alin Marin Elena) Date: Thu, 11 Dec 2014 10:08:21 +0000 Subject: [cmake-developers] FindMPI take 2 In-Reply-To: <54871E4E.6090308@kitware.com> References: <54871E4E.6090308@kitware.com> Message-ID: Hi Brad, >> 0001-correctly-detect-MPI-linker-flags-for-Intel-MPI-mayb.patch > > Thanks. That adds a block much like one above it. Can the preceding > block be modified to match both -Wl, and -Xlinker? Something like: > > - string(REGEX MATCHALL "(^| )-Wl,([^\" ]+|\"[^\"]+\")" MPI_ALL_LINK_FLAGS "${MPI_LINK_CMDLINE}") > + string(REGEX MATCHALL "(^| )(-Wl,|-Xlinker )([^\" ]+|\"[^\"]+\")" MPI_ALL_LINK_FLAGS "${MPI_LINK_CMDLINE}") > > may work (untested). Indeed the merging of the two sections is the elegant decision... I kept it in two separate blocks maybe due to my phobia for debugging regexes. I have attached a checked patch for linker. flags with the blocks merged. > The check for whether the CMAKE__COMPILER is already a MPI > compiler requires a try_compile. Is there some other way to check > to see if there is any chance before the full test? I do not know the answer to this. When I did my changes I tried to minimise them. > Also I'm not sure we fully support using a MPI compiler as the main > compiler. I can't think of anything that definitely won't work, but > we don't have nightly testing for the case. > > Generally I've viewed the MPI compiler interrogation to be much like > using pkg-config or $pkg-config tools to get the info needed to use > a package. Once that is done then MPI should be treated like any > other library. Unfortunately MPI wrapper is abused as main compiler in some projects. Practically my patch just checks for that. As it involves a pretty active decision from the user, I think we shall be fine. > The user should be able to specify MPI__COMPILER explicitly. > Perhaps it could be initialized by ENV{MPICC}, ENV{MPICXX}, and > ENV{MPIFC} environment variables? This selection is much like > picking the primary compiler in the first place. This will the the best situation but will involve changes to the FindMPI module that may be above my station to do. regards, Alin -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Linking-flags-correctly-detected-for-intel-compilers.patch Type: text/x-diff Size: 1463 bytes Desc: not available URL: From alinm.elena at gmail.com Thu Dec 11 05:24:24 2014 From: alinm.elena at gmail.com (Alin Marin Elena) Date: Thu, 11 Dec 2014 10:24:24 +0000 Subject: [cmake-developers] FindMPI take 2 In-Reply-To: <0458DF31F610EF42BFC78C497E806C7B3B543625@ECS-EXG-P-MB03.win.lanl.gov> References: <54871E4E.6090308@kitware.com> <0458DF31F610EF42BFC78C497E806C7B3B543625@ECS-EXG-P-MB03.win.lanl.gov> Message-ID: Hi Kelly > I have been looking into this. For my setup, I found it useful to compare the CMAKE__COMPILER to the list of known mpi wrapper names and prepend _MPI_${lang}_COMPILER_NAMES with CMAKE__COMPILER so that the remaining logic in FindMPI.cmake chooses the user supplied compiler/mpi-wrapper over any of the other choices. Something like this: > > # append vendor-specific compilers to the list if we either don't know the compiler id, > # or if we know it matches the regular compiler. > foreach (lang C CXX Fortran) > foreach (id GNU Intel PGI XL) > if (NOT CMAKE_${lang}_COMPILER_ID OR CMAKE_${lang}_COMPILER_ID STREQUAL id) > list(APPEND _MPI_${lang}_COMPILER_NAMES ${_MPI_${id}_${lang}_COMPILER_NAMES}) > endif() > unset(_MPI_${id}_${lang}_COMPILER_NAMES) # clean up the namespace here > endforeach() > > + # If cmake_$lang_compiler matches a known mpi compiler wrapper name, > + # prefer the provided value. > + get_filename_component( compiler_wo_path "${CMAKE_${lang}_COMPILER}" NAME ) > + set( ${lang}_compiler_is_mpiwrapper false ) > + foreach( mpiwrapper ${_MPI_${lang}_COMPILER_NAMES} ) > + if( "${mpiwrapper}" STREQUAL "${compiler_wo_path}" ) > + set( ${lang}_compiler_is_mpiwrapper true ) > + endif() > + endforeach() > + if( ${lang}_compiler_is_mpiwrapper ) > + list( REMOVE_ITEM _MPI_${lang}_COMPILER_NAMES ${compiler_wo_path} ) > + list( INSERT _MPI_${lang}_COMPILER_NAMES 0 ${compiler_wo_path} ) > + endif() > endforeach() checked your patch and indeed works. In addition to that I have noticed that in the interrogate function we never check that we can actually generate a binary with the findings, shall we have a try_mpi_compile at the end of interrogate function? regards Alin From mantis at public.kitware.com Thu Dec 11 06:36:02 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 11 Dec 2014 06:36:02 -0500 Subject: [cmake-developers] [CMake 0015299]: CMakeExpandImportedTargets does not support generator expression TARGET_PROPERTY w/o target specified Message-ID: The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15299 ====================================================================== Reported By: Pawe? Stankowski Assigned To: ====================================================================== Project: CMake Issue ID: 15299 Category: Modules Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2014-12-11 06:36 EST Last Modified: 2014-12-11 06:36 EST ====================================================================== Summary: CMakeExpandImportedTargets does not support generator expression TARGET_PROPERTY w/o target specified Description: CMakeExpandImportedTarget expands target names to file paths including targets from IMPORTED_LINK_INTERFACE_LIBRARIES* properties of expanded targets. However, IMPORTED_LINK_INTERFACE_LIBRARIES property may contain generator expression $. It should be converted to $ expression. Otherwise following error will appear: "$ may only be used with targets. It may not be used with add_custom_command. Specify the target to read a property from using the $ signature instead". BTW: INTERFACE_LINK_LIBRARIES property should be preferred, IMPORTED_LINK_INTERFACE_LIBRARIES should not be used when the former is defined. Currently INTERFACE_LINK_LIBRARIES property is ignored. Steps to Reproduce: This is easily reproducible on Windows with Qt libraries. For example, Qt5 adds following generator expression in IMPORTED_LINK_INTERFACE_LIBRARIES of Qt targets: $<$,EXECUTABLE>,$>,$>>,$>:Qt5::WinMain>;C:/Qt5/5.3/msvc2013_opengl/bin/Qt5Networkd.dll;C:/Qt5/5.3/msvc2013_opengl/bin/Qt5Cored.dll;$<$,EXECUTABLE>,$>,$>>,$>:Qt5::WinMain> Qt4 does similar thing. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-12-11 06:36 Pawe? StankowskiNew Issue ====================================================================== From pascal.bach at siemens.com Thu Dec 11 07:23:21 2014 From: pascal.bach at siemens.com (Bach, Pascal) Date: Thu, 11 Dec 2014 12:23:21 +0000 Subject: [cmake-developers] [PATCH] VS, WINCE: Fix entry point for Unicode builds In-Reply-To: <54871F07.4010902@kitware.com> References: <1417523622-26389-1-git-send-email-pascal.bach@siemens.com> <547DCDEF.2050009@kitware.com> <547F2847.9060703@kitware.com> <355BE46A91031048906B695426A8D8E616B0E3B6@DEFTHW99EH4MSX.ww902.siemens.net> <548717D5.5010601@kitware.com> <355BE46A91031048906B695426A8D8E616B0E563@DEFTHW99EH4MSX.ww902.siemens.net> <54871A4A.4000604@kitware.com> <355BE46A91031048906B695426A8D8E616B0E57E@DEFTHW99EH4MSX.ww902.siemens.net> <54871F07.4010902@kitware.com> Message-ID: <355BE46A91031048906B695426A8D8E616B0ECC6@DEFTHW99EH4MSX.ww902.siemens.net> > > I think that would be the best approach. If you work on it, please ensure > the implementation supports all Windows toolchains on all generators, or at > least those combinations that already support WIN32_EXECUTABLE. > I had a look trough the code. I found that the VS6 generator also sets the entry point for Windows CE (https://github.com/Kitware/CMake/blob/a11dda1c4883eddf763ba1eb2979b45220886b01/Source/cmLocalVisualStudio7Generator.cxx#L1313) But here it is set to wmain as default if Unicode is active. So for consistency reason I think the VS10 generator should do the same. This is also consistent with the case for Windows NT where the entry point is not set by CMake and wmain is automatically selected by VS if UNICODE is enabled This should be in addition to a WIN32_ENTRYPOINT property that the user can set to override the default. Pascal From kgt at lanl.gov Thu Dec 11 09:28:19 2014 From: kgt at lanl.gov (Thompson, KT) Date: Thu, 11 Dec 2014 14:28:19 +0000 Subject: [cmake-developers] FindMPI take 2 In-Reply-To: References: <54871E4E.6090308@kitware.com> <0458DF31F610EF42BFC78C497E806C7B3B543625@ECS-EXG-P-MB03.win.lanl.gov> Message-ID: <0458DF31F610EF42BFC78C497E806C7B3B54E4F1@ECS-EXG-P-MB03.win.lanl.gov> Alin Elena wrote: > In addition to that I have noticed that in the interrogate > function we never check that we can actually generate a binary > with the findings, shall we have a try_mpi_compile at the end > of interrogate function? In general, I think this is a good idea because I have encountered situation were the cmake compiler was a different flavor (intel, gnu, pgi, etc) than the selected mpi compiler wrapper. However, if the chosen mpi compiler wrapper is the same as CMAKE__COMPILER, we don't need the try_compile because cmake will have already verified that the CMAKE__COMPILER works. -kt From alinm.elena at gmail.com Thu Dec 11 09:38:36 2014 From: alinm.elena at gmail.com (Alin Marin Elena) Date: Thu, 11 Dec 2014 14:38:36 +0000 Subject: [cmake-developers] FindMPI take 2 In-Reply-To: <0458DF31F610EF42BFC78C497E806C7B3B54E4F1@ECS-EXG-P-MB03.win.lanl.gov> References: <54871E4E.6090308@kitware.com> <0458DF31F610EF42BFC78C497E806C7B3B543625@ECS-EXG-P-MB03.win.lanl.gov> <0458DF31F610EF42BFC78C497E806C7B3B54E4F1@ECS-EXG-P-MB03.win.lanl.gov> Message-ID: Hi KT, > In general, I think this is a good idea because I have encountered situation were the cmake compiler was a different flavor (intel, gnu, pgi, etc) than the selected mpi compiler wrapper. However, if the chosen mpi compiler wrapper is the same as CMAKE__COMPILER, we don't need the try_compile because cmake will have already verified that the CMAKE__COMPILER works. The nornal test will not test any MPI feature...to be sure that actually the wrapper is an MPI compiler we will need to test a MPI test. Also we need to add a test to see if the found mpi has mpi.mod and can be used. This is a Fortran usage only. Also I like Brad's suggestion on MPICC&friends. regards, Alin From DLRdave at aol.com Thu Dec 11 14:41:36 2014 From: DLRdave at aol.com (David Cole) Date: Thu, 11 Dec 2014 14:41:36 -0500 Subject: [cmake-developers] OpenBSD and srand()/rand() changes In-Reply-To: References: <20141210143856.GA25671@megas.kitwarein.com> Message-ID: Yes, setting an explicit seed should make subsequent calls to random be deterministic... On Wed, Dec 10, 2014 at 9:50 AM, Rolf Eike Beer wrote: > Am 10.12.2014 15:38, schrieb Ben Boeckel: >> >> Hi, >> >> It appears[1] as though OpenBSD has changed srand and rand which we use >> in CMake for string(RANDOM) and with the change, RANDOM_SEED will be a >> no-op there. >> >> Do we want to use rand_deterministic and srand_determinitic or does it >> not matter? > > > From what I see there we want to use the deterministic variants. May also > get us rid of some warnings on OpenBSD. > > 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-developers From steveire at gmail.com Thu Dec 11 18:19:27 2014 From: steveire at gmail.com (Stephen Kelly) Date: Fri, 12 Dec 2014 00:19:27 +0100 Subject: [cmake-developers] [DISCUSSION] Using COMPONENTs for CMake install(...)? References: <50071417557052@web29o.yandex.ru> <547F298A.8020002@kitware.com> <2931041417672790@web24g.yandex.ru> <54820895.40900@kitware.com> <158731417810418@web3o.yandex.ru> <93911417991658@web27m.yandex.ru> <5485B4F6.2040104@kitware.com> <727251418150361@web27m.yandex.ru> <54876015.3090806@kitware.com> <1162201418162609@web1m.yandex.ru> Message-ID: Konstantin Podsvirov wrote: > The data now includes subfolders Help, Modules and Templates. > Why are Help (the rst set of files)? As they are used after installation? Yes. The Help files need to be mandatory too. They are used by cmake for showing documentation on the command line like cmake --help-command file > There are a series of resources that have not been specified. > Please look at the files in the folder: > > http://ifw.podsvirov.pro/cmake/dev/unspecified/ > > What components to include these files? Everything in share seems to be about '3rd party integration'. > > For example, files with different licenses? Probably the same component as the Copyright.txt file. Thanks, Steve. From brad.king at kitware.com Fri Dec 12 09:44:27 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 12 Dec 2014 09:44:27 -0500 Subject: [cmake-developers] Volunteering to maintain a new module: FindGSL.cmake In-Reply-To: <0458DF31F610EF42BFC78C497E806C7B3B5435CE@ECS-EXG-P-MB03.win.lanl.gov> References: <0458DF31F610EF42BFC78C497E806C7B3B53D706@ECS-EXG-P-MB03.win.lanl.gov> <0458DF31F610EF42BFC78C497E806C7B3B5435CE@ECS-EXG-P-MB03.win.lanl.gov> Message-ID: <548AFF4B.8080805@kitware.com> On 12/09/2014 05:56 PM, Thompson, KT wrote: > I made both of these recommended changes. Thanks. > set( GSL_INCLUDE_DIRS ${GSL_INCLUDE_DIR} CACHE PATH "Location of GSL include directives." ) > set( GSL_LIBRARIES ${GSL_LIBRARY};${GSL_CBLAS_LIBRARY} CACHE PATH "GSL libraries." ) These values should not be cached. They can be dropped from the mark_as_advanced call too. They are always re-computed from the cached values that compose them. Also please drop trailing whitespace from all source lines. > How does cmake provide tests for modules like this? > How is the correctness of the module checked before a release? > Do you simply rely on release candidates? Historically that is how it has been done. However more recently we've started adding tests for find modules. See Tests/FindGTK2 for example. It would be great to have tests come with this patch for FindGSL. There are two steps to adding tests for this module: 1. Add a Tests/FindGSL test. Have Tests/CMakeLists.txt add the test if some option is enabled. 2. Set up a nightly dashboard submission using instructions here: http://www.cmake.org/Wiki/CMake/Git/Dashboard Install GSL on the dashboard machine so the test can run. Add a dashboard_cache setting to the dashboard script to set the option to enable the test. Thanks, -Brad From brad.king at kitware.com Fri Dec 12 09:57:10 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 12 Dec 2014 09:57:10 -0500 Subject: [cmake-developers] FindMPI take 2 In-Reply-To: References: <54871E4E.6090308@kitware.com> Message-ID: <548B0246.5060905@kitware.com> On 12/11/2014 05:08 AM, Alin Marin Elena wrote: > I have attached a checked patch for linker. flags with the blocks merged. Thanks. I've applied the combined patch for -Xlinker options here: FindMPI: Extract -Xlinker options http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a0792c48 I'll wait for more iterations on the other side of this thread for the MPI compiler selection work. Thanks, -Brad From mantis at public.kitware.com Fri Dec 12 12:03:51 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Fri, 12 Dec 2014 12:03:51 -0500 Subject: [cmake-developers] [CMake 0015301]: FIND_LIBRARY_USE_LIB64_PATHS doesn't work on Windows OSes Message-ID: The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15301 ====================================================================== Reported By: jackcmedia Assigned To: ====================================================================== Project: CMake Issue ID: 15301 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-12-12 12:03 EST Last Modified: 2014-12-12 12:03 EST ====================================================================== Summary: FIND_LIBRARY_USE_LIB64_PATHS doesn't work on Windows OSes Description: Setting up a bi-arch cross-compiling script to generate 32 or 64 bit binaries on demand. Found that FIND_LIBRARY_USE_LIB64_PATHS doesn't work on Windows, failing to locate the 64 bit libraries placed on a folder named "lib64". Renaming said folder to "lib" makes it work as intended. Steps to Reproduce: 1.- Install CMake 3.0.2 (TDM-GCC's MinGW-w64 4.9.2 and CLion are my compiler and IDE of choice, but are not required). 2.- Set up SFML 2.1 64 bits, a third party library, like this: ??include ??lib64 (x64 libs) and set the CMake (or environmental variable) SFML_ROOT pointing to the root folder of the third party library. 3.- Create a minimal CMakeLists.txt, like the following: cmake_minimum_required(VERSION 2.8) project(CMakeTest LANGUAGES CXX) if("${CMAKE_SIZEOF_VOID_P}" EQUAL "8") ??message(WARNING "Target is 64 bits") else("${CMAKE_SIZEOF_VOID_P}" EQUAL "8") ??message(WARNING "Target is 32 bits") endif("${CMAKE_SIZEOF_VOID_P}" EQUAL "8") set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_LIB64_PATHS ON) set(CMAKE_MODULE_PATH "${CMAKE_SOURCE_DIR}/cmake/Modules" ${CMAKE_MODULE_PATH}) find_package(SFML 2.1 REQUIRED graphics system window) include_directories(${PROJECT_SOURCE_DIR}/) aux_source_directory(. SRC_LIST) add_executable(${PROJECT_NAME} ${SRC_LIST}) if(SFML_FOUND) ??include_directories(${SFML_INCLUDE_DIR}) ??target_link_libraries(${PROJECT_NAME} ${SFML_LIBRARIES}) endif() 4.- Create a minimal source file, like the following: #include int main() { ??sf::RenderWindow window2; ??return 0; } 5.- Download FindSFML.cmake from https://github.com/LaurentGomila/SFML/blob/2.1/cmake/Modules/FindSFML.cmake and add it to the project inside ${PROJECT_SOURCE_DIR}/cmake/Modules. 6.- Try to compile and confirm it fails to locate the libraries. 7.- Rename "lib64" to "lib" and compile again. This time, it's a success. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-12-12 12:03 jackcmedia New Issue ====================================================================== From sean at rogue-research.com Fri Dec 12 12:20:17 2014 From: sean at rogue-research.com (Sean McBride) Date: Fri, 12 Dec 2014 12:20:17 -0500 Subject: [cmake-developers] Fragile OS X version checks failing against 10.10 Message-ID: <20141212172017.894552485@mail.rogue-research.com> Hi all, Dunno why I didn't notice until now, but CMake seems to be doing some fragile checks for OS X version numbers. Specifically in cmCPackPackageMakerGenerator, at least 2 things: 1) a 'double' variable: this->PackageCompatibilityVersion = 10.4; 10.10 will compare like 10.1 there. 2) a regex: if(OSX_VERSION MATCHES "^10\\.[0123]" OR OSX_VERSION MATCHES "ProductVersion:\t10\\.[0123]") message(STATUS "Forcing CTEST_TEST_CPACK=OFF on OSX < 10.4") Cheers, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From brad.king at kitware.com Fri Dec 12 15:19:10 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 12 Dec 2014 15:19:10 -0500 Subject: [cmake-developers] Fragile OS X version checks failing against 10.10 In-Reply-To: <20141212172017.894552485@mail.rogue-research.com> References: <20141212172017.894552485@mail.rogue-research.com> Message-ID: <548B4DBE.4050203@kitware.com> On 12/12/2014 12:20 PM, Sean McBride wrote: > in cmCPackPackageMakerGenerator > this->PackageCompatibilityVersion = 10.4; I would appreciate help (a patch) for this one from anyone that is interested in trying to use the long-deprecated PackageMaker tool on OS X 10.10 or above. > if(OSX_VERSION MATCHES "^10\\.[0123]" OR OSX_VERSION MATCHES "ProductVersion:\t10\\.[0123]") Here is a fix for this one: Tests: Fix OS X version check to use component-wise test http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f53a3340 Thanks, -Brad From djouakr91 at gmail.com Fri Dec 12 16:24:53 2014 From: djouakr91 at gmail.com (djou akr) Date: Fri, 12 Dec 2014 22:24:53 +0100 Subject: [cmake-developers] Compiling with a programmatic way Message-ID: To whom it may concern I am trying to find how to compile in an automatic ( programmatically ) way a c++ file without the manual way in the terminal (I am on ubuntu) I mean, while a c++ file is executing it will compile another c++ file at run time. Of course this with the use of make and cmake. Thanks in advance Best regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From mantis at public.kitware.com Sat Dec 13 09:45:57 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sat, 13 Dec 2014 09:45:57 -0500 Subject: [cmake-developers] [CMake 0015303]: Turning off package registry Message-ID: The following issue has been SUBMITTED. ====================================================================== https://www.cmake.org/Bug/view.php?id=15303 ====================================================================== Reported By: scunz Assigned To: ====================================================================== Project: CMake Issue ID: 15303 Category: CMake Reproducibility: N/A Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-12-13 09:45 EST Last Modified: 2014-12-13 09:45 EST ====================================================================== Summary: Turning off package registry Description: Even though the package registry system is a nice and very welcome feature, I have 2 scenarios in which the automatic it is more of a burden than useful. I'd like to turn it off via a command line argument to cmake - Or more precise: I want to either turn off finding packages through the registry or turn off the writing to the registry. These scenarios are: 1. I'm running builds of a lot of libraries in a CI system. The builds each do a full fetch-source / build / install / archive results each. There are several different build jobs for each library. The libraries have a deep tree of dependencies on each other. The build trees are fully separated from each other. Build results from other projects (i.e. prerequisite libraries) are copied into a local install tree for each build. Occasionally, cmake now finds libraries inside other job's build trees and uses them, which I want to avoid. Thus, I'm removing the .cmake directory before each build right now. However, there's a race condition, that is triggered when one project is installing the config files into the registry while another job has just cleaned the registry and not yet finished the cmake run. Of course, I do not want to pollute the CMakeLists with conditionals that disable the registry on find_package calls (which would be a lot of work for me). For now, I simply do a "chmod 700 ~./.cmake && chown root:root ~/.cmake" on the CI system, but this seems more like a hack and causes some warnings... 2. (Less important) I have several source/build trees of the same libraries on my machines and the entries in the registry do not get stale (as build trees are always there) when I switch between these checkouts. I've worked around the occasional confusion this produces by always outputting the paths that have been found and check them manually on each cmake run. This is of course not an optimal solution. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-12-13 09:45 scunz New Issue ====================================================================== From ben.boeckel at kitware.com Sat Dec 13 13:05:00 2014 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Sat, 13 Dec 2014 13:05:00 -0500 Subject: [cmake-developers] OpenBSD and srand()/rand() changes In-Reply-To: References: <20141210143856.GA25671@megas.kitwarein.com> Message-ID: <20141213180500.GA3991@bronto-burt.dev.benboeckel.net> On Thu, Dec 11, 2014 at 14:41:36 -0500, David Cole via cmake-developers wrote: > Yes, setting an explicit seed should make subsequent calls to random > be deterministic... Well, *we* want that, but I don't think that OpenBSD is making an *awful* decision here. Even if you want deterministic, you're only deterministic on a single platform, so if you want to get a deterministicly random (such an odd phrase?) sequence, the best thing to do is to code up an Mersenne Twister or something and ignore the rand/srand functions. --Ben From DLRdave at aol.com Sat Dec 13 22:30:08 2014 From: DLRdave at aol.com (David Cole) Date: Sat, 13 Dec 2014 22:30:08 -0500 Subject: [cmake-developers] OpenBSD and srand()/rand() changes In-Reply-To: <20141213180500.GA3991@bronto-burt.dev.benboeckel.net> References: <20141210143856.GA25671@megas.kitwarein.com> <20141213180500.GA3991@bronto-burt.dev.benboeckel.net> Message-ID: The utility of the determinism is all about enabling test suites to pass even if they use "random" behavior. How the determinism is achieved, I don't really care. As long as tests that use "random" behavior have predictable results. It doesn't matter to me if they have platform differences. As long as the expected test results account for any differences that do exist, the goal can still be satisfied: predictable results. thx, D On Sat, Dec 13, 2014 at 1:05 PM, Ben Boeckel wrote: > On Thu, Dec 11, 2014 at 14:41:36 -0500, David Cole via cmake-developers wrote: >> Yes, setting an explicit seed should make subsequent calls to random >> be deterministic... > > Well, *we* want that, but I don't think that OpenBSD is making an > *awful* decision here. > > Even if you want deterministic, you're only deterministic on a single > platform, so if you want to get a deterministicly random (such an odd > phrase?) sequence, the best thing to do is to code up an Mersenne > Twister or something and ignore the rand/srand functions. > > --Ben From eike at sf-mail.de Sun Dec 14 02:26:15 2014 From: eike at sf-mail.de (Rolf Eike Beer) Date: Sun, 14 Dec 2014 08:26:15 +0100 Subject: [cmake-developers] OpenBSD and srand()/rand() changes In-Reply-To: <20141213180500.GA3991@bronto-burt.dev.benboeckel.net> References: <20141210143856.GA25671@megas.kitwarein.com> <20141213180500.GA3991@bronto-burt.dev.benboeckel.net> Message-ID: <5337458.5mnaS22u7t@caliban.sf-tec.de> Am Samstag, 13. Dezember 2014, 13:05:00 schrieben Sie: > On Thu, Dec 11, 2014 at 14:41:36 -0500, David Cole via cmake-developers wrote: > > Yes, setting an explicit seed should make subsequent calls to random > > be deterministic... > > Well, *we* want that, but I don't think that OpenBSD is making an > *awful* decision here. > > Even if you want deterministic, you're only deterministic on a single > platform, so if you want to get a deterministicly random (such an odd > phrase?) sequence, the best thing to do is to code up an Mersenne > Twister or something and ignore the rand/srand functions. Well, srand() and random() have ever been deterministic, and AFAIK using the same algorhtim and thus the same results on all supporting platforms, so it is the perfect choice for us. What is happening is that OpenBSD is fighting people that don't get that this is deterministic. Eike -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From micha.hergarden at gmail.com Sun Dec 14 04:22:06 2014 From: micha.hergarden at gmail.com (Micha Hergarden) Date: Sun, 14 Dec 2014 10:22:06 +0100 Subject: [cmake-developers] Compiling with a programmatic way In-Reply-To: References: Message-ID: <548D56BE.8060108@gmail.com> Hello Djou, You will be better of asking this question on the 'cmake' mailing list itself. That is geared towards cmake users. This list is for people developing cmake itself. Here is a cmake example to get you started: project(DEMO) cmake_minimum_required(VERSION 2.8) add_executable(demo main.cxx) If you save this to a file called CMakeLists.txt and create a build directory, you can call 'cmake ' (fill in the actual source directory) and cmake will generate a buildsystem for you (i.e. a Makefile or a visual studio project file). Then you just call 'make' in the case of a Makefile and your executable will be compiled for you. HTH, Micha On 12/12/2014 10:24 PM, djou akr wrote: > To whom it may concern > > I am trying to find how to compile in an automatic ( programmatically > ) way a c++ file without the manual way in the terminal (I am on ubuntu) > > I mean, while a c++ file is executing it will compile another c++ file > at run time. Of course this with the use of make and cmake. > > Thanks in advance > Best regards > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From DLRdave at aol.com Sun Dec 14 08:03:51 2014 From: DLRdave at aol.com (David Cole) Date: Sun, 14 Dec 2014 08:03:51 -0500 Subject: [cmake-developers] OpenBSD and srand()/rand() changes In-Reply-To: <5337458.5mnaS22u7t@caliban.sf-tec.de> References: <20141210143856.GA25671@megas.kitwarein.com> <20141213180500.GA3991@bronto-burt.dev.benboeckel.net> <5337458.5mnaS22u7t@caliban.sf-tec.de> Message-ID: Sounds to me like the perfect thing to just ignore till the dust settles. And then, after that, if there's no srand/rand on OpenBSD....... Well... There will be, won't there? On Sunday, December 14, 2014, Rolf Eike Beer wrote: > Am Samstag, 13. Dezember 2014, 13:05:00 schrieben Sie: > > On Thu, Dec 11, 2014 at 14:41:36 -0500, David Cole via cmake-developers > wrote: > > > Yes, setting an explicit seed should make subsequent calls to random > > > be deterministic... > > > > Well, *we* want that, but I don't think that OpenBSD is making an > > *awful* decision here. > > > > Even if you want deterministic, you're only deterministic on a single > > platform, so if you want to get a deterministicly random (such an odd > > phrase?) sequence, the best thing to do is to code up an Mersenne > > Twister or something and ignore the rand/srand functions. > > Well, srand() and random() have ever been deterministic, and AFAIK using > the > same algorhtim and thus the same results on all supporting platforms, so > it is > the perfect choice for us. What is happening is that OpenBSD is fighting > people > that don't get that this is deterministic. > > Eike -------------- next part -------------- An HTML attachment was scrubbed... URL: From eike at sf-mail.de Sun Dec 14 08:36:08 2014 From: eike at sf-mail.de (Rolf Eike Beer) Date: Sun, 14 Dec 2014 14:36:08 +0100 Subject: [cmake-developers] OpenBSD and srand()/rand() changes In-Reply-To: References: <20141210143856.GA25671@megas.kitwarein.com> <5337458.5mnaS22u7t@caliban.sf-tec.de> Message-ID: <2877892.UFApgEOuJf@eto> David Cole wrote: > Sounds to me like the perfect thing to just ignore till the dust settles. Yes, this will probably take a while until this shows up in a release version of OpenBSD. But if this is not reverted then it will probably be a good idea to have check for this in 3.2 ready so it will just work in the next release of OpenBSD. > And then, after that, if there's no srand/rand on OpenBSD....... Well... > There will be, won't there? There will be srand()/rand() on OpenBSD. It's just that srand() will be ignored and rand() will return really random numbers if there has not been a call to srand_deterministic() before, which will make rand() return the same numbers as on other platforms. The idea behind this API in OpenBSD is: if you are looking for the pseudo numbers you need to call srand_deterministic(), i.e. you must explicitely state that you want the not really random random numbers. Everyone else will get real random. Eike -- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From mantis at public.kitware.com Mon Dec 15 04:05:02 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Mon, 15 Dec 2014 04:05:02 -0500 Subject: [cmake-developers] [CMake 0015308]: CPack seg fault during stripping Message-ID: The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15308 ====================================================================== Reported By: Xi Yang Assigned To: ====================================================================== Project: CMake Issue ID: 15308 Category: CPack Reproducibility: always Severity: crash Priority: normal Status: new ====================================================================== Date Submitted: 2014-12-15 04:05 EST Last Modified: 2014-12-15 04:05 EST ====================================================================== Summary: CPack seg fault during stripping Description: While running cpack individually using a generated cpack configure file, it crashed without any error messages: $ cpack CPack: Create package using DEB CPack: Install projects Segmentation fault The backtrace: http://public.kitware.com/Bug/view.php?id=0 cmCPackGenerator::InstallProjectViaInstallCMakeProjects (this=0xa21be0, setDestDir=true, baseTempInstallDirectory=0xa28a48 "/home/yangxi/projects/GenoEye-build/package/deb/lib/_CPack_Packages/DEB/libgenoeye") at ../../Source/CPack/cmCPackGenerator.cxx:633 http://public.kitware.com/Bug/view.php?id=1 0x000000000049c954 in cmCPackGenerator::InstallProject (this=this at entry=0xa21be0) at ../../Source/CPack/cmCPackGenerator.cxx:257 http://public.kitware.com/Bug/view.php?id=2 0x000000000049cdef in cmCPackGenerator::DoPackage (this=0xa21be0) at ../../Source/CPack/cmCPackGenerator.cxx:1045 http://public.kitware.com/Bug/view.php?id=3 0x000000000048dfed in main (argc=, argv=) at ../../Source/CPack/cpack.cxx:434 Additional Information: The CPackConfig.cmake is attached, hopefully it could provide some hints. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-12-15 04:05 Xi Yang New Issue 2014-12-15 04:05 Xi Yang File Added: CPackConfig.cmake ====================================================================== From mantis at public.kitware.com Mon Dec 15 07:27:56 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Mon, 15 Dec 2014 13:27:56 +0100 Subject: [cmake-developers] [CMake 0015309]: 64 bit build of wxWidgets-2.8.12 is not found Message-ID: <32eb1d161a33d33ef491dbfdf3eafb50@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15309 ====================================================================== Reported By: Robert Pollak Assigned To: ====================================================================== Project: CMake Issue ID: 15309 Category: Modules Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2014-12-15 13:27 CET Last Modified: 2014-12-15 13:27 CET ====================================================================== Summary: 64 bit build of wxWidgets-2.8.12 is not found Description: The thread http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/51251/ ("64 bit build of wxWidgets-2.8.12 is not found") describes it: The patch of issue http://www.cmake.org/Bug/view.php?id=14393 [1] only deals with wxWidgets versions after 2.8.x. For finding 2.8.x, the module should look for "vc_amd64" instead of "vc_x64". [1] http://www.cmake.org/Bug/view.php?id=14393, "FindwxWidgets.cmake doesn't look for x64 wxWidgets (MSVC) directories." Steps to Reproduce: See the mailing list thread: - install wxMSW-2.8.12-Setup.exe - build 64-bit wxWidgets - try to find them with CMake. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-12-15 13:27 Robert Pollak New Issue ====================================================================== From brad.king at kitware.com Mon Dec 15 09:32:17 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 15 Dec 2014 09:32:17 -0500 Subject: [cmake-developers] OpenBSD and srand()/rand() changes In-Reply-To: <2877892.UFApgEOuJf@eto> References: <20141210143856.GA25671@megas.kitwarein.com> <5337458.5mnaS22u7t@caliban.sf-tec.de> <2877892.UFApgEOuJf@eto> Message-ID: <548EF0F1.7090200@kitware.com> On 12/14/2014 08:36 AM, Rolf Eike Beer wrote: > The idea behind this API in OpenBSD is: if you are looking for the pseudo > numbers you need to call srand_deterministic(), i.e. you must explicitely > state that you want the not really random random numbers. Everyone else will > get real random. CMake uses /dev/urandom on POSIX and wincrypt APIs on Windows to choose the seed specifically to get "really" random behavior. The *only* reason we continue to use s/rand() at all is to support the RANDOM_SEED API in string(RANDOM), AFAIK. One approach to dealing with this is to refactor the implementation of string(RANDOM) to use non-deterministic APIs until RANDOM_SEED is used and then use deterministic APIs after that. That will get better random values by default but still honor the existing API when it is used. -Brad From eike at sf-mail.de Mon Dec 15 11:48:21 2014 From: eike at sf-mail.de (Rolf Eike Beer) Date: Mon, 15 Dec 2014 17:48:21 +0100 Subject: [cmake-developers] OpenBSD and srand()/rand() changes In-Reply-To: <548EF0F1.7090200@kitware.com> References: <20141210143856.GA25671@megas.kitwarein.com> <2877892.UFApgEOuJf@eto> <548EF0F1.7090200@kitware.com> Message-ID: <2576021.RH2YmyoXAu@eto> Brad King wrote: > On 12/14/2014 08:36 AM, Rolf Eike Beer wrote: > > The idea behind this API in OpenBSD is: if you are looking for the pseudo > > numbers you need to call srand_deterministic(), i.e. you must explicitely > > state that you want the not really random random numbers. Everyone else > > will get real random. > > CMake uses /dev/urandom on POSIX and wincrypt APIs on Windows to choose > the seed specifically to get "really" random behavior. The *only* reason > we continue to use s/rand() at all is to support the RANDOM_SEED API in > string(RANDOM), AFAIK. > > One approach to dealing with this is to refactor the implementation of > string(RANDOM) to use non-deterministic APIs until RANDOM_SEED is used > and then use deterministic APIs after that. That will get better random > values by default but still honor the existing API when it is used. Which is what we would get if we do not call srand_deterministic() on OpenBSD afaict. We would get weaker random numbers on other platforms, but I doubt this matters at all. Eike -- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From DLRdave at aol.com Mon Dec 15 13:46:19 2014 From: DLRdave at aol.com (David Cole) Date: Mon, 15 Dec 2014 13:46:19 -0500 Subject: [cmake-developers] OpenBSD and srand()/rand() changes In-Reply-To: <2576021.RH2YmyoXAu@eto> References: <20141210143856.GA25671@megas.kitwarein.com> <2877892.UFApgEOuJf@eto> <548EF0F1.7090200@kitware.com> <2576021.RH2YmyoXAu@eto> Message-ID: Looking at our own internal test suite usage of RANDOM_SEED leads to the conclusion that we do not verify the sequences produced when actually using RANDOM_SEED...... So, from our point of view, we don't really care about what effect RANDOM_SEED has for our test suite. But I think we do still care that it maintains its existing behavior for folks who are using it: some clients may depend on it producing a deterministic sequence. If you don't use RANDOM_SEED, you should get as random a sequence as possible when using RANDOM. If you do use RANDOM_SEED, you should see a deterministic sequence for subsequent uses of RANDOM in the same run of cmake. Just my opinion, David C. On Mon, Dec 15, 2014 at 11:48 AM, Rolf Eike Beer wrote: > Brad King wrote: >> On 12/14/2014 08:36 AM, Rolf Eike Beer wrote: >> > The idea behind this API in OpenBSD is: if you are looking for the pseudo >> > numbers you need to call srand_deterministic(), i.e. you must explicitely >> > state that you want the not really random random numbers. Everyone else >> > will get real random. >> >> CMake uses /dev/urandom on POSIX and wincrypt APIs on Windows to choose >> the seed specifically to get "really" random behavior. The *only* reason >> we continue to use s/rand() at all is to support the RANDOM_SEED API in >> string(RANDOM), AFAIK. >> >> One approach to dealing with this is to refactor the implementation of >> string(RANDOM) to use non-deterministic APIs until RANDOM_SEED is used >> and then use deterministic APIs after that. That will get better random >> values by default but still honor the existing API when it is used. > > Which is what we would get if we do not call srand_deterministic() on OpenBSD > afaict. We would get weaker random numbers on other platforms, but I doubt > this matters at all. > > 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-developers From Robert.Goulet at autodesk.com Mon Dec 15 16:01:38 2014 From: Robert.Goulet at autodesk.com (Robert Goulet) Date: Mon, 15 Dec 2014 21:01:38 +0000 Subject: [cmake-developers] CMake 3.1 Android - generator expressions and output names In-Reply-To: References: <547E24E7.8040109@kitware.com> Message-ID: Hi Dmitry, I just tried to upgrade to 3.0r4 and it still defaults the Visual Project setting of "Language -> C++ Language Standard" to "Default". I need to set it to C++11 somehow, otherwise I get many errors that the C++11 code we are using in our engine cannot compile. This will either need to be fixed in CMake through a new variable or in the NVidia NSight Tegra package? Furthermore, upgrading to 3.0r4 has added a popup when opening the solution in Visual Studio, stating that the project files generated needs to be upgraded. Its upgrading the setting "Preserve native API level" to some value. My guess it that the CMake generator doesn't set the proper default value for this version of NSight. -----Original Message----- From: Dmitry Polyanitsa [mailto:dpolyanitsa at nvidia.com] Sent: Wednesday, December 3, 2014 11:14 AM To: Robert Goulet; Brad King Cc: cmake-developers at cmake.org Subject: RE: [cmake-developers] CMake 3.1 Android - generator expressions and output names We usually advise to upgrade to the latest version. The transition should be smooth, but you may want to install TADP 3.0r4 on one of the machines first to check all's good before updating it everywhere. In case of any issues or questions you can contact me directly via email. -Dmitry -----Original Message----- From: Robert Goulet [mailto:Robert.Goulet at autodesk.com] Sent: Wednesday, December 3, 2014 7:03 PM To: Dmitry Polyanitsa; Brad King Cc: cmake-developers at cmake.org Subject: RE: [cmake-developers] CMake 3.1 Android - generator expressions and output names We are currently using 3.0-r3, and I am guessing this version doesn't use C++11 by default. You are saying that the latest release should fix this, because it defaults to C++11? I am not sure what are the implications of upgrading our engine with this new version. Should we expect the transition to go smoothly? We have to decide on a final version for the release, what's your thoughts on this? Thanks! -----Original Message----- From: Dmitry Polyanitsa [mailto:dpolyanitsa at nvidia.com] Sent: Wednesday, December 3, 2014 10:46 AM To: Robert Goulet; Brad King Cc: cmake-developers at cmake.org Subject: RE: [cmake-developers] CMake 3.1 Android - generator expressions and output names Hi Robert, I'm Dmitry from the Nsight Tegra team. Currently, we do not allow changing the APK name, so copying/moving the outputs is the best you can do. As for the language standard override, latest Nsight Tegra uses C++11 by default, why would you want to set it explicitly? -Dmitry -----Original Message----- From: Robert Goulet [mailto:Robert.Goulet at autodesk.com] Sent: Wednesday, December 3, 2014 12:28 AM To: Brad King Cc: cmake-developers at cmake.org Subject: RE: [cmake-developers] CMake 3.1 Android - generator expressions and output names I can't find any options to set the .apk name from the IDE, but I find it interesting that it uses the project's name instead of the output file name set in the IDE. Hence why I wonder if its CMake result or if its NVidia's Tegra toolkit? But I have a work-around for that, using add_custom_command to do a copy using ${CMAKE_COMMAND} -E copy. So my only issue left is the fact that I will have to use set_source_properties to pass the -std=c++11 flag instead of being able to set the "C++ Language Standard" option. That is a bit annoying, is there a better work-around? Thanks! -----Original Message----- From: Brad King [mailto:brad.king at kitware.com] Sent: Tuesday, December 2, 2014 3:45 PM To: Robert Goulet Cc: cmake-developers at cmake.org Subject: Re: [cmake-developers] CMake 3.1 Android - generator expressions and output names Hi Robert, Thanks for trying out the Nsight Tegra generator support. It is brand new so we are just at the beginning of the maturation process. We would appreciate any help you can provide. On 12/02/2014 02:24 PM, Robert Goulet wrote: > Perhaps it would be nice to have a generator expression that refers to > the .apk file produced when compiling for Android? This may be possible, but first we should work out the output name and location settings as discussed next. > Also, it would make sense that the .apk output name respect the names > that we set using the target properties OUTPUT_NAME_. Right > now it uses the project's name for the .apk, while the .so does indeed > respect the output name set. Is it possible to configure the .apk name through the IDE? If so, CMake could be taught to add the corresponding setting to the .vcxproj file. If not, then Nsight Tegra itself would have to be modified by NVIDIA to support such a setting. Some output directory settings may be needed too. We have RUNTIME_OUTPUT_DIRECTORY, LIBRARY_OUTPUT_DIRECTORY, and ARCHIVE_OUTPUT_DIRECTORY already. I'm not sure if one of these should apply to the .apk, or if another setting would be needed. Also the availability of Nsight Tegra settings for this needs to be investigated. > C++ Language Standard to other values than Default? I don't think there is currently. The commit adding the original support was: VS: Teach vcxproj generation about the Tegra-Android platform http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ef0fd4f0 The commit message documents many of the limitations. Only the last bullet (ANDROID_GUI prop) and part of the second bullet (ANDROID_API prop) have been addressed so far. The lack of a flag table or other controls for the rest of the project settings is currently the main limitation. -Brad ----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ----------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpolyanitsa at nvidia.com Tue Dec 16 06:58:09 2014 From: dpolyanitsa at nvidia.com (Dmitry Polyanitsa) Date: Tue, 16 Dec 2014 11:58:09 +0000 Subject: [cmake-developers] CMake 3.1 Android - generator expressions and output names In-Reply-To: References: <547E24E7.8040109@kitware.com> Message-ID: <7ac316f6d59a4ea682b76ba003c1fb05@UKMAIL102.nvidia.com> Hi Robert, > I just tried to upgrade to 3.0r4 and it still defaults the Visual Project setting of "Language -> C++ Language Standard" to "Default". I need to set it to C++11 somehow, otherwise I get many errors that the C++11 code we are using in our engine cannot compile. This will either need to be fixed in CMake through a new variable or in the NVidia NSight Tegra package? I was wrong about this. We're using C++11 by default only in our template projects, the default value still being left up to the compiler to decide (== don't pass the standard-changing flags). I'm afraid for the time being you'll need to use the workaround you've already mentioned. We'll probably add some Nsight Tegra specific properties to CMake in the future and when we do, we'll make sure C++ Language Standard will be one of them. > Furthermore, upgrading to 3.0r4 has added a popup when opening the solution in Visual Studio, stating that the project files generated needs to be upgraded. Its upgrading the setting "Preserve native API level" to some value. My guess it that the CMake generator doesn't set the proper default value for this version of NSight. I'm sure I've submitted a patch for this - please try updating CMake to a newer RC or nightly and see if the problem goes away. -Dmitry From: Robert Goulet [mailto:Robert.Goulet at autodesk.com] Sent: Tuesday, December 16, 2014 12:02 AM To: Dmitry Polyanitsa; Brad King Cc: cmake-developers at cmake.org Subject: RE: [cmake-developers] CMake 3.1 Android - generator expressions and output names Hi Dmitry, I just tried to upgrade to 3.0r4 and it still defaults the Visual Project setting of "Language -> C++ Language Standard" to "Default". I need to set it to C++11 somehow, otherwise I get many errors that the C++11 code we are using in our engine cannot compile. This will either need to be fixed in CMake through a new variable or in the NVidia NSight Tegra package? Furthermore, upgrading to 3.0r4 has added a popup when opening the solution in Visual Studio, stating that the project files generated needs to be upgraded. Its upgrading the setting "Preserve native API level" to some value. My guess it that the CMake generator doesn't set the proper default value for this version of NSight. -----Original Message----- From: Dmitry Polyanitsa [mailto:dpolyanitsa at nvidia.com] Sent: Wednesday, December 3, 2014 11:14 AM To: Robert Goulet; Brad King Cc: cmake-developers at cmake.org Subject: RE: [cmake-developers] CMake 3.1 Android - generator expressions and output names We usually advise to upgrade to the latest version. The transition should be smooth, but you may want to install TADP 3.0r4 on one of the machines first to check all's good before updating it everywhere. In case of any issues or questions you can contact me directly via email. -Dmitry -----Original Message----- From: Robert Goulet [mailto:Robert.Goulet at autodesk.com] Sent: Wednesday, December 3, 2014 7:03 PM To: Dmitry Polyanitsa; Brad King Cc: cmake-developers at cmake.org Subject: RE: [cmake-developers] CMake 3.1 Android - generator expressions and output names We are currently using 3.0-r3, and I am guessing this version doesn't use C++11 by default. You are saying that the latest release should fix this, because it defaults to C++11? I am not sure what are the implications of upgrading our engine with this new version. Should we expect the transition to go smoothly? We have to decide on a final version for the release, what's your thoughts on this? Thanks! -----Original Message----- From: Dmitry Polyanitsa [mailto:dpolyanitsa at nvidia.com] Sent: Wednesday, December 3, 2014 10:46 AM To: Robert Goulet; Brad King Cc: cmake-developers at cmake.org Subject: RE: [cmake-developers] CMake 3.1 Android - generator expressions and output names Hi Robert, I'm Dmitry from the Nsight Tegra team. Currently, we do not allow changing the APK name, so copying/moving the outputs is the best you can do. As for the language standard override, latest Nsight Tegra uses C++11 by default, why would you want to set it explicitly? -Dmitry -----Original Message----- From: Robert Goulet [mailto:Robert.Goulet at autodesk.com] Sent: Wednesday, December 3, 2014 12:28 AM To: Brad King Cc: cmake-developers at cmake.org Subject: RE: [cmake-developers] CMake 3.1 Android - generator expressions and output names I can't find any options to set the .apk name from the IDE, but I find it interesting that it uses the project's name instead of the output file name set in the IDE. Hence why I wonder if its CMake result or if its NVidia's Tegra toolkit? But I have a work-around for that, using add_custom_command to do a copy using ${CMAKE_COMMAND} -E copy. So my only issue left is the fact that I will have to use set_source_properties to pass the -std=c++11 flag instead of being able to set the "C++ Language Standard" option. That is a bit annoying, is there a better work-around? Thanks! -----Original Message----- From: Brad King [mailto:brad.king at kitware.com] Sent: Tuesday, December 2, 2014 3:45 PM To: Robert Goulet Cc: cmake-developers at cmake.org Subject: Re: [cmake-developers] CMake 3.1 Android - generator expressions and output names Hi Robert, Thanks for trying out the Nsight Tegra generator support. It is brand new so we are just at the beginning of the maturation process. We would appreciate any help you can provide. On 12/02/2014 02:24 PM, Robert Goulet wrote: > Perhaps it would be nice to have a generator expression that refers to > the .apk file produced when compiling for Android? This may be possible, but first we should work out the output name and location settings as discussed next. > Also, it would make sense that the .apk output name respect the names > that we set using the target properties OUTPUT_NAME_. Right > now it uses the project's name for the .apk, while the .so does indeed > respect the output name set. Is it possible to configure the .apk name through the IDE? If so, CMake could be taught to add the corresponding setting to the .vcxproj file. If not, then Nsight Tegra itself would have to be modified by NVIDIA to support such a setting. Some output directory settings may be needed too. We have RUNTIME_OUTPUT_DIRECTORY, LIBRARY_OUTPUT_DIRECTORY, and ARCHIVE_OUTPUT_DIRECTORY already. I'm not sure if one of these should apply to the .apk, or if another setting would be needed. Also the availability of Nsight Tegra settings for this needs to be investigated. > C++ Language Standard to other values than Default? I don't think there is currently. The commit adding the original support was: VS: Teach vcxproj generation about the Tegra-Android platform http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ef0fd4f0 The commit message documents many of the limitations. Only the last bullet (ANDROID_GUI prop) and part of the second bullet (ANDROID_API prop) have been addressed so far. The lack of a flag table or other controls for the rest of the project settings is currently the main limitation. -Brad ----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ----------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Tue Dec 16 08:29:38 2014 From: brad.king at kitware.com (Brad King) Date: Tue, 16 Dec 2014 08:29:38 -0500 Subject: [cmake-developers] CMake 3.1 Android - generator expressions and output names In-Reply-To: <7ac316f6d59a4ea682b76ba003c1fb05@UKMAIL102.nvidia.com> References: <547E24E7.8040109@kitware.com> <7ac316f6d59a4ea682b76ba003c1fb05@UKMAIL102.nvidia.com> Message-ID: <549033C2.7070803@kitware.com> On 12/16/2014 06:58 AM, Dmitry Polyanitsa wrote: >> 3.0r4 has added a popup when opening the solution in Visual Studio >> stating that the project files generated needs to be upgraded. > > I'm sure I've submitted a patch for this ? please try updating CMake IIUC the patch was this one: VS: Change Nsight Tegra 2.0 Project Revision Number from 8 to 9 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bb3c87f1 and is available in 3.1.0-rc3. However, CMake cannot predict future version numbers, so it writes a "NsightTegraUpgradeOnceWithoutPrompt" element into the project file. Nsight Tegra is supposed to upgrade such projects without any popup. -Brad From dpolyanitsa at nvidia.com Tue Dec 16 08:45:38 2014 From: dpolyanitsa at nvidia.com (Dmitry Polyanitsa) Date: Tue, 16 Dec 2014 13:45:38 +0000 Subject: [cmake-developers] CMake 3.1 Android - generator expressions and output names In-Reply-To: <549033C2.7070803@kitware.com> References: <547E24E7.8040109@kitware.com> <7ac316f6d59a4ea682b76ba003c1fb05@UKMAIL102.nvidia.com> <549033C2.7070803@kitware.com> Message-ID: <5424b682cea744a79adae0775ad3f29f@UKMAIL102.nvidia.com> Yes, that's the one. Nsight Tegra will upgrade the projects without a prompt, but only starting with the next version number increase. -Dmitry -----Original Message----- From: Brad King [mailto:brad.king at kitware.com] Sent: Tuesday, December 16, 2014 4:30 PM To: Robert Goulet Cc: Dmitry Polyanitsa; cmake-developers at cmake.org Subject: Re: [cmake-developers] CMake 3.1 Android - generator expressions and output names On 12/16/2014 06:58 AM, Dmitry Polyanitsa wrote: >> 3.0r4 has added a popup when opening the solution in Visual Studio >> stating that the project files generated needs to be upgraded. > > I'm sure I've submitted a patch for this - please try updating CMake IIUC the patch was this one: VS: Change Nsight Tegra 2.0 Project Revision Number from 8 to 9 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bb3c87f1 and is available in 3.1.0-rc3. However, CMake cannot predict future version numbers, so it writes a "NsightTegraUpgradeOnceWithoutPrompt" element into the project file. Nsight Tegra is supposed to upgrade such projects without any popup. -Brad ----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ----------------------------------------------------------------------------------- From d3ck0r at gmail.com Tue Dec 16 10:04:54 2014 From: d3ck0r at gmail.com (J Decker) Date: Tue, 16 Dec 2014 07:04:54 -0800 Subject: [cmake-developers] CMake 3.1 Android - generator expressions and output names In-Reply-To: <5424b682cea744a79adae0775ad3f29f@UKMAIL102.nvidia.com> References: <547E24E7.8040109@kitware.com> <7ac316f6d59a4ea682b76ba003c1fb05@UKMAIL102.nvidia.com> <549033C2.7070803@kitware.com> <5424b682cea744a79adae0775ad3f29f@UKMAIL102.nvidia.com> Message-ID: Set_source_files_properties( *test2.c** PROPERTIES** LANGUAGE CXX** )* http://www.cmake.org/pipermail/cmake/2008-July/022647.html On Tue, Dec 16, 2014 at 5:45 AM, Dmitry Polyanitsa wrote: > > Yes, that's the one. > > Nsight Tegra will upgrade the projects without a prompt, but only starting > with the next version number increase. > > -Dmitry > > -----Original Message----- > From: Brad King [mailto:brad.king at kitware.com] > Sent: Tuesday, December 16, 2014 4:30 PM > To: Robert Goulet > Cc: Dmitry Polyanitsa; cmake-developers at cmake.org > Subject: Re: [cmake-developers] CMake 3.1 Android - generator expressions > and output names > > On 12/16/2014 06:58 AM, Dmitry Polyanitsa wrote: > >> 3.0r4 has added a popup when opening the solution in Visual Studio > >> stating that the project files generated needs to be upgraded. > > > > I'm sure I've submitted a patch for this - please try updating CMake > > IIUC the patch was this one: > > VS: Change Nsight Tegra 2.0 Project Revision Number from 8 to 9 > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bb3c87f1 > > and is available in 3.1.0-rc3. > > However, CMake cannot predict future version numbers, so it writes a > "NsightTegraUpgradeOnceWithoutPrompt" element into the project file. > Nsight Tegra is supposed to upgrade such projects without any popup. > > -Brad > > > ----------------------------------------------------------------------------------- > This email message is for the sole use of the intended recipient(s) and > may contain > confidential information. Any unauthorized review, use, disclosure or > distribution > is prohibited. If you are not the intended recipient, please contact the > sender by > reply email and destroy all copies of the original message. > > ----------------------------------------------------------------------------------- > -- > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Robert.Goulet at autodesk.com Tue Dec 16 10:58:22 2014 From: Robert.Goulet at autodesk.com (Robert Goulet) Date: Tue, 16 Dec 2014 15:58:22 +0000 Subject: [cmake-developers] CMake 3.1 Android - generator expressions and output names In-Reply-To: <5424b682cea744a79adae0775ad3f29f@UKMAIL102.nvidia.com> References: <547E24E7.8040109@kitware.com> <7ac316f6d59a4ea682b76ba003c1fb05@UKMAIL102.nvidia.com> <549033C2.7070803@kitware.com> <5424b682cea744a79adae0775ad3f29f@UKMAIL102.nvidia.com> Message-ID: Upgrading to CMake 3.1-rc3 indeed fixed the upgrade popup upon opening generated solution/project files when using NVidia NSight Tegra 3.0r4, however the value of "Native Android API Level" seems to default to "Use Min Android API Level" instead of the expected "Use Target Android API Level". Since we cannot set the Min or the Native API Level explicitly in CMake, this is a regression when upgrading to NVidia NSight Tegra 3.0r4 (from 3.0r3). I guess we will have to stick with NVidia NSight Tegra 3.0r3 for now. -----Original Message----- From: Dmitry Polyanitsa [mailto:dpolyanitsa at nvidia.com] Sent: Tuesday, December 16, 2014 8:46 AM To: Brad King; Robert Goulet Cc: cmake-developers at cmake.org Subject: RE: [cmake-developers] CMake 3.1 Android - generator expressions and output names Yes, that's the one. Nsight Tegra will upgrade the projects without a prompt, but only starting with the next version number increase. -Dmitry -----Original Message----- From: Brad King [mailto:brad.king at kitware.com] Sent: Tuesday, December 16, 2014 4:30 PM To: Robert Goulet Cc: Dmitry Polyanitsa; cmake-developers at cmake.org Subject: Re: [cmake-developers] CMake 3.1 Android - generator expressions and output names On 12/16/2014 06:58 AM, Dmitry Polyanitsa wrote: >> 3.0r4 has added a popup when opening the solution in Visual Studio >> stating that the project files generated needs to be upgraded. > > I'm sure I've submitted a patch for this - please try updating CMake IIUC the patch was this one: VS: Change Nsight Tegra 2.0 Project Revision Number from 8 to 9 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bb3c87f1 and is available in 3.1.0-rc3. However, CMake cannot predict future version numbers, so it writes a "NsightTegraUpgradeOnceWithoutPrompt" element into the project file. Nsight Tegra is supposed to upgrade such projects without any popup. -Brad ----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ----------------------------------------------------------------------------------- From dpolyanitsa at nvidia.com Tue Dec 16 11:09:21 2014 From: dpolyanitsa at nvidia.com (Dmitry Polyanitsa) Date: Tue, 16 Dec 2014 16:09:21 +0000 Subject: [cmake-developers] CMake 3.1 Android - generator expressions and output names In-Reply-To: References: <547E24E7.8040109@kitware.com> <7ac316f6d59a4ea682b76ba003c1fb05@UKMAIL102.nvidia.com> <549033C2.7070803@kitware.com> <5424b682cea744a79adae0775ad3f29f@UKMAIL102.nvidia.com> Message-ID: <47b52e386fec464994c22b1ab0259d7c@UKMAIL102.nvidia.com> Native Android API Level really should be the same as Min Android API Level, otherwise you might have problems in runtime. The upgrade action sets this property to Use Target Android API Level only for the sake of compatibility between Nsight Tegra versions, but we strongly encourage our users to switch it back to Use Min. We will show a warning if the Native and Min API Levels are not the same (Google's ndk-build does it as well). -Dmitry -----Original Message----- From: Robert Goulet [mailto:Robert.Goulet at autodesk.com] Sent: Tuesday, December 16, 2014 6:58 PM To: Dmitry Polyanitsa; Brad King Cc: cmake-developers at cmake.org Subject: RE: [cmake-developers] CMake 3.1 Android - generator expressions and output names Upgrading to CMake 3.1-rc3 indeed fixed the upgrade popup upon opening generated solution/project files when using NVidia NSight Tegra 3.0r4, however the value of "Native Android API Level" seems to default to "Use Min Android API Level" instead of the expected "Use Target Android API Level". Since we cannot set the Min or the Native API Level explicitly in CMake, this is a regression when upgrading to NVidia NSight Tegra 3.0r4 (from 3.0r3). I guess we will have to stick with NVidia NSight Tegra 3.0r3 for now. -----Original Message----- From: Dmitry Polyanitsa [mailto:dpolyanitsa at nvidia.com] Sent: Tuesday, December 16, 2014 8:46 AM To: Brad King; Robert Goulet Cc: cmake-developers at cmake.org Subject: RE: [cmake-developers] CMake 3.1 Android - generator expressions and output names Yes, that's the one. Nsight Tegra will upgrade the projects without a prompt, but only starting with the next version number increase. -Dmitry -----Original Message----- From: Brad King [mailto:brad.king at kitware.com] Sent: Tuesday, December 16, 2014 4:30 PM To: Robert Goulet Cc: Dmitry Polyanitsa; cmake-developers at cmake.org Subject: Re: [cmake-developers] CMake 3.1 Android - generator expressions and output names On 12/16/2014 06:58 AM, Dmitry Polyanitsa wrote: >> 3.0r4 has added a popup when opening the solution in Visual Studio >> stating that the project files generated needs to be upgraded. > > I'm sure I've submitted a patch for this - please try updating CMake IIUC the patch was this one: VS: Change Nsight Tegra 2.0 Project Revision Number from 8 to 9 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bb3c87f1 and is available in 3.1.0-rc3. However, CMake cannot predict future version numbers, so it writes a "NsightTegraUpgradeOnceWithoutPrompt" element into the project file. Nsight Tegra is supposed to upgrade such projects without any popup. -Brad ----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ----------------------------------------------------------------------------------- From Robert.Goulet at autodesk.com Tue Dec 16 11:35:56 2014 From: Robert.Goulet at autodesk.com (Robert Goulet) Date: Tue, 16 Dec 2014 16:35:56 +0000 Subject: [cmake-developers] CMake 3.1 Android - generator expressions and output names In-Reply-To: <47b52e386fec464994c22b1ab0259d7c@UKMAIL102.nvidia.com> References: <547E24E7.8040109@kitware.com> <7ac316f6d59a4ea682b76ba003c1fb05@UKMAIL102.nvidia.com> <549033C2.7070803@kitware.com> <5424b682cea744a79adae0775ad3f29f@UKMAIL102.nvidia.com> <47b52e386fec464994c22b1ab0259d7c@UKMAIL102.nvidia.com> Message-ID: Yes but in our case, we target API 19 (4.4), and min seems to defaults to 9 (2.3) with CMake, and if we leave the native API to use the min, then it fails to find GLES 3.0 headers. It only works if I set the native API to Target instead of Min. Perhaps I misunderstood something? -----Original Message----- From: Dmitry Polyanitsa [mailto:dpolyanitsa at nvidia.com] Sent: Tuesday, December 16, 2014 11:09 AM To: Robert Goulet; Brad King Cc: cmake-developers at cmake.org Subject: RE: [cmake-developers] CMake 3.1 Android - generator expressions and output names Native Android API Level really should be the same as Min Android API Level, otherwise you might have problems in runtime. The upgrade action sets this property to Use Target Android API Level only for the sake of compatibility between Nsight Tegra versions, but we strongly encourage our users to switch it back to Use Min. We will show a warning if the Native and Min API Levels are not the same (Google's ndk-build does it as well). -Dmitry -----Original Message----- From: Robert Goulet [mailto:Robert.Goulet at autodesk.com] Sent: Tuesday, December 16, 2014 6:58 PM To: Dmitry Polyanitsa; Brad King Cc: cmake-developers at cmake.org Subject: RE: [cmake-developers] CMake 3.1 Android - generator expressions and output names Upgrading to CMake 3.1-rc3 indeed fixed the upgrade popup upon opening generated solution/project files when using NVidia NSight Tegra 3.0r4, however the value of "Native Android API Level" seems to default to "Use Min Android API Level" instead of the expected "Use Target Android API Level". Since we cannot set the Min or the Native API Level explicitly in CMake, this is a regression when upgrading to NVidia NSight Tegra 3.0r4 (from 3.0r3). I guess we will have to stick with NVidia NSight Tegra 3.0r3 for now. -----Original Message----- From: Dmitry Polyanitsa [mailto:dpolyanitsa at nvidia.com] Sent: Tuesday, December 16, 2014 8:46 AM To: Brad King; Robert Goulet Cc: cmake-developers at cmake.org Subject: RE: [cmake-developers] CMake 3.1 Android - generator expressions and output names Yes, that's the one. Nsight Tegra will upgrade the projects without a prompt, but only starting with the next version number increase. -Dmitry -----Original Message----- From: Brad King [mailto:brad.king at kitware.com] Sent: Tuesday, December 16, 2014 4:30 PM To: Robert Goulet Cc: Dmitry Polyanitsa; cmake-developers at cmake.org Subject: Re: [cmake-developers] CMake 3.1 Android - generator expressions and output names On 12/16/2014 06:58 AM, Dmitry Polyanitsa wrote: >> 3.0r4 has added a popup when opening the solution in Visual Studio >> stating that the project files generated needs to be upgraded. > > I'm sure I've submitted a patch for this - please try updating CMake IIUC the patch was this one: VS: Change Nsight Tegra 2.0 Project Revision Number from 8 to 9 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bb3c87f1 and is available in 3.1.0-rc3. However, CMake cannot predict future version numbers, so it writes a "NsightTegraUpgradeOnceWithoutPrompt" element into the project file. Nsight Tegra is supposed to upgrade such projects without any popup. -Brad ----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ----------------------------------------------------------------------------------- From kgt at lanl.gov Tue Dec 16 13:36:22 2014 From: kgt at lanl.gov (Thompson, KT) Date: Tue, 16 Dec 2014 18:36:22 +0000 Subject: [cmake-developers] Volunteering to maintain a new module: FindGSL.cmake In-Reply-To: <548AFF4B.8080805@kitware.com> References: <0458DF31F610EF42BFC78C497E806C7B3B53D706@ECS-EXG-P-MB03.win.lanl.gov> <0458DF31F610EF42BFC78C497E806C7B3B5435CE@ECS-EXG-P-MB03.win.lanl.gov> <548AFF4B.8080805@kitware.com> Message-ID: <0458DF31F610EF42BFC78C497E806C7B3B577B79@ECS-EXG-P-MB03.win.lanl.gov> Brad, I made the changes that you suggested wrt removing trailing whitespace and removing variables from the cache. I also reverted a recent change by replacing GSL_CONFIG_EXECUTABLE with GSL_CONFIG to remain consistent with the naming conventions of PkgConfig.cmake. The updated FindGSL.cmake is attached. I also created a simple test for the new module (see attached FindGSL.tgz). If ENABLE_FINDGSL_TEST is true, this test will be included. I am setting up a nightly cmake regression on one of my machines that will run this test. In addition to the new files found in FindGSL.tgz, the Tests/CMakeLists.txt will require this simple addition: --- a/Tests/CMakeLists.txt +++ b/Tests/CMakeLists.txt @@ -1252,6 +1252,11 @@ ${CMake_BINARY_DIR}/bin/cmake -DDIR=dev -P ${CMake_SOURCE_DIR}/Utilities/Release add_subdirectory(FindGTK2) endif() + find_package(GSL QUIET) + if(GSL_FOUND AND ENABLE_FINDGSL_TEST) + add_subdirectory(FindGSL) + endif() + add_test(ExternalProject ${CMAKE_CTEST_COMMAND} --build-and-test "${CMake_SOURCE_DIR}/Tests/ExternalProject" I can build build and test cmake with my new tests in my local sandbox so I have some confidence that the test is working as intended. I don't know how to check the testing code in the cmake regression system w/o it being checked into git. Let me know how I should proceed. -kt -------------- next part -------------- A non-text attachment was scrubbed... Name: FindGSL.cmake Type: application/octet-stream Size: 9500 bytes Desc: FindGSL.cmake URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: FindGSL.tgz Type: application/x-compressed Size: 952 bytes Desc: FindGSL.tgz URL: From mantis at public.kitware.com Tue Dec 16 14:46:05 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 16 Dec 2014 14:46:05 -0500 Subject: [cmake-developers] [CMake 0015311]: CMAKE_CXX_KNOWN_FEATURES variable documentation should be corrected Message-ID: <3d98ae8b9aafb1f961d06b1b61dc275a@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15311 ====================================================================== Reported By: Pawe? Stankowski Assigned To: ====================================================================== Project: CMake Issue ID: 15311 Category: CMake Reproducibility: always Severity: text Priority: high Status: new ====================================================================== Date Submitted: 2014-12-16 14:46 EST Last Modified: 2014-12-16 14:46 EST ====================================================================== Summary: CMAKE_CXX_KNOWN_FEATURES variable documentation should be corrected Description: CMake 3.1 documentation available at www.cmake.org contains reference to obsolete documentation of override control features. According to [[http://msdn.microsoft.com/en-us/library/hh567368.aspx|http://msdn.microsoft.com/en-us/library/hh567368.aspx]], final version of override control in C++11 is based on changes from N3206 and N3272 documents. It means that defining \[\[hiding\]\],\[\[override\]\] and other attributes and hiding control are not part of C++11 Standard. Current CMake documentation: cxx_final Override control final keyword, as defined in N2928. cxx_override Override control override keyword, as defined in N2928. Even CMake unit tests Tests/CompileFeatures/cxx_{final,override}.cpp check only for 'override' keyword support, and not for attributes support from N2928. There is a bug in GCC site, which potencially could be a reason for this one. [[https://gcc.gnu.org/gcc-4.7/changes.html|GCC 4.7 changes page]] contains an example of usage for 'override' keyword (and not attribute), but [[https://gcc.gnu.org/gcc-4.7/cxx0x_status.html|Status of Experimental C++11 Support in GCC 4.7]] page lists only proposal N2928 as the one being implemented. This bug was fixed at general [[https://gcc.gnu.org/projects/cxx0x.html|C++0x/C++11 Support in GCC]] page. Btw: Support for C++11 attribute syntax was added in [[https://gcc.gnu.org/gcc-4.8/changes.html|g++ 4.8]]. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-12-16 14:46 Pawe? StankowskiNew Issue ====================================================================== From gjasny at googlemail.com Tue Dec 16 16:22:06 2014 From: gjasny at googlemail.com (Gregor Jasny) Date: Tue, 16 Dec 2014 22:22:06 +0100 Subject: [cmake-developers] [PATCH 0/4] XCTest Bundles v2 Message-ID: Hello, I addressed all the comments you gave about the last series. changes to v1: * Slit out independent patches * Restrict testing to Cocoa Applications because I have not managed to test Frameworks without crashing Xcode * cross referenced properties * Enhanced error logs in Xcode generator open issues: * if a fatal error is issued in cmGlobalXCodeGenerator::CreateBuildSettings generation does not stop. So you'll see the error for every configuration. * Hooking up CocoaExample into test suite. Note: This is an Cocoa application, so it needs a valid display session. targets for separate patch sets: * Framework test support * Makefile / Ninja xctest support - but this will need some bigger patches in all Framework, CFBundle, and Application Bundle code. Don't know if it's worth the trouble On 09/12/14 21:40, Brad King wrote: >> > On non-Apple platforms and Xcode < 5.0 those XCTest bundles are pretty >> > useless. > What should CMake do on those platforms? The fact that an add_library > call has occurred means it needs to do something with the target. > Should it be an error to ensure that the project adds such targets > only conditionally? I'd say handle it exactly like CFBundles are handled on foreign platforms. I added a warning if the Xcode version is too old to support XCTest. >> > Note: It is currently not possible to run the tests without opening Xcode >> > once to (auto) generate the Schema files. Otherwise calling >> > "xcodebuild test -scheme CocoaExample" will not recognise the scheme. > Does this mean we can't automatically setup testing? I added a Schema and install it as part of the configuration run. But I don't know how stable the IDs in the schema or pbxproj are. You can run the tests: mkdir Tests/CocoaExample/_build cd Tests/CocoaExample/_build cmake -GXcode .. xcodebuild -scheme CocoaExample test Thanks, Gregor Gregor Jasny (4): Use GetCFBundleDirectory within GetFullNameInternal Call cmTarget::IsCFBundleOnApple to decide if bundle is being built Add handling for XCTest bundles Add XCTest Example Help/manual/cmake-properties.7.rst | 2 + Help/prop_tgt/XCTEST.rst | 11 + Help/prop_tgt/XCTEST_HOST.rst | 8 + Source/cmGlobalXCodeGenerator.cxx | 69 ++- Source/cmTarget.cxx | 30 +- Source/cmTarget.h | 3 + Tests/CocoaExample/CMakeLists.txt | 31 + Tests/CocoaExample/CocoaExample.xcscheme | 110 ++++ Tests/CocoaExample/CocoaExample/AppDelegate.h | 7 + Tests/CocoaExample/CocoaExample/AppDelegate.m | 18 + Tests/CocoaExample/CocoaExample/Info.plist.in | 32 + Tests/CocoaExample/CocoaExample/MainMenu.xib | 680 +++++++++++++++++++++ Tests/CocoaExample/CocoaExample/main.m | 5 + .../CocoaExampleTests/CocoaExampleTests.m | 13 + 14 files changed, 1005 insertions(+), 14 deletions(-) create mode 100644 Help/prop_tgt/XCTEST.rst create mode 100644 Help/prop_tgt/XCTEST_HOST.rst create mode 100644 Tests/CocoaExample/CMakeLists.txt create mode 100644 Tests/CocoaExample/CocoaExample.xcscheme create mode 100644 Tests/CocoaExample/CocoaExample/AppDelegate.h create mode 100644 Tests/CocoaExample/CocoaExample/AppDelegate.m create mode 100644 Tests/CocoaExample/CocoaExample/Info.plist.in create mode 100644 Tests/CocoaExample/CocoaExample/MainMenu.xib create mode 100644 Tests/CocoaExample/CocoaExample/main.m create mode 100644 Tests/CocoaExample/CocoaExampleTests/CocoaExampleTests.m -- 1.9.3 (Apple Git-50) From gjasny at googlemail.com Tue Dec 16 16:22:07 2014 From: gjasny at googlemail.com (Gregor Jasny) Date: Tue, 16 Dec 2014 22:22:07 +0100 Subject: [cmake-developers] [PATCH 1/4] Use GetCFBundleDirectory within GetFullNameInternal In-Reply-To: References: Message-ID: <42f68afb0499178df00827365841ddaa2c7b37b9.1418764007.git.gjasny@googlemail.com> Replace duplicated code by call to GetCFBundleDirectory. Signed-off-by: Gregor Jasny --- Source/cmTarget.cxx | 11 ++--------- 1 file changed, 2 insertions(+), 9 deletions(-) diff --git a/Source/cmTarget.cxx b/Source/cmTarget.cxx index f0957d0..90295c8 100644 --- a/Source/cmTarget.cxx +++ b/Source/cmTarget.cxx @@ -4056,15 +4056,8 @@ void cmTarget::GetFullNameInternal(const std::string& config, if(this->IsCFBundleOnApple()) { - fw_prefix = this->GetOutputName(config, false); - fw_prefix += "."; - const char *ext = this->GetProperty("BUNDLE_EXTENSION"); - if (!ext) - { - ext = "bundle"; - } - fw_prefix += ext; - fw_prefix += "/Contents/MacOS/"; + fw_prefix = this->GetCFBundleDirectory(config, false); + fw_prefix += "/"; targetPrefix = fw_prefix.c_str(); targetSuffix = 0; } -- 1.9.3 (Apple Git-50) From gjasny at googlemail.com Tue Dec 16 16:22:08 2014 From: gjasny at googlemail.com (Gregor Jasny) Date: Tue, 16 Dec 2014 22:22:08 +0100 Subject: [cmake-developers] [PATCH 2/4] Call cmTarget::IsCFBundleOnApple to decide if bundle is being built In-Reply-To: References: Message-ID: <9e4abf5b6193ad954454bdece912016b04f45799.1418764007.git.gjasny@googlemail.com> Narrow down the decision if a CFBundle is built to one place. This is a preparation patch to add the XCTEST target property which, if set, will imply BUNDLE. Having only one function which will have to look at both properties helps to keep code clean. Signed-off-by: Gregor Jasny --- Source/cmGlobalXCodeGenerator.cxx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Source/cmGlobalXCodeGenerator.cxx b/Source/cmGlobalXCodeGenerator.cxx index de6e915..6a480a9 100644 --- a/Source/cmGlobalXCodeGenerator.cxx +++ b/Source/cmGlobalXCodeGenerator.cxx @@ -1925,7 +1925,7 @@ void cmGlobalXCodeGenerator::CreateBuildSettings(cmTarget& target, { buildSettings->AddAttribute("LIBRARY_STYLE", this->CreateString("BUNDLE")); - if (target.GetPropertyAsBool("BUNDLE")) + if (target.IsCFBundleOnApple()) { // It turns out that a BUNDLE is basically the same // in many ways as an application bundle, as far as -- 1.9.3 (Apple Git-50) From gjasny at googlemail.com Tue Dec 16 16:22:09 2014 From: gjasny at googlemail.com (Gregor Jasny) Date: Tue, 16 Dec 2014 22:22:09 +0100 Subject: [cmake-developers] [PATCH 3/4] Add handling for XCTest bundles In-Reply-To: References: Message-ID: <18b217ec7bcdd4183bff16cbd68700104f882750.1418764007.git.gjasny@googlemail.com> An XCTest bundle is a CFBundle with a special product-type and bundle extension. It gets loaded directly into the AppBundle it should test. For more information about XCTest visit the Mac Developer library at: http://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/testing_with_xcode/ To build a XCTest bundle, you need to create a CFBundle and set the XCTEST property. Additionally you need to specify the application target to test within the XCTEST_HOST property. CMake and Xcode will then setup the correct target dependencies. add_library(CocoaExampleTest MODULE ...) set_target_properties(CocoaExampleTest PROPERTIES XCTEST TRUE XCTEST_HOST CocoaExample) Signed-off-by: Gregor Jasny --- Help/manual/cmake-properties.7.rst | 2 ++ Help/prop_tgt/XCTEST.rst | 11 +++++++ Help/prop_tgt/XCTEST_HOST.rst | 8 +++++ Source/cmGlobalXCodeGenerator.cxx | 67 ++++++++++++++++++++++++++++++++++++-- Source/cmTarget.cxx | 19 +++++++++-- Source/cmTarget.h | 3 ++ 6 files changed, 106 insertions(+), 4 deletions(-) create mode 100644 Help/prop_tgt/XCTEST.rst create mode 100644 Help/prop_tgt/XCTEST_HOST.rst diff --git a/Help/manual/cmake-properties.7.rst b/Help/manual/cmake-properties.7.rst index cca6d28..7b8aa66 100644 --- a/Help/manual/cmake-properties.7.rst +++ b/Help/manual/cmake-properties.7.rst @@ -242,6 +242,8 @@ Properties on Targets /prop_tgt/VS_WINRT_REFERENCES /prop_tgt/WIN32_EXECUTABLE /prop_tgt/XCODE_ATTRIBUTE_an-attribute + /prop_tgt/XCTEST + /prop_tgt/XCTEST_HOST Properties on Tests =================== diff --git a/Help/prop_tgt/XCTEST.rst b/Help/prop_tgt/XCTEST.rst new file mode 100644 index 0000000..9086485 --- /dev/null +++ b/Help/prop_tgt/XCTEST.rst @@ -0,0 +1,11 @@ +XCTEST +------ + +This target is a XCTest CFBundle on the Mac. + +If a module library target has this property set to true it will be +built as a CFBundle when built on the mac. It will have the directory +structure required for a CFBundle. + +This property implies :prop_tgt:`BUNDLE` and also requires the +:prop_tgt:`XCTEST_HOST` property to be set. diff --git a/Help/prop_tgt/XCTEST_HOST.rst b/Help/prop_tgt/XCTEST_HOST.rst new file mode 100644 index 0000000..5284246 --- /dev/null +++ b/Help/prop_tgt/XCTEST_HOST.rst @@ -0,0 +1,8 @@ +XCTEST_HOST +----------- + +XCTest works by injecting an XCTest CFBundle directly into an AppBundle. +This property names this destination target under test. + +This property is only useful with the Xcode Generator and also needs the +:prop_tgt:`XCTEST` property enabled on the target. diff --git a/Source/cmGlobalXCodeGenerator.cxx b/Source/cmGlobalXCodeGenerator.cxx index 6a480a9..7a71e70 100644 --- a/Source/cmGlobalXCodeGenerator.cxx +++ b/Source/cmGlobalXCodeGenerator.cxx @@ -493,6 +493,15 @@ cmGlobalXCodeGenerator::AddExtraTargets(cmLocalGenerator* root, allbuild->AddUtility(target.GetName()); } + if(target.IsXCTestOnApple()) + { + const char *testHostName = target.GetProperty("XCTEST_HOST"); + if(testHostName && this->CurrentMakefile->FindTargetToUse(testHostName)) + { + target.AddUtility(testHostName); + } + } + // Refer to the build configuration file for easy editing. listfile = lg->GetMakefile()->GetStartDirectory(); listfile += "/"; @@ -761,6 +770,10 @@ GetSourcecodeValueFromFileExtension(const std::string& _ext, { sourcecode = "compiled.mach-o.objfile"; } + else if(ext == "xctest") + { + sourcecode = "wrapper.cfbundle"; + } else if(ext == "xib") { keepLastKnownFileType = true; @@ -2321,6 +2334,52 @@ void cmGlobalXCodeGenerator::CreateBuildSettings(cmTarget& target, buildSettings->AddAttribute("DYLIB_COMPATIBILITY_VERSION", this->CreateString(vso.str().c_str())); } + + if(target.IsXCTestOnApple()) + { + if(this->XcodeVersion < 50) + { + this->CMakeInstance->IssueMessage(cmake::WARNING, + "Xcode 5.0 or later is required for XCTEST support.", + target.GetBacktrace()); + } + + const char *testHostName = target.GetProperty("XCTEST_HOST"); + if(!testHostName) + { + this->CMakeInstance->IssueMessage(cmake::FATAL_ERROR, + "target has XCTEST property but no XCTEST_HOST one.", + target.GetBacktrace()); + return; + } + + cmTarget *testHostTarget = + this->CurrentMakefile->FindTargetToUse(testHostName); + if(!testHostTarget) + { + cmOStringStream e; + e << "Cannot find XCTEST_HOST target: " << testHostName; + this->CMakeInstance->IssueMessage(cmake::FATAL_ERROR, + e.str(), target.GetBacktrace()); + return; + } + + if (!testHostTarget->IsAppBundleOnApple()) + { + cmOStringStream e; + e << "XCTEST_HOST target " << testHostName; + e << " is not an App Bundle"; + this->CMakeInstance->IssueMessage(cmake::FATAL_ERROR, + e.str(), target.GetBacktrace()); + return; + } + + buildSettings->AddAttribute("BUNDLE_LOADER", + this->CreateString("$(TEST_HOST)")); + buildSettings->AddAttribute("TEST_HOST", + this->CreateString(testHostTarget->GetLocationForBuild())); + } + // put this last so it can override existing settings // Convert "XCODE_ATTRIBUTE_*" properties directly. { @@ -2519,7 +2578,9 @@ const char* cmGlobalXCodeGenerator::GetTargetFileType(cmTarget& cmtarget) case cmTarget::STATIC_LIBRARY: return "archive.ar"; case cmTarget::MODULE_LIBRARY: - if (cmtarget.IsCFBundleOnApple()) + if (cmtarget.IsXCTestOnApple()) + return "wrapper.cfbundle"; + else if (cmtarget.IsCFBundleOnApple()) return "wrapper.plug-in"; else return ((this->XcodeVersion >= 22)? @@ -2543,7 +2604,9 @@ const char* cmGlobalXCodeGenerator::GetTargetProductType(cmTarget& cmtarget) case cmTarget::STATIC_LIBRARY: return "com.apple.product-type.library.static"; case cmTarget::MODULE_LIBRARY: - if (cmtarget.IsCFBundleOnApple()) + if (cmtarget.IsXCTestOnApple()) + return "com.apple.product-type.bundle.unit-test"; + else if (cmtarget.IsCFBundleOnApple()) return "com.apple.product-type.bundle"; else return ((this->XcodeVersion >= 22)? diff --git a/Source/cmTarget.cxx b/Source/cmTarget.cxx index 90295c8..db1d0f2 100644 --- a/Source/cmTarget.cxx +++ b/Source/cmTarget.cxx @@ -624,7 +624,15 @@ bool cmTarget::IsCFBundleOnApple() const { return (this->GetType() == cmTarget::MODULE_LIBRARY && this->Makefile->IsOn("APPLE") && - this->GetPropertyAsBool("BUNDLE")); + (this->GetPropertyAsBool("BUNDLE") || + this->GetPropertyAsBool("XCTEST"))); +} + +//---------------------------------------------------------------------------- +bool cmTarget::IsXCTestOnApple() const +{ + return (this->IsCFBundleOnApple() && + this->GetPropertyAsBool("XCTEST")); } //---------------------------------------------------------------------------- @@ -6842,7 +6850,14 @@ std::string cmTarget::GetCFBundleDirectory(const std::string& config, const char *ext = this->GetProperty("BUNDLE_EXTENSION"); if (!ext) { - ext = "bundle"; + if (this->IsXCTestOnApple()) + { + ext = "xctest"; + } + else + { + ext = "bundle"; + } } fpath += ext; fpath += "/Contents"; diff --git a/Source/cmTarget.h b/Source/cmTarget.h index a3ecca0..5786d78 100644 --- a/Source/cmTarget.h +++ b/Source/cmTarget.h @@ -526,6 +526,9 @@ public: /** Return whether this target is a CFBundle (plugin) on Apple. */ bool IsCFBundleOnApple() const; + /** Return whether this target is a XCTest on Apple. */ + bool IsXCTestOnApple() const; + /** Return whether this target is an executable Bundle on Apple. */ bool IsAppBundleOnApple() const; -- 1.9.3 (Apple Git-50) From gjasny at googlemail.com Tue Dec 16 16:22:10 2014 From: gjasny at googlemail.com (Gregor Jasny) Date: Tue, 16 Dec 2014 22:22:10 +0100 Subject: [cmake-developers] [PATCH 4/4] Add XCTest Example In-Reply-To: References: Message-ID: <4d03ac74e99d2bf09d1d4218718fa15c8e832a58.1418764007.git.gjasny@googlemail.com> This test builds an trivial Cocoa App Bundle and an XCTest Bundle. After project generation open it in Xcode and 'Test' the project. You can run the example with: cmake -GXcode . xcodebuild -scheme CocoaExample test Signed-off-by: Gregor Jasny --- Tests/CocoaExample/CMakeLists.txt | 31 + Tests/CocoaExample/CocoaExample.xcscheme | 110 ++++ Tests/CocoaExample/CocoaExample/AppDelegate.h | 7 + Tests/CocoaExample/CocoaExample/AppDelegate.m | 18 + Tests/CocoaExample/CocoaExample/Info.plist.in | 32 + Tests/CocoaExample/CocoaExample/MainMenu.xib | 680 +++++++++++++++++++++ Tests/CocoaExample/CocoaExample/main.m | 5 + .../CocoaExampleTests/CocoaExampleTests.m | 13 + 8 files changed, 896 insertions(+) create mode 100644 Tests/CocoaExample/CMakeLists.txt create mode 100644 Tests/CocoaExample/CocoaExample.xcscheme create mode 100644 Tests/CocoaExample/CocoaExample/AppDelegate.h create mode 100644 Tests/CocoaExample/CocoaExample/AppDelegate.m create mode 100644 Tests/CocoaExample/CocoaExample/Info.plist.in create mode 100644 Tests/CocoaExample/CocoaExample/MainMenu.xib create mode 100644 Tests/CocoaExample/CocoaExample/main.m create mode 100644 Tests/CocoaExample/CocoaExampleTests/CocoaExampleTests.m diff --git a/Tests/CocoaExample/CMakeLists.txt b/Tests/CocoaExample/CMakeLists.txt new file mode 100644 index 0000000..d88f0ee --- /dev/null +++ b/Tests/CocoaExample/CMakeLists.txt @@ -0,0 +1,31 @@ +cmake_minimum_required(VERSION 3.1) + +project(CocoaExample) + +if(NOT XCODE) + message(FATAL_ERROR "Only Xcode Generator is currently supported.") +endif(NOT XCODE) + +add_executable(CocoaExample MACOSX_BUNDLE + CocoaExample/main.m + CocoaExample/AppDelegate.m + CocoaExample/AppDelegate.h + CocoaExample/MainMenu.xib +) + +target_link_libraries(CocoaExample "-framework Foundation" "-framework AppKit") + +set_target_properties(CocoaExample PROPERTIES + MACOSX_BUNDLE_INFO_PLIST ${CMAKE_CURRENT_SOURCE_DIR}/CocoaExample/Info.plist.in + RESOURCE "CocoaExample/MainMenu.xib") + +add_library(CocoaExampleTest MODULE + CocoaExampleTests/CocoaExampleTests.m +) + +set_target_properties(CocoaExampleTest PROPERTIES + XCTEST TRUE + XCTEST_HOST CocoaExample +) + +file(COPY CocoaExample.xcscheme DESTINATION ${PROJECT_BINARY_DIR}/${PROJECT_NAME}.xcodeproj/xcshareddata/xcschemes) diff --git a/Tests/CocoaExample/CocoaExample.xcscheme b/Tests/CocoaExample/CocoaExample.xcscheme new file mode 100644 index 0000000..3037472 --- /dev/null +++ b/Tests/CocoaExample/CocoaExample.xcscheme @@ -0,0 +1,110 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/Tests/CocoaExample/CocoaExample/AppDelegate.h b/Tests/CocoaExample/CocoaExample/AppDelegate.h new file mode 100644 index 0000000..69b6e0f --- /dev/null +++ b/Tests/CocoaExample/CocoaExample/AppDelegate.h @@ -0,0 +1,7 @@ +#import + + at interface AppDelegate : NSObject + + + at end + diff --git a/Tests/CocoaExample/CocoaExample/AppDelegate.m b/Tests/CocoaExample/CocoaExample/AppDelegate.m new file mode 100644 index 0000000..07af62f --- /dev/null +++ b/Tests/CocoaExample/CocoaExample/AppDelegate.m @@ -0,0 +1,18 @@ +#import "AppDelegate.h" + + at interface AppDelegate () + + at property (assign) IBOutlet NSWindow *window; + at end + + at implementation AppDelegate + +- (void)applicationDidFinishLaunching:(NSNotification *)aNotification { + // Insert code here to initialize your application +} + +- (void)applicationWillTerminate:(NSNotification *)aNotification { + // Insert code here to tear down your application +} + + at end diff --git a/Tests/CocoaExample/CocoaExample/Info.plist.in b/Tests/CocoaExample/CocoaExample/Info.plist.in new file mode 100644 index 0000000..3814d1d --- /dev/null +++ b/Tests/CocoaExample/CocoaExample/Info.plist.in @@ -0,0 +1,32 @@ + + + + + CFBundleDevelopmentRegion + en + CFBundleExecutable + $(EXECUTABLE_NAME) + CFBundleIconFile + + CFBundleIdentifier + org.cmake.test.$(PRODUCT_NAME:rfc1034identifier) + CFBundleInfoDictionaryVersion + 6.0 + CFBundleName + $(PRODUCT_NAME) + CFBundlePackageType + APPL + CFBundleShortVersionString + 1.0 + CFBundleSignature + ???? + CFBundleVersion + 1 + LSMinimumSystemVersion + $(MACOSX_DEPLOYMENT_TARGET) + NSMainNibFile + MainMenu + NSPrincipalClass + NSApplication + + diff --git a/Tests/CocoaExample/CocoaExample/MainMenu.xib b/Tests/CocoaExample/CocoaExample/MainMenu.xib new file mode 100644 index 0000000..9498a0a --- /dev/null +++ b/Tests/CocoaExample/CocoaExample/MainMenu.xib @@ -0,0 +1,680 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Default + + + + + + + Left to Right + + + + + + + Right to Left + + + + + + + + + + + Default + + + + + + + Left to Right + + + + + + + Right to Left + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/Tests/CocoaExample/CocoaExample/main.m b/Tests/CocoaExample/CocoaExample/main.m new file mode 100644 index 0000000..8a6799b --- /dev/null +++ b/Tests/CocoaExample/CocoaExample/main.m @@ -0,0 +1,5 @@ +#import + +int main(int argc, const char * argv[]) { + return NSApplicationMain(argc, argv); +} diff --git a/Tests/CocoaExample/CocoaExampleTests/CocoaExampleTests.m b/Tests/CocoaExample/CocoaExampleTests/CocoaExampleTests.m new file mode 100644 index 0000000..70d61d6 --- /dev/null +++ b/Tests/CocoaExample/CocoaExampleTests/CocoaExampleTests.m @@ -0,0 +1,13 @@ +#import + + at interface CocoaExampleTests : XCTestCase + + at end + + at implementation CocoaExampleTests + +- (void)testExample { + XCTAssert(YES, @"Pass"); +} + + at end -- 1.9.3 (Apple Git-50) From mantis at public.kitware.com Tue Dec 16 17:00:31 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 17 Dec 2014 00:00:31 +0200 Subject: [cmake-developers] [CMake 0015312]: setting CMAKE_AR doesn't work Message-ID: <4b8df4291e36a35eedc3ae4a96761c6b@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15312 ====================================================================== Reported By: Alan Scott Assigned To: ====================================================================== Project: CMake Issue ID: 15312 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-12-17 00:00 WAST Last Modified: 2014-12-17 00:00 WAST ====================================================================== Summary: setting CMAKE_AR doesn't work Description: >From a user (Dave K): when using the intel compilers, you need to use their "ar" tool, xiar. The first issue is that the intel ar utility is not automatically recognized when the compiler is intel. The second issue is that setting the CMAKE_AR variable does not propagate to the CMakeFiles//CMakeCCompiler and CMakeCXXCompiler files (so it's effectively ignored) This becomes evident when using -ip and -ipo optimization flags (since they fail with static libraries linked with ar vs xiar) ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-12-17 00:00 Alan Scott New Issue ====================================================================== From dpolyanitsa at nvidia.com Wed Dec 17 09:22:54 2014 From: dpolyanitsa at nvidia.com (Dmitry Polyanitsa) Date: Wed, 17 Dec 2014 14:22:54 +0000 Subject: [cmake-developers] CMake 3.1 Android - generator expressions and output names In-Reply-To: References: <547E24E7.8040109@kitware.com> <7ac316f6d59a4ea682b76ba003c1fb05@UKMAIL102.nvidia.com> <549033C2.7070803@kitware.com> <5424b682cea744a79adae0775ad3f29f@UKMAIL102.nvidia.com> <47b52e386fec464994c22b1ab0259d7c@UKMAIL102.nvidia.com> Message-ID: No, you're right - this is an unfortunate shortcoming. I've attached a patch for CMake as of 0dd9e71 that adds ANDROID_API_MIN/CMAKE_ANDROID_API_MIN which will allow you to set the Min Android API Level in your projects. Brad, I've used ANDROID_API/CMAKE_ANDROID_API as an example when implementing this change. I've added "MIN" as a postfix, for it seemed to be the preferred way, judging by the other propertiy names. Could you please merge the patch into CMake? -Dmitry -----Original Message----- From: Robert Goulet [mailto:Robert.Goulet at autodesk.com] Sent: Tuesday, December 16, 2014 7:36 PM To: Dmitry Polyanitsa; Brad King Cc: cmake-developers at cmake.org Subject: RE: [cmake-developers] CMake 3.1 Android - generator expressions and output names Yes but in our case, we target API 19 (4.4), and min seems to defaults to 9 (2.3) with CMake, and if we leave the native API to use the min, then it fails to find GLES 3.0 headers. It only works if I set the native API to Target instead of Min. Perhaps I misunderstood something? -----Original Message----- From: Dmitry Polyanitsa [mailto:dpolyanitsa at nvidia.com] Sent: Tuesday, December 16, 2014 11:09 AM To: Robert Goulet; Brad King Cc: cmake-developers at cmake.org Subject: RE: [cmake-developers] CMake 3.1 Android - generator expressions and output names Native Android API Level really should be the same as Min Android API Level, otherwise you might have problems in runtime. The upgrade action sets this property to Use Target Android API Level only for the sake of compatibility between Nsight Tegra versions, but we strongly encourage our users to switch it back to Use Min. We will show a warning if the Native and Min API Levels are not the same (Google's ndk-build does it as well). -Dmitry -----Original Message----- From: Robert Goulet [mailto:Robert.Goulet at autodesk.com] Sent: Tuesday, December 16, 2014 6:58 PM To: Dmitry Polyanitsa; Brad King Cc: cmake-developers at cmake.org Subject: RE: [cmake-developers] CMake 3.1 Android - generator expressions and output names Upgrading to CMake 3.1-rc3 indeed fixed the upgrade popup upon opening generated solution/project files when using NVidia NSight Tegra 3.0r4, however the value of "Native Android API Level" seems to default to "Use Min Android API Level" instead of the expected "Use Target Android API Level". Since we cannot set the Min or the Native API Level explicitly in CMake, this is a regression when upgrading to NVidia NSight Tegra 3.0r4 (from 3.0r3). I guess we will have to stick with NVidia NSight Tegra 3.0r3 for now. -----Original Message----- From: Dmitry Polyanitsa [mailto:dpolyanitsa at nvidia.com] Sent: Tuesday, December 16, 2014 8:46 AM To: Brad King; Robert Goulet Cc: cmake-developers at cmake.org Subject: RE: [cmake-developers] CMake 3.1 Android - generator expressions and output names Yes, that's the one. Nsight Tegra will upgrade the projects without a prompt, but only starting with the next version number increase. -Dmitry -----Original Message----- From: Brad King [mailto:brad.king at kitware.com] Sent: Tuesday, December 16, 2014 4:30 PM To: Robert Goulet Cc: Dmitry Polyanitsa; cmake-developers at cmake.org Subject: Re: [cmake-developers] CMake 3.1 Android - generator expressions and output names On 12/16/2014 06:58 AM, Dmitry Polyanitsa wrote: >> 3.0r4 has added a popup when opening the solution in Visual Studio >> stating that the project files generated needs to be upgraded. > > I'm sure I've submitted a patch for this - please try updating CMake IIUC the patch was this one: VS: Change Nsight Tegra 2.0 Project Revision Number from 8 to 9 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bb3c87f1 and is available in 3.1.0-rc3. However, CMake cannot predict future version numbers, so it writes a "NsightTegraUpgradeOnceWithoutPrompt" element into the project file. Nsight Tegra is supposed to upgrade such projects without any popup. -Brad ----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ----------------------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-ANDROID_API_MIN-target-property-and-CMAKE_ANDROI.patch Type: application/octet-stream Size: 4998 bytes Desc: 0001-Add-ANDROID_API_MIN-target-property-and-CMAKE_ANDROI.patch URL: From brad.king at kitware.com Wed Dec 17 11:02:10 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 17 Dec 2014 11:02:10 -0500 Subject: [cmake-developers] Volunteering to maintain a new module: FindGSL.cmake In-Reply-To: <0458DF31F610EF42BFC78C497E806C7B3B577B79@ECS-EXG-P-MB03.win.lanl.gov> References: <0458DF31F610EF42BFC78C497E806C7B3B53D706@ECS-EXG-P-MB03.win.lanl.gov> <0458DF31F610EF42BFC78C497E806C7B3B5435CE@ECS-EXG-P-MB03.win.lanl.gov> <548AFF4B.8080805@kitware.com> <0458DF31F610EF42BFC78C497E806C7B3B577B79@ECS-EXG-P-MB03.win.lanl.gov> Message-ID: <5491A902.8040509@kitware.com> On 12/16/2014 01:36 PM, Thompson, KT wrote: > I also reverted a recent change by replacing GSL_CONFIG_EXECUTABLE > with GSL_CONFIG to remain consistent with the naming conventions > of PkgConfig.cmake. The convention is for libraries to be FOO_LIBRARY and executables to be FOO_EXECUTABLE. PkgConfig is an exception for historical reasons. I updated the patch for you to use GSL_CONFIG_EXECUTABLE. > The updated FindGSL.cmake is attached. Thanks. I've applied it and merged for testing: FindGSL: Add module to find the GNU Scientific Library http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1b28e3b2 I also fixed repeat inclusion with: -if( GSL_FOUND ) +if( GSL_FOUND AND NOT TARGET GSL::gsl ) > I also created a simple test for the new module (see attached FindGSL.tgz). I created a test based on that, thanks. I chose to use just + if(CMake_TEST_FindGSL) + add_subdirectory(FindGSL) + endif() so that the build of CMake itself does not try to search for a library CMake does not need (this needs to be fixed up for a few other find module tests, but that is not your problem). Therefore in your dashboard script please add: set( dashboard_cache "CMake_TEST_FindGSL:BOOL=ON") Thanks, -Brad From brad.king at kitware.com Wed Dec 17 11:20:16 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 17 Dec 2014 11:20:16 -0500 Subject: [cmake-developers] CMake 3.1 Android - generator expressions and output names In-Reply-To: References: <547E24E7.8040109@kitware.com> <7ac316f6d59a4ea682b76ba003c1fb05@UKMAIL102.nvidia.com> <549033C2.7070803@kitware.com> <5424b682cea744a79adae0775ad3f29f@UKMAIL102.nvidia.com> <47b52e386fec464994c22b1ab0259d7c@UKMAIL102.nvidia.com> Message-ID: <5491AD40.6010003@kitware.com> On 12/17/2014 09:22 AM, Dmitry Polyanitsa wrote: > adds ANDROID_API_MIN/CMAKE_ANDROID_API_MIN which will allow you > to set the Min Android API Level in your projects. Thanks. I've applied the patch and merged for testing: Add 'ANDROID_API_MIN' target property to set Android Target MIN API http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=eeaa25e5 This will be available in the next nightly binaries that appear here: http://www.cmake.org/files/dev/?C=M;O=D We're long past the freeze for 3.1 features so this will be in 3.2. -Brad From mantis at public.kitware.com Wed Dec 17 11:26:44 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 17 Dec 2014 11:26:44 -0500 Subject: [cmake-developers] [CMake 0015313]: .def files are not visible in Visual Studio project tree Message-ID: <7a3d7dcc1894893b321b16f395bf4128@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15313 ====================================================================== Reported By: patep Assigned To: ====================================================================== Project: CMake Issue ID: 15313 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-12-17 11:26 EST Last Modified: 2014-12-17 11:26 EST ====================================================================== Summary: .def files are not visible in Visual Studio project tree Description: When using .def files to set public symbols in libraries it is important to edit .def file (sometimes frequently). But now they are just consumed by CMake, added to project building (/DEF:...) and not visible in solution. Is it possible to add .def files to project file tree in Visual Studio? Steps to Reproduce: a.cpp: void a(){} a.def: EXPORTS a CMakeLists.txt add_library(a SHARED a.cpp a.def) ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-12-17 11:26 patep New Issue ====================================================================== From mantis at public.kitware.com Wed Dec 17 11:29:58 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 17 Dec 2014 11:29:58 -0500 Subject: [cmake-developers] [CMake 0015314]: FindMPI.cmake can choose incompatible set of libraries for Intel MPI Message-ID: The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15314 ====================================================================== Reported By: Kelly Thompson Assigned To: ====================================================================== Project: CMake Issue ID: 15314 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-12-17 11:29 EST Last Modified: 2014-12-17 11:29 EST ====================================================================== Summary: FindMPI.cmake can choose incompatible set of libraries for Intel MPI Description: When using Intel MPI, CMake's FindMPI.cmake can choose the wrong MPI libraries for linking because it does not differentiate between the regular and the thread safe versions of the libraries (this might be related to http://public.kitware.com/Bug/view.php?id=14991). The problem can been observed by noting that FindMPI.cmake calls '@mpiicpc -show@' to determine the MPI libraries that should be used during linking (these will not be the thread safe versions). For example: % mpiicpc -show icpc -I/projects/opt/mpi/impi/5.0.1.035/intel64/include \ -L/projects/opt/mpi/impi/5.0.1.035/intel64/lib/release \ -L/projects/opt/mpi/impi/5.0.1.035/intel64/lib \ -Xlinker --enable-new-dtags \ -Xlinker -rpath \ -Xlinker /projects/opt/mpi/impi/5.0.1.035/intel64/lib/release \ -Xlinker -rpath -Xlinker /projects/opt/mpi/impi/5.0.1.035/intel64/lib \ -Xlinker -rpath -Xlinker /opt/intel/mpi-rt/5.0/intel64/lib/release \ -Xlinker -rpath -Xlinker /opt/intel/mpi-rt/5.0/intel64/lib \ -lmpicxx -lmpifort -lmpi -lmpigi -ldl -lrt -lpthread However, if thread safe versions are desired, the command 'mpiicpc -mt_mpi -show' should be used instead. Note that adding '-openmp' (my situation) will also select the thread safe versions. These libraries are: 
% mpiicpc -mt_mpi -show
icpc -I/projects/opt/mpi/impi/5.0.1.035/intel64/include \
-L/projects/opt/mpi/impi/5.0.1.035/intel64/lib/release_mt \
-L/projects/opt/mpi/impi/5.0.1.035/intel64/lib \
-Xlinker --enable-new-dtags \
-Xlinker -rpath -Xlinker /projects/opt/mpi/impi/5.0.1.035/intel64/lib/release_mt
\
-Xlinker -rpath -Xlinker /projects/opt/mpi/impi/5.0.1.035/intel64/lib \
-Xlinker -rpath -Xlinker /opt/intel/mpi-rt/5.0/intel64/lib/release_mt \
-Xlinker -rpath -Xlinker /opt/intel/mpi-rt/5.0/intel64/lib \
-lmpicxx -lmpifort -lmpi_mt -lmpigi -ldl -lrt -lpthread
The difference is the library folder location: 'release' vs. 'relase_mt' Currently, when the CMAKE__COMPILER == MPI__COMPILER, FindMPI.cmake will always add the non-thread safe library to the link line via ${MPI__LIBRARIES} so that if the compiler flags include '-mt_mpi' or '-openmp', the link line will include both the thread safe libraries and the normal libraries resulting in: ld: MPIR_Thread: TLS definition in .../intel64/lib/release_mt/libmpi_mt.so section .tbss mismatches non-TLS definition in .../intel64/lib/libmpi.so section .bss .../intel64/lib/release_mt/libmpi_mt.so: could not read symbols: Bad value I think the correct resolution to this issue would be to disable the interrogation of the wrapper when CMAKE__COMPILER == MPI__COMPILER because all of the required include and link information will already be available via the MPI compiler wrapper. In this model, MPI__LIBRARIES would be an empty string if the mpi compiler wrapper is used as the project primary compiler. A potential fix would be a modification of some sample code that I recently proposed via the cmake-developers mailing list: --- a/Modules/FindMPI.cmake +++ b/Modules/FindMPI.cmake @@ -165,11 +165,28 @@ foreach (lang C CXX Fortran) endif() unset(_MPI_${id}_${lang}_COMPILER_NAMES) # clean up the namespace here endforeach() + + # If cmake_$lang_compiler matches a known mpi compiler wrapper name, + # prefer the provided name and prevent interrogation. + get_filename_component( compiler_wo_path "${CMAKE_${lang}_COMPILER}" NAME ) + set( ${lang}_compiler_is_mpiwrapper false ) + foreach( mpiwrapper ${_MPI_${lang}_COMPILER_NAMES} ) + if( "${mpiwrapper}" STREQUAL "${compiler_wo_path}" ) + set( ${lang}_compiler_is_mpiwrapper true ) + endif() + endforeach() + if( ${lang}_compiler_is_mpiwrapper ) + set( MPI_${lang}_COMPILER ${CMAKE_${lang}_COMPILER} ) + set( MPI_${lang}_NO_INTERROGATE ${CMAKE_${lang}_COMPILER} ) + endif() endforeach() Steps to Reproduce: On Linux with Intel/15.0 and Intel MPI 5.0 (my testing used cmake/3.0.1 and the git source version). export CXX=`which mpiicpc` export CC=`which mpiicc` cmake has 2 files: CMakeLists.txt and hw.cc # CMakeLists.txt cmake_minimum_required(VERSION 3.0) project( hw_mpi CXX ) set( CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -mt_mpi" ) find_package( MPI ) include_directories( ${MPI_INCLUDE_PATH} ) add_executable( hw hw.cc ) target_link_libraries( hw ${MPI_LIBRARIES} ) // hw.cc #include #include int main(int argc, char* argv[]) { MPI_Init(&argc, &argv); int rank; MPI_Comm_rank(MPI_COMM_WORLD, &rank); if (rank == 0) { int value = 17; int result = MPI_Send(&value, 1, MPI_INT, 1, 0, MPI_COMM_WORLD); if (result == MPI_SUCCESS) std::cout << "Rank 0 OK!" << std::endl; } else if (rank == 1) { int value; int result = MPI_Recv(&value, 1, MPI_INT, 0, 0, MPI_COMM_WORLD, MPI_STATUS_IGNORE); if (result == MPI_SUCCESS && value == 17) std::cout << "Rank 1 OK!" << std::endl; } MPI_Finalize(); return 0; } Additionally, a short test like this should probably be added to the standard suite of CMake regression tests. Additional Information: This issue is possibly related to http://public.kitware.com/Bug/view.php?id=15182 and http://public.kitware.com/Bug/view.php?id=14991. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-12-17 11:29 Kelly Thompson New Issue ====================================================================== From mw_triad at users.sourceforge.net Wed Dec 17 13:11:38 2014 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Wed, 17 Dec 2014 13:11:38 -0500 Subject: [cmake-developers] New command 'file(LOCK_DIRECTORY ...)' In-Reply-To: <543BE40C.4000404@kitware.com> References: <5431B11C.3010209@yahoo.com> <54329100.8020502@kitware.com> <54338CF1.3070304@yahoo.com> <5433DBC1.5080800@kitware.com> <5435257B.80201@yahoo.com> <543531CC.7090103@kitware.com> <5437C6CA.3030201@yahoo.com> <543BE40C.4000404@kitware.com> Message-ID: On 2014-10-13 10:39, Brad King wrote: > On 10/10/2014 07:45 AM, Ruslan Baratov wrote: >> Locking directory is equivalent to locking file `cmake.lock` in >> directory "/path/to/shared/directory/": > > I think this can be activated buy a DIRECTORY option. Why do we need even that? Can't CMake just test if the lock target is a directory? p.s. For a lock with no timeout, maybe there can be a built-in timeout after which CMake displays a message what it's trying to do, so that it doesn't just hang mysteriously. -- Matthew From brad.king at kitware.com Wed Dec 17 14:18:04 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 17 Dec 2014 14:18:04 -0500 Subject: [cmake-developers] pause on new topics please Message-ID: <5491D6EC.9000607@kitware.com> Hi Folks, I have a few open topics in 'next' right now that may take a few more nightly iterations to cleanup the dashboard. In order to avoid disrupting this process with other changes, please refrain from adding more topics to 'next'. Of course topics for documentation-only changes or fixes to existing dashboard problems are still allowed. Thanks, -Brad From brad.king at kitware.com Wed Dec 17 15:04:16 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 17 Dec 2014 15:04:16 -0500 Subject: [cmake-developers] [PATCH 0/4] XCTest Bundles v2 In-Reply-To: References: Message-ID: <5491E1C0.10406@kitware.com> On 12/16/2014 04:22 PM, Gregor Jasny wrote: > I addressed all the comments you gave about the last series. Thanks. I've applied the first two patches since they are independent cleanups and merged for testing: cmTarget: Use GetCFBundleDirectory within GetFullNameInternal http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=207b7af0 Xcode: Call IsCFBundleOnApple to decide if bundle is being built http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3a605693 > * if a fatal error is issued in cmGlobalXCodeGenerator::CreateBuildSettings > generation does not stop. So you'll see the error for every configuration. FATAL_ERROR messages are meant to stop the configuration step. The generation step is different for every generator so one would need custom code to avoid the duplicate warning. However, in this case the XCTEST_HOST checking is an aspect of the project specification and not of the Xcode generator. These checks should be done somewhere at the beginning of generation. You could hook in to cmGlobalGenerator::Generate just after the call to FinalizeTargetCompileInfo, for example. With that you should be able to add tests somewhere in the Tests/RunCMake/ infrastructure to cover these error messages on all platforms. > * Hooking up CocoaExample into test suite. Note: This is an Cocoa application, > so it needs a valid display session. Does this mean it cannot run in a cron job? Or just that the user must be logged in? Thanks, -Brad From robert.maynard at kitware.com Wed Dec 17 15:54:01 2014 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 17 Dec 2014 15:54:01 -0500 Subject: [cmake-developers] [ANNOUNCE] CMake 3.1.0 Released! Message-ID: I am proud to announce that CMake 3.1 is now available for download at: http://www.cmake.org/download http://www.cmake.org/files/v3.1/?C=M;O=D Documentation is available at: http://www.cmake.org/cmake/help/v3.1 Release notes appear below and are also published at http://www.cmake.org/cmake/help/v3.1/release/3.1.0.html Some of the more significant features of CMake 3.1 are: * Windows Phone and Windows Store support has been added to Visual Studio 11 (2012) and above Generators. * NVIDIA Nsight Tegra support has been added to Visual Studio 10 (2010) and above Generators. * New "target_compile_features" command allows populating target based compile features. CMake uses this information to ensure that the compiler in use is capable of building the target, and to add any necessary compile flags such as -std=gnu++11 to support language features. More information on this is found at: - http://www.cmake.org/cmake/help/v3.1/manual/cmake-compile-features.7.html * The syntax for *Variable References* and *Escape Sequences* was simplified in order to allow a much faster implementation. See policy "CMP0053". * The "if" command no longer automatically dereferences variables named in quoted or bracket arguments. See policy "CMP0054". * The target property "SOURCES" now generally supports "Generator Expressions". The generator expressions may be used in the "add_library" and "add_executable" commands. * It is now possible to write and append to the target property "SOURCES". The variable "CMAKE_DEBUG_TARGET_PROPERTIES" can be used to trace the origin of sources. * CPack gained "7Z" and "TXZ" generators supporting lzma-compressed archives. * The ExternalProject module has learned to support lzma-compressed source tarballs with ".7z", ".tar.xz", and ".txz" extensions. * The ExternalProject module ExternalProject_Add command learned a new BUILD_ALWAYS option to cause the external project build step to run every time the host project is built. * The ctest_coverage command learned to support Intel coverage files with the "codecov" tool. * The ctest_memcheck command learned to support sanitizer modes, including "AddressSanitizer", "MemorySanitizer", "ThreadSanitizer", and "UndefinedBehaviorSanitizer". Deprecated and Removed Features: * In CMake 3.0 the "target_link_libraries" command accidentally began allowing unquoted arguments to use Generator Expressions containing a semicolon separated list within them. For example: set(libs B C) target_link_libraries(A PUBLIC $) This is equivalent to writing: target_link_libraries(A PUBLIC $) and was never intended to work. It did not work in CMake 2.8.12. Such generator expressions should be in quoted arguments: set(libs B C) target_link_libraries(A PUBLIC "$") CMake 3.1 again requires the quotes for this to work correctly. CMake 3.1.0 Release Notes ************************* Changes made since CMake 3.0.0 include the following. Documentation Changes ===================== * A new "cmake-compile-features(7)" manual was added. New Features ============ Generators ---------- * The "Visual Studio 14 2015" generator was added. Windows Phone and Windows Store ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * Generators for Visual Studio 11 (2012) and above learned to generate projects for Windows Phone and Windows Store. One may set the "CMAKE_SYSTEM_NAME" variable to "WindowsPhone" or "WindowsStore" on the "cmake(1)" command-line or in a "CMAKE_TOOLCHAIN_FILE" to activate these platforms. Also set "CMAKE_SYSTEM_VERSION" to "8.0" or "8.1" to specify the version of Windows to be targeted. NVIDIA Nsight Tegra ~~~~~~~~~~~~~~~~~~~ * Generators for Visual Studio 10 (2010) and above learned to generate projects for NVIDIA Nsight Tegra Visual Studio Edition. One may set the "CMAKE_SYSTEM_NAME" variable to "Android" on the "cmake(1)" command-line or in a "CMAKE_TOOLCHAIN_FILE" to activate this platform. Syntax ------ * The "cmake-language(7)" syntax for *Variable References* and *Escape Sequences* was simplified in order to allow a much faster implementation. See policy "CMP0053". * The "if()" command no longer automatically dereferences variables named in quoted or bracket arguments. See policy "CMP0054". Commands -------- * The "add_custom_command()" command learned to interpret "cmake- generator-expressions(7)" in arguments to "DEPENDS". * The "export(PACKAGE)" command learned to check the "CMAKE_EXPORT_NO_PACKAGE_REGISTRY" variable to skip exporting the package. * The "file(STRINGS)" command gained a new "ENCODING" option to enable extraction of "UTF-8" strings. * The "find_package()" command learned to check the "CMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY" and "CMAKE_FIND_PACKAGE_NO_SYSTEM_PACKAGE_REGISTRY" variables to skip searching the package registries. * The "get_property()" command learned a new "INSTALL" scope for properties. * The "install()" command learned a "MESSAGE_NEVER" option to avoid output during installation. * The "set_property()" command learned a new "INSTALL" scope for properties. * The "string()" command learned a new "GENEX_STRIP" subcommand which removes "generator expression". * The "string()" command learned a new "UUID" subcommand to generate a univerally unique identifier. * New "target_compile_features()" command allows populating the "COMPILE_FEATURES" target property, just like any other build variable. * The "target_sources()" command was added to add to the "SOURCES" target property. Variables --------- * The Visual Studio generators for versions 8 (2005) and above learned to read the target platform name from a new "CMAKE_GENERATOR_PLATFORM" variable when it is not specified as part of the generator name. The platform name may be specified on the "cmake(1)" command line with the "-A" option, e.g. "-G "Visual Studio 12 2013" -A x64". * The "CMAKE_GENERATOR_TOOLSET" variable may now be initialized in a toolchain file specified by the "CMAKE_TOOLCHAIN_FILE" variable. This is useful when cross-compiling with the Xcode or Visual Studio generators. * The "CMAKE_INSTALL_MESSAGE" variable was introduced to optionally reduce output installation. Properties ---------- * New "CXX_STANDARD" and "CXX_EXTENSIONS" target properties may specify values which CMake uses to compute required compile options such as "-std=c++11" or "-std=gnu++11". The "CMAKE_CXX_STANDARD" and "CMAKE_CXX_EXTENSIONS" variables may be set to initialize the target properties. * New "C_STANDARD" and "C_EXTENSIONS" target properties may specify values which CMake uses to compute required compile options such as "-std=c11" or "-std=gnu11". The "CMAKE_C_STANDARD" and "CMAKE_C_EXTENSIONS" variables may be set to initialize the target properties. * New "COMPILE_FEATURES" target property may contain a list of features required to compile a target. CMake uses this information to ensure that the compiler in use is capable of building the target, and to add any necessary compile flags to support language features. * New "COMPILE_PDB_NAME" and "COMPILE_PDB_OUTPUT_DIRECTORY" target properties were introduced to specify the MSVC compiler program database file location ("cl /Fd"). This complements the existing "PDB_NAME" and "PDB_OUTPUT_DIRECTORY" target properties that specify the linker program database file location ("link /pdb"). * The "INTERFACE_LINK_LIBRARIES" target property now supports a "$" "generator expression". * A new "INTERFACE_SOURCES" target property was introduced. This is consumed by dependent targets, which compile and link the listed sources. * The "SOURCES" target property now contains "generator expression" such as "TARGET_OBJECTS" when read at configure time, if policy "CMP0051" is "NEW". * The "SOURCES" target property now generally supports "generator expression". The generator expressions may be used in the "add_library()" and "add_executable()" commands. * It is now possible to write and append to the "SOURCES" target property. The "CMAKE_DEBUG_TARGET_PROPERTIES" variable may be used to trace the origin of sources. * A "VS_DEPLOYMENT_CONTENT" source file property was added to tell the Visual Studio generators to mark content for deployment in Windows Phone and Windows Store projects. * A "VS_DEPLOYMENT_LOCATION" source file property was added to tell the Visual Studio generators the relative location of content marked for deployment in Windows Phone and Windows Store projects. * The "VS_WINRT_COMPONENT" target property was created to tell Visual Studio generators to compile a shared library as a Windows Runtime (WinRT) component. * The "Xcode" generator learned to check source file properties "XCODE_EXPLICIT_FILE_TYPE" and "XCODE_LAST_KNOWN_FILE_TYPE" for a custom Xcode file reference type. Modules ------- * The "BundleUtilities" module learned to resolve and replace "@rpath" placeholders on OS X to correctly bundle applications using them. * The "CMakePackageConfigHelpers" module "configure_package_config_file()" command learned a new "INSTALL_PREFIX" option to generate package configuration files meant for a prefix other than "CMAKE_INSTALL_PREFIX". * The "CheckFortranSourceCompiles" module was added to provide a "CHECK_Fortran_SOURCE_COMPILES" macro. * The "ExternalData" module learned to tolerate a "DATA{}" reference to a missing source file with a warning instead of rejecting it with an error. This helps developers write new "DATA{}" references to test reference outputs that have not yet been created. * The "ExternalProject" module learned to support lzma-compressed source tarballs with ".7z", ".tar.xz", and ".txz" extensions. * The "ExternalProject" module "ExternalProject_Add" command learned a new "BUILD_ALWAYS" option to cause the external project build step to run every time the host project is built. * The "ExternalProject" module "ExternalProject_Add" command learned a new "EXCLUDE_FROM_ALL" option to cause the external project target to have the "EXCLUDE_FROM_ALL" target property set. * The "ExternalProject" module "ExternalProject_Add_Step" command learned a new "EXCLUDE_FROM_MAIN" option to cause the step to not be a direct dependency of the main external project target. * The "ExternalProject" module "ExternalProject_Add" command learned a new "DOWNLOAD_NO_PROGRESS" option to disable progress output while downloading the source tarball. * The "FeatureSummary" module "feature_summary" API learned to accept multiple values for the "WHAT" option and combine them appropriately. * The "FindCUDA" module learned to support "fatbin" and "cubin" modules. * The "FindGTest" module "gtest_add_tests" macro learned a new "AUTO" option to automatically read the "SOURCES" target property of the test executable and scan the source files for tests to be added. * The "FindGLEW" module now provides imported targets. * The "FindGLUT" module now provides imported targets. * The "FindHg" module gained a new "Hg_WC_INFO" macro to help run "hg" to extract information about a Mercurial work copy. * The "FindOpenCL" module was introduced. * The "FindOpenMP" module learned to support Fortran. * The "FindPkgConfig" module learned to use the "PKG_CONFIG" environment variable value as the "pkg-config" executable, if set. * The "FindXercesC" module was introduced. * The "FindZLIB" module now provides imported targets. * The "GenerateExportHeader" module "generate_export_header" function learned to allow use with *Object Libraries*. * The "InstallRequiredSystemLibraries" module gained a new "CMAKE_INSTALL_OPENMP_LIBRARIES" option to install MSVC OpenMP runtime libraries. * The "UseSWIG" module learned to detect the module name from ".i" source files if possible to avoid the need to set the "SWIG_MODULE_NAME" source file property explicitly. * The "WriteCompilerDetectionHeader" module was added to allow creation of a portable header file for compiler optional feature detection. Generator Expressions --------------------- * New "COMPILE_FEATURES" "generator expression" allows setting build properties based on available compiler features. CTest ----- * The "ctest_coverage()" command learned to read variable "CTEST_COVERAGE_EXTRA_FLAGS" to set "CoverageExtraFlags". * The "ctest_coverage()" command learned to support Intel coverage files with the "codecov" tool. * The "ctest_memcheck()" command learned to support sanitizer modes, including "AddressSanitizer", "MemorySanitizer", "ThreadSanitizer", and "UndefinedBehaviorSanitizer". Options may be set using the new "CTEST_MEMORYCHECK_SANITIZER_OPTIONS" variable. CPack ----- * "cpack(1)" gained an "IFW" generator to package using Qt Framework Installer tools. See the "CPackIFW" module. * "cpack(1)" gained "7Z" and "TXZ" generators supporting lzma- compressed archives. * The "CPackDeb" module learned a new "CPACK_DEBIAN_COMPRESSION_TYPE" variable to set the tarball compression type. * The "cpack(1)" "WiX" generator learned to support a "CPACK_WIX_ACL" installed file property to specify an Access Control List. Other ----- * The "cmake(1)" "-E" option learned a new "env" command. * The "cmake(1)" "-E tar" command learned to support lzma-compressed files. * *Object Libraries* may now have extra sources that do not compile to object files so long as they would not affect linking of a normal library (e.g. ".dat" is okay but not ".def"). * Visual Studio generators for VS 8 and later learned to support the "ASM_MASM" language. * The Visual Studio generators learned to treat ".hlsl" source files as High Level Shading Language sources (using "FXCompile" in ".vcxproj" files). Source file properties "VS_SHADER_TYPE", "VS_SHADER_MODEL", and "VS_SHADER_ENTRYPOINT" were added added to specify the shader type, model, and entry point name. New Diagnostics =============== * Policy "CMP0052" introduced to control directories in the "INTERFACE_INCLUDE_DIRECTORIES" of exported targets. Deprecated and Removed Features =============================== * In CMake 3.0 the "target_link_libraries()" command accidentally began allowing unquoted arguments to use "generator expressions" containing a (";" separated) list within them. For example: set(libs B C) target_link_libraries(A PUBLIC $) This is equivalent to writing: target_link_libraries(A PUBLIC $) and was never intended to work. It did not work in CMake 2.8.12. Such generator expressions should be in quoted arguments: set(libs B C) target_link_libraries(A PUBLIC "$") CMake 3.1 again requires the quotes for this to work correctly. * Callbacks established by the "variable_watch()" command will no longer receive the "ALLOWED_UNKNOWN_READ_ACCESS" access type when the undocumented "CMAKE_ALLOW_UNKNOWN_VARIABLE_READ_ACCESS" variable is set. Uninitialized variable accesses will always be reported as "UNKNOWN_READ_ACCESS". * The "CMakeDetermineVSServicePack" module now warns that it is deprecated and should not longer be used. Use the "CMAKE__COMPILER_VERSION" variable instead. * The "FindITK" module has been removed altogether. It was a thin- wrapper around "find_package(ITK ... NO_MODULE)". This produces much clearer error messages when ITK is not found. * The "FindVTK" module has been removed altogether. It was a thin- wrapper around "find_package(VTK ... NO_MODULE)". This produces much clearer error messages when VTK is not found. The module also provided compatibility support for finding VTK 4.0. This capability has been dropped. Other Changes ============= * The "cmake-gui(1)" learned to capture output from child processes started by the "execute_process()" command and display it in the output window. * The "cmake-language(7)" internal implementation of generator expression and list expansion parsers have been optimized and shows non-trivial speedup on large projects. * The Makefile generators learned to use response files with GNU tools on Windows to pass library directories and names to the linker. * When generating linker command-lines, CMake now avoids repeating items corresponding to SHARED library targets. * Support for the Open Watcom compiler has been overhauled. The "CMAKE__COMPILER_ID" is now "OpenWatcom", and the "CMAKE__COMPILER_VERSION" now uses the Open Watcom external version numbering. The external version numbers are lower than the internal version number by 11. * The "cmake-mode.el" major Emacs editing mode no longer treats "_" as part of words, making it more consistent with other major modes. ------------------------------------------------------------------- Changes made since CMake 3.1.0-rc3: Brad King (2): Help: Drop FeatureSummary example in cmake-developer.7 CMake 3.1.0 Nils Gladitz (1): Help: Extend policy CMP0054 documentation with an example From tim at klingt.org Wed Dec 17 16:01:46 2014 From: tim at klingt.org (Tim Blechmann) Date: Wed, 17 Dec 2014 22:01:46 +0100 Subject: [cmake-developers] documentation patch Message-ID: hi all, this trivial patch adds INTERFACE_LIBRARY to the documentation of the TYPE target property. would be great, if it could be applied. thnx, tim -------------- next part -------------- From f9ff9226bd0985aa239564e93eb42ed4d57b208d Mon Sep 17 00:00:00 2001 From: Tim Blechmann Date: Wed, 17 Dec 2014 21:59:51 +0100 Subject: [PATCH] Help: add INTERFACE_LIBRARY to TYPE property documentation --- Help/prop_tgt/TYPE.rst | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Help/prop_tgt/TYPE.rst b/Help/prop_tgt/TYPE.rst index 1951d46..5ac63cc 100644 --- a/Help/prop_tgt/TYPE.rst +++ b/Help/prop_tgt/TYPE.rst @@ -5,4 +5,5 @@ The type of the target. This read-only property can be used to test the type of the given target. It will be one of STATIC_LIBRARY, MODULE_LIBRARY, -SHARED_LIBRARY, EXECUTABLE or one of the internal target types. +SHARED_LIBRARY, INTERFACE_LIBRARY, EXECUTABLE or one of the internal +target types. -- 2.2.0 From brad.king at kitware.com Wed Dec 17 16:04:50 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 17 Dec 2014 16:04:50 -0500 Subject: [cmake-developers] documentation patch In-Reply-To: References: Message-ID: <5491EFF2.5010006@kitware.com> On 12/17/2014 04:01 PM, Tim Blechmann wrote: > this trivial patch adds INTERFACE_LIBRARY to the documentation of the > TYPE target property. would be great, if it could be applied. Thanks. Applied: Help: Add INTERFACE_LIBRARY to TYPE target property documentation http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=473446ab -Brad From ruslan_baratov at yahoo.com Wed Dec 17 16:58:33 2014 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Thu, 18 Dec 2014 00:58:33 +0300 Subject: [cmake-developers] New command 'file(LOCK_DIRECTORY ...)' In-Reply-To: References: <5431B11C.3010209@yahoo.com> <54329100.8020502@kitware.com> <54338CF1.3070304@yahoo.com> <5433DBC1.5080800@kitware.com> <5435257B.80201@yahoo.com> <543531CC.7090103@kitware.com> <5437C6CA.3030201@yahoo.com> <543BE40C.4000404@kitware.com> Message-ID: <5491FC89.9020008@yahoo.com> On 17-Dec-14 21:11, Matthew Woehlke wrote: > On 2014-10-13 10:39, Brad King wrote: >> On 10/10/2014 07:45 AM, Ruslan Baratov wrote: >>> Locking directory is equivalent to locking file `cmake.lock` in >>> directory "/path/to/shared/directory/": >> I think this can be activated buy a DIRECTORY option. > Why do we need even that? Can't CMake just test if the lock target is a > directory? I've used boost.interprocess as a hint for implementation, as far as I know boost::interprocess::file_lock is not able to lock directories: terminate called after throwing an instance of 'boost::interprocess::interprocess_exception' what(): Is a directory I'm not saying that it's not possible, just trying to use well-known cross-platform solution. > p.s. For a lock with no timeout, maybe there can be a built-in timeout > after which CMake displays a message what it's trying to do, so that it > doesn't just hang mysteriously. You can use `message` command: message(STATUS "Try to lock ${file}") file(LOCK ${file}) or more complex (more user-friendly): while(TRUE) file(LOCK "${file}" RESULT is_locked TIMEOUT 5) if(is_locked) message("Locked. ${resource_info}") break() endif() string(TIMESTAMP time_now "%S/%M") message("[${time_now}] Lock failed, retry... (file: ${file})") endwhile() Ruslo From mantis at public.kitware.com Wed Dec 17 17:48:15 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 17 Dec 2014 23:48:15 +0100 Subject: [cmake-developers] [CMake 0015315]: Qt4And5AutomocReverse test fails with cmake-3.1.0 Message-ID: The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15315 ====================================================================== Reported By: Heiko Becker Assigned To: ====================================================================== Project: CMake Issue ID: 15315 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-12-17 23:48 CET Last Modified: 2014-12-17 23:48 CET ====================================================================== Summary: Qt4And5AutomocReverse test fails with cmake-3.1.0 Description: test 138 Start 138: Qt4And5AutomocReverse 138: Test command: /var/tmp/paludis/build/sys-devel-cmake-3.1.0/work/cmake-3.1.0/bin/ctest "--build-and-test" "/var/tmp/paludis/build/sys-devel-cmake-3.1.0/work/cmake-3.1.0/Tests/Qt4And5Automoc" "/var/tmp/paludis/build/sys-devel-cmake-3.1.0/work/cmake-3.1.0/Tests/Qt4And5AutomocReverse" "--build-generator" "Unix Makefiles" "--build-project" "Qt4And5Automoc" "--build-exe-dir" "/var/tmp/paludis/build/sys-devel-cmake-3.1.0/work/cmake-3.1.0/Tests/Qt4And5AutomocReverse" "--force-new-ctest-process" "--build-options" "-DCMAKE_MAKE_PROGRAM:FILEPATH=/usr/bin/make" "-DQT_REVERSE_FIND_ORDER=1" "--test-command" "/var/tmp/paludis/build/sys-devel-cmake-3.1.0/work/cmake-3.1.0/bin/ctest" "-V" 138: Test timeout computed to be: 1500 138: Internal cmake changing into directory: /var/tmp/paludis/build/sys-devel-cmake-3.1.0/work/cmake-3.1.0/Tests/Qt4And5AutomocReverse 138: ======== CMake output ====== 138: Configuring 138: Configuring done 138: Generating 138: Generating done 138: Build files have been written to: /var/tmp/paludis/build/sys-devel-cmake-3.1.0/work/cmake-3.1.0/Tests/Qt4And5Automoc 138: ======== End CMake output ====== 138: Change Dir: /var/tmp/paludis/build/sys-devel-cmake-3.1.0/work/cmake-3.1.0/Tests/Qt4And5AutomocReverse 138: 138: Run Clean Command:"/usr/bin/make" "clean" 138: make[1]: Entering directory '/var/tmp/paludis/build/sys-devel-cmake-3.1.0/work/cmake-3.1.0/Tests/Qt4And5AutomocReverse' 138: make[1]: *** No rule to make target 'clean'. Stop. 138: make[1]: Leaving directory '/var/tmp/paludis/build/sys-devel-cmake-3.1.0/work/cmake-3.1.0/Tests/Qt4And5AutomocReverse' 138: 138: Run Build Command:"/usr/bin/make" 138: make[1]: Entering directory '/var/tmp/paludis/build/sys-devel-cmake-3.1.0/work/cmake-3.1.0/Tests/Qt4And5AutomocReverse' 138: make[1]: Leaving directory '/var/tmp/paludis/build/sys-devel-cmake-3.1.0/work/cmake-3.1.0/Tests/Qt4And5AutomocReverse' 138: make[1]: *** No targets specified and no makefile found. Stop. 138/419 Test http://public.kitware.com/Bug/view.php?id=138: Qt4And5AutomocReverse ..............................***Failed 0.09 sec ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-12-17 23:48 Heiko Becker New Issue ====================================================================== From mw_triad at users.sourceforge.net Wed Dec 17 17:49:36 2014 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Wed, 17 Dec 2014 17:49:36 -0500 Subject: [cmake-developers] New command 'file(LOCK_DIRECTORY ...)' In-Reply-To: <5491FC89.9020008@yahoo.com> References: <5431B11C.3010209@yahoo.com> <54329100.8020502@kitware.com> <54338CF1.3070304@yahoo.com> <5433DBC1.5080800@kitware.com> <5435257B.80201@yahoo.com> <543531CC.7090103@kitware.com> <5437C6CA.3030201@yahoo.com> <543BE40C.4000404@kitware.com> <5491FC89.9020008@yahoo.com> Message-ID: On 2014-12-17 16:58, Ruslan Baratov via cmake-developers wrote: > On 17-Dec-14 21:11, Matthew Woehlke wrote: >> On 2014-10-13 10:39, Brad King wrote: >>> On 10/10/2014 07:45 AM, Ruslan Baratov wrote: >>>> Locking directory is equivalent to locking file `cmake.lock` in >>>> directory "/path/to/shared/directory/": >>> I think this can be activated buy a DIRECTORY option. >> Why do we need even that? Can't CMake just test if the lock target is a >> directory? > I've used boost.interprocess as a hint for implementation, as far as I > know boost::interprocess::file_lock is not able to lock directories: > terminate called after throwing an instance of > 'boost::interprocess::interprocess_exception' > what(): Is a directory > > I'm not saying that it's not possible, just trying to use well-known > cross-platform solution. Locking a directory "as such" may not be possible (that wouldn't surprise me). That's not what I meant, though; what I meant is, rather than make the user say "this is a directory" to instead lock a special file name in the directory, just have CMake check if the path is a directory and then use that logic implicitly. Requiring the user to specify seems superfluous when it's trivial for CMake to just check. Example: file(LOCK /path/to/file) # lock /path/to/file file(LOCK /path/to) # lock /path/to/.cmake_lock (And before anyone mentions it, I have limited sympathy for someone locking a non-existing directory and then later trying to create it. Don't do that :-). I'm having a very hard time coming up with a reason why one wouldn't just create the directory first to ensure it exists.) For that matter, do we even *need* this feature? If I want to lock a "directory", is it worth the extra implementation complexity just to save me inventing some arbitrary name for a lock file? >> p.s. For a lock with no timeout, maybe there can be a built-in timeout >> after which CMake displays a message what it's trying to do, so that it >> doesn't just hang mysteriously. > > You can use `message` command: > > message(STATUS "Try to lock ${file}") > file(LOCK ${file}) > > or more complex (more user-friendly): > > while(TRUE) > file(LOCK "${file}" RESULT is_locked TIMEOUT 5) > if(is_locked) > message("Locked. ${resource_info}") > break() > endif() > string(TIMESTAMP time_now "%S/%M") > message("[${time_now}] Lock failed, retry... (file: ${file})") > endwhile() Sure. I was just thinking out loud if folks are worried about CMake "mysteriously" hanging, this (implemented in CMake proper) would be an option to allay those concerns. (I'd also encourage anyone writing locks, especially with no time out, to always say what they're doing first :-). But that's somewhat a separate issue.) -- Matthew From daniel at pfeifer-mail.de Thu Dec 18 07:23:38 2014 From: daniel at pfeifer-mail.de (Daniel Pfeifer) Date: Thu, 18 Dec 2014 12:23:38 +0000 Subject: [cmake-developers] Minimal compiler requirements for CMake itself Message-ID: Hi, I would like to know what the oldest versions of GCC and Visual Studio are that should be able to compile the CMake source code. I was unable to find any information about that. I expected the oldest supported version of Visual Studio to be 6.0, but that one fails to build CMake. Don't get me wrong. I would not be unhappy if building CMake required the latest and greatest compilers and language features. I just want to know which compilers I need to be support when I contribute code. cheers, Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: From eike at sf-mail.de Thu Dec 18 08:44:27 2014 From: eike at sf-mail.de (Rolf Eike Beer) Date: Thu, 18 Dec 2014 14:44:27 +0100 Subject: [cmake-developers] Minimal compiler requirements for CMake itself In-Reply-To: References: Message-ID: <4225785.x1cX8Y68kb@caliban.sf-tec.de> Am Donnerstag, 18. Dezember 2014, 12:23:38 schrieb Daniel Pfeifer: > Hi, > > I would like to know what the oldest versions of GCC and Visual Studio are > that should be able to compile the CMake source code. I was unable to find > any information about that. > > I expected the oldest supported version of Visual Studio to be 6.0, but > that one fails to build CMake. IIRC 6.0 was able to build CMake up to 3.0, but then it was dropped as compiler to build CMake. Steven? Brad? I have a dashboard that builds CMake using gcc 3.4, IIRC 2.95 is also still supported. Greetings, Eike -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From mantis at public.kitware.com Thu Dec 18 08:46:34 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 18 Dec 2014 08:46:34 -0500 Subject: [cmake-developers] [CMake 0015316]: Generation of Eclipse project does not provide support for c++ 11 Message-ID: <1bf5a54e145377c423365d198e20f431@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15316 ====================================================================== Reported By: lucaghera Assigned To: ====================================================================== Project: CMake Issue ID: 15316 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-12-18 08:46 EST Last Modified: 2014-12-18 08:46 EST ====================================================================== Summary: Generation of Eclipse project does not provide support for c++ 11 Description: I?m writing a CMake file for a project that should be compiled both in Ubuntu and OS X. I want to use eclipse as IDE, gcc and C++ 11. I read different threads that suggest how to enable C++ 11 in eclipse. According to them I included these lines in my CMake: set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11 -Wall") if (${CMAKE_EXTRA_GENERATOR} MATCHES "Eclipse CDT4") set(CMAKE_CXX_COMPILER_ARG1 "-std=c++11" CACHE STRING "C++ version for eclipse" FORCE) set(CMAKE_ECLIPSE_VERSION "4.3" CACHE STRING "Eclipse version" FORCE) endif (${CMAKE_EXTRA_GENERATOR} MATCHES "Eclipse CDT4?) However, eclipse still set a wrong value for the symbol __cplusplus (199711L instead of 201103L I guess). In the generated file .cproject this should be the line (in my case 265) For this reason eclipse is not able to index C++ 11 features such as shared pointer. Therefore I get a syntax error also if the code compiles. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-12-18 08:46 lucaghera New Issue ====================================================================== From dpolyanitsa at nvidia.com Thu Dec 18 08:59:28 2014 From: dpolyanitsa at nvidia.com (Dmitry Polyanitsa) Date: Thu, 18 Dec 2014 13:59:28 +0000 Subject: [cmake-developers] CMake 3.1 Android - generator expressions and output names In-Reply-To: <5491AD40.6010003@kitware.com> References: <547E24E7.8040109@kitware.com> <7ac316f6d59a4ea682b76ba003c1fb05@UKMAIL102.nvidia.com> <549033C2.7070803@kitware.com> <5424b682cea744a79adae0775ad3f29f@UKMAIL102.nvidia.com> <47b52e386fec464994c22b1ab0259d7c@UKMAIL102.nvidia.com> <5491AD40.6010003@kitware.com> Message-ID: Great, thank you! Robert, could you please try the nightly to see if there are any further issues preventing you from using the latest Nsight Tegra? -Dmitry -----Original Message----- From: Brad King [mailto:brad.king at kitware.com] Sent: Wednesday, December 17, 2014 7:20 PM To: Dmitry Polyanitsa Cc: Robert Goulet; cmake-developers at cmake.org Subject: Re: [cmake-developers] CMake 3.1 Android - generator expressions and output names On 12/17/2014 09:22 AM, Dmitry Polyanitsa wrote: > adds ANDROID_API_MIN/CMAKE_ANDROID_API_MIN which will allow you to set > the Min Android API Level in your projects. Thanks. I've applied the patch and merged for testing: Add 'ANDROID_API_MIN' target property to set Android Target MIN API http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=eeaa25e5 This will be available in the next nightly binaries that appear here: http://www.cmake.org/files/dev/?C=M;O=D We're long past the freeze for 3.1 features so this will be in 3.2. -Brad ----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ----------------------------------------------------------------------------------- From brad.king at kitware.com Thu Dec 18 09:01:31 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 18 Dec 2014 09:01:31 -0500 Subject: [cmake-developers] Minimal compiler requirements for CMake itself In-Reply-To: <4225785.x1cX8Y68kb@caliban.sf-tec.de> References: <4225785.x1cX8Y68kb@caliban.sf-tec.de> Message-ID: <5492DE3B.30700@kitware.com> On 12/18/2014 08:44 AM, Rolf Eike Beer wrote: >> I expected the oldest supported version of Visual Studio to be 6.0, but >> that one fails to build CMake. > > IIRC 6.0 was able to build CMake up to 3.0, but then it was dropped as > compiler to build CMake. Steven? Brad? Support for building CMake itself with VS 6 and 7.0 (2002) was dropped recently in 'master' and is not a requirement for future contributions. It still builds with VS 7.1 (2003). > I have a dashboard that builds CMake using gcc 3.4 > IIRC 2.95 is also still supported. I don't think anyone is submitting a dashboard with 2.95 anymore. The general answer is that contributions must build cleanly on the compilers submitting to the nightly dashboard. Note that some of them are not actually building CMake anymore, but merely running the test suite to make sure targeting older compilers still works. These include: - Borland 5.x - OpenWatcom - VS 6, 7.0 They are all testing CMake binaries built with newer compilers. -Brad From mantis at public.kitware.com Thu Dec 18 09:34:45 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 18 Dec 2014 15:34:45 +0100 Subject: [cmake-developers] [CMake 0015317]: cmake-3.0.1: failing bootstrap on solaris 10 Message-ID: The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15317 ====================================================================== Reported By: Fritz H Assigned To: ====================================================================== Project: CMake Issue ID: 15317 Category: CMake Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2014-12-18 15:34 CET Last Modified: 2014-12-18 15:34 CET ====================================================================== Summary: cmake-3.0.1: failing bootstrap on solaris 10 Description: command ./bootstrap immediately fails on solaris 10; error message: ./bootstrap: syntax error at line 148: `!' unexpected solution: --- cmake-3.1.0_orig/bootstrap Mon Dec 15 21:07:45 2014 +++ cmake-3.1.0/bootstrap Thu Dec 18 15:21:44 2014 @@ -145,7 +145,9 @@ cmake_machine_parisc=true fi elif ${cmake_system_hpux}; then - if !(uname -m | grep ia64 >/dev/null 2>&1); then + if (uname -m | grep ia64 >/dev/null 2>&1); then + : + else cmake_machine_parisc=true fi fi ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-12-18 15:34 Fritz H New Issue ====================================================================== From mantis at public.kitware.com Thu Dec 18 11:14:19 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 18 Dec 2014 17:14:19 +0100 Subject: [cmake-developers] [CMake 0015318]: cmComputeLinkDepends.cxx fils to compile Message-ID: <7d60797431e6e1629fc8cb87f062c813@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15318 ====================================================================== Reported By: Fritz H Assigned To: ====================================================================== Project: CMake Issue ID: 15318 Category: CMake Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2014-12-18 17:14 CET Last Modified: 2014-12-18 17:14 CET ====================================================================== Summary: cmComputeLinkDepends.cxx fils to compile Description: os: solaris 10, compiler: sunstudio 12.1 file Source/cmComputeLinkDepends.cxx fails to compile, error: line 270: Error: Cannot use std::reverse_iterator to initialize std::reverse_iterator. line 271: Error: Cannot use std::reverse_iterator to initialize std::reverse_iterator. i am not an expert in c++, but the following change at least satisfied the compiler: --- cmake-3.1.0_orig/Source/cmComputeLinkDepends.cxx Mon Dec 15 21:07:43 2014 +++ cmake-3.1.0/Source/cmComputeLinkDepends.cxx Thu Dec 18 16:17:00 2014 @@ -266,7 +266,7 @@ // Iterate in reverse order so we can keep only the last occurrence // of a shared library. std::set emmitted; - for(std::vector::const_reverse_iterator + for(std::vector::reverse_iterator li = this->FinalLinkOrder.rbegin(), le = this->FinalLinkOrder.rend(); li != le; ++li) ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-12-18 17:14 Fritz H New Issue ====================================================================== From ruslan_baratov at yahoo.com Thu Dec 18 11:30:54 2014 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Thu, 18 Dec 2014 19:30:54 +0300 Subject: [cmake-developers] New command 'file(LOCK_DIRECTORY ...)' In-Reply-To: References: <5431B11C.3010209@yahoo.com> <54329100.8020502@kitware.com> <54338CF1.3070304@yahoo.com> <5433DBC1.5080800@kitware.com> <5435257B.80201@yahoo.com> <543531CC.7090103@kitware.com> <5437C6CA.3030201@yahoo.com> <543BE40C.4000404@kitware.com> <5491FC89.9020008@yahoo.com> Message-ID: <5493013E.8070404@yahoo.com> On 18-Dec-14 01:49, Matthew Woehlke wrote: > On 2014-12-17 16:58, Ruslan Baratov via cmake-developers wrote: >> On 17-Dec-14 21:11, Matthew Woehlke wrote: >>> On 2014-10-13 10:39, Brad King wrote: >>>> On 10/10/2014 07:45 AM, Ruslan Baratov wrote: >>>>> Locking directory is equivalent to locking file `cmake.lock` in >>>>> directory "/path/to/shared/directory/": >>>> I think this can be activated buy a DIRECTORY option. >>> Why do we need even that? Can't CMake just test if the lock target is a >>> directory? >> I've used boost.interprocess as a hint for implementation, as far as I >> know boost::interprocess::file_lock is not able to lock directories: >> terminate called after throwing an instance of >> 'boost::interprocess::interprocess_exception' >> what(): Is a directory >> >> I'm not saying that it's not possible, just trying to use well-known >> cross-platform solution. > Locking a directory "as such" may not be possible (that wouldn't > surprise me). That's not what I meant, though; what I meant is, rather > than make the user say "this is a directory" to instead lock a special > file name in the directory, just have CMake check if the path is a > directory and then use that logic implicitly. Okay, now I see what you mean :) > Requiring the user to > specify seems superfluous when it's trivial for CMake to just check. > > Example: > > file(LOCK /path/to/file) # lock /path/to/file > file(LOCK /path/to) # lock /path/to/.cmake_lock `file(LOCK /path/to/file DIRECTORY)` and `file(LOCK /path/to/directory)` will report an error instead of silently lock creation. > (And before anyone mentions it, I have limited sympathy for someone > locking a non-existing directory and then later trying to create it. > Don't do that :-). I'm having a very hard time coming up with a reason > why one wouldn't just create the directory first to ensure it exists.) Just for your information: * there is no sub-option RECURSIVE for command `file(MAKE_DIRECTORY ...)`, so all intermediate directories will be always created if they not exist. * command `file(WRITE "/path/to/some/file.txt" "some info") will create all directories too * command `install` create all directories. E.g. if some developer (well, bad developer) will hardcode '/usr/local' in CMAKE_INSTALL_PREFIX, binaries will be installed into `X:/usr/local` on windows. > > For that matter, do we even *need* this feature? If I want to lock a > "directory", is it worth the extra implementation complexity just to > save me inventing some arbitrary name for a lock file? You prefer ".cmake.lock", I prefer "cmake.lock", others prefer '.lock'/'.cmake'. For me it doesn't really matter. What matter is the *standard* cmake name. About "implementation complexity": @@ -3512,7 +3512,6 @@ bool cmFileCommand::HandleLockCommand( - bool directory = false; @@ -3535,10 +3534,6 @@ bool cmFileCommand::HandleLockCommand( - if (args[i] == "DIRECTORY") - { - directory = true; - } @@ -3617,11 +3612,6 @@ bool cmFileCommand::HandleLockCommand( - if (directory) - { - path += "/cmake.lock"; - } >>> p.s. For a lock with no timeout, maybe there can be a built-in timeout >>> after which CMake displays a message what it's trying to do, so that it >>> doesn't just hang mysteriously. >> You can use `message` command: >> >> message(STATUS "Try to lock ${file}") >> file(LOCK ${file}) >> >> or more complex (more user-friendly): >> >> while(TRUE) >> file(LOCK "${file}" RESULT is_locked TIMEOUT 5) >> if(is_locked) >> message("Locked. ${resource_info}") >> break() >> endif() >> string(TIMESTAMP time_now "%S/%M") >> message("[${time_now}] Lock failed, retry... (file: ${file})") >> endwhile() > Sure. I was just thinking out loud if folks are worried about CMake > "mysteriously" hanging, this (implemented in CMake proper) would be an > option to allay those concerns. You can use `file(LOCK ...` as a base block for creation more complex/verbose locks (i.e. you can add CMakeLockHelpers extra module), I don't see any implementation defects that can't you allow to do one. *Developers* do the "mysterious" stuff, not cmake. You can write: while(TRUE) endwhile() so should we print extra message on entering `while`? Though it would be the nice feature if you can read some info about lockers. E.g. `CMAKE_BINARY_DIR`, username, pid and timestamp. But this require a lot of work: lock new file for writing (cmake.lock-info), write some info (what format?), unlock (allow other process read info file) and so on. > (I'd also encourage anyone writing > locks, especially with no time out, to always say what they're doing > first :-). But that's somewhat a separate issue.) > I'm the one who will use this feature without timeouts (it's impossible to predict some). E.g. cmake instance will run ExternalProject_Add with Qt building for > 4 hours, should I set the timeout so my jenkins jobs will crash? Or should I print waiting message every second? What about > 14400 lines of useless/endless logs? The important part is that if you abort the job, or "kill" the process, then lock will be released automagically. There are no instruments in cmake right now that can emulate such behaviour. Ruslo From mw_triad at users.sourceforge.net Thu Dec 18 11:48:19 2014 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Thu, 18 Dec 2014 11:48:19 -0500 Subject: [cmake-developers] New command 'file(LOCK_DIRECTORY ...)' In-Reply-To: <5493013E.8070404@yahoo.com> References: <5431B11C.3010209@yahoo.com> <54329100.8020502@kitware.com> <54338CF1.3070304@yahoo.com> <5433DBC1.5080800@kitware.com> <5435257B.80201@yahoo.com> <543531CC.7090103@kitware.com> <5437C6CA.3030201@yahoo.com> <543BE40C.4000404@kitware.com> <5491FC89.9020008@yahoo.com> <5493013E.8070404@yahoo.com> Message-ID: On 2014-12-18 11:30, Ruslan Baratov via cmake-developers wrote: > You prefer ".cmake.lock", I prefer "cmake.lock", others prefer > '.lock'/'.cmake'. For me it doesn't really matter. What matter is the > *standard* cmake name. FWIW, I do have a slight preference to using a hidden file :-). > About "implementation complexity": > [...diffs elided...] There's also the documentation, unit tests... I don't think there is appreciable maintenance overhead, or I'd feel more strongly about it. The point was just to consider these things. (Having written it already also makes the question somewhat moot.) > I'm the one who will use this feature without timeouts (it's impossible > to predict some). E.g. cmake instance will run ExternalProject_Add with > Qt building for > 4 hours, should I set the timeout so my jenkins jobs > will crash? Or should I print waiting message every second? I'd print *one* message if the lock has not been obtained "quickly". Even in the situation you describe, if I were writing the lock, I would probably wrap it in a helper to print why it's waiting (or else always print a message before trying to get the lock and once the lock is held), just so that it's obvious from the logs if a build is stuck waiting on the lock or stuck for some other reason. That said... I think you've convinced me that if you need a lock with no timeout, it should *always* generate status messages, which can more reasonably be punted to the CMakeLists.txt author. -- Matthew From mantis at public.kitware.com Thu Dec 18 15:57:56 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 18 Dec 2014 15:57:56 -0500 Subject: [cmake-developers] [CMake 0015319]: Documentation clarification Message-ID: <46c14977f373fb3a7c7052e1c0d666e3@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15319 ====================================================================== Reported By: Craig Hicks Assigned To: ====================================================================== Project: CMake Issue ID: 15319 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-12-18 15:57 EST Last Modified: 2014-12-18 15:57 EST ====================================================================== Summary: Documentation clarification Description: The manual entry -G "MinGW Makefiles" on http://www.cmake.org/cmake/help/v2.8.12/cmake.html#gen%3aMinGWMakefiles is ambiguous: MinGW Makefiles: Generates a make file for use with mingw32-make. The makefiles generated use cmd.exe as the shell. They do not require msys or a unix shell. Should be changed to : MinGW Makefiles: Generates a make file for use with mingw32-make. The makefiles generated use cmd.exe as the shell. They are not compatible msys or a unix shell. "cmake" should not be invoked from msys or unix shells when "MinGW Makefiles" is specified as the generator. Steps to Reproduce: Invoking (cmake -G "MinGW Makefiles" ...) from msys shell always fails in many ways. Additional Information: Obvious only once you know it. The wording "does not require msys or a unix shell" could be interpreted as implying that ", however they can be used". As background, mingw32-make did not come with the minwg 64 bit gcc 4.8.2 downloaded from sourceforge. It seemed correct that cmake would require "MinGW Makefiles" for the mingw compiler. However, cmake could not find a make program, but since I had make sitting around under msys, I just specified that. If the manual had been more explicit, it would have saved your novice user a lot of time. Trolling the web for advice, it seems there are many folks who have encountered the same problem. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-12-18 15:57 Craig Hicks New Issue ====================================================================== From aleixpol at kde.org Thu Dec 18 21:02:24 2014 From: aleixpol at kde.org (Aleix Pol) Date: Fri, 19 Dec 2014 03:02:24 +0100 Subject: [cmake-developers] Extracting target metadata, IDE integration In-Reply-To: References: <8D194B4B1E73A83-15CC-952@webmail-m269.sysops.aol.com> <542D4879.20204@kitware.com> <6761034.LHuUtODnIM@eto> Message-ID: On Wed, Oct 15, 2014 at 1:46 AM, Aleix Pol wrote: > On Fri, Oct 3, 2014 at 3:52 PM, Rolf Eike Beer wrote: >> >> Brad King wrote: >> > On 10/01/2014 07:46 PM, Aleix Pol wrote: >> > > I'm very interested in getting this in and iterating forward. >> > > >> > > Any comments? How do changes get integrated? >> > >> > My main concern is that the format has not been proven with a >> > corresponding implementation of an actual IDE/plugin to use it. >> > Once we start producing a format changing it later will be >> > problematic for compatibility. Even though we added a version >> > number to the file, an IDE might not be updated along with a >> > CMake that produces a newer version. >> >> This probably needs a way to query for the IDE which versions the given >> CMake >> version supports, no? Otherwise a newer IDE may request version 3 and just >> get >> nothing because the CMake binary only supports 1 and 2. >> >> Eike >> -- > > > If it's not available then it should just error out. > > Aleix > > PS: I'm alive, working on this, when I get some free time Hi, I would like to propose this as a final version of this patch. http://proli.net/meu/kdevelop/0001-cmake-Add-option-to-generate-target-metadata-for-IDE.patch I have a working proof of concept in KDevelop already I'm quite happy with. Any thoughts? Aleix From steveire at gmail.com Fri Dec 19 02:51:39 2014 From: steveire at gmail.com (Stephen Kelly) Date: Fri, 19 Dec 2014 08:51:39 +0100 Subject: [cmake-developers] Extracting target metadata, IDE integration References: <8D194B4B1E73A83-15CC-952@webmail-m269.sysops.aol.com> <542D4879.20204@kitware.com> <6761034.LHuUtODnIM@eto> Message-ID: Aleix Pol wrote: > Hi, > I would like to propose this as a final version of this patch. > http://proli.net/meu/kdevelop/0001-cmake-Add-option-to-generate-target-metadata-for-IDE.patch > > I have a working proof of concept in KDevelop already I'm quite happy > with. > > Any thoughts? Just some quick ones: 1) Getting the right sources: Consider this: cmake_minimum_required(VERSION 2.8) project(cmaketest) add_custom_command( OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/other.cpp" COMMAND ${CMAKE_COMMAND} -E copy "${CMAKE_CURRENT_SOURCE_DIR}/bar.cpp" "${CMAKE_CURRENT_BINARY_DIR}/other.cpp" MAIN_DEPENDENCY "${CMAKE_CURRENT_SOURCE_DIR}/bar.cpp" ) file(GENERATE OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/somefile.cpp" CONTENT " static const char all_srcs[] = \"$\";\n" ) add_executable(foo main.cpp "${CMAKE_CURRENT_BINARY_DIR}/other.cpp" somefile.txt foo.h ) After running cmake: $ cat somefile.cpp static const char all_srcs[] = "main.cpp;/home/stephen/dev/src/playground/cmake/build/other.cpp;somefile.txt;foo.h;/home/stephen/dev/src/playground/cmake/bar.cpp"; You would get the same result with your patch: "bar.cpp" is a 'SOURCE', but it is not an 'object source'. It is not compiled into the target. CMake knows that, and provides cmGeneratorTarget::GetObjectSources to get 'the list of sources compiled into objects by this buildsystem'. You should list that in your JSON instead. You might also make use of GetHeaderSources and GetExtraSources at least to cover foo.h and somefile.txt too, and probably GetExternalObjects too. 2) The final patch will need to have unit tests and documentation. 3) Did you find any of the feedback from the Creator or CLion guys relevant? I'd have to review the rest of the thread again to see if there's anything else which should be addressed already by this iteration of the patch. 4) I won't be able to do a complete review before January. Thanks! Steve. From ppietraszkiewicz at psi.de Fri Dec 19 06:31:24 2014 From: ppietraszkiewicz at psi.de (Pietraszkiewicz, Piotr) Date: Fri, 19 Dec 2014 12:31:24 +0100 Subject: [cmake-developers] [PATCH] FindCURL: Search for Windows debug builds as well In-Reply-To: <6A111E4E6826BD4E826D9EFED1970381A08208@INFRA-BLN-EXP.psi.de> References: <6A111E4E6826BD4E826D9EFED1970381A08208@INFRA-BLN-EXP.psi.de> Message-ID: <6A111E4E6826BD4E826D9EFED1970381A0820A@INFRA-BLN-EXP.psi.de> Please forgive me the patch below. It looks my email client (MS Outlook) tempered with the content after I pressed "Send". Here it comes again as attachment. Thanks for applying, Piotr -----Urspr?ngliche Nachricht----- Von: Pietraszkiewicz, Piotr Gesendet: Freitag, 19. Dezember 2014 12:21 An: 'cmake-developers at cmake.org' Betreff: [PATCH] FindCURL: Search for Windows debug builds as well Signed-off-by: Piotr Pietraszkiewicz --- Modules/FindCURL.cmake | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Modules/FindCURL.cmake b/Modules/FindCURL.cmake index 209fd87..6fb8f7d 100644 --- a/Modules/FindCURL.cmake +++ b/Modules/FindCURL.cmake @@ -40,6 +40,9 @@ find_library(CURL_LIBRARY NAMES curllib_static # Windows older "Win32 - MSVC" prebuilts (libcurl.lib, e.g. libcurl-7.15.5-win32- msvc.zip): libcurl + # Windows debug builds (produced by curl's build system by passing + DEBUG=yes # option to nmake invocation) + libcurl_debug ) mark_as_advanced(CURL_LIBRARY) -- 2.1.1 -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-FindCURL-Search-for-Windows-debug-builds-as-well.patch Type: application/octet-stream Size: 871 bytes Desc: 0001-FindCURL-Search-for-Windows-debug-builds-as-well.patch URL: From ppietraszkiewicz at psi.de Fri Dec 19 06:20:43 2014 From: ppietraszkiewicz at psi.de (Pietraszkiewicz, Piotr) Date: Fri, 19 Dec 2014 12:20:43 +0100 Subject: [cmake-developers] [PATCH] FindCURL: Search for Windows debug builds as well Message-ID: <6A111E4E6826BD4E826D9EFED1970381A08208@INFRA-BLN-EXP.psi.de> Signed-off-by: Piotr Pietraszkiewicz --- Modules/FindCURL.cmake | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Modules/FindCURL.cmake b/Modules/FindCURL.cmake index 209fd87..6fb8f7d 100644 --- a/Modules/FindCURL.cmake +++ b/Modules/FindCURL.cmake @@ -40,6 +40,9 @@ find_library(CURL_LIBRARY NAMES curllib_static # Windows older "Win32 - MSVC" prebuilts (libcurl.lib, e.g. libcurl-7.15.5-win32- msvc.zip): libcurl + # Windows debug builds (produced by curl's build system by passing DEBUG=yes + # option to nmake invocation) + libcurl_debug ) mark_as_advanced(CURL_LIBRARY) -- 2.1.1 From eike at sf-mail.de Fri Dec 19 07:38:51 2014 From: eike at sf-mail.de (Rolf Eike Beer) Date: Fri, 19 Dec 2014 13:38:51 +0100 Subject: [cmake-developers] [PATCH] FindCURL: Search for Windows debug builds as well In-Reply-To: <6A111E4E6826BD4E826D9EFED1970381A0820A@INFRA-BLN-EXP.psi.de> References: <6A111E4E6826BD4E826D9EFED1970381A08208@INFRA-BLN-EXP.psi.de> <6A111E4E6826BD4E826D9EFED1970381A0820A@INFRA-BLN-EXP.psi.de> Message-ID: <3504156.qAej1ZuaQ6@caliban.sf-tec.de> Am Freitag, 19. Dezember 2014, 12:31:24 schrieb Pietraszkiewicz, Piotr: > Please forgive me the patch below. It looks my email client (MS Outlook) > tempered with the content after I pressed "Send". Here it comes again as > attachment. The right way would be to do another find_library() into a different variable, and then use SelectLibraryConfigurations.cmake to merge the results into CURL_LIBRARIES, so it will work with any combination of libs found. That way linking will work on Windows if you switch between debug and release configurations. Eike -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From brad.king at kitware.com Fri Dec 19 08:44:12 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 19 Dec 2014 08:44:12 -0500 Subject: [cmake-developers] pause on new topics please In-Reply-To: <5491D6EC.9000607@kitware.com> References: <5491D6EC.9000607@kitware.com> Message-ID: <54942BAC.4@kitware.com> On 12/17/2014 02:18 PM, Brad King wrote: > I have a few open topics in 'next' right now that may take a > few more nightly iterations to cleanup the dashboard. In order > to avoid disrupting this process with other changes, please > refrain from adding more topics to 'next'. This is all done now. Please proceed to add topics normally. Thanks, -Brad From mantis at public.kitware.com Fri Dec 19 10:07:54 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Fri, 19 Dec 2014 16:07:54 +0100 Subject: [cmake-developers] [CMake 0015320]: Xcode with space in path can not be used to run CMake Message-ID: The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15320 ====================================================================== Reported By: Stephen Kelly Assigned To: ====================================================================== Project: CMake Issue ID: 15320 Category: CMake Reproducibility: have not tried Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-12-19 16:07 CET Last Modified: 2014-12-19 16:07 CET ====================================================================== Summary: Xcode with space in path can not be used to run CMake Description: CMake fails while trying to test the C compiler. Although cmGlobalGenerator::Build runs '/usr/bin/make', somehow it gets transformed into an improperly quoted "/Applications/Xcode 2.app/Contents/Developer/usr/bin/make", which then fails: Run Build Command:"/usr/bin/make" "cmTryCompileExec4267961401/fast" /Applications/Xcode 2.app/Contents/Developer/usr/bin/make -f CMakeFiles/cmTryCompileExec4267961401.dir/build.make CMakeFiles/cmTryCompileExec4267961401.dir/build make: /Applications/Xcode: No such file or directory make: *** [cmTryCompileExec4267961401/fast] Error 1 I don't know how the command to execute is transformed. It is still '/usr/bin/make' when passed to cmsysProcess_SetCommand in cmSystemTools::RunSingleCommand. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-12-19 16:07 Stephen Kelly New Issue ====================================================================== From kgt at lanl.gov Fri Dec 19 17:46:00 2014 From: kgt at lanl.gov (Thompson, KT) Date: Fri, 19 Dec 2014 22:46:00 +0000 Subject: [cmake-developers] Proposed change to behavior of find_program Message-ID: <0458DF31F610EF42BFC78C497E806C7B3B5796F9@ECS-EXG-P-MB03.win.lanl.gov> CMake developers, I am proposing a small change to SystemTools.cxx to address a problem I have on multiple systems. I need find_program to return the path to an executable file that is not marked with the read permission bit, but is marked with the execute bit (e.g.: chmod 111 file). On Linux systems, find_program unnecessarily requires that a file be readable. I propose that the FileExists function be changed to test for execute permission instead of read permission: --- a/Source/kwsys/SystemTools.cxx +++ b/Source/kwsys/SystemTools.cxx @@ -1148,13 +1148,13 @@ bool SystemTools::FileExists(const kwsys_stl::string& filename) { return (GetFileAttributesA(winpath) != INVALID_FILE_ATTRIBUTES); } - return access(filename.c_str(), R_OK) == 0; + return access(filename.c_str(), X_OK) == 0; #elif defined(_WIN32) return (GetFileAttributesW( SystemTools::ConvertToWindowsExtendedPath(filename).c_str()) != INVALID_FILE_ATTRIBUTES); #else - return access(filename.c_str(), R_OK) == 0; + return access(filename.c_str(), X_OK) == 0; #endif } Comments? Thoughts? -kt Kelly (KT) Thompson -------------- next part -------------- An HTML attachment was scrubbed... URL: From kgt at lanl.gov Fri Dec 19 18:25:34 2014 From: kgt at lanl.gov (Thompson, KT) Date: Fri, 19 Dec 2014 23:25:34 +0000 Subject: [cmake-developers] Proposed change to behavior of find_program In-Reply-To: <0458DF31F610EF42BFC78C497E806C7B3B5796F9@ECS-EXG-P-MB03.win.lanl.gov> References: <0458DF31F610EF42BFC78C497E806C7B3B5796F9@ECS-EXG-P-MB03.win.lanl.gov> Message-ID: <0458DF31F610EF42BFC78C497E806C7B3B579719@ECS-EXG-P-MB03.win.lanl.gov> Hmm. It looks my original proposal breaks some backward compatibility. Maybe this patch is better: --- a/Source/kwsys/SystemTools.cxx +++ b/Source/kwsys/SystemTools.cxx @@ -1148,13 +1148,13 @@ bool SystemTools::FileExists(const kwsys_stl::string& filename) { return (GetFileAttributesA(winpath) != INVALID_FILE_ATTRIBUTES); } - return access(filename.c_str(), R_OK) == 0; + return access(filename.c_str(), R_OK) == 0 || access(filename.c_str(), X_OK) == 0; #elif defined(_WIN32) return (GetFileAttributesW( SystemTools::ConvertToWindowsExtendedPath(filename).c_str()) != INVALID_FILE_ATTRIBUTES); #else - return access(filename.c_str(), R_OK) == 0; + return access(filename.c_str(), R_OK) == 0 || access(filename.c_str(), X_OK) == 0; #endif } From: cmake-developers [mailto:cmake-developers-bounces at cmake.org] On Behalf Of Thompson, KT Sent: Friday, December 19, 2014 3:46 PM To: cmake-developers at cmake.org Subject: [cmake-developers] Proposed change to behavior of find_program CMake developers, I am proposing a small change to SystemTools.cxx to address a problem I have on multiple systems. I need find_program to return the path to an executable file that is not marked with the read permission bit, but is marked with the execute bit (e.g.: chmod 111 file). On Linux systems, find_program unnecessarily requires that a file be readable. I propose that the FileExists function be changed to test for execute permission instead of read permission: --- a/Source/kwsys/SystemTools.cxx +++ b/Source/kwsys/SystemTools.cxx @@ -1148,13 +1148,13 @@ bool SystemTools::FileExists(const kwsys_stl::string& filename) { return (GetFileAttributesA(winpath) != INVALID_FILE_ATTRIBUTES); } - return access(filename.c_str(), R_OK) == 0; + return access(filename.c_str(), X_OK) == 0; #elif defined(_WIN32) return (GetFileAttributesW( SystemTools::ConvertToWindowsExtendedPath(filename).c_str()) != INVALID_FILE_ATTRIBUTES); #else - return access(filename.c_str(), R_OK) == 0; + return access(filename.c_str(), X_OK) == 0; #endif } Comments? Thoughts? -kt Kelly (KT) Thompson -------------- next part -------------- An HTML attachment was scrubbed... URL: From justin.borodinsky at gmail.com Sat Dec 20 08:26:07 2014 From: justin.borodinsky at gmail.com (Justin Borodinsky) Date: Sat, 20 Dec 2014 08:26:07 -0500 Subject: [cmake-developers] [PATCH] Avoid bad alloc for large files Message-ID: I received a bad alloc when uploading a large file with CTest. The patch below resolved this. --- Source/cmCTest.cxx | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Source/cmCTest.cxx b/Source/cmCTest.cxx index 2bf7b77..52bf651 100644 --- a/Source/cmCTest.cxx +++ b/Source/cmCTest.cxx @@ -1688,7 +1688,7 @@ std::string cmCTest::Base64GzipEncodeFile(std::string file) //---------------------------------------------------------------------- std::string cmCTest::Base64EncodeFile(std::string file) { - long len = cmSystemTools::FileLength(file); + std::size_t len = static_cast(cmSystemTools::FileLength(file)); cmsys::ifstream ifs(file.c_str(), std::ios::in #ifdef _WIN32 | std::ios::binary @@ -1699,7 +1699,7 @@ std::string cmCTest::Base64EncodeFile(std::string file) ifs.close(); unsigned char *encoded_buffer - = new unsigned char [ static_cast( + = new unsigned char [ static_cast( static_cast(len) * 1.5 + 5.0) ]; unsigned long rlen -------------- next part -------------- An HTML attachment was scrubbed... URL: From eike at sf-mail.de Sat Dec 20 08:44:59 2014 From: eike at sf-mail.de (Rolf Eike Beer) Date: Sat, 20 Dec 2014 14:44:59 +0100 Subject: [cmake-developers] [PATCH] Avoid bad alloc for large files In-Reply-To: References: Message-ID: <1527258.6sUHiuymsO@eto> Justin Borodinsky wrote: > I received a bad alloc when uploading a large file with CTest. The patch > below resolved this. Your patch is line-wrapped and can't be applied. However, I did this by hand. This is basically the same, but it avoids the needless floating point arithmetic. Does it work for you? diff --git a/Source/cmCTest.cxx b/Source/cmCTest.cxx index 2bf7b77..1a7bf45 100644 --- a/Source/cmCTest.cxx +++ b/Source/cmCTest.cxx @@ -1688,7 +1688,7 @@ std::string cmCTest::Base64GzipEncodeFile(std::string file) //---------------------------------------------------------------------- std::string cmCTest::Base64EncodeFile(std::string file) { - long len = cmSystemTools::FileLength(file); + const size_t len = cmSystemTools::FileLength(file); cmsys::ifstream ifs(file.c_str(), std::ios::in #ifdef _WIN32 | std::ios::binary @@ -1699,8 +1699,7 @@ std::string cmCTest::Base64EncodeFile(std::string file) ifs.close(); unsigned char *encoded_buffer - = new unsigned char [ static_cast( - static_cast(len) * 1.5 + 5.0) ]; + = new unsigned char [ (len * 3) / 2 + 5 ]; unsigned long rlen = cmsysBase64_Encode(file_buffer, len, encoded_buffer, 1); Eike -- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From justin.borodinsky at gmail.com Sat Dec 20 09:03:13 2014 From: justin.borodinsky at gmail.com (Justin Borodinsky) Date: Sat, 20 Dec 2014 09:03:13 -0500 Subject: [cmake-developers] [PATCH] Avoid bad alloc for large files In-Reply-To: <1527258.6sUHiuymsO@eto> References: <1527258.6sUHiuymsO@eto> Message-ID: Yes, thank you. On Saturday, December 20, 2014, Rolf Eike Beer wrote: > Justin Borodinsky wrote: > > I received a bad alloc when uploading a large file with CTest. The patch > > below resolved this. > > Your patch is line-wrapped and can't be applied. However, I did this by > hand. > This is basically the same, but it avoids the needless floating point > arithmetic. Does it work for you? > > diff --git a/Source/cmCTest.cxx b/Source/cmCTest.cxx > index 2bf7b77..1a7bf45 100644 > --- a/Source/cmCTest.cxx > +++ b/Source/cmCTest.cxx > @@ -1688,7 +1688,7 @@ std::string > cmCTest::Base64GzipEncodeFile(std::string file) > //---------------------------------------------------------------------- > std::string cmCTest::Base64EncodeFile(std::string file) > { > - long len = cmSystemTools::FileLength(file); > + const size_t len = cmSystemTools::FileLength(file); > cmsys::ifstream ifs(file.c_str(), std::ios::in > #ifdef _WIN32 > | std::ios::binary > @@ -1699,8 +1699,7 @@ std::string cmCTest::Base64EncodeFile(std::string > file) > ifs.close(); > > unsigned char *encoded_buffer > - = new unsigned char [ static_cast( > - static_cast(len) * 1.5 + 5.0) ]; > + = new unsigned char [ (len * 3) / 2 + 5 ]; > > unsigned long rlen > = cmsysBase64_Encode(file_buffer, len, encoded_buffer, 1); > > > > Eike > -- -------------- next part -------------- An HTML attachment was scrubbed... URL: From mantis at public.kitware.com Sat Dec 20 19:12:08 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sat, 20 Dec 2014 19:12:08 -0500 Subject: [cmake-developers] [CMake 0015321]: Generation of the ninja, ignore escape Message-ID: <66916ff4bd8539d6933811a7581dce6e@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15321 ====================================================================== Reported By: Denis Denisov Assigned To: ====================================================================== Project: CMake Issue ID: 15321 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-12-20 19:12 EST Last Modified: 2014-12-20 19:12 EST ====================================================================== Summary: Generation of the ninja, ignore escape Description: `ninja: error: build.ninja:3194: bad $-escape (literal $ must be written as $$)`` Additional Information: before code: ``` # Xcode/Ninja generators undefined MAKE if(NOT MAKE) set(MAKE make) endif() add_custom_target( hack ALL COMMAND env OPTBIN="${OCAMLC_OPT_SUFFIX}" $(MAKE) EXTRA_INCLUDE_PATHS="${extra_include_paths}" EXTRA_LIB_PATHS="${extra_lib_paths}" EXTRA_CC_FLAGS="${extra_cc_flags}" EXTRA_NATIVE_LIBRARIES="${extra_native_libraries}" WORKING_DIRECTORY "${CMAKE_CURRENT_SOURCE_DIR}/src" ) ``` code build.ninja:3194: ``` ############################################# # Custom command for hphp/hack/CMakeFiles/hack build hphp/hack/CMakeFiles/hack: CUSTOM_COMMAND || third-party/lz4/liblz4.a COMMAND = cd /home/denji/Desktop/hhvm/hphp/hack/src && env OPTBIN=".opt" $(MAKE) EXTRA_INCLUDE_PATHS="/usr/include /home/denji/Desktop/hhvm/third-party/lz4" EXTRA_LIB_PATHS="/usr/lib/x86_64-linux-gnu /home/denji/Desktop/hhvm/third-party/lz4" EXTRA_CC_FLAGS="-DHAVE_ELF_GETSHDRSTRNDX -pthread" EXTRA_NATIVE_LIBRARIES="lz4" `` ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-12-20 19:12 Denis Denisov New Issue ====================================================================== From cascaval at acm.org Sun Dec 21 00:34:40 2014 From: cascaval at acm.org (Calin Cascaval) Date: Sat, 20 Dec 2014 21:34:40 -0800 Subject: [cmake-developers] patch to fix installed size for cpack PackageMaker generator References: <99A92BD4-266B-4B89-989D-503F2CA06F1F@acm.org> Message-ID: Hi, The cpack PackageMaker generator reports all packages as having a size of 1 because it does not use the CPACK_PACKAGING_INSTALL_PREFIX when looking for files in a component. Attached is a patch that fixes this issue. -- Thanks, Calin -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-fixes-installed-sizes-for-cpack-PackageMaker-generat.patch Type: application/octet-stream Size: 938 bytes Desc: not available URL: -------------- next part -------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4130 bytes Desc: not available URL: From pasanen.tuukka at gmail.com Mon Dec 22 02:16:25 2014 From: pasanen.tuukka at gmail.com (Tuukka Pasanen) Date: Mon, 22 Dec 2014 09:16:25 +0200 Subject: [cmake-developers] FindSWIG and UseSWIG modules ain't having maintainer Message-ID: Hello, I'm fairly new to CMake but use it intensive in many applications. In one where SWIG stuff used to work very well in new version error started to rise and I noticed that SWIG ain't maintained anymore. If it's so I can start keeping it up-to-date as we rely on that. Thanks, Tuukka From vlad.vinogradov47 at gmail.com Mon Dec 22 02:34:36 2014 From: vlad.vinogradov47 at gmail.com (=?UTF-8?B?0JLQu9Cw0LTQuNGB0LvQsNCyINCS0LjQvdC+0LPRgNCw0LTQvtCy?=) Date: Mon, 22 Dec 2014 11:34:36 +0400 Subject: [cmake-developers] [PATCH][CTest] Fix error message in ctest_coverage command Message-ID: Hello all, I'd like to submit a small patch for CTest tool. It fixes one error message from ctest_coverage command: "Looks like there are more lines in the file: ...". Original code prints line, while from logic it should print file name. Best regards, Vlad Vinogradov -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-CTest-Fix-error-message-in-ctest_coverage-command.patch Type: text/x-patch Size: 1054 bytes Desc: not available URL: From foss at grueninger.de Mon Dec 22 02:44:55 2014 From: foss at grueninger.de (=?windows-1252?Q?Christoph_Gr=FCninger?=) Date: Mon, 22 Dec 2014 08:44:55 +0100 Subject: [cmake-developers] Which binaries should be required in FindLATEX? In-Reply-To: <5481FFA6.5080004@kitware.com> References: <54816045.5070306@grueninger.de> <5481FFA6.5080004@kitware.com> Message-ID: <5497CBF7.1090001@grueninger.de> Hi Brad, please find attached a patch that introduces components handling for optional LaTeX executable. FPHSA's components handling feature is pretty cool. I first wrote the components handling myself, but the built-in version is more elegant. I am the first one to use this feature in an official test. Yeah! Maybe we should deprecate the old variables name? I don't know and its not a big deal to keep them. Bye and thanks for your constructive feedback, Christoph -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-FindLATEX-Add-components-handling.patch Type: text/x-patch Size: 4551 bytes Desc: not available URL: From brad.king at kitware.com Mon Dec 22 09:38:22 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 22 Dec 2014 09:38:22 -0500 Subject: [cmake-developers] Proposed change to behavior of find_program In-Reply-To: <0458DF31F610EF42BFC78C497E806C7B3B579719@ECS-EXG-P-MB03.win.lanl.gov> References: <0458DF31F610EF42BFC78C497E806C7B3B5796F9@ECS-EXG-P-MB03.win.lanl.gov> <0458DF31F610EF42BFC78C497E806C7B3B579719@ECS-EXG-P-MB03.win.lanl.gov> Message-ID: <54982CDE.8090506@kitware.com> On 12/19/2014 06:25 PM, Thompson, KT wrote: > Hmm. It looks my original proposal breaks some backward compatibility. [snip] > @@ -1148,13 +1148,13 @@ bool SystemTools::FileExists(const kwsys_stl::string& filename) [snip] > - return access(filename.c_str(), R_OK) == 0; > + return access(filename.c_str(), R_OK) == 0 || access(filename.c_str(), X_OK) == 0; The issue your patch tries to address is tracked here: http://www.cmake.org/Bug/view.php?id=10468 However, there is a deeper issue discussed here: http://www.cmake.org/Bug/view.php?id=14022 Basically "access" is not the right way to implement FileExists. If we're going to change it at all, the change should make it do the right thing. See comments in issue 14022 for details. Unfortunately the full fix likely requires an audit of all FileExists call sites to determine which ones need to be just lstat and which ones care about permissions too. -Brad From brad.king at kitware.com Mon Dec 22 09:40:12 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 22 Dec 2014 09:40:12 -0500 Subject: [cmake-developers] patch to fix installed size for cpack PackageMaker generator In-Reply-To: References: <99A92BD4-266B-4B89-989D-503F2CA06F1F@acm.org> Message-ID: <54982D4C.5060808@kitware.com> On 12/21/2014 12:34 AM, Calin Cascaval wrote: > [PATCH] fixes installed sizes for cpack PackageMaker generator Thanks. Applied: cpack: Fix installed size computation with PackageMaker generator http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=42ed76bc FYI, if you're still using the PackageMaker generator please note that it will require changes to package for OS X 10.10. The cmCPackPackageMakerGenerator::PackageCompatibilityVersion variable uses a floating point value for the OS X version so 10.10 ends up being treated as 10.1. Since Apple has deprecated PackageMaker no one has taken the time to fix this in CMake yet. -Brad From brad.king at kitware.com Mon Dec 22 10:12:43 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 22 Dec 2014 10:12:43 -0500 Subject: [cmake-developers] Which binaries should be required in FindLATEX? In-Reply-To: <5497CBF7.1090001@grueninger.de> References: <54816045.5070306@grueninger.de> <5481FFA6.5080004@kitware.com> <5497CBF7.1090001@grueninger.de> Message-ID: <549834EB.9080307@kitware.com> On 12/22/2014 02:44 AM, Christoph Gr?ninger wrote: > please find attached a patch that introduces components handling for > optional LaTeX executable. Thanks for working on this. > Maybe we should deprecate the old variables name? The names should not be changed at all. They become cache entries that people may be setting in their scripts on the command line, or have set in existing build trees. Also the names are visible to the human in cmake-gui so calling them "..._FOUND" does not make sense. The FPHSA component handling still leaves it to the module code to specify whether each component was found. Therefore you should just use a pattern like this: find_program(LATEX2HTML_CONVERTER ...) if (LATEX2HTML_CONVERTER) set(LATEX_LATEX2HTML_FOUND 1) else() set(LATEX_LATEX2HTML_FOUND 0) endif() Once you have that explicit mapping then you can optionally use lower-case component names. I have no strong preference on that though. Thanks, -Brad From brad.king at kitware.com Mon Dec 22 10:22:35 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 22 Dec 2014 10:22:35 -0500 Subject: [cmake-developers] CMake 3.2 feature freeze on 2015-02-02 Message-ID: <5498373B.9070308@kitware.com> Hi Folks, The feature freeze in 'master' for CMake 3.2 will be on Feb 2, 2015. I will announce a freeze in 'next' sometime in the preceding week so that we can get any remaining dashboard trouble cleaned up. Please schedule any planned topics accordingly. Any major or disruptive changes should be completed a few weeks prior to the freeze or delayed until after 'next' re-opens. Thanks, -Brad From brad.king at kitware.com Mon Dec 22 10:26:36 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 22 Dec 2014 10:26:36 -0500 Subject: [cmake-developers] Maintainer vacation until Jan 7 Message-ID: <5498382C.8030902@kitware.com> Hi Folks, FYI, tomorrow I'm heading out for vacation and will likely not be responsive until at least Jan 7. -Brad From cascaval at acm.org Mon Dec 22 10:38:33 2014 From: cascaval at acm.org (Calin Cascaval) Date: Mon, 22 Dec 2014 07:38:33 -0800 Subject: [cmake-developers] patch to fix installed size for cpack PackageMaker generator In-Reply-To: <54982D4C.5060808@kitware.com> References: <99A92BD4-266B-4B89-989D-503F2CA06F1F@acm.org> <54982D4C.5060808@kitware.com> Message-ID: <868D11C2-18AD-49A5-8711-6E77F0B48258@acm.org> Hi Brad, Thank you! Quick question: if PackageMaker is deprecated, what do you recommend for packaging on OSX. I will take a look and fix the compatibility version. Thanks, Calin http://developer.qualcomm.com/mare > On Dec 22, 2014, at 06:40, Brad King wrote: > >> On 12/21/2014 12:34 AM, Calin Cascaval wrote: >> [PATCH] fixes installed sizes for cpack PackageMaker generator > > Thanks. Applied: > > cpack: Fix installed size computation with PackageMaker generator > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=42ed76bc > > FYI, if you're still using the PackageMaker generator please note > that it will require changes to package for OS X 10.10. The > cmCPackPackageMakerGenerator::PackageCompatibilityVersion variable > uses a floating point value for the OS X version so 10.10 ends up > being treated as 10.1. Since Apple has deprecated PackageMaker > no one has taken the time to fix this in CMake yet. > > -Brad From eike at sf-mail.de Mon Dec 22 10:39:02 2014 From: eike at sf-mail.de (Rolf Eike Beer) Date: Mon, 22 Dec 2014 16:39:02 +0100 Subject: [cmake-developers] Introducing targets in FindPkgConfig Message-ID: <5843192.04Xz6GJ9j3@caliban.sf-tec.de> Hi Daniele, the feature about CMake language I probably hate most is link_directories(). Sadly one currently needs to use it when working with software dependencies imported from PkgConfig. What I would like to get is the following: when a list of libraries and directories is returned by PkgConfig then for every of these libraries the absolute path to the library is determined using find_library() using the given directories as hints. With that, noone needs to use link_directories() anymore. Since this would introduce new behavior people would need to adapt their CMakeLists.txt to this new feature. Therefore I think it would be a good idea to expose this new information not by new variables, but using targets. So if I search for OpenSSL using PkgConfig I would get a target PkgConfig::OpenSSL that I can link to, and that has the libraries, compile flags, include dirs and whatnot. Sadly, I don't quite understand all the macros in FindPkgConfig.cmake. Can you either point me to the right place where I would hook up something like that or try doing it? Greetings, Eike -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From brad.king at kitware.com Mon Dec 22 10:42:49 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 22 Dec 2014 10:42:49 -0500 Subject: [cmake-developers] patch to fix installed size for cpack PackageMaker generator In-Reply-To: <868D11C2-18AD-49A5-8711-6E77F0B48258@acm.org> References: <99A92BD4-266B-4B89-989D-503F2CA06F1F@acm.org> <54982D4C.5060808@kitware.com> <868D11C2-18AD-49A5-8711-6E77F0B48258@acm.org> Message-ID: <54983BF9.8060507@kitware.com> On 12/22/2014 10:38 AM, Calin Cascaval wrote: > if PackageMaker is deprecated, what do you recommend for > packaging on OSX. IIRC Apple deprecated PackageMaker and no longer distributes it with Xcode. The preferred method of packaging on OS X is now with the DragNDrop generator. Users see a .dmg that they mount and view in Finder. Finder shows the .app and a symlink to the /Applications folder. The user needs only to drag the .app to the Applications symlink (or anywhere else they want to install it). > I will take a look and fix the compatibility version. Great, thanks! -Brad From brad.king at kitware.com Mon Dec 22 10:50:28 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 22 Dec 2014 10:50:28 -0500 Subject: [cmake-developers] [PATCH] Avoid bad alloc for large files In-Reply-To: <1527258.6sUHiuymsO@eto> References: <1527258.6sUHiuymsO@eto> Message-ID: <54983DC4.9090906@kitware.com> On 12/20/2014 08:44 AM, Rolf Eike Beer wrote: > This is basically the same, but it avoids the needless floating point > arithmetic. Does it work for you? Thanks, Eike. Please add a topic to put this in 'next' when ready. Thanks, -Brad From brad.king at kitware.com Mon Dec 22 10:51:03 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 22 Dec 2014 10:51:03 -0500 Subject: [cmake-developers] [PATCH][CTest] Fix error message in ctest_coverage command In-Reply-To: References: Message-ID: <54983DE7.3050800@kitware.com> On 12/22/2014 02:34 AM, ????????? ?????????? wrote: > I'd like to submit a small patch for CTest tool. > It fixes one error message from ctest_coverage command: > "Looks like there are more lines in the file: ...". > Original code prints line, while from logic it should print file name. Thanks! Applied: ctest_coverage: Fix error message to report the file name http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9c4984b4 -Brad From brad.king at kitware.com Mon Dec 22 10:51:29 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 22 Dec 2014 10:51:29 -0500 Subject: [cmake-developers] FindSWIG and UseSWIG modules ain't having maintainer In-Reply-To: References: Message-ID: <54983E01.1040908@kitware.com> Hi Tuukka, On 12/22/2014 02:16 AM, Tuukka Pasanen wrote: > I'm fairly new to CMake but use it intensive in many applications. In > one where SWIG stuff used to work very well in new version error > started to rise and I noticed that SWIG ain't maintained anymore. If > it's so I can start keeping it up-to-date as we rely on that. Great, thanks for volunteering! Please start by reading CONTRIBUTING.rst at the top of the CMake source tree. At first please send patches to this mailing list for review and integration. Thanks, -Brad From sean at rogue-research.com Mon Dec 22 10:52:11 2014 From: sean at rogue-research.com (Sean McBride) Date: Mon, 22 Dec 2014 10:52:11 -0500 Subject: [cmake-developers] patch to fix installed size for cpack PackageMaker generator In-Reply-To: <868D11C2-18AD-49A5-8711-6E77F0B48258@acm.org> References: <99A92BD4-266B-4B89-989D-503F2CA06F1F@acm.org> <54982D4C.5060808@kitware.com> <868D11C2-18AD-49A5-8711-6E77F0B48258@acm.org> Message-ID: <20141222155211.1362005544@mail.rogue-research.com> On Mon, 22 Dec 2014 07:38:33 -0800, Calin Cascaval said: >I will take a look and fix the compatibility version. I had started a patch but haven't had time to test it. Perhaps you could continue from where I left off, see attached. Cheers, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada -------------- next part -------------- A non-text attachment was scrubbed... Name: Archive.zip Type: application/zip Size: 9800 bytes Desc: not available URL: From brad.king at kitware.com Mon Dec 22 10:57:24 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 22 Dec 2014 10:57:24 -0500 Subject: [cmake-developers] patch to fix installed size for cpack PackageMaker generator In-Reply-To: <20141222155211.1362005544@mail.rogue-research.com> References: <99A92BD4-266B-4B89-989D-503F2CA06F1F@acm.org> <54982D4C.5060808@kitware.com> <868D11C2-18AD-49A5-8711-6E77F0B48258@acm.org> <20141222155211.1362005544@mail.rogue-research.com> Message-ID: <54983F64.5020307@kitware.com> On 12/22/2014 10:52 AM, Sean McBride wrote: > I had started a patch but haven't had time to test it. Perhaps > you could continue from where I left off, see attached. Thanks, Sean. Calin, the patch currently hard-codes encoding of the major and minor versions into an integer: this->PackageCompatibilityVersion = ((10 << 16) | 4); I think the encoding is a good approach, but please factor it out into a helper macro (local to the .cxx file) so the encoding logic does not have to be repeated. Thanks, -Brad From mantis at public.kitware.com Mon Dec 22 11:55:16 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Mon, 22 Dec 2014 11:55:16 -0500 Subject: [cmake-developers] [CMake 0015322]: Double backslash to escape '#' in CMAKE_CXX_FLAGS no longer works Message-ID: <9b94aa76eba4f3d17ede331e52a1058d@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15322 ====================================================================== Reported By: Braden McDaniel Assigned To: ====================================================================== Project: CMake Issue ID: 15322 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-12-22 11:55 EST Last Modified: 2014-12-22 11:55 EST ====================================================================== Summary: Double backslash to escape '#' in CMAKE_CXX_FLAGS no longer works Description: In versions of CMake prior to 3.1.0, this worked: set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wno-\\#pragma-messages") In CMake 3.1.0, that no longer works; this, however, does: set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wno-#pragma-messages") I'm not sure if this is a deliberate change or not; but it's a slightly annoying break with backward compatibility. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-12-22 11:55 Braden McDanielNew Issue ====================================================================== From ddomenichelli at drdanz.it Mon Dec 22 11:51:21 2014 From: ddomenichelli at drdanz.it (Daniele E. Domenichelli) Date: Mon, 22 Dec 2014 17:51:21 +0100 Subject: [cmake-developers] [Review request] Topic install_CMAKE_INSTALL_RELATIVE Message-ID: <54984C09.9080409@drdanz.it> Hello all, Please review the topic install_CMAKE_INSTALL_RELATIVE. install: Add CMAKE_INSTALL_RELATIVE variable http://www.cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=3b57fa0 This patch adds a a variable CMAKE_INSTALL_RELATIVE to install files in CMAKE_INSTALL_PREFIX using relative path, even if an absolute path was passed to the install() command. This might be useful in some cases to create binary packages. For example, CPack will refuse to create a relocatable package if files are installed using absolute paths, even if inside the prefix. In my experience, I found that many projects install files using absolute paths, even when they should be installed using a path relative to the CMAKE_INSTALL_PREFIX. This makes it impossible to package them using CPack without large modification of the cmake code. Moreover it makes it hard to install only one component in a different prefix, for example using: cmake -DCMAKE_PREFIX_PATH=/new/prefix -DCOMPONENT=foo \ -P cmake_install.cmake (You can probably use DESTDIR, calculating the relative path between the original prefix and the new prefix, but I believe that's not the best way to do it) Since the usage of absolute path instead of relative is in most of the cases just a an unwanted effect, I believe that using this variable, could simplify this kind of tasks. What do you think? Cheers, Daniele From ddomenichelli at drdanz.it Mon Dec 22 12:55:16 2014 From: ddomenichelli at drdanz.it (Daniele E. Domenichelli) Date: Mon, 22 Dec 2014 18:55:16 +0100 Subject: [cmake-developers] Introducing targets in FindPkgConfig In-Reply-To: <5843192.04Xz6GJ9j3@caliban.sf-tec.de> References: <5843192.04Xz6GJ9j3@caliban.sf-tec.de> Message-ID: <54985B04.3030601@drdanz.it> Hello Eike, On 22/12/14 16:39, Rolf Eike Beer wrote: > What I would like to get is the following: when a list of libraries and > directories is returned by PkgConfig then for every of these libraries the > absolute path to the library is determined using find_library() using the given > directories as hints. > [...] > Since this would introduce new behavior people would need to adapt > their CMakeLists.txt to this new feature. Therefore I think it would be a good > idea to expose this new information not by new variables, but using targets. We have a macro to do exactly this and a few other things (actually 2 macros, that diverged slightly I will make them one again as soon I as I have some time), you can find them here: https://github.com/robotology/yarp/blob/master/conf/MacroStandardFindModule.cmake https://github.com/robotology/ycm/blob/master/modules/StandardFindModule.cmake The macro tries first to find a CMake config file (some recent version of some package installs cmake config files, but we still need to support older versions, so that's the reason for this check). If the config files were not found, it uses pkg-config to detect the package, and find the libraries as you want to do, but instead of creating targets it sets some variables (see the documentation in the files). It's probably not perfect, but with this, creating a "FindXXX.cmake" for a software using pkg-config becomes trivial, for example: https://github.com/robotology/yarp/blob/master/conf/FindGtkDataboxMM.cmake and then you just use find_package() to locate your package and to get the variables. I agree that using targets would be a great thing, but at the time I didn't find a way generic enough to do all of this in the macro, since it's not always easy to understand which one is the "main" library "add_library(UNKNOWN IMPORTED)" and which ones should be in the "INTERFACE_LINK_LIBRARIES" property. Moreover we depend on CMake 2.8.9 that does not support all the features that we would need for targets. Perhaps using a recent CMake version you can use "add_library(INTERFACE IMPORTED)" and put all of them in the INTERFACE_LINK_LIBRARIES? > So if I search for OpenSSL using PkgConfig I would get a target > PkgConfig::OpenSSL that I can link to, and that has the libraries, compile > flags, include dirs and whatnot. > > Sadly, I don't quite understand all the macros in FindPkgConfig.cmake. Can you > either point me to the right place where I would hook up something like that > or try doing it? You can start from the macros I linked before for the pkg-config part, and then have a look at the CMake modules that create imported targets (FindQt4, FindGTK2, FindZLIB, FindGLUT, FindGLEW) for the targets part (all the variables you need should be there already). Let me know if you do it, I'd like to do it too one day... About the FindPkgConfig macros documentation, what is that is not clear? http://www.cmake.org/cmake/help/git-master/module/FindPkgConfig.html It looks well documented to me, but if there is something that is not clear we could try to improve it... I hope this helps. Let me know if I can help you more specifically with this... Cheers, Daniele From eike at sf-mail.de Mon Dec 22 13:38:20 2014 From: eike at sf-mail.de (Rolf Eike Beer) Date: Mon, 22 Dec 2014 19:38:20 +0100 Subject: [cmake-developers] Introducing targets in FindPkgConfig In-Reply-To: <54985B04.3030601@drdanz.it> References: <5843192.04Xz6GJ9j3@caliban.sf-tec.de> <54985B04.3030601@drdanz.it> Message-ID: <6338647.XjMTEVcYgP@caliban.sf-tec.de> Am Montag, 22. Dezember 2014, 18:55:16 schrieb Daniele E. Domenichelli: > Hello Eike, > > On 22/12/14 16:39, Rolf Eike Beer wrote: > > What I would like to get is the following: when a list of libraries and > > directories is returned by PkgConfig then for every of these libraries the > > absolute path to the library is determined using find_library() using the > > given directories as hints. > > [...] > > Since this would introduce new behavior people would need to adapt > > their CMakeLists.txt to this new feature. Therefore I think it would be a > > good idea to expose this new information not by new variables, but using > > targets. > We have a macro to do exactly this and a few other things (actually 2 > macros, that diverged slightly I will make them one again as soon I as I > have some time), you can find them here: > > https://github.com/robotology/yarp/blob/master/conf/MacroStandardFindModule.cmake > https://github.com/robotology/ycm/blob/master/modules/StandardFindModule.cmake [...] > > So if I search for OpenSSL using PkgConfig I would get a target > > PkgConfig::OpenSSL that I can link to, and that has the libraries, compile > > flags, include dirs and whatnot. > > > > Sadly, I don't quite understand all the macros in FindPkgConfig.cmake. Can > > you either point me to the right place where I would hook up something > > like that or try doing it? > > You can start from the macros I linked before for the pkg-config part, and > then have a look at the CMake modules that create imported targets > (FindQt4, FindGTK2, FindZLIB, FindGLUT, FindGLEW) for the targets part > (all the variables you need should be there already). > Let me know if you do it, I'd like to do it too one day... The imported targets was not the thing worrying me, although my experience with this is a bit limited at the moment. > About the FindPkgConfig macros documentation, what is that is not clear? It's not about the documentation of that module, but where I need to hack it into the module. The code is quite a bit of indirections, I guess I would need to do this _pkg_check_modules_internal at the end of the last foreach? Eike -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From domen.vrankar at gmail.com Mon Dec 22 14:01:31 2014 From: domen.vrankar at gmail.com (Domen Vrankar) Date: Mon, 22 Dec 2014 20:01:31 +0100 Subject: [cmake-developers] [PATCH] Avoid bad alloc for large files In-Reply-To: <1527258.6sUHiuymsO@eto> References: <1527258.6sUHiuymsO@eto> Message-ID: >> I received a bad alloc when uploading a large file with CTest. The patch >> below resolved this. > > Your patch is line-wrapped and can't be applied. However, I did this by hand. > This is basically the same, but it avoids the needless floating point > arithmetic. Does it work for you? snip > std::string cmCTest::Base64EncodeFile(std::string file) snip > - static_cast(len) * 1.5 + 5.0) ]; > + = new unsigned char [ (len * 3) / 2 + 5 ]; snip I came across a similar issue a few days ago in our code base (bad alloc when compressing a large file in-memory with 256 MB data ulimit per process) and I used a different formula to calculate the maximum buffer size: http://stackoverflow.com/questions/1533113/calculate-the-size-to-a-base-64-encoded-message I used a bit modified answer from "kanaka". size_t output_size = ((len - 1) / 3) * 4 + 4; size_t final_size = output_size + (output_size / 64) * 2; // 64 instead of 76 since RFC 3548 and RFC 4648 allow CLRF line breaks every 64 characters This formula would give less memory allocation overhead. Regards, Domen From robert.maynard at kitware.com Mon Dec 22 14:15:56 2014 From: robert.maynard at kitware.com (Robert Maynard) Date: Mon, 22 Dec 2014 14:15:56 -0500 Subject: [cmake-developers] DragNDrop: Easier custom dmg layouts Message-ID: I have pushed to next a branch called better_custom_dmgs that improves and helps automate the process of creating custom dmg's. Previously the DragNDrop generator allowed the user to specify a custom background image file and a custom .DS_Store. This approach had some serious limitations the primary being that a new .DS_Store would have to be externally created each time the package name was changed. The new version now allows the user to specify a custom apple script to run during the package step that is used to generate the .DS_Store. This allows projects to now have a nice looking package without having to externally generate a new .DS_Store. Additionally this branch has changed the behavior of CPACK_DMG_BACKGROUND_IMAGE. Now the background image is stored in a hidden folder, and the extension of the source image is retained. These changes are needed to allow the custom apple script to easily set the background image. If anyone has any questions or issues with this branch please tell me. From domen.vrankar at gmail.com Mon Dec 22 14:51:51 2014 From: domen.vrankar at gmail.com (Domen Vrankar) Date: Mon, 22 Dec 2014 20:51:51 +0100 Subject: [cmake-developers] [PATCH] Avoid bad alloc for large files In-Reply-To: References: <1527258.6sUHiuymsO@eto> Message-ID: >>> I received a bad alloc when uploading a large file with CTest. The patch >>> below resolved this. I just took a look at the code and noticed that it is quite memory consumption heavy ((2 * encoded_buffer_size) + file_buffer_size). This implementation could be used instead (not tested): std::string cmCTest::Base64EncodeFile(const std::string& file) { const size_t len = cmSystemTools::FileLength(file); cmsys::ifstream ifs(file.c_str(), std::ios::in #ifdef _WIN32 | std::ios::binary #endif ); std::string base64; // set to empty string by default // section for throwing encoded_buffer out of scope as soon as possible to // use up less memory { const size_t output_size = ((len - 1) / 3) * 4 + 4; const size_t final_size = output_size + (output_size / 64) * 2; std::vector encoded_buffer; encoded_buffer.resize(final_size); // section for throwing file_buffer out of scope as soon as possible to // use up less memory { std::vector file_buffer; file_buffer.resize(len); ifs.read(reinterpret_cast(file_buffer), len); ifs.close(); unsigned long rlen = cmsysBase64_Encode(&file_buffer[0], len, &encoded_buffer[0], 1); } // consume less memory by swapping tmp string buffer with base64 variable std::string(encoded_buffer.begin(), encoded_buffer.begin() + rlen).swap(base64); } return base64; // this will produce another copy in C++98 } It lowers memory consumption to approximately (2 * encoded_buffer_size) and it also makes memory deallocation exception safe (file_buffer and encoded_buffer variables). A better solution would be to rewrite the function to: void cmCTest::Base64EncodeFile(const std::string& file, std::string& base64) to prevent one more copy at return but since this changes the interface we could go a step further and simply rewrite the entire function and cmsysBase64_Encode function to use streams and thereby lower the memory consumption even further (less copying between different containers and more readable than the above version). Thoughts? p.s. I think that using std::ios::binary would work on all platforms so I guess that the function does not need ifdef at the top. Regards, Domen From domen.vrankar at gmail.com Mon Dec 22 15:28:02 2014 From: domen.vrankar at gmail.com (Domen Vrankar) Date: Mon, 22 Dec 2014 21:28:02 +0100 Subject: [cmake-developers] [Review request] Topic install_CMAKE_INSTALL_RELATIVE In-Reply-To: <54984C09.9080409@drdanz.it> References: <54984C09.9080409@drdanz.it> Message-ID: > In my experience, I found that many projects install files using > absolute paths, even when they should be installed using a path relative > to the CMAKE_INSTALL_PREFIX. This makes it impossible to package them > using CPack without large modification of the cmake code. Maybe others will disagree but to be quite honest I myself don't think that CMAKE_INSTALL_RELATIVE variable would be the right solution... I myself prefer to write install commands with relative paths and I guess that something like that should be fixed in CMakeLists.txt and contributed to projects that use absolute paths and not add a new variable for doing this... (maybe someone decided to leave some paths absolute for a reason e.g. symlinks or system/program requirements for certain files). > Moreover it makes it hard to install only one component in a different > prefix, for example using: > > cmake -DCMAKE_PREFIX_PATH=/new/prefix -DCOMPONENT=foo \ > -P cmake_install.cmake This is again something that can be solved by using for e.g. GNUInstallDirs.cmake module and adding the paths set in this module to paths provided to install commands. As for CPack and different locations... I don't know about other packagers but for RPM packages I wrote a patch a few weeks ago that uses GNUInstallDirs.cmake and provides option to have more than one relocation path per RPM package. The reason that I haven't contributed it yet is that I still have to write tests for the code (I'll do this in the following days) before submitting the patch for review. Preview patch is attached. Regards, Domen -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-multiple-path-relocation-prefixes.patch Type: text/x-diff Size: 7455 bytes Desc: not available URL: From mantis at public.kitware.com Mon Dec 22 15:45:42 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Mon, 22 Dec 2014 15:45:42 -0500 Subject: [cmake-developers] [CMake 0015323]: Visual Studio 2013 %3B in IMPORTED_IMPLIB_ Message-ID: <16be80e450e87e0d3170fd4b86b9691a@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15323 ====================================================================== Reported By: yaruopooner Assigned To: ====================================================================== Project: CMake Issue ID: 15323 Category: CMake Reproducibility: always Severity: minor Priority: high Status: new ====================================================================== Date Submitted: 2014-12-22 15:45 EST Last Modified: 2014-12-22 15:45 EST ====================================================================== Summary: Visual Studio 2013 %3B in IMPORTED_IMPLIB_ Description: Include "%3B" in the output of the "IMPORTED_IMPLIB_". This problem has occurred from cmake3.1.0. 3.0.2 don't have this issue. I tried a few pattern. set_property(TARGET additional_dependencies PROPERTY IMPORTED_IMPLIB_RELEASE foo.lib bar.lib) or set_property(TARGET additional_dependencies PROPERTY IMPORTED_IMPLIB_RELEASE "foo.lib;bar.lib") but I got same output. foo.lib%3Bbar.lib Steps to Reproduce: -console cmake -G "Visual Studio 12 2013 Win64" . -CMakeLists.txt(Excerpt) add_library(additional_dependencies SHARED IMPORTED) set_property(TARGET additional_dependencies PROPERTY IMPORTED_IMPLIB_RELEASE foo.lib bar.lib) -output foo.lib%3Bbar.lib ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-12-22 15:45 yaruopooner New Issue ====================================================================== From eike at sf-mail.de Mon Dec 22 16:16:50 2014 From: eike at sf-mail.de (Rolf Eike Beer) Date: Mon, 22 Dec 2014 22:16:50 +0100 Subject: [cmake-developers] [PATCH] Avoid bad alloc for large files In-Reply-To: <54983DC4.9090906@kitware.com> References: <1527258.6sUHiuymsO@eto> <54983DC4.9090906@kitware.com> Message-ID: <3389915.ry4cKcysDS@caliban.sf-tec.de> Am Montag, 22. Dezember 2014, 10:50:28 schrieb Brad King: > On 12/20/2014 08:44 AM, Rolf Eike Beer wrote: > > This is basically the same, but it avoids the needless floating point > > arithmetic. Does it work for you? > > Thanks, Eike. Please add a topic to put this in 'next' when ready. Done. I wonder if we should not check for new returning null? Eike -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From mantis at public.kitware.com Mon Dec 22 16:20:45 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Mon, 22 Dec 2014 16:20:45 -0500 Subject: [cmake-developers] [CMake 0015324]: CMake 3.1.0 Crashes When Told to Regenerate a Project Originally Generated Under CMake 3.0.2 Message-ID: The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15324 ====================================================================== Reported By: Bryce Glover Assigned To: ====================================================================== Project: CMake Issue ID: 15324 Category: CMake Reproducibility: sometimes Severity: crash Priority: low Status: new ====================================================================== Date Submitted: 2014-12-22 16:20 EST Last Modified: 2014-12-22 16:20 EST ====================================================================== Summary: CMake 3.1.0 Crashes When Told to Regenerate a Project Originally Generated Under CMake 3.0.2 Description: If one runs the command 'cmake -G "Xcode" [project-location]' from within '[project-location]/build/' after updating CMake from version 3.0.2 to version 3.1.0 when this directory was last populated by CMake 3.0.2. Steps to Reproduce: 1.) Make sure that CMake 3.0.2 is installed. 2.) Run 'cmake -G "Xcode" [project-location]' from within '[project-location]/build/' via Terminal. 3.) Update CMake from version 3.0.2 to version 3.1.0. 4.) Run 'cmake -G "Xcode" [project-location]' from within '[project-location]/build/' via Terminal again. 5.) CMake should crash when 'Checking for a C compiler using Xcode?.' Additional Information: The project I'm having trouble with is LLVM/Clang/compiler-rt/test-suite, and I use Homebrew in order to keep CMake up to date. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-12-22 16:20 Bryce Glover New Issue ====================================================================== From brad.king at kitware.com Mon Dec 22 16:25:02 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 22 Dec 2014 16:25:02 -0500 Subject: [cmake-developers] [Review request] Topic install_CMAKE_INSTALL_RELATIVE In-Reply-To: References: <54984C09.9080409@drdanz.it> Message-ID: <54988C2E.7030607@kitware.com> On 12/22/2014 03:28 PM, Domen Vrankar wrote: > Maybe others will disagree but to be quite honest I myself don't think > that CMAKE_INSTALL_RELATIVE variable would be the right solution... I > myself prefer to write install commands with relative paths and I > guess that something like that should be fixed in CMakeLists.txt and > contributed to projects that use absolute paths and not add a new > variable for doing this... I agree. If a project uses absolute install paths that means its authors have not thought about making relocatable packages. There could be many other problems with making such projects relocatable other than just install rules. -Brad From mantis at public.kitware.com Mon Dec 22 16:27:53 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Mon, 22 Dec 2014 16:27:53 -0500 Subject: [cmake-developers] [CMake 0015325]: Regression building x265 using CMake 3.1 (Segmentation fault) Message-ID: The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15325 ====================================================================== Reported By: David Coppa Assigned To: ====================================================================== Project: CMake Issue ID: 15325 Category: CMake Reproducibility: always Severity: crash Priority: normal Status: new ====================================================================== Date Submitted: 2014-12-22 16:27 EST Last Modified: 2014-12-22 16:27 EST ====================================================================== Summary: Regression building x265 using CMake 3.1 (Segmentation fault) Description: CMake 3.1 segfaults while building x265 using the ninja generator, "Unix Makefiles" generator is not affected. This crash didn't happen with cmake-3.0.2 (same version of x265). I have the same segfault on both Arch Linux and OpenBSD-current. I've attached two files with the gdb output for both systems. You can have a look at the source code for x265 here: https://github.com/videolan/x265/tree/master/source/cmake $ cmake -G Ninja -DCMAKE_INSTALL_PREFIX=/usr ../source/ -- cmake version 3.1.0 -- The C compiler identification is GNU 4.9.2 -- The CXX compiler identification is GNU 4.9.2 -- Check for working C compiler using: Ninja -- Check for working C compiler using: Ninja -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Detecting C compile features -- Detecting C compile features - done -- Check for working CXX compiler using: Ninja -- Check for working CXX compiler using: Ninja -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done -- Detected x86 target processor -- Looking for include file inttypes.h -- Looking for include file inttypes.h - found -- Performing Test CC_HAS_NO_NARROWING -- Performing Test CC_HAS_NO_NARROWING - Success -- Performing Test CC_HAS_NO_ARRAY_BOUNDS -- Performing Test CC_HAS_NO_ARRAY_BOUNDS - Success -- Performing Test CC_HAS_FAST_MATH -- Performing Test CC_HAS_FAST_MATH - Success -- Performing Test CC_HAS_STACK_REALIGN -- Performing Test CC_HAS_STACK_REALIGN - Success -- Performing Test CC_HAS_FNO_EXCEPTIONS_FLAG -- Performing Test CC_HAS_FNO_EXCEPTIONS_FLAG - Success -- Found yasm: /usr/bin/yasm (found version "1.3.0") -- Found Yasm 1.3.0 to build assembly primitives -- x265 version 1.4 -- The ASM_YASM compiler identification is unknown -- Found assembler: /usr/bin/yasm -- Looking for strtok_r -- Looking for strtok_r - found -- Looking for include file getopt.h -- Looking for include file getopt.h - found -- Configuring done CMake Error: Error required internal CMake variable not set, cmake may be not be built correctly. Missing variable is: CMAKE_ASM_YASM_COMPILE_OBJECT Segmentation fault (core dumped) Steps to Reproduce: Try building x265 using the ninja generator of CMake 3.1.0. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-12-22 16:27 David Coppa New Issue 2014-12-22 16:27 David Coppa File Added: cmake31-x265-openbsd.out ====================================================================== From foss at grueninger.de Mon Dec 22 18:29:33 2014 From: foss at grueninger.de (=?windows-1252?Q?Christoph_Gr=FCninger?=) Date: Tue, 23 Dec 2014 00:29:33 +0100 Subject: [cmake-developers] Which binaries should be required in FindLATEX? In-Reply-To: <549834EB.9080307@kitware.com> References: <54816045.5070306@grueninger.de> <5481FFA6.5080004@kitware.com> <5497CBF7.1090001@grueninger.de> <549834EB.9080307@kitware.com> Message-ID: <5498A95D.1010509@grueninger.de> Hi Brad, please find attached a new patch following your latest suggestions. > Once you have that explicit mapping then you can optionally use > lower-case component names. I have no strong preference on that > though. I'd like to have lower case components but I dislike mixed-cased variable names. The latter feeling is stronger. Wish you nice holidays, Christoph -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-FindLATEX-Add-components-handling.patch Type: text/x-patch Size: 4994 bytes Desc: not available URL: From aleixpol at kde.org Mon Dec 22 19:30:58 2014 From: aleixpol at kde.org (Aleix Pol) Date: Tue, 23 Dec 2014 01:30:58 +0100 Subject: [cmake-developers] Extracting target metadata, IDE integration In-Reply-To: References: Message-ID: On Thu, Sep 25, 2014 at 9:14 AM, Anton Makeev wrote: > Hey everyone, > > We are developing CLion at JetBrains that utilizes CMake as its main project > model. Stephen Kelly timely drew our attention to this discussion, and I?d like > to share some thoughts. Here are the general ones and I?ll also comment on > separate messages in the thread. > > > We?ve managed to get almost all the necessary project information, > using ?GNU/MinGW Makefiles? generators: > > * list of targets comes from 'CMakeFiles/TargetDirectories.txt' > * list of source files from ?CMakeFiles/A.dir/DependInfo.cmake? > * list of headers and resources from ?codeblocks.cbp? file > * per-file/target compiler and its flags from ?CMakeFiles/Target.dir/flags.make? > * location of product files from ?CMakeFiles/Target.dir/build.make? > > > What we miss (not all of them are directly related the targets metadata, > but I'd like to share anyway since the topic is about IDE integration): > > * Location of every source file and target in CMakeLists > - it would greatly help to refactorings, navigation etc. In the implementation I'm proposing, the target is specified. The file is hard to figure out given that it's passed as a string argument and it could come virtually from anywhere (i.e. glob, operations, a set() somewhere else, etc.). My conclusion is that knowing the target position is already a good enough help. > * Complete list of headers and resource files > - they are only listed in special generators like code blocks. I'll look into it, what do you need exactly? The headers in each target? > * An easily parseable list of errors and warnings with origin information. > At the moment we parse error output but not everything can be parsed reliably. Agreed, It's something we're missing as well. I also don't really like the fact that sometimes the paths are absolute and sometimes they're relative, especially in the relative case, since it's hard to tell if it's relative to the build directory or source directory. > * No progress indication. Since the generation may take several minutes, > providing feedback is crucial. I never found such case, I would argue that a project which has a cmake script that takes several minutes is broken, but maybe we can open a thread to discuss it? > * Ability to distinguish a library from an executable target. > This will help to offer a better UI for run/debug configurations. It's included in the proposed implementation. > * Possibility to collect information for every build target in one run. > Currently, we have to invoke generator for every CMAKE_BUILT_TYPE separately. Well, that's because you use CodeBlocks generators. It seems like for example in MSVC they generate many build configurations at once. This implementation supports having parallel debug/release builds. Then we can fix make/ninja generators or even create new ones. > * CMake stops processing when it find a missing file, so that IDE cannot have > full project model, until this files is created. Well, it's related to the error generation issue we discussed. I think it's something we should discuss in parallel. > * When there are existing in-source generated files in the project dir, > CMake doesn't allow generating into a separate out-of-source folder. > An IDE has to invent workarounds here. Arguably, in-source generation is broken by definition... > * Not sure if it?s possible at all - a lightweight phase where CMake only > collects necessary information (list of files/targets, compiler settings). > This will help IDE react to the changes much faster. That would be extra-cool, agreed. Maybe it's an iteration we can consider in the future. > > > Here is why I think the discussed functionality should not be a separate > generator: > > CLion doesn?t have it?s own project model nor is intended as build tool > replacement. Currently, the only option for CLion users is makefiles build, that > is not a best option for everyone: there is a good and fast alternative ?Ninja?. > Ideally, users should be able to choose whatever tool better suites them. > > The problem is that the generated Makefiles are used both, for internal needs, > like reading project structure, and also to build and run the user?s program. > If we wanted to support Ninja generator, we would need to rewrite all the logic > that retrieves the project information, using the files that are created by > Ninja generator. While I suppose it?s possible, it?s not the best option - very > error prone and resource demanding. > > If CMake generated a separate descriptor, regardless the generator used > (Makefiles, Ninja), it would be much easier to support; and the users will > benefit from better, more reliable and faster CMake integration in an IDE. I'd really appreciate your feedback on the patch I provided, I'll be happy to provide the information you miss. Aleix From aleixpol at kde.org Mon Dec 22 19:42:24 2014 From: aleixpol at kde.org (Aleix Pol) Date: Tue, 23 Dec 2014 01:42:24 +0100 Subject: [cmake-developers] Extracting target metadata, IDE integration In-Reply-To: References: Message-ID: On Tue, Dec 23, 2014 at 1:30 AM, Aleix Pol wrote: > On Thu, Sep 25, 2014 at 9:14 AM, Anton Makeev > wrote: >> Hey everyone, >> >> We are developing CLion at JetBrains that utilizes CMake as its main project >> model. Stephen Kelly timely drew our attention to this discussion, and I?d like >> to share some thoughts. Here are the general ones and I?ll also comment on >> separate messages in the thread. >> >> >> We?ve managed to get almost all the necessary project information, >> using ?GNU/MinGW Makefiles? generators: >> >> * list of targets comes from 'CMakeFiles/TargetDirectories.txt' >> * list of source files from ?CMakeFiles/A.dir/DependInfo.cmake? >> * list of headers and resources from ?codeblocks.cbp? file >> * per-file/target compiler and its flags from ?CMakeFiles/Target.dir/flags.make? >> * location of product files from ?CMakeFiles/Target.dir/build.make? >> >> >> What we miss (not all of them are directly related the targets metadata, >> but I'd like to share anyway since the topic is about IDE integration): >> >> * Location of every source file and target in CMakeLists >> - it would greatly help to refactorings, navigation etc. > In the implementation I'm proposing, the target is specified. The file > is hard to figure out given that it's passed as a string argument and > it could come virtually from anywhere (i.e. glob, operations, a set() > somewhere else, etc.). My conclusion is that knowing the target > position is already a good enough help. > >> * Complete list of headers and resource files >> - they are only listed in special generators like code blocks. > I'll look into it, what do you need exactly? The headers in each target? > >> * An easily parseable list of errors and warnings with origin information. >> At the moment we parse error output but not everything can be parsed reliably. > Agreed, It's something we're missing as well. I also don't really like > the fact that sometimes the paths are absolute and sometimes they're > relative, especially in the relative case, since it's hard to tell if > it's relative to the build directory or source directory. > >> * No progress indication. Since the generation may take several minutes, >> providing feedback is crucial. > I never found such case, I would argue that a project which has a > cmake script that takes several minutes is broken, but maybe we can > open a thread to discuss it? > >> * Ability to distinguish a library from an executable target. >> This will help to offer a better UI for run/debug configurations. > It's included in the proposed implementation. > >> * Possibility to collect information for every build target in one run. >> Currently, we have to invoke generator for every CMAKE_BUILT_TYPE separately. > Well, that's because you use CodeBlocks generators. It seems like for > example in MSVC they generate many build configurations at once. This > implementation supports having parallel debug/release builds. Then we > can fix make/ninja generators or even create new ones. > >> * CMake stops processing when it find a missing file, so that IDE cannot have >> full project model, until this files is created. > Well, it's related to the error generation issue we discussed. I think > it's something we should discuss in parallel. > >> * When there are existing in-source generated files in the project dir, >> CMake doesn't allow generating into a separate out-of-source folder. >> An IDE has to invent workarounds here. > Arguably, in-source generation is broken by definition... > >> * Not sure if it?s possible at all - a lightweight phase where CMake only >> collects necessary information (list of files/targets, compiler settings). >> This will help IDE react to the changes much faster. > That would be extra-cool, agreed. Maybe it's an iteration we can > consider in the future. > >> >> >> Here is why I think the discussed functionality should not be a separate >> generator: >> >> CLion doesn?t have it?s own project model nor is intended as build tool >> replacement. Currently, the only option for CLion users is makefiles build, that >> is not a best option for everyone: there is a good and fast alternative ?Ninja?. >> Ideally, users should be able to choose whatever tool better suites them. >> >> The problem is that the generated Makefiles are used both, for internal needs, >> like reading project structure, and also to build and run the user?s program. >> If we wanted to support Ninja generator, we would need to rewrite all the logic >> that retrieves the project information, using the files that are created by >> Ninja generator. While I suppose it?s possible, it?s not the best option - very >> error prone and resource demanding. >> >> If CMake generated a separate descriptor, regardless the generator used >> (Makefiles, Ninja), it would be much easier to support; and the users will >> benefit from better, more reliable and faster CMake integration in an IDE. > > I'd really appreciate your feedback on the patch I provided, I'll be > happy to provide the information you miss. > > Aleix By the way, I just looked into the Implementation for obtaining the header files in the CodeBlocks generator and I don't think we want something like that in a standarized file: https://paste.kde.org/pbzigoaq5 It's basically based on conjectures over the actually built files, if such thing needs to be done, it can be done by the IDE just as well. Aleix From d3ck0r at gmail.com Mon Dec 22 21:42:43 2014 From: d3ck0r at gmail.com (J Decker) Date: Mon, 22 Dec 2014 18:42:43 -0800 Subject: [cmake-developers] [Review request] Topic install_CMAKE_INSTALL_RELATIVE In-Reply-To: <54988C2E.7030607@kitware.com> References: <54984C09.9080409@drdanz.it> <54988C2E.7030607@kitware.com> Message-ID: On Mon, Dec 22, 2014 at 1:25 PM, Brad King wrote: > On 12/22/2014 03:28 PM, Domen Vrankar wrote: > > Maybe others will disagree but to be quite honest I myself don't think > > that CMAKE_INSTALL_RELATIVE variable would be the right solution... I > > myself prefer to write install commands with relative paths and I > > guess that something like that should be fixed in CMakeLists.txt and > > contributed to projects that use absolute paths and not add a new > > variable for doing this... > > I agree. If a project uses absolute install paths that means its > authors have not thought about making relocatable packages. There > could be many other problems with making such projects relocatable > other than just install rules. > > THere's not a problem with relative install paths; why were they passed as absolute? Just apply a pre-filter on your side like if( matches ${destpath} ${cmake_install_prefix} ) subst it out. All paths are relative to start with; and seems like a corruption to have an abosolute path > -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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eike at sf-mail.de Tue Dec 23 04:27:47 2014 From: eike at sf-mail.de (Rolf Eike Beer) Date: Tue, 23 Dec 2014 10:27:47 +0100 Subject: [cmake-developers] [PATCH] Avoid bad alloc for large files In-Reply-To: <3389915.ry4cKcysDS@caliban.sf-tec.de> References: <54983DC4.9090906@kitware.com> <3389915.ry4cKcysDS@caliban.sf-tec.de> Message-ID: <2169516.HuKNnRZuIO@caliban.sf-tec.de> Am Montag, 22. Dezember 2014, 22:16:50 schrieb Rolf Eike Beer: > Am Montag, 22. Dezember 2014, 10:50:28 schrieb Brad King: > > On 12/20/2014 08:44 AM, Rolf Eike Beer wrote: > > > This is basically the same, but it avoids the needless floating point > > > arithmetic. Does it work for you? > > > > Thanks, Eike. Please add a topic to put this in 'next' when ready. > > Done. I wonder if we should not check for new returning null? Ok, now I get this: cmCTest.cxx C:\Dashboards\My Tests\CMakeNext-vs12-64-ninja-src\Source\cmCTest.cxx(1705) : warning C4267: 'argument' : conversion from 'size_t' to 'unsigned long', possible loss of data The problem is: this is absolutely right. On Windows64 this means that the maximum file size will be 4GB, or one needs to change the base64 implementation. Which way to go? Eike -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From eike at sf-mail.de Tue Dec 23 04:32:14 2014 From: eike at sf-mail.de (Rolf Eike Beer) Date: Tue, 23 Dec 2014 10:32:14 +0100 Subject: [cmake-developers] [PATCH] Avoid bad alloc for large files In-Reply-To: <2169516.HuKNnRZuIO@caliban.sf-tec.de> References: <3389915.ry4cKcysDS@caliban.sf-tec.de> <2169516.HuKNnRZuIO@caliban.sf-tec.de> Message-ID: <1583147.SYO83yAqcF@caliban.sf-tec.de> Am Dienstag, 23. Dezember 2014, 10:27:47 schrieb Rolf Eike Beer: > Am Montag, 22. Dezember 2014, 22:16:50 schrieb Rolf Eike Beer: > > Am Montag, 22. Dezember 2014, 10:50:28 schrieb Brad King: > > > On 12/20/2014 08:44 AM, Rolf Eike Beer wrote: > > > > This is basically the same, but it avoids the needless floating point > > > > arithmetic. Does it work for you? > > > > > > Thanks, Eike. Please add a topic to put this in 'next' when ready. > > > > Done. I wonder if we should not check for new returning null? > > Ok, now I get this: > > cmCTest.cxx > C:\Dashboards\My Tests\CMakeNext-vs12-64-ninja-src\Source\cmCTest.cxx(1705) > : warning C4267: 'argument' : conversion from 'size_t' to 'unsigned long', > possible loss of data > > The problem is: this is absolutely right. On Windows64 this means that the > maximum file size will be 4GB, or one needs to change the base64 > implementation. Which way to go? *lol* From: "Brad King (Code Review)" Date: Tue, 23 Dec 2014 04:27:55 -0500 Subject: Change in KWSys[master]: Base64: Use size_t for lenghts in API -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From brad.king at kitware.com Tue Dec 23 04:34:03 2014 From: brad.king at kitware.com (Brad King) Date: Tue, 23 Dec 2014 04:34:03 -0500 Subject: [cmake-developers] [PATCH] Avoid bad alloc for large files In-Reply-To: <2169516.HuKNnRZuIO@caliban.sf-tec.de> References: <54983DC4.9090906@kitware.com> <3389915.ry4cKcysDS@caliban.sf-tec.de> <2169516.HuKNnRZuIO@caliban.sf-tec.de> Message-ID: <5499370B.30502@kitware.com> On 12/23/2014 4:27 AM, Rolf Eike Beer wrote: > cmCTest.cxx > C:\Dashboards\My Tests\CMakeNext-vs12-64-ninja-src\Source\cmCTest.cxx(1705) : > warning C4267: 'argument' : conversion from 'size_t' to 'unsigned long', > possible loss of data > > The problem is: this is absolutely right. On Windows64 this means that the > maximum file size will be 4GB, or one needs to change the base64 > implementation. Which way to go? The KWSys Base64 API should be fixed to use size_t: http://review.source.kitware.com/18579 Domen's suggestion elsewhere in this thread of using a streaming implementation will be necessary to support large files on 32-bit platforms. That can be done as follow-up work though. -Brad From brad.king at kitware.com Tue Dec 23 04:40:39 2014 From: brad.king at kitware.com (Brad King) Date: Tue, 23 Dec 2014 04:40:39 -0500 Subject: [cmake-developers] Which binaries should be required in FindLATEX? In-Reply-To: <5498A95D.1010509@grueninger.de> References: <54816045.5070306@grueninger.de> <5481FFA6.5080004@kitware.com> <5497CBF7.1090001@grueninger.de> <549834EB.9080307@kitware.com> <5498A95D.1010509@grueninger.de> Message-ID: <54993897.4000106@kitware.com> On 12/22/2014 6:29 PM, Christoph Gr?ninger wrote: > please find attached a new patch following your latest suggestions. Thanks. > I'd like to have lower case components but I dislike mixed-cased > variable names. The latter feeling is stronger. Mixed-case variable names are quite common in CMake APIs, especially when dealing with components like this, but I don't have a strong feeling either way on this. However, the _FOUND variables are not cache entries so they do not need to appear in mark_as_advanced. > -find_package_handle_standard_args(Latex > +find_package_handle_standard_args(LATEX Good catch. The capitalization should match the name of the find module. This was a mistake in the original FPHSA change for FindLATEX. Thanks, -Brad From ddomenichelli at drdanz.it Tue Dec 23 04:47:16 2014 From: ddomenichelli at drdanz.it (Daniele E. Domenichelli) Date: Tue, 23 Dec 2014 10:47:16 +0100 Subject: [cmake-developers] Introducing targets in FindPkgConfig In-Reply-To: <6338647.XjMTEVcYgP@caliban.sf-tec.de> References: <5843192.04Xz6GJ9j3@caliban.sf-tec.de> <54985B04.3030601@drdanz.it> <6338647.XjMTEVcYgP@caliban.sf-tec.de> Message-ID: <54993A24.1000804@drdanz.it> On 22/12/14 19:38, Rolf Eike Beer wrote: >> About the FindPkgConfig macros documentation, what is that is not clear? > > It's not about the documentation of that module, but where I need to hack it > into the module. The code is quite a bit of indirections, I guess I would need > to do this _pkg_check_modules_internal at the end of the last foreach? Yes, I think that you can do it either in _pkg_check_modules_internal after the line 385 (unset(_pkgconfig_path_old)) right before the else(), or (perhaps better) in a new internal macro that you will call after the "_pkgconfig_set" line in pkg_search_module and pkg_check_modules. Cheers, Daniele From foss at grueninger.de Tue Dec 23 05:35:12 2014 From: foss at grueninger.de (=?windows-1252?Q?Christoph_Gr=FCninger?=) Date: Tue, 23 Dec 2014 11:35:12 +0100 Subject: [cmake-developers] Which binaries should be required in FindLATEX? In-Reply-To: <54993897.4000106@kitware.com> References: <54816045.5070306@grueninger.de> <5481FFA6.5080004@kitware.com> <5497CBF7.1090001@grueninger.de> <549834EB.9080307@kitware.com> <5498A95D.1010509@grueninger.de> <54993897.4000106@kitware.com> Message-ID: <54994560.2070400@grueninger.de> Hi Brad, next try and as always better than the last attempt. Bye Christoph -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-FindLATEX-Add-components-handling.patch Type: text/x-patch Size: 4731 bytes Desc: not available URL: From ddomenichelli at drdanz.it Tue Dec 23 06:24:58 2014 From: ddomenichelli at drdanz.it (Daniele E. Domenichelli) Date: Tue, 23 Dec 2014 12:24:58 +0100 Subject: [cmake-developers] Separate components for library and .so link Message-ID: <5499510A.6060501@drdanz.it> Is there a way to separate components for a library with a SONAME and the link? For example if I do something like this: add_library(foo ${foo_SRCS}) set_target_properties(foo PROPERTIES SOVERSION 1) install(TARGETS foo LIBRARY DESTINATION lib) This will install /lib/libfoo.so.1 /lib/libfoo.so -> libfoo.so.1 When packaging (at least for Debian and derived distributions), the .so link is considered part of the "-dev" package (and installed with the header files), while the library is part of the library package. Is there a way to separate these 2 components with just one install command? As far as I understand, it is possible to install the target twice using NAMELINK_SKIP and NAMELINK_ONLY, but that seems a bit too redundant to me... install(TARGETS foo LIBRARY DESTINATION lib COMPONENT library NAMELINK_SKIP) install(TARGETS foo LIBRARY DESTINATION lib COMPONENT devel NAMELINK_ONLY) I think it would be nice to be able to do something like install(TARGETS foo LIBRARY DESTINATION lib COMPONENT library NAMELINK_COMPONENT devel) What do you think? Cheers, Daniele From foss at grueninger.de Tue Dec 23 07:36:36 2014 From: foss at grueninger.de (=?UTF-8?B?Q2hyaXN0b3BoIEdyw7xuaW5nZXI=?=) Date: Tue, 23 Dec 2014 13:36:36 +0100 Subject: [cmake-developers] [Patch] Get rid of C++ warnings Message-ID: <549961D4.3030001@grueninger.de> Dear CMake developers, find attached two small patches that get rid of C++ warnings I get from the current GCC 5 development build. One patch removes semicolons after methods, the other uses unsigned ints for version numbers to match the type of the sscanf string %u. Bye Christoph -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Remove-superfluous-semicolons-after-methods.patch Type: text/x-patch Size: 933 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-use-unsigned-int-for-version-numbers.patch Type: text/x-patch Size: 1612 bytes Desc: not available URL: From brad.king at kitware.com Tue Dec 23 09:01:53 2014 From: brad.king at kitware.com (Brad King) Date: Tue, 23 Dec 2014 09:01:53 -0500 Subject: [cmake-developers] DragNDrop: Easier custom dmg layouts In-Reply-To: References: Message-ID: <549975D1.6030802@kitware.com> On 12/22/2014 02:15 PM, Robert Maynard wrote: > If anyone has any questions or issues with this branch please tell me. I'd appreciate feedback on this from others with experience in OS X packaging. For reference, the commit drafts are: DragNDropGenerator background image now uses source file extension. http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2c8b9f50 DragNDropGenerator now places the background image file in a hidden folder. http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a7f55ac9 DragNDropGenerator now can run an apple script when making a package. http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=309ffd8e DragNDropGenerator copies the background image after the dmg is created. http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2dc198b2 DragNDropGenerator now manually computes the size of the temp dmg image. http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=dfb74f52 DragNDropGenerator Updated Documentation to include new variables. http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=76a39f7a CMake DragNDrop release now uses a custom background and script http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4549f8ef However, for now I had to revert it from 'next' because it does not work on OS X <= 10.5. -Brad From brad.king at kitware.com Tue Dec 23 09:02:04 2014 From: brad.king at kitware.com (Brad King) Date: Tue, 23 Dec 2014 09:02:04 -0500 Subject: [cmake-developers] Separate components for library and .so link In-Reply-To: <5499510A.6060501@drdanz.it> References: <5499510A.6060501@drdanz.it> Message-ID: <549975DC.4020008@kitware.com> On 12/23/2014 06:24 AM, Daniele E. Domenichelli wrote: > I think it would be nice to be able to do something like > > install(TARGETS foo > LIBRARY DESTINATION lib COMPONENT library > NAMELINK_COMPONENT devel) Yes, I think that would make sense. Thanks, -Brad From brad.king at kitware.com Tue Dec 23 09:06:54 2014 From: brad.king at kitware.com (Brad King) Date: Tue, 23 Dec 2014 09:06:54 -0500 Subject: [cmake-developers] [Patch] Get rid of C++ warnings In-Reply-To: <549961D4.3030001@grueninger.de> References: <549961D4.3030001@grueninger.de> Message-ID: <549976FE.3020708@kitware.com> On 12/23/2014 07:36 AM, Christoph Gr?ninger wrote: > find attached two small patches that get rid of C++ warnings I get from > the current GCC 5 development build. > One patch removes semicolons after methods, the other uses unsigned ints > for version numbers to match the type of the sscanf string %u. Applied, thanks: cmParseDelphiCoverage: Remove superfluous semicolons after methods http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1a9ba381 cmCMakeMinimumRequired: Use unsigned int for version numbers http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=098fc4a8 -Brad From brad.king at kitware.com Tue Dec 23 09:14:02 2014 From: brad.king at kitware.com (Brad King) Date: Tue, 23 Dec 2014 09:14:02 -0500 Subject: [cmake-developers] Which binaries should be required in FindLATEX? In-Reply-To: <54994560.2070400@grueninger.de> References: <54816045.5070306@grueninger.de> <5481FFA6.5080004@kitware.com> <5497CBF7.1090001@grueninger.de> <549834EB.9080307@kitware.com> <5498A95D.1010509@grueninger.de> <54993897.4000106@kitware.com> <54994560.2070400@grueninger.de> Message-ID: <549978AA.9070000@kitware.com> On 12/23/2014 05:35 AM, Christoph Gr?ninger wrote: > next try and as always better than the last attempt. Applied: FindLATEX: Add components handling http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=07a3f9ad with minor documentation tweaks and one logic fix: -# set(LATEX_MAKEINDEX_FOUND TRUE) + set(LATEX_MAKEINDEX_FOUND TRUE) that looked left from local testing. Thanks, -Brad From DLRdave at aol.com Tue Dec 23 10:58:12 2014 From: DLRdave at aol.com (David Cole) Date: Tue, 23 Dec 2014 10:58:12 -0500 Subject: [cmake-developers] DragNDrop: Easier custom dmg layouts In-Reply-To: <549975D1.6030802@kitware.com> References: <549975D1.6030802@kitware.com> Message-ID: This looks pretty reasonable to me. From Rob's initial email, I thought it sounded like there was some sort of backward compatibility problem, but looking through the code, it seems like everything should all work the same for projects that aren't changing..... Was I misunderstanding about backwards compatibility, or am I missing something? And although I haven't built it or run it myself yet, I trust that if the DMG produced for CMake looks good, that people can model their own code after CMake's own code to achieve better looking DMG installers. Personally, I am stuck on what I consider to be a very old Mac right now. It's a mini from ~2007-2008, and it's stuck running 10.6. I use it only when I absolutely have to (i.e. for virtually nothing) because it's so much slower than other machines I use. My point with mentioning this at all is to encourage you to drop support entirely for <10.6 at this point. (i.e. -- put this topic back in 'next' and retire those old Macs... they're tired... :-) Nice work, Rob. Thanks, David C. On Tue, Dec 23, 2014 at 9:01 AM, Brad King wrote: > On 12/22/2014 02:15 PM, Robert Maynard wrote: >> If anyone has any questions or issues with this branch please tell me. > > I'd appreciate feedback on this from others with experience in > OS X packaging. For reference, the commit drafts are: > > DragNDropGenerator background image now uses source file extension. > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2c8b9f50 > > DragNDropGenerator now places the background image file in a hidden folder. > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a7f55ac9 > > DragNDropGenerator now can run an apple script when making a package. > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=309ffd8e > > DragNDropGenerator copies the background image after the dmg is created. > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2dc198b2 > > DragNDropGenerator now manually computes the size of the temp dmg image. > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=dfb74f52 > > DragNDropGenerator Updated Documentation to include new variables. > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=76a39f7a > > CMake DragNDrop release now uses a custom background and script > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4549f8ef > > However, for now I had to revert it from 'next' because it does > not work on OS X <= 10.5. > > -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 From mantis at public.kitware.com Wed Dec 24 12:48:05 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 24 Dec 2014 12:48:05 -0500 Subject: [cmake-developers] [CMake 0015326]: CMake can't read UTF-16 source files Message-ID: <54836b72b00cb65f91d85924caa995b3@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15326 ====================================================================== Reported By: Kwabena W. Agyeman Assigned To: ====================================================================== Project: CMake Issue ID: 15326 Category: CMake Reproducibility: always Severity: feature Priority: normal Status: new ====================================================================== Date Submitted: 2014-12-24 12:48 EST Last Modified: 2014-12-24 12:48 EST ====================================================================== Summary: CMake can't read UTF-16 source files Description: I'm trying to do dependency parsing in cmake for parallax propeller spin files. This involves opening up *.spin code files and parsing them using the file(STRINGS ... REGEX ...) command. Most spin files are saved as ASCII/UTF-8 files and there are no problems parsing these files. However, some spin files are saved in UTF-16 format which allows the use of special schematic characters in the files. Using the file(STRINGS ... REGEX ...) command does not work on UTF-16 files as cmake is unable to parse them. Steps to Reproduce: The below code should find the "DAT" string in the attached file... file(STRINGS "Quadrature Encoder.spin" OUT REGEX "^[\t ]*[Dd][Aa][Tt].*$") Additional Information: Saving the problem UTF-16 files as UTF-8 files fixes the issue. But, I can't just convert the source files. There's a lot of legacy spin code I need to support that uses the UTF-16 format for the special schematic characters. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-12-24 12:48 Kwabena W. AgyemanNew Issue 2014-12-24 12:48 Kwabena W. AgyemanFile Added: Quadrature Encoder.spin ====================================================================== From cascaval at acm.org Fri Dec 26 12:55:15 2014 From: cascaval at acm.org (Calin Cascaval) Date: Fri, 26 Dec 2014 09:55:15 -0800 Subject: [cmake-developers] patch to fix installed size for cpack PackageMaker generator In-Reply-To: <54983F64.5020307@kitware.com> References: <99A92BD4-266B-4B89-989D-503F2CA06F1F@acm.org> <54982D4C.5060808@kitware.com> <868D11C2-18AD-49A5-8711-6E77F0B48258@acm.org> <20141222155211.1362005544@mail.rogue-research.com> <54983F64.5020307@kitware.com> Message-ID: <4D6C5E27-2087-4AC4-98AA-DC6350F0DE7B@acm.org> Brad, Sean, The patch is attached. I tested it with a few settings (10.4, 10.5, and 10.10) on a 10.9.5 system. Unfortunately I don?t have a 10.10 machine, however, the package built with a 10.10 option looks good. -- Thanks, Calin On Dec 22, 2014, at 7:57, Brad King wrote: > On 12/22/2014 10:52 AM, Sean McBride wrote: >> I had started a patch but haven't had time to test it. Perhaps >> you could continue from where I left off, see attached. > > Thanks, Sean. Calin, the patch currently hard-codes encoding of > the major and minor versions into an integer: > > this->PackageCompatibilityVersion = ((10 << 16) | 4); > > I think the encoding is a good approach, but please factor it out > into a helper macro (local to the .cxx file) so the encoding logic > does not have to be repeated. > > Thanks, > -Brad > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-PackageMaker-fixes-version-format.patch Type: application/octet-stream Size: 4790 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4130 bytes Desc: not available URL: From mantis at public.kitware.com Sat Dec 27 14:41:17 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sat, 27 Dec 2014 20:41:17 +0100 Subject: [cmake-developers] [CMake 0015328]: cmake generates corrupt Xcode projects for KDE projects Message-ID: <432092424ad9ee51a34eef9c0bd0818d@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15328 ====================================================================== Reported By: Ren? J.V. Bertin Assigned To: ====================================================================== Project: CMake Issue ID: 15328 Category: CMake Reproducibility: always Severity: block Priority: normal Status: new ====================================================================== Date Submitted: 2014-12-27 20:41 CET Last Modified: 2014-12-27 20:41 CET ====================================================================== Summary: cmake generates corrupt Xcode projects for KDE projects Description: When using cmake to create an Xcode project for building KDE applications from MacPorts (that build fine with the Makefiles generator), the generation terminates fine, but Xcode fails to open the generated project because of a parsing error. Steps to Reproduce: 1) Install MacPorts and the required dependencies for KDE apps 2) build a target project from source using MacPorts and retrieve the cmake command line from the build log 3) in a fresh build directory, execute the same cmake command but add -G Xcode to generate an XCode project. For digikam, this is `cmake -DCMAKE_INSTALL_PREFIX=/opt/local -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_COLOR_MAKEFILE=ON -DCMAKE_BUILD_TYPE=Release -DCMAKE_BUILD_WITH_INSTALL_RPATH=ON -DCMAKE_INSTALL_RPATH=/opt/local/lib -DCMAKE_INSTALL_NAME_DIR=/opt/local/lib -DCMAKE_SYSTEM_PREFIX_PATH="/opt/local;/usr" -DCMAKE_MODULE_PATH=/opt/local/share/cmake/Modules -DCMAKE_FIND_FRAMEWORK=LAST -Wno-dev -DBUILD_SHARED_LIBS=ON -DBUNDLE_INSTALL_DIR=/Applications/MacPorts/KDE4 -DKDE_DISTRIBUTION_TEXT="MacPorts/Mac OS X" -DQT_QT_INCLUDE_DIR=/opt/local/include -DQT_QMAKESPEC=macx-g++ -DQT_ZLIB_LIBRARY=/opt/local/lib/libz.dylib -DQT_PNG_LIBRARY=/opt/local/lib/libpng.dylib -DDOCBOOKXSL_DIR=/opt/local/share/xsl/docbook-xsl -DGETTEXT_INCLUDE_DIR=/opt/local/include -DGETTEXT_LIBRARY=/opt/local/lib/libgettextlib.dylib -DGIF_INCLUDE_DIR=/opt/local/include -DGIF_LIBRARY=/opt/local/lib/libgif.dylib -DJASPER_INCLUDE_DIR=/opt/local/include -DJASPER_LIBRARY=/opt/local/lib/libjasper.dylib -DJPEG_INCLUDE_DIR=/opt/local/include -DJPEG_LIBRARY=/opt/local/lib/libjpeg.dylib -DLBER_LIBRARIES=/opt/local/lib/liblber.dylib -DLDAP_INCLUDE_DIR=/opt/local/include -DLDAP_LIBRARIES=/opt/local/lib/libldap.dylib -DLIBEXSLT_INCLUDE_DIR=/opt/local/include -DLIBEXSLT_LIBRARIES=/opt/local/lib/libexslt.dylib -DLIBICALSS_LIBRARY=/opt/local/lib/libicalss.dylib -DLIBICAL_INCLUDE_DIRS=/opt/local/include -DLIBICAL_LIBRARY=/opt/local/lib/libical.dylib -DLIBINTL_INCLUDE_DIR=/opt/local/include -DLIBINTL_LIBRARY=/opt/local/lib/libintl.dylib -DLIBXML2_INCLUDE_DIR=/opt/local/include/libxml2 -DLIBXML2_LIBRARIES=/opt/local/lib/libxml2.dylib -DLIBXML2_XMLLINT_EXECUTABLE=/opt/local/bin/xmllint -DLIBXSLT_INCLUDE_DIR=/opt/local/include -DLIBXSLT_LIBRARIES=/opt/local/lib/libxslt.dylib -DMYSQLD_EXECUTABLE=/opt/local/libexec/mysqld -DMYSQL_INCLUDE_DIR=/opt/local/include/mysql5/mysql -DMYSQL_LIB_DIR=/opt/local/lib/mysql5/mysql -DMYSQLCONFIG_EXECUTABLE=/opt/local/bin/mysql_config5 -DOPENAL_INCLUDE_DIR=/System/Library/Frameworks/OpenAL.framework/Headers -DOPENAL_LIBRARY=/System/Library/Frameworks/OpenAL.framework -DPNG_INCLUDE_DIR=/opt/local/include -DPNG_PNG_INCLUDE_DIR=/opt/local/include -DPNG_LIBRARY=/opt/local/lib/libpng.dylib -DTIFF_INCLUDE_DIR=/opt/local/include -DTIFF_LIBRARY=/opt/local/lib/libtiff.dylib -DENABLE_KDEPIMLIBSSUPPORT:BOOL=ON -DOpenCV_DIR=/opt/local/lib/cmake -DDIGIKAMSC_COMPILE_LIBKGEOMAP:BOOL=ON -DDIGIKAMSC_COMPILE_LIBKVKONTAKTE:BOOL=ON -DDIGIKAMSC_COMPILE_LIBMEDIAWIKI:BOOL=ON -DDIGIKAMSC_COMPILE_LIBKFACE:BOOL=ON -Wno-dev ../digikam-4.6.0 -DCMAKE_BUILD_TYPE:STRING=RelWithDebInfo -DCMAKE_STRIP:FILEPATH=/bin/echo -DDIGIKAMSC_COMPILE_DOC=on -DDIGIKAMSC_COMPILE_PO=OFF -DDIGIKAMSC_USE_PRIVATE_KDEGRAPHICS=off -DENABLE_LCMS2=on -DENABLE_INTERNALMYSQL=off -DCMAKE_C_FLAGS_RELEASE="-DNDEBUG" -DCMAKE_CXX_FLAGS_RELEASE="-DNDEBUG" -DCMAKE_OSX_ARCHITECTURES="x86_64" -G Xcode ../digikam-4.6.0` 4) Try to open the generated Xcode project file in Xcode (5.1) Additional Information: This hasn't been working for me on OS X 10.6.8 (Xcode 3.2.6) and now 10.9.5, neither with cmake 3.0.2 nor with older versions. I'm attaching the generated CMakeCache.txt as well as the xml file inside the Xcode project bundle (if this bugtracker allows me to attach multiple files). ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-12-27 20:41 Ren? J.V. BertinNew Issue 2014-12-27 20:41 Ren? J.V. BertinFile Added: CMakeCache.txt ====================================================================== From mantis at public.kitware.com Sun Dec 28 06:35:44 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sun, 28 Dec 2014 06:35:44 -0500 Subject: [cmake-developers] [CMake 0015329]: Cannot set CMAKE_XCODE_ATTRIBUTE_ID_PRODUCT_TYPE manually Message-ID: <7250fc8d137c8de3345e6159f01709fd@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15329 ====================================================================== Reported By: patep Assigned To: ====================================================================== Project: CMake Issue ID: 15329 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-12-28 06:35 EST Last Modified: 2014-12-28 06:35 EST ====================================================================== Summary: Cannot set CMAKE_XCODE_ATTRIBUTE_ID_PRODUCT_TYPE manually Description: This is related to: http://www.cmake.org/Bug/view.php?id=15214 When crosscompiling for iOS I see an error: Check dependencies target specifies product type 'com.apple.product-type.tool', but there's no such product type for the 'iphoneos' platform This is during configure stage. In that ticket above you mentioned two commits: http://www.cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c48f6e12 http://www.cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b91020f6 The fix to id_product_type is related for some "...bundle.unit-test". + set(id_product_type "com.apple.product-type.tool") if(CMAKE_OSX_SYSROOT) set(id_sdkroot "SDKROOT = \"${CMAKE_OSX_SYSROOT}\";") + if(CMAKE_OSX_SYSROOT MATCHES "(^|/)[Ii][Pp][Hh][Oo][Nn][Ee]") + set(id_product_type "com.apple.product-type.bundle.unit-test") + endif() At the second commit related to code signing we see: + if(CMAKE_XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY) + set(id_code_sign_identity "CODE_SIGN_IDENTITY = \"${CMAKE_XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY}\";") + else() + set(id_code_sign_identity "") + endif() Can you please add such switch to id_product_type? E.g.: if(CMAKE_XCODE_ATTRIBUTE_ID_PRODUCT_TYPE) set(id_product_type "ID_PRODUCT_TYPE = \"${CMAKE_XCODE_ATTRIBUTE_ID_PRODUCT_TYPE}\";") else() ........ endif() I'm asking this because I found the next page with different possible product types: https://github.com/freewizard/Xcode-Template-iOS-dylib/blob/master/Platforms/iPhoneSimulator.platform/Developer/Library/Xcode/Specifications/iPhone%20Simulator%20ProductTypes.xcspec And when I set PRODUCT_TYPE = com.apple.product-type.application in Xcode manually, the build works. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-12-28 06:35 patep New Issue ====================================================================== From robert.maynard at kitware.com Mon Dec 29 09:40:12 2014 From: robert.maynard at kitware.com (Robert Maynard) Date: Mon, 29 Dec 2014 09:40:12 -0500 Subject: [cmake-developers] DragNDrop: Easier custom dmg layouts In-Reply-To: References: <549975D1.6030802@kitware.com> Message-ID: On Tue, Dec 23, 2014 at 10:58 AM, David Cole wrote: > This looks pretty reasonable to me. From Rob's initial email, I > thought it sounded like there was some sort of backward compatibility > problem, but looking through the code, it seems like everything should > all work the same for projects that aren't changing..... Was I > misunderstanding about backwards compatibility, or am I missing > something? > If an existing project is using a custom .DS_Store and background, this will cause the custom background to not show up. The reason being that that the .DS_Store stores the absolute path to background and that path now has changed. > And although I haven't built it or run it myself yet, I trust that if > the DMG produced for CMake looks good, that people can model their own > code after CMake's own code to achieve better looking DMG installers. > > Personally, I am stuck on what I consider to be a very old Mac right > now. It's a mini from ~2007-2008, and it's stuck running 10.6. I use > it only when I absolutely have to (i.e. for virtually nothing) because > it's so much slower than other machines I use. My point with > mentioning this at all is to encourage you to drop support entirely > for <10.6 at this point. (i.e. -- put this topic back in 'next' and > retire those old Macs... they're tired... :-) > > Nice work, Rob. > > Thanks, > David C. > > > > On Tue, Dec 23, 2014 at 9:01 AM, Brad King wrote: >> On 12/22/2014 02:15 PM, Robert Maynard wrote: >>> If anyone has any questions or issues with this branch please tell me. >> >> I'd appreciate feedback on this from others with experience in >> OS X packaging. For reference, the commit drafts are: >> >> DragNDropGenerator background image now uses source file extension. >> http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2c8b9f50 >> >> DragNDropGenerator now places the background image file in a hidden folder. >> http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a7f55ac9 >> >> DragNDropGenerator now can run an apple script when making a package. >> http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=309ffd8e >> >> DragNDropGenerator copies the background image after the dmg is created. >> http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2dc198b2 >> >> DragNDropGenerator now manually computes the size of the temp dmg image. >> http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=dfb74f52 >> >> DragNDropGenerator Updated Documentation to include new variables. >> http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=76a39f7a >> >> CMake DragNDrop release now uses a custom background and script >> http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4549f8ef >> >> However, for now I had to revert it from 'next' because it does >> not work on OS X <= 10.5. >> >> -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 From evangelos at foutrelis.com Mon Dec 29 12:02:04 2014 From: evangelos at foutrelis.com (Evangelos Foutras) Date: Mon, 29 Dec 2014 19:02:04 +0200 Subject: [cmake-developers] [PATCH] FindRuby: Fix output check in _RUBY_CONFIG_VAR Message-ID: <1419872524-11286-1-git-send-email-evangelos@foutrelis.com> Since commit 854e762 (FindRuby: clean up querying variables from Ruby) we query RbConfig::CONFIG first and, if the command fails or its output equates to a false constant, then fall back to querying Config::CONFIG. Due to the above, an error condition exists with Ruby 2.2.0; when querying RbConfig::CONFIG['TEENY'], the output of '0' will be discarded since it matches the false constant '0'. In previous versions this wasn't a problem, but Ruby 2.2 has completely removed Config::CONFIG. This causes RUBY_VERSION_PATCH to be set to an empty string and the Ruby version to be detected as '2.2.' (instead of '2.2.0'). This patch fixes the output check to explicitly look for an empty string before using the fallback query method. (Someone more familiar with Ruby might be able to deem the fallback as unnecessary and fully remove it.) --- Modules/FindRuby.cmake | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Modules/FindRuby.cmake b/Modules/FindRuby.cmake index b5ac703..0950d15 100644 --- a/Modules/FindRuby.cmake +++ b/Modules/FindRuby.cmake @@ -90,7 +90,7 @@ if(RUBY_EXECUTABLE AND NOT RUBY_VERSION_MAJOR) RESULT_VARIABLE _RUBY_SUCCESS OUTPUT_VARIABLE _RUBY_OUTPUT ERROR_QUIET) - if(_RUBY_SUCCESS OR NOT _RUBY_OUTPUT) + if(_RUBY_SUCCESS OR _RUBY_OUTPUT STREQUAL "") execute_process(COMMAND ${RUBY_EXECUTABLE} -r rbconfig -e "print Config::CONFIG['${RBVAR}']" RESULT_VARIABLE _RUBY_SUCCESS OUTPUT_VARIABLE _RUBY_OUTPUT -- 2.2.1 From mw_triad at users.sourceforge.net Mon Dec 29 16:22:53 2014 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Mon, 29 Dec 2014 16:22:53 -0500 Subject: [cmake-developers] Extracting target metadata, IDE integration In-Reply-To: References: Message-ID: On 2014-12-22 19:30, Aleix Pol wrote: > On Thu, Sep 25, 2014 at 9:14 AM, Anton Makeev wrote: >> * No progress indication. Since the generation may take several minutes, >> providing feedback is crucial. > > I never found such case, ParaView. (To a lesser extent, VTK.) > I would argue that a project which has a cmake script that takes > several minutes is broken, but maybe we can open a thread to discuss > it? Well, yes, one might argue that :-). >> * When there are existing in-source generated files in the project dir, >> CMake doesn't allow generating into a separate out-of-source folder. >> An IDE has to invent workarounds here. > > Arguably, in-source generation is broken by definition... Also, because CMake allows either a source OR BUILD directory to be given, such a configuration is almost certainly doomed. IMO, trying to do an out-of-source build of a source directory that already contains an in-source build *is* broken (i.e. no "arguably" about it)... and so is an IDE trying to work around such situation. At most, detect the situation and nicely report the problem to the user. -- Matthew From steveire at gmail.com Tue Dec 30 07:20:29 2014 From: steveire at gmail.com (Stephen Kelly) Date: Tue, 30 Dec 2014 13:20:29 +0100 Subject: [cmake-developers] [Patch] Get rid of C++ warnings References: <549961D4.3030001@grueninger.de> Message-ID: Christoph Gr?ninger wrote: > Dear CMake developers, > find attached two small patches that get rid of C++ warnings I get from > the current GCC 5 development build. > One patch removes semicolons after methods, the other uses unsigned ints > for version numbers to match the type of the sscanf string %u. It would be awesome if you could run a dashboard for that compiler. http://www.cmake.org/Wiki/CMake/Git/Dashboard Thanks, Steve. From domen.vrankar at gmail.com Tue Dec 30 20:03:28 2014 From: domen.vrankar at gmail.com (Domen Vrankar) Date: Wed, 31 Dec 2014 02:03:28 +0100 Subject: [cmake-developers] [PATCH][CPack][RPM] multiple path relocation prefixes Message-ID: Hello, Could somebody please review the topic rpm_multi_prefix. http://www.cmake.org/gitweb?p=stage/cmake.git;a=commit;h=c908ba3707fcf8cf43df0c5cd90f8ea6d98d7c29 Patch adds support for multiple relocation paths per RPM package. For relocation paths I have extended GNUInstallDirs module since it already provides the required functionality but for install command. Is this OK? Thanks, Domen From mantis at public.kitware.com Wed Dec 31 02:45:34 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 31 Dec 2014 02:45:34 -0500 Subject: [cmake-developers] [CMake 0015331]: Impossible to use Modules from GIT as project-local module because of CMAKE_CURRENT_LIST_DIR Message-ID: <72c9918cbf0ad51b8fec146e5f28b6f8@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== https://public.kitware.com/Bug/view.php?id=15331 ====================================================================== Reported By: AmiGO Assigned To: ====================================================================== Project: CMake Issue ID: 15331 Category: CMake Reproducibility: always Severity: minor Priority: low Status: new ====================================================================== Date Submitted: 2014-12-31 02:45 EST Last Modified: 2014-12-31 02:45 EST ====================================================================== Summary: Impossible to use Modules from GIT as project-local module because of CMAKE_CURRENT_LIST_DIR Description: CMake package: cmake-2.8.12.2-2.fc20.x86_64 Here is the details: https://github.com/Kitware/CMake/blob/master/Modules/FindLibLZMA.cmake Line 57: include(${CMAKE_CURRENT_LIST_DIR}/CheckLibraryExists.cmake) Line 66: include(${CMAKE_CURRENT_LIST_DIR}/FindPackageHandleStandardArgs.cmake) CMAKE_CURRENT_LIST_DIR causes CMake to search for CheckLibraryExists and FindPackageHandleStandardArgs in directory where the FindLibLZMA was placed. So if I want to include FindLibLZMA in project-local CMake modules directory CMake will fail. Sometimes before it looks like include(FindPackageHandleStandardArgs) and observed behaviour was correct but now it's broken. Steps to Reproduce: 1. Untar demo project from attachment; 2. Run cmake ./ in project directory; CMake will fail with the following message: CMake Error at cmake/FindLibLZMA.cmake:67 (include): include could not find load file: /home/AmiGO/soft/sources/zbackup/demo/cmake/FindPackageHandleStandardArgs.cmake Call Stack (most recent call first): CMakeLists.txt:6 (find_package) CMake Error at cmake/FindLibLZMA.cmake:68 (FIND_PACKAGE_HANDLE_STANDARD_ARGS): Unknown CMake command "FIND_PACKAGE_HANDLE_STANDARD_ARGS". Call Stack (most recent call first): CMakeLists.txt:6 (find_package) -- Configuring incomplete, errors occurred! 3. Comment line 67 and uncomment line 66; 4. Run cmake ./ again. Now all becomes normal. Additional Information: You should probably need to introduce something like ${CMAKE_MODULE_VENDOR_PATH} that will unwind to /usr/share/cmake/Modules and use it in GIT modules instead of ${CMAKE_CURRENT_LIST_DIR}. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-12-31 02:45 AmiGO New Issue 2014-12-31 02:45 AmiGO File Added: demo.tar.xz ======================================================================