From jackie at sdiwc.info Thu Jan 1 22:49:43 2015 From: jackie at sdiwc.info (Jackie Blanco) Date: Thu, 01 Jan 2015 20:49:43 -0700 Subject: [CMake] Last Call for Papers: EECEA2015 - Philippines Message-ID: The Second International Conference on Electrical, Electronics, Computer Engineering and their Applications (EECEA2015) World Trade Center, Manila Philippines Seminar Date: February 11, 2015 University of Perpetual Help System Dalta Las Pi?as - Manila, Philippines Conference Dates: February 12-14, 2015 The event will be held over four days with presentations delivered by researchers from the international community, including presentations from keynote speakers and state-of-the-art lectures. A seminar will take place at the World Trade Center, Manila Philippines on February 11, 2015 where international participants are free to attend. The conference will be held in University of Perpetual Help System DALTA, Las Pi?as ? Manila, Philippines on February 12-14, 2015. In addition, trainings will be conducted by companies namely Microchip, Dassault Syst?mes and TechSource in parallel with the paper presentations where delegates are encouraged to participate. PAPER SUBMISSION is until January 12, 2015. For more details and updates, visit -- http://sdiwc.net/conferences/eecea2015/ From scott.bloom at onshorecs.com Thu Jan 1 23:27:46 2015 From: scott.bloom at onshorecs.com (Scott Aron Bloom) Date: Fri, 2 Jan 2015 04:27:46 +0000 Subject: [CMake] Rename target RUN_TESTS Message-ID: <6FD2E165340D9A429CF831C7A2D4F42E4E5812D0@WIN-R92V03RFJ85.onshorecs.local> For windows Visual Studio using CMake with google test, one of the complaints my team has, is the project name "RUN_TESTS" gets lost in the numerous projects. Is there a CMake command to "rename" a target? We would like to name it "ALL_RUN_TEST" Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From drescherjm at gmail.com Thu Jan 1 23:44:32 2015 From: drescherjm at gmail.com (John Drescher) Date: Thu, 1 Jan 2015 23:44:32 -0500 Subject: [CMake] Rename target RUN_TESTS In-Reply-To: <6FD2E165340D9A429CF831C7A2D4F42E4E5812D0@WIN-R92V03RFJ85.onshorecs.local> References: <6FD2E165340D9A429CF831C7A2D4F42E4E5812D0@WIN-R92V03RFJ85.onshorecs.local> Message-ID: On Thu, Jan 1, 2015 at 11:27 PM, Scott Aron Bloom wrote: > For windows Visual Studio using CMake with google test, one of the > complaints my team has, is the project name ?RUN_TESTS? gets lost in the > numerous projects. I am not sure about renaming that however I find it helpful to organize my projects using solution folders with set_property(GLOBAL PROPERTY USE_FOLDERS ON) and set_target_properties(mylocalproject PROPERTIES FOLDER folder) John From joubert.sy at gmail.com Fri Jan 2 05:43:00 2015 From: joubert.sy at gmail.com (Sylvain Joubert) Date: Fri, 02 Jan 2015 11:43:00 +0100 Subject: [CMake] Rename target RUN_TESTS In-Reply-To: <6FD2E165340D9A429CF831C7A2D4F42E4E5812D0@WIN-R92V03RFJ85.onshorecs.local> References: <6FD2E165340D9A429CF831C7A2D4F42E4E5812D0@WIN-R92V03RFJ85.onshorecs.local> Message-ID: <54A67634.1000409@gmail.com> Le 02/01/2015 05:27, Scott Aron Bloom a ?crit : > Is there a CMake command to "rename" a target? > I don't think you can rename a target. > We would like to name it "ALL_RUN_TEST" > However, you can add a custom target that depends on the misnamed one: if(MSVC) add_custom_target(ALL_RUN_TEST ALL DEPENDS RUN_TESTS) endif() This way the target is not renamed but you have at your disposal a new target that will do and act the same, with a name better suited to your needs. Sylvain From joubert.sy at gmail.com Fri Jan 2 05:55:48 2015 From: joubert.sy at gmail.com (Sylvain Joubert) Date: Fri, 02 Jan 2015 11:55:48 +0100 Subject: [CMake] Rename target RUN_TESTS In-Reply-To: <54A67634.1000409@gmail.com> References: <6FD2E165340D9A429CF831C7A2D4F42E4E5812D0@WIN-R92V03RFJ85.onshorecs.local> <54A67634.1000409@gmail.com> Message-ID: <54A67934.1000403@gmail.com> Le 02/01/2015 11:43, Sylvain Joubert a ?crit : > if(MSVC) > add_custom_target(ALL_RUN_TEST ALL DEPENDS RUN_TESTS) > endif() The "ALL" dependency should not be there. No need to run the tests at every compilation. This is better: if(MSVC) add_custom_target(ALL_RUN_TEST DEPENDS RUN_TESTS) endif() Sylvain From scott.bloom at onshorecs.com Fri Jan 2 06:19:25 2015 From: scott.bloom at onshorecs.com (Scott Aron Bloom) Date: Fri, 2 Jan 2015 11:19:25 +0000 Subject: [CMake] Rename target RUN_TESTS In-Reply-To: <54A67934.1000403@gmail.com> References: <6FD2E165340D9A429CF831C7A2D4F42E4E5812D0@WIN-R92V03RFJ85.onshorecs.local> <54A67634.1000409@gmail.com> <54A67934.1000403@gmail.com> Message-ID: <6FD2E165340D9A429CF831C7A2D4F42E4E581869@WIN-R92V03RFJ85.onshorecs.local> That doesn't work :( Unfortunately it "could" be that I have put the custom target command in the wrong location, however, I put it as the last line in my top level CMakeLists.txt ADD_CUSTOM_TARGET( ALL_RUN_TEST DEPENDS RUN_TESTS ) But it doesn't right mouse clicking -> build doesn't give the same results as building "RUN_TESTS" Scott -----Original Message----- From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Sylvain Joubert Sent: Friday, January 02, 2015 2:56 AM To: cmake at cmake.org Subject: Re: [CMake] Rename target RUN_TESTS Le 02/01/2015 11:43, Sylvain Joubert a ?crit : > if(MSVC) > add_custom_target(ALL_RUN_TEST ALL DEPENDS RUN_TESTS) > endif() The "ALL" dependency should not be there. No need to run the tests at every compilation. This is better: if(MSVC) add_custom_target(ALL_RUN_TEST DEPENDS RUN_TESTS) endif() Sylvain -- 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 From bill.hoffman at kitware.com Fri Jan 2 14:16:56 2015 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Fri, 02 Jan 2015 14:16:56 -0500 Subject: [CMake] Rename target RUN_TESTS In-Reply-To: <6FD2E165340D9A429CF831C7A2D4F42E4E581869@WIN-R92V03RFJ85.onshorecs.local> References: <6FD2E165340D9A429CF831C7A2D4F42E4E5812D0@WIN-R92V03RFJ85.onshorecs.local> <54A67634.1000409@gmail.com> <54A67934.1000403@gmail.com> <6FD2E165340D9A429CF831C7A2D4F42E4E581869@WIN-R92V03RFJ85.onshorecs.local> Message-ID: <54A6EEA8.5030907@kitware.com> On 1/2/2015 6:19 AM, Scott Aron Bloom wrote: > That doesn't work:( > > Unfortunately it "could" be that I have put the custom target command in the wrong location, however, I put it as the last line in my top level CMakeLists.txt > > ADD_CUSTOM_TARGET( ALL_RUN_TEST DEPENDS RUN_TESTS ) > > But it doesn't right mouse clicking -> build doesn't give the same results as building "RUN_TESTS" RUN_TESTS just runs ctest in a specific directory. It is easy to create a custom target ALL_RUN_TESTS that does the same thing. -Bill From paul at mad-scientist.net Sat Jan 3 11:11:41 2015 From: paul at mad-scientist.net (Paul Smith) Date: Sat, 03 Jan 2015 11:11:41 -0500 Subject: [CMake] Help with Policy CMP0026 (disallow LOCATION target property) In-Reply-To: <54A0B661.2090207@gmail.com> References: <1419368804.19591.10.camel@mad-scientist.net> <1419426261.7095.55.camel@homebase> <54A0B661.2090207@gmail.com> Message-ID: <1420301501.7095.156.camel@homebase> On Mon, 2014-12-29 at 02:03 +0000, Fraser Hutchison wrote: > I'd have thought the following replacement would work the same: > > function(stageobj target dir) > add_custom_target(stage_${target} ALL > COMMAND "${CMAKE_COMMAND}" -E make_directory "${DESTDIR}/${dir}" > COMMAND "${CMAKE_COMMAND}" -E copy_if_different "$" "${DESTDIR}/${dir}" > COMMENT "Staging ${target} to ${DESTDIR}/${dir}" > VERBATIM) > add_dependencies(stage_${target} ${target}) > endfunction() Sorry for the delayed reply, I was on holiday. Yes, this will work although it means I get the "Staging ..." message for every staged file every time I build (even if it doesn't actually copy unless different); I think that's why I used the other method. I bit the bullet and changed my rules to build directly into the staging area rather than copying them afterward. Since I already went through the pain I'd just as soon not go back again now :-), so I'm all set I think. Thanks all! From scott.bloom at onshorecs.com Sat Jan 3 14:39:12 2015 From: scott.bloom at onshorecs.com (Scott Aron Bloom) Date: Sat, 3 Jan 2015 19:39:12 +0000 Subject: [CMake] Rename target RUN_TESTS In-Reply-To: References: <6FD2E165340D9A429CF831C7A2D4F42E4E5812D0@WIN-R92V03RFJ85.onshorecs.local> Message-ID: <6FD2E165340D9A429CF831C7A2D4F42E4E583518@WIN-R92V03RFJ85.onshorecs.local> So I turned this on, it definitely helps.. However, I find that the order of the folders is now sorted case sensitive. Is there anyway to turn it back to the "non folder manner" where the folder order is case-insensitive? Scott -----Original Message----- From: John Drescher [mailto:drescherjm at gmail.com] Sent: Thursday, January 01, 2015 20:45 PM To: Scott Aron Bloom Cc: cmake at cmake.org Subject: Re: [CMake] Rename target RUN_TESTS On Thu, Jan 1, 2015 at 11:27 PM, Scott Aron Bloom wrote: > For windows Visual Studio using CMake with google test, one of the > complaints my team has, is the project name ?RUN_TESTS? gets lost in > the numerous projects. I am not sure about renaming that however I find it helpful to organize my projects using solution folders with set_property(GLOBAL PROPERTY USE_FOLDERS ON) and set_target_properties(mylocalproject PROPERTIES FOLDER folder) John From marcomilanese7 at gmail.com Sat Jan 3 16:50:38 2015 From: marcomilanese7 at gmail.com (Marco Milanese) Date: Sat, 3 Jan 2015 14:50:38 -0700 (MST) Subject: [CMake] Wrong CMAKE_SYSTEM_NAME handling Message-ID: <1420321838617-7589372.post@n2.nabble.com> Hi, I'm trying to setup a cross compile CMakeLists.txt. My target is a embedded ARM core. This is my CMakeLists.txt . The linker script seems wrong: mm7 at pc5:~/test/cmake/build$ cat CMakeFiles/target.dir/link.txt arm-none-eabi-g++ CMakeFiles/target.dir/test.cpp.o -o target -rdynamic I can't understand why is "-rdynamic" appended. It should be appended only if "CMAKE_SYSTEM_NAME"=Linux (https://github.com/Kitware/CMake/blob/4811915367cc23e68e2171b83509b8a382ff1941/Modules/Platform/Linux-GNU.cmake#L24). Is this a CMake bug or am I making some mistakes? Thank you Marco -- View this message in context: http://cmake.3232098.n2.nabble.com/Wrong-CMAKE-SYSTEM-NAME-handling-tp7589372.html Sent from the CMake mailing list archive at Nabble.com. From d3ck0r at gmail.com Sat Jan 3 18:11:57 2015 From: d3ck0r at gmail.com (J Decker) Date: Sat, 3 Jan 2015 15:11:57 -0800 Subject: [CMake] Wrong CMAKE_SYSTEM_NAME handling In-Reply-To: <1420321838617-7589372.post@n2.nabble.com> References: <1420321838617-7589372.post@n2.nabble.com> Message-ID: On Sat, Jan 3, 2015 at 1:50 PM, Marco Milanese wrote: > Hi, > > I'm trying to setup a cross compile CMakeLists.txt. My target is a embedded > ARM core. > This is my CMakeLists.txt > . > > The linker script seems wrong: > mm7 at pc5:~/test/cmake/build$ cat CMakeFiles/target.dir/link.txt > arm-none-eabi-g++ CMakeFiles/target.dir/test.cpp.o -o target > -rdynamic > > I can't understand why is "-rdynamic" appended. It should be appended only > if "CMAKE_SYSTEM_NAME"=Linux > ( > https://github.com/Kitware/CMake/blob/4811915367cc23e68e2171b83509b8a382ff1941/Modules/Platform/Linux-GNU.cmake#L24 > ). > > try setting cmake_system_name before project() Ninja uses that is it's cmakelists.txt; but it appears before project. I use it in a toolcain file and toolchain is loaded before cmakelists so also before Project() > Is this a CMake bug or am I making some mistakes? Thank you > > Marco > > > > -- > View this message in context: > http://cmake.3232098.n2.nabble.com/Wrong-CMAKE-SYSTEM-NAME-handling-tp7589372.html > Sent from the CMake mailing list archive at Nabble.com. > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcomilanese7 at gmail.com Sun Jan 4 02:21:40 2015 From: marcomilanese7 at gmail.com (Marco Milanese) Date: Sun, 4 Jan 2015 00:21:40 -0700 (MST) Subject: [CMake] Wrong CMAKE_SYSTEM_NAME handling In-Reply-To: References: <1420321838617-7589372.post@n2.nabble.com> Message-ID: <1420356100334-7589375.post@n2.nabble.com> Thanks J Decker, that solved my question. -- View this message in context: http://cmake.3232098.n2.nabble.com/Wrong-CMAKE-SYSTEM-NAME-handling-tp7589372p7589375.html Sent from the CMake mailing list archive at Nabble.com. From rkspsm at gmail.com Sun Jan 4 07:58:43 2015 From: rkspsm at gmail.com (Ravi Kumar Singh) Date: Sun, 4 Jan 2015 18:28:43 +0530 Subject: [CMake] Probably a bug in FindIce.cmake Message-ID: In FindIce.cmake, when searching for libraries, there are lots of if conditionals with quotes around their arguments. With changes in cmake 3.1 (policy CMP0054), they are preventing the module to find libraries successfully. See lines 285, 292, 293, 299 in Modules/FindIce.cmake I am new to cmake thus have little experience with cmake language, so I am not sure if its a bug, but removing the quotes made it find ice and libraries properly. -------------- next part -------------- An HTML attachment was scrubbed... URL: From eike at sf-mail.de Sun Jan 4 08:07:07 2015 From: eike at sf-mail.de (Rolf Eike Beer) Date: Sun, 04 Jan 2015 14:07:07 +0100 Subject: [CMake] Probably a bug in FindIce.cmake In-Reply-To: References: Message-ID: <3527135.fXInctrMGX@caliban.sf-tec.de> Am Sonntag, 4. Januar 2015, 18:28:43 schrieb Ravi Kumar Singh: > In FindIce.cmake, when searching for libraries, there are lots of if > conditionals with quotes around their arguments. With changes in cmake 3.1 > (policy CMP0054), they are preventing the module to find libraries > successfully. See lines 285, 292, 293, 299 in Modules/FindIce.cmake > > I am new to cmake thus have little experience with cmake language, so I am > not sure if its a bug, but removing the quotes made it find ice and > libraries properly. Please try if the attached patch fixes all your issues: commit 65351fe916f2d537e722ccbcc37ed1b76bd1af0e Author: Rolf Eike Beer Date: Sun Jan 4 14:06:14 2015 +0100 FindICE: remove quoting of variable names that must be dereferenced diff --git a/Modules/FindIce.cmake b/Modules/FindIce.cmake index 76cecc1..8493d80 100644 --- a/Modules/FindIce.cmake +++ b/Modules/FindIce.cmake @@ -282,21 +282,21 @@ function(_Ice_FIND) PATH_SUFFIXES ${ice_library_suffixes} DOC "Ice ${component} library") mark_as_advanced("${component_cache}") - if("${component_cache}") + if(${component_cache}) set("${component_found}" ON) list(APPEND Ice_LIBRARY "${${component_cache}}") endif() mark_as_advanced("${component_found}") set("${component_cache}" "${${component_cache}}" PARENT_SCOPE) set("${component_found}" "${${component_found}}" PARENT_SCOPE) - if("${component_found}") - if ("Ice_FIND_REQUIRED_${component}") + if(${component_found}) + if (Ice_FIND_REQUIRED_${component}) list(APPEND Ice_LIBS_FOUND "${component} (required)") else() list(APPEND Ice_LIBS_FOUND "${component} (optional)") endif() else() - if ("Ice_FIND_REQUIRED_${component}") + if (Ice_FIND_REQUIRED_${component}) set(Ice_REQUIRED_LIBS_FOUND OFF) list(APPEND Ice_LIBS_NOTFOUND "${component} (required)") else() @@ -356,7 +356,7 @@ if(Ice_FOUND) set(_Ice_component_cache "Ice_${_Ice_component_upcase}_LIBRARY") set(_Ice_component_lib "Ice_${_Ice_component_upcase}_LIBRARIES") set(_Ice_component_found "${_Ice_component_upcase}_FOUND") - if("${_Ice_component_found}") + if(${_Ice_component_found}) set("${_Ice_component_lib}" "${${_Ice_component_cache}}") endif() unset(_Ice_component_upcase) -------------- 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 rkspsm at gmail.com Sun Jan 4 08:21:38 2015 From: rkspsm at gmail.com (Ravi Kumar Singh) Date: Sun, 4 Jan 2015 18:51:38 +0530 Subject: [CMake] Probably a bug in FindIce.cmake In-Reply-To: <3527135.fXInctrMGX@caliban.sf-tec.de> References: <3527135.fXInctrMGX@caliban.sf-tec.de> Message-ID: Yes, its working fine, thanks. On Sun, Jan 4, 2015 at 6:37 PM, Rolf Eike Beer wrote: > Am Sonntag, 4. Januar 2015, 18:28:43 schrieb Ravi Kumar Singh: > > In FindIce.cmake, when searching for libraries, there are lots of if > > conditionals with quotes around their arguments. With changes in cmake > 3.1 > > (policy CMP0054), they are preventing the module to find libraries > > successfully. See lines 285, 292, 293, 299 in Modules/FindIce.cmake > > > > I am new to cmake thus have little experience with cmake language, so I > am > > not sure if its a bug, but removing the quotes made it find ice and > > libraries properly. > > Please try if the attached patch fixes all your issues: > > commit 65351fe916f2d537e722ccbcc37ed1b76bd1af0e > Author: Rolf Eike Beer > Date: Sun Jan 4 14:06:14 2015 +0100 > > FindICE: remove quoting of variable names that must be dereferenced > > diff --git a/Modules/FindIce.cmake b/Modules/FindIce.cmake > index 76cecc1..8493d80 100644 > --- a/Modules/FindIce.cmake > +++ b/Modules/FindIce.cmake > @@ -282,21 +282,21 @@ function(_Ice_FIND) > PATH_SUFFIXES ${ice_library_suffixes} > DOC "Ice ${component} library") > mark_as_advanced("${component_cache}") > - if("${component_cache}") > + if(${component_cache}) > set("${component_found}" ON) > list(APPEND Ice_LIBRARY "${${component_cache}}") > endif() > mark_as_advanced("${component_found}") > set("${component_cache}" "${${component_cache}}" PARENT_SCOPE) > set("${component_found}" "${${component_found}}" PARENT_SCOPE) > - if("${component_found}") > - if ("Ice_FIND_REQUIRED_${component}") > + if(${component_found}) > + if (Ice_FIND_REQUIRED_${component}) > list(APPEND Ice_LIBS_FOUND "${component} (required)") > else() > list(APPEND Ice_LIBS_FOUND "${component} (optional)") > endif() > else() > - if ("Ice_FIND_REQUIRED_${component}") > + if (Ice_FIND_REQUIRED_${component}) > set(Ice_REQUIRED_LIBS_FOUND OFF) > list(APPEND Ice_LIBS_NOTFOUND "${component} (required)") > else() > @@ -356,7 +356,7 @@ if(Ice_FOUND) > set(_Ice_component_cache "Ice_${_Ice_component_upcase}_LIBRARY") > set(_Ice_component_lib "Ice_${_Ice_component_upcase}_LIBRARIES") > set(_Ice_component_found "${_Ice_component_upcase}_FOUND") > - if("${_Ice_component_found}") > + if(${_Ice_component_found}) > set("${_Ice_component_lib}" "${${_Ice_component_cache}}") > endif() > unset(_Ice_component_upcase) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eike at sf-mail.de Sun Jan 4 08:30:12 2015 From: eike at sf-mail.de (Rolf Eike Beer) Date: Sun, 04 Jan 2015 14:30:12 +0100 Subject: [CMake] Probably a bug in FindIce.cmake In-Reply-To: References: <3527135.fXInctrMGX@caliban.sf-tec.de> Message-ID: <1539832.suRPaE1NuJ@caliban.sf-tec.de> Am Sonntag, 4. Januar 2015, 18:51:38 schrieb Ravi Kumar Singh: > Yes, its working fine, thanks. Ok, fix pushed to next. Brad, this is based on release and can go into 3.1.1. 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 irwin.zaid at physics.ox.ac.uk Mon Jan 5 07:32:09 2015 From: irwin.zaid at physics.ox.ac.uk (Irwin Zaid) Date: Mon, 5 Jan 2015 12:32:09 +0000 Subject: [CMake] FindCUDA ignores project dependencies when separable compilation is on In-Reply-To: <4634e484e7954171a22b8bebc07ae578@EXCHANGE-CAS1.physics.ox.ac.uk> References: <4634e484e7954171a22b8bebc07ae578@EXCHANGE-CAS1.physics.ox.ac.uk> Message-ID: <54AA8449.70404@physics.ox.ac.uk> Just wanted to send this again, as the problem still exists. While working on the libdynd project (https://github.com/libdynd/libdynd), we've discovered two CUDA CMake issues that we'd like to help resolve. Who are the right people to speak with about these? Irwin Irwin Zaid wrote: > Hi all, > > Just wanted to mention this issue I've run into. > > I have a project (libdynd -- https://github.com/libdynd/libdynd) that > uses FindCUDA to deal with CUDA compilation. A part of our library is > generated at compile-time, which we handle by the command > "add_dependencies(libdynd some_exe)", where "some_exe" is an executable > built with a custom command. This part of our library needs to be > present before anything else is built. > > So far, everything has worked great, with and without CUDA. However, I > found that by just turning separable compilation on, via > set(CUDA_SEPARABLE_COMPILATION ON), the dependency I've added is then > ignored and the necessary files are not generated. Basically, CMake goes > straight to NVCC without running the custom command. > > This seems to me to be something wrong with FindCUDA, but it is of > course possible that I've done something wrong. Any help would be > appreciated! > > Irwin From kainjow at kainjow.com Mon Jan 5 10:44:51 2015 From: kainjow at kainjow.com (Kevin Wojniak) Date: Mon, 5 Jan 2015 07:44:51 -0800 Subject: [CMake] CMake 3.1 and add_executable() without sources Message-ID: <5ACC63A5-2D1B-47D5-9669-3769DB321105@kainjow.com> Hi, I am wondering now that 3.1 is out if using add_executable() without sources and later using target_sources() is a new supported way of creating targets? The docs don?t actually say the sources are optional and you can later use target_sources(). We currently have several macros we reuse for multiple targets across multiple projects but currently require 2 separate macros per functionality to specify target sources (via a shared per-target global variable - yuck) and another for linker options. With 3.1 we can combine these into a single macro without the global var which simplifies our CMakeLists files greatly. But before I start doing this, I want to make sure this an acceptable way going forward. Thanks, Kevin From jamesbigler at gmail.com Mon Jan 5 14:53:11 2015 From: jamesbigler at gmail.com (James Bigler) Date: Mon, 5 Jan 2015 12:53:11 -0700 Subject: [CMake] IMPLICIT_DEPENDS and removal of dependencies Message-ID: If I have a file that depended on another file (say file.cpp includes a.h which includes b.h), and then I rename b.h to c.h is CMake able to detect that b.h no longer exists on disk and remove the dependency from the makefiles? Right now the makefile still has a dependency to b.h which it cannot resolve preventing compilation. I've run a configure/generate step with cmake, but dependencies to b.h persist. I'm using CMake 3.0.2. Thanks, James -------------- next part -------------- An HTML attachment was scrubbed... URL: From scott.bloom at onshorecs.com Mon Jan 5 14:53:47 2015 From: scott.bloom at onshorecs.com (Scott Aron Bloom) Date: Mon, 5 Jan 2015 19:53:47 +0000 Subject: [CMake] Bug in SLN generation Message-ID: <6FD2E165340D9A429CF831C7A2D4F42E4E5864D4@WIN-R92V03RFJ85.onshorecs.local> I have found a bug in SLN generation when the property USE_FOLDERS is set to on. The order of the folders, and vcprojects added to the folders is not sorted. It is sorted correctly if USE_FOLDERS is not set. I have two questions, first, what is the appropriate mechanism for filing a bug? I will create a trivial testcase to show the issue. Second, in the meantime I have a way to fix the sln file, as a post process after its generated. What type of rule could I add to the CMakeLists.txt file to run after the sln has been generated/updated by cmake? Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamesbigler at gmail.com Mon Jan 5 15:05:49 2015 From: jamesbigler at gmail.com (James Bigler) Date: Mon, 5 Jan 2015 13:05:49 -0700 Subject: [CMake] FindCUDA ignores project dependencies when separable compilation is on In-Reply-To: <54AA8449.70404@physics.ox.ac.uk> References: <4634e484e7954171a22b8bebc07ae578@EXCHANGE-CAS1.physics.ox.ac.uk> <54AA8449.70404@physics.ox.ac.uk> Message-ID: The only CMake build dependency changes when doing separable compilation are found in CUDA_LINK_SEPARABLE_COMPILATION_OBJECTS. Basically what this does is create a new rule to build an intermediate link file. For everything but some versions of MSVC generators it adds a custom command to generate this intermediate link file. The other case adds a custom command that runs as a PRE_LINK command to generate the object file (the reasons for this is a bug in VS custom command dependency scanning), but this should happen during link phase and not compile phase. Nothing in here should change what happens before the target is built, though. On Mon, Jan 5, 2015 at 5:32 AM, Irwin Zaid wrote: > Just wanted to send this again, as the problem still exists. While working > on the libdynd project (https://github.com/libdynd/libdynd), we've > discovered two CUDA CMake issues that we'd like to help resolve. > > Who are the right people to speak with about these? > > Irwin > > Irwin Zaid wrote: > >> Hi all, >> >> Just wanted to mention this issue I've run into. >> >> I have a project (libdynd -- https://github.com/libdynd/libdynd) that >> uses FindCUDA to deal with CUDA compilation. A part of our library is >> generated at compile-time, which we handle by the command >> "add_dependencies(libdynd some_exe)", where "some_exe" is an executable >> built with a custom command. This part of our library needs to be >> present before anything else is built. >> >> So far, everything has worked great, with and without CUDA. However, I >> found that by just turning separable compilation on, via >> set(CUDA_SEPARABLE_COMPILATION ON), the dependency I've added is then >> ignored and the necessary files are not generated. Basically, CMake goes >> straight to NVCC without running the custom command. >> >> This seems to me to be something wrong with FindCUDA, but it is of >> course possible that I've done something wrong. Any help would be >> appreciated! >> >> Irwin >> > -- > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From irwin.zaid at physics.ox.ac.uk Mon Jan 5 15:57:55 2015 From: irwin.zaid at physics.ox.ac.uk (Irwin Zaid) Date: Mon, 5 Jan 2015 20:57:55 +0000 Subject: [CMake] FindCUDA ignores project dependencies when separable compilation is on In-Reply-To: <24de6f36f39c40caaf533f87173c6f83@EXCHANGE-CAS1.physics.ox.ac.uk> References: <4634e484e7954171a22b8bebc07ae578@EXCHANGE-CAS1.physics.ox.ac.uk> <54AA8449.70404@physics.ox.ac.uk> <24de6f36f39c40caaf533f87173c6f83@EXCHANGE-CAS1.physics.ox.ac.uk> Message-ID: <54AAFAD3.2080102@physics.ox.ac.uk> Hi James, Thanks for the quick reply! As I mentioned, we've hit two issues. The first is the project dependencies one, which I'll try and describe more a bit below. I'm not a CMake expert, so please bear with me. The second is what I've put under 2). > The only CMake build dependency changes when doing separable compilation > are found in CUDA_LINK_SEPARABLE_COMPILATION_OBJECTS. Basically what > this does is create a new rule to build an intermediate link file. For > everything but some versions of MSVC generators it adds a custom command > to generate this intermediate link file. The other case adds a custom > command that runs as a PRE_LINK command to generate the object file (the > reasons for this is a bug in VS custom command dependency scanning), but > this should happen during link phase and not compile phase. > > Nothing in here should change what happens before the target is built, > though. 1) Okay, I understand that, but I do think we saw a different behaviour when we switched to separable compilation. Let me describe what we are doing. We generate part of our library from a simple program (call the simple program 'gen', which generates a source file 'gen.hpp') that we want to execute before compiling our library (call our library 'main'). We set this up with the following: - add_executable(...) is called for 'gen' - add_custom_command(...) sets up a command that executes 'gen' - set_source_files_properties(...) is called to set 'gen.hpp' as having the PROPERTY of GENERATED - add_dependencies(main gen) is called to establish 'main' depends on 'gen' So far, this has only failed for CUDA with separable compilation. (It has worked for all of our other configurations. including CUDA without separable compilation.) Have we done something wrong? Is there some additional information we can look at to figure out what's going on? 2) A second problem we've run into is an error when trying to link a CUDA shared library with separable compilation. This is specifically a Linux problem, on Mac it is fine. A static library is also fine, working for both Linux and Mac. The particular error is "relocation R_X86_64_32S against `__nv_module_id' can not be used when making a shared object; recompile with -fPIC". However, we are already compiling with -fPIC. I can confirm that -fPIC appears to be passed to both the host compiler for non-CUDA source and via -Xcompiler -fPIC for CUDA source. This error occurs when trying to link all the different object files together of our library. Do you have any idea of what this could be? -- Thanks for all of your help. Cheers, Irwin From jamesbigler at gmail.com Mon Jan 5 17:31:14 2015 From: jamesbigler at gmail.com (James Bigler) Date: Mon, 5 Jan 2015 15:31:14 -0700 Subject: [CMake] FindCUDA ignores project dependencies when separable compilation is on In-Reply-To: <54AAFAD3.2080102@physics.ox.ac.uk> References: <4634e484e7954171a22b8bebc07ae578@EXCHANGE-CAS1.physics.ox.ac.uk> <54AA8449.70404@physics.ox.ac.uk> <24de6f36f39c40caaf533f87173c6f83@EXCHANGE-CAS1.physics.ox.ac.uk> <54AAFAD3.2080102@physics.ox.ac.uk> Message-ID: On Mon, Jan 5, 2015 at 1:57 PM, Irwin Zaid wrote: > Hi James, > > Thanks for the quick reply! As I mentioned, we've hit two issues. The > first is the project dependencies one, which I'll try and describe more a > bit below. I'm not a CMake expert, so please bear with me. > > The second is what I've put under 2). > > The only CMake build dependency changes when doing separable compilation >> are found in CUDA_LINK_SEPARABLE_COMPILATION_OBJECTS. Basically what >> this does is create a new rule to build an intermediate link file. For >> everything but some versions of MSVC generators it adds a custom command >> to generate this intermediate link file. The other case adds a custom >> command that runs as a PRE_LINK command to generate the object file (the >> reasons for this is a bug in VS custom command dependency scanning), but >> this should happen during link phase and not compile phase. >> >> Nothing in here should change what happens before the target is built, >> though. >> > > 1) Okay, I understand that, but I do think we saw a different behaviour > when we switched to separable compilation. Let me describe what we are > doing. > > We generate part of our library from a simple program (call the simple > program 'gen', which generates a source file 'gen.hpp') that we want to > execute before compiling our library (call our library 'main'). We set this > up with the following: > > - add_executable(...) is called for 'gen' > - add_custom_command(...) sets up a command that executes 'gen' > - set_source_files_properties(...) is called to set 'gen.hpp' as having > the PROPERTY of GENERATED > - add_dependencies(main gen) is called to establish 'main' depends on 'gen' > > So far, this has only failed for CUDA with separable compilation. (It has > worked for all of our other configurations. including CUDA without > separable compilation.) > > Have we done something wrong? Is there some additional information we can > look at to figure out what's going on? > > What kind of generator are you using (e.g. makefile)? Here's what I'm thinking might be the problem, though I'm not sure why it would have worked without CUDA_SEPARABLE_COMPILATION. There's a dependency between gen and gen.hpp (encoded in the call to add_custom_command(OUTPUTS gen.hpp COMMAND gen)). There's a dependency between main and gen (can't start building main until gen is built). There's a dependency between gen.hpp and main (gen.hpp is an input source to main, so it needs to be built as part of main). What I don't see is a dependency between gen.hpp and all the cuda sources that might use it as input. So from a dependency graph standpoint a makefile (if one is being used in this case) is entirely free to start compiling the CUDA code once the gen target has been satisfied. What you need is another target that builds the gen.hpp file which can be forced to run before main starts to build. There are more than one way to do this, and I'm not sure what the best option is, but you might try this: add_custom_command(OUTPUTS gen.hpp ....) add_custom_target(make_gen_hpp DEPENDS gen.hpp) add_dependency(main make_gen_hpp) > 2) A second problem we've run into is an error when trying to link a CUDA > shared library with separable compilation. This is specifically a Linux > problem, on Mac it is fine. A static library is also fine, working for both > Linux and Mac. > > The particular error is "relocation R_X86_64_32S against `__nv_module_id' > can not be used when making a shared object; recompile with -fPIC". > However, we are already compiling with -fPIC. I can confirm that -fPIC > appears to be passed to both the host compiler for non-CUDA source and via > -Xcompiler -fPIC for CUDA source. > > This error occurs when trying to link all the different object files > together of our library. > > Do you have any idea of what this could be? > > I'm not sure which object file wasn't compiled with -fPIC, but I would suspect it might be the intermediate link object file. FindCUDA is supposed to pass this flag along (see function(_cuda_get_important_host_flags)), but you might want to verify this with a 'make VERBOSE=1' and look for _intermediate_link.o (substitute your target name in or leave it out of the search string). James -------------- next part -------------- An HTML attachment was scrubbed... URL: From irwin.zaid at physics.ox.ac.uk Mon Jan 5 17:43:27 2015 From: irwin.zaid at physics.ox.ac.uk (Irwin Zaid) Date: Mon, 5 Jan 2015 22:43:27 +0000 Subject: [CMake] FindCUDA ignores project dependencies when separable compilation is on In-Reply-To: <6c2cbb1f096c4cd29c49a0dbfeaec934@EXCHANGE-CAS2.physics.ox.ac.uk> References: <4634e484e7954171a22b8bebc07ae578@EXCHANGE-CAS1.physics.ox.ac.uk> <54AA8449.70404@physics.ox.ac.uk> <24de6f36f39c40caaf533f87173c6f83@EXCHANGE-CAS1.physics.ox.ac.uk> <54AAFAD3.2080102@physics.ox.ac.uk> <6c2cbb1f096c4cd29c49a0dbfeaec934@EXCHANGE-CAS2.physics.ox.ac.uk> Message-ID: <54AB138F.1010406@physics.ox.ac.uk> Alright, this is a lot of progress! 1) We are using Makefiles. I agree with you about the dependency graph, so I'll try and sort that out. I'll let you know what the result is. 2) I just checked and, indeed, the *_intermediate_link.o file is not being passed -fPIC. Is this our problem? What is the correct fix? Irwin James Bigler wrote: > > > On Mon, Jan 5, 2015 at 1:57 PM, Irwin Zaid > wrote: > > Hi James, > > Thanks for the quick reply! As I mentioned, we've hit two issues. > The first is the project dependencies one, which I'll try and > describe more a bit below. I'm not a CMake expert, so please bear > with me. > > The second is what I've put under 2). > > The only CMake build dependency changes when doing separable > compilation > are found in CUDA_LINK_SEPARABLE___COMPILATION_OBJECTS. > Basically what > this does is create a new rule to build an intermediate link > file. For > everything but some versions of MSVC generators it adds a custom > command > to generate this intermediate link file. The other case adds a > custom > command that runs as a PRE_LINK command to generate the object > file (the > reasons for this is a bug in VS custom command dependency > scanning), but > this should happen during link phase and not compile phase. > > Nothing in here should change what happens before the target is > built, > though. > > > 1) Okay, I understand that, but I do think we saw a different > behaviour when we switched to separable compilation. Let me describe > what we are doing. > > We generate part of our library from a simple program (call the > simple program 'gen', which generates a source file 'gen.hpp') that > we want to execute before compiling our library (call our library > 'main'). We set this up with the following: > > - add_executable(...) is called for 'gen' > - add_custom_command(...) sets up a command that executes 'gen' > - set_source_files_properties(..__.) is called to set 'gen.hpp' as > having the PROPERTY of GENERATED > - add_dependencies(main gen) is called to establish 'main' depends > on 'gen' > > So far, this has only failed for CUDA with separable compilation. > (It has worked for all of our other configurations. including CUDA > without separable compilation.) > > Have we done something wrong? Is there some additional information > we can look at to figure out what's going on? > > > What kind of generator are you using (e.g. makefile)? > > Here's what I'm thinking might be the problem, though I'm not sure why > it would have worked without CUDA_SEPARABLE_COMPILATION. > > There's a dependency between gen and gen.hpp (encoded in the call to > add_custom_command(OUTPUTS gen.hpp COMMAND gen)). > There's a dependency between main and gen (can't start building main > until gen is built). > There's a dependency between gen.hpp and main (gen.hpp is an input > source to main, so it needs to be built as part of main). > > What I don't see is a dependency between gen.hpp and all the cuda > sources that might use it as input. So from a dependency graph > standpoint a makefile (if one is being used in this case) is entirely > free to start compiling the CUDA code once the gen target has been > satisfied. > > What you need is another target that builds the gen.hpp file which can > be forced to run before main starts to build. There are more than one > way to do this, and I'm not sure what the best option is, but you might > try this: > > add_custom_command(OUTPUTS gen.hpp ....) > add_custom_target(make_gen_hpp DEPENDS gen.hpp) > add_dependency(main make_gen_hpp) > > 2) A second problem we've run into is an error when trying to link a > CUDA shared library with separable compilation. This is specifically > a Linux problem, on Mac it is fine. A static library is also fine, > working for both Linux and Mac. > > The particular error is "relocation R_X86_64_32S against > `__nv_module_id' can not be used when making a shared object; > recompile with -fPIC". However, we are already compiling with -fPIC. > I can confirm that -fPIC appears to be passed to both the host > compiler for non-CUDA source and via -Xcompiler -fPIC for CUDA source. > > This error occurs when trying to link all the different object files > together of our library. > > Do you have any idea of what this could be? > > > I'm not sure which object file wasn't compiled with -fPIC, but I would > suspect it might be the intermediate link object file. FindCUDA is > supposed to pass this flag along (see > function(_cuda_get_important_host_flags)), but you might want to verify > this with a 'make VERBOSE=1' and look for > _intermediate_link.o (substitute your target name in or > leave it out of the search string). > > James From jamesbigler at gmail.com Mon Jan 5 19:02:50 2015 From: jamesbigler at gmail.com (James Bigler) Date: Mon, 5 Jan 2015 17:02:50 -0700 Subject: [CMake] FindCUDA ignores project dependencies when separable compilation is on In-Reply-To: <54AB138F.1010406@physics.ox.ac.uk> References: <4634e484e7954171a22b8bebc07ae578@EXCHANGE-CAS1.physics.ox.ac.uk> <54AA8449.70404@physics.ox.ac.uk> <24de6f36f39c40caaf533f87173c6f83@EXCHANGE-CAS1.physics.ox.ac.uk> <54AAFAD3.2080102@physics.ox.ac.uk> <6c2cbb1f096c4cd29c49a0dbfeaec934@EXCHANGE-CAS2.physics.ox.ac.uk> <54AB138F.1010406@physics.ox.ac.uk> Message-ID: 2. It looks as though CUDA_LINK_SEPARABLE_COMPILATION_OBJECTS is only looking at the configuration specific flags. You can add the flag specifically to all your configs (e.g. CMAKE_CXX_FLAGS_DEBUG) or you could try adding these lines of code in your FindCUDA.cmake file somewhere in CUDA_LINK_SEPARABLE_COMPILATION_OBJECTS after set(flags). It looks as though this was overlooked (sorry). set(important_host_flags) _cuda_get_important_host_flags(important_host_flags ${CMAKE_${CUDA_C_OR_CXX}_FLAGS}) foreach(f ${important_host_flags}) list(APPEND flags -Xcompiler ${f}) endforeach() On Mon, Jan 5, 2015 at 3:43 PM, Irwin Zaid wrote: > Alright, this is a lot of progress! > > 1) We are using Makefiles. I agree with you about the dependency graph, so > I'll try and sort that out. I'll let you know what the result is. > > 2) I just checked and, indeed, the *_intermediate_link.o file is not being > passed -fPIC. Is this our problem? What is the correct fix? > > Irwin > > James Bigler wrote: > >> >> >> On Mon, Jan 5, 2015 at 1:57 PM, Irwin Zaid > > wrote: >> >> Hi James, >> >> Thanks for the quick reply! As I mentioned, we've hit two issues. >> The first is the project dependencies one, which I'll try and >> describe more a bit below. I'm not a CMake expert, so please bear >> with me. >> >> The second is what I've put under 2). >> >> The only CMake build dependency changes when doing separable >> compilation >> are found in CUDA_LINK_SEPARABLE___COMPILATION_OBJECTS. >> Basically what >> this does is create a new rule to build an intermediate link >> file. For >> everything but some versions of MSVC generators it adds a custom >> command >> to generate this intermediate link file. The other case adds a >> custom >> command that runs as a PRE_LINK command to generate the object >> file (the >> reasons for this is a bug in VS custom command dependency >> scanning), but >> this should happen during link phase and not compile phase. >> >> Nothing in here should change what happens before the target is >> built, >> though. >> >> >> 1) Okay, I understand that, but I do think we saw a different >> behaviour when we switched to separable compilation. Let me describe >> what we are doing. >> >> We generate part of our library from a simple program (call the >> simple program 'gen', which generates a source file 'gen.hpp') that >> we want to execute before compiling our library (call our library >> 'main'). We set this up with the following: >> >> - add_executable(...) is called for 'gen' >> - add_custom_command(...) sets up a command that executes 'gen' >> - set_source_files_properties(..__.) is called to set 'gen.hpp' as >> having the PROPERTY of GENERATED >> - add_dependencies(main gen) is called to establish 'main' depends >> on 'gen' >> >> So far, this has only failed for CUDA with separable compilation. >> (It has worked for all of our other configurations. including CUDA >> without separable compilation.) >> >> Have we done something wrong? Is there some additional information >> we can look at to figure out what's going on? >> >> >> What kind of generator are you using (e.g. makefile)? >> >> Here's what I'm thinking might be the problem, though I'm not sure why >> it would have worked without CUDA_SEPARABLE_COMPILATION. >> >> There's a dependency between gen and gen.hpp (encoded in the call to >> add_custom_command(OUTPUTS gen.hpp COMMAND gen)). >> There's a dependency between main and gen (can't start building main >> until gen is built). >> There's a dependency between gen.hpp and main (gen.hpp is an input >> source to main, so it needs to be built as part of main). >> >> What I don't see is a dependency between gen.hpp and all the cuda >> sources that might use it as input. So from a dependency graph >> standpoint a makefile (if one is being used in this case) is entirely >> free to start compiling the CUDA code once the gen target has been >> satisfied. >> >> What you need is another target that builds the gen.hpp file which can >> be forced to run before main starts to build. There are more than one >> way to do this, and I'm not sure what the best option is, but you might >> try this: >> >> add_custom_command(OUTPUTS gen.hpp ....) >> add_custom_target(make_gen_hpp DEPENDS gen.hpp) >> add_dependency(main make_gen_hpp) >> >> 2) A second problem we've run into is an error when trying to link a >> CUDA shared library with separable compilation. This is specifically >> a Linux problem, on Mac it is fine. A static library is also fine, >> working for both Linux and Mac. >> >> The particular error is "relocation R_X86_64_32S against >> `__nv_module_id' can not be used when making a shared object; >> recompile with -fPIC". However, we are already compiling with -fPIC. >> I can confirm that -fPIC appears to be passed to both the host >> compiler for non-CUDA source and via -Xcompiler -fPIC for CUDA source. >> >> This error occurs when trying to link all the different object files >> together of our library. >> >> Do you have any idea of what this could be? >> >> >> I'm not sure which object file wasn't compiled with -fPIC, but I would >> suspect it might be the intermediate link object file. FindCUDA is >> supposed to pass this flag along (see >> function(_cuda_get_important_host_flags)), but you might want to verify >> this with a 'make VERBOSE=1' and look for >> _intermediate_link.o (substitute your target name in or >> leave it out of the search string). >> >> James >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From petr.kmoch at gmail.com Tue Jan 6 02:50:52 2015 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Tue, 6 Jan 2015 08:50:52 +0100 Subject: [CMake] Bug in SLN generation In-Reply-To: <6FD2E165340D9A429CF831C7A2D4F42E4E5864D4@WIN-R92V03RFJ85.onshorecs.local> References: <6FD2E165340D9A429CF831C7A2D4F42E4E5864D4@WIN-R92V03RFJ85.onshorecs.local> Message-ID: Hi Scott. To file a bug, use the Mantis tracker at http://public.kitware.com/Bug/ As for running custom processing post-generation, there is no way hook this, and a request for it was explicitly declined: http://public.kitware.com/Bug/view.php?id=13020 Petr On Mon, Jan 5, 2015 at 8:53 PM, Scott Aron Bloom wrote: > I have found a bug in SLN generation when the property USE_FOLDERS is > set to on. > > > The order of the folders, and vcprojects added to the folders is not > sorted. It is sorted correctly if USE_FOLDERS is not set. > > > > I have two questions, first, what is the appropriate mechanism for filing > a bug? I will create a trivial testcase to show the issue. > > > > Second, in the meantime I have a way to fix the sln file, as a post > process after its generated. What type of rule could I add to the > CMakeLists.txt file to run after the sln has been generated/updated by > cmake? > > Scott > > -- > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From DLRdave at aol.com Tue Jan 6 08:29:57 2015 From: DLRdave at aol.com (David Cole) Date: Tue, 6 Jan 2015 08:29:57 -0500 Subject: [CMake] Bug in SLN generation In-Reply-To: References: <6FD2E165340D9A429CF831C7A2D4F42E4E5864D4@WIN-R92V03RFJ85.onshorecs.local> Message-ID: Two ways to do this occur to me: (1) wrap cmake with a two-line script that your project developers use: @call cmake -G "Visual Studio 12 2013" @call post-cmake.cmd (2) do a file(WRITE ...) unconditionally somewhere in your CMakeLists.txt file, and then introduce a custom command that depends on that file, and a custom target for that command to live in, and then make all your other targets depend on that one. That way, the first thing that happens in a build is your "post-CMake" step. (this one will be a weird interactive experience in Visual Studio, though, if your custom command modifies the sln/vcxproj files...) Perhaps neither is "ideal," but either technique should be able to help you until an ideal solution can be implemented. HTH, David C. On Tue, Jan 6, 2015 at 2:50 AM, Petr Kmoch wrote: > Hi Scott. > > To file a bug, use the Mantis tracker at http://public.kitware.com/Bug/ > > As for running custom processing post-generation, there is no way hook this, > and a request for it was explicitly declined: > http://public.kitware.com/Bug/view.php?id=13020 > > Petr > > On Mon, Jan 5, 2015 at 8:53 PM, Scott Aron Bloom > wrote: >> >> I have found a bug in SLN generation when the property USE_FOLDERS is set >> to on. >> >> >> The order of the folders, and vcprojects added to the folders is not >> sorted. It is sorted correctly if USE_FOLDERS is not set. >> >> >> >> I have two questions, first, what is the appropriate mechanism for filing >> a bug? I will create a trivial testcase to show the issue. >> >> >> >> Second, in the meantime I have a way to fix the sln file, as a post >> process after its generated. What type of rule could I add to the >> CMakeLists.txt file to run after the sln has been generated/updated by >> cmake? >> >> Scott >> >> >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake > > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake From petr.kmoch at gmail.com Tue Jan 6 08:39:55 2015 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Tue, 6 Jan 2015 14:39:55 +0100 Subject: [CMake] Bug in SLN generation In-Reply-To: References: <6FD2E165340D9A429CF831C7A2D4F42E4E5864D4@WIN-R92V03RFJ85.onshorecs.local> Message-ID: On Tue, Jan 6, 2015 at 2:29 PM, David Cole wrote: > Two ways to do this occur to me: > > (1) wrap cmake with a two-line script that your project developers use: > @call cmake -G "Visual Studio 12 2013" > @call post-cmake.cmd > Would this work with re-runs triggered by CMake itself (e.g. by ZERO_CHECK)? > > (2) do a file(WRITE ...) unconditionally somewhere in your > CMakeLists.txt file, and then introduce a custom command that depends > on that file, and a custom target for that command to live in, and > then make all your other targets depend on that one. That way, the > first thing that happens in a build is your "post-CMake" step. (this > one will be a weird interactive experience in Visual Studio, though, > if your custom command modifies the sln/vcxproj files...) > > Perhaps neither is "ideal," but either technique should be able to > help you until an ideal solution can be implemented. > > > HTH, > David C. > > > On Tue, Jan 6, 2015 at 2:50 AM, Petr Kmoch wrote: > > Hi Scott. > > > > To file a bug, use the Mantis tracker at http://public.kitware.com/Bug/ > > > > As for running custom processing post-generation, there is no way hook > this, > > and a request for it was explicitly declined: > > http://public.kitware.com/Bug/view.php?id=13020 > > > > Petr > > > > On Mon, Jan 5, 2015 at 8:53 PM, Scott Aron Bloom < > scott.bloom at onshorecs.com> > > wrote: > >> > >> I have found a bug in SLN generation when the property USE_FOLDERS is > set > >> to on. > >> > >> > >> The order of the folders, and vcprojects added to the folders is not > >> sorted. It is sorted correctly if USE_FOLDERS is not set. > >> > >> > >> > >> I have two questions, first, what is the appropriate mechanism for > filing > >> a bug? I will create a trivial testcase to show the issue. > >> > >> > >> > >> Second, in the meantime I have a way to fix the sln file, as a post > >> process after its generated. What type of rule could I add to the > >> CMakeLists.txt file to run after the sln has been generated/updated by > >> cmake? > >> > >> Scott > -------------- next part -------------- An HTML attachment was scrubbed... URL: From DLRdave at aol.com Tue Jan 6 10:36:33 2015 From: DLRdave at aol.com (David Cole) Date: Tue, 6 Jan 2015 10:36:33 -0500 Subject: [CMake] Bug in SLN generation In-Reply-To: References: <6FD2E165340D9A429CF831C7A2D4F42E4E5864D4@WIN-R92V03RFJ85.onshorecs.local> Message-ID: No, with the wrapper script technique, you'd have to train all your developers to run the wrapper script whenever any "CMake stuff" changes... On Tue, Jan 6, 2015 at 8:39 AM, Petr Kmoch wrote: > On Tue, Jan 6, 2015 at 2:29 PM, David Cole wrote: >> >> Two ways to do this occur to me: >> >> (1) wrap cmake with a two-line script that your project developers use: >> @call cmake -G "Visual Studio 12 2013" >> @call post-cmake.cmd > > > Would this work with re-runs triggered by CMake itself (e.g. by ZERO_CHECK)? > >> >> >> (2) do a file(WRITE ...) unconditionally somewhere in your >> CMakeLists.txt file, and then introduce a custom command that depends >> on that file, and a custom target for that command to live in, and >> then make all your other targets depend on that one. That way, the >> first thing that happens in a build is your "post-CMake" step. (this >> one will be a weird interactive experience in Visual Studio, though, >> if your custom command modifies the sln/vcxproj files...) >> >> Perhaps neither is "ideal," but either technique should be able to >> help you until an ideal solution can be implemented. >> >> >> HTH, >> David C. >> >> >> On Tue, Jan 6, 2015 at 2:50 AM, Petr Kmoch wrote: >> > Hi Scott. >> > >> > To file a bug, use the Mantis tracker at http://public.kitware.com/Bug/ >> > >> > As for running custom processing post-generation, there is no way hook >> > this, >> > and a request for it was explicitly declined: >> > http://public.kitware.com/Bug/view.php?id=13020 >> > >> > Petr >> > >> > On Mon, Jan 5, 2015 at 8:53 PM, Scott Aron Bloom >> > >> > wrote: >> >> >> >> I have found a bug in SLN generation when the property USE_FOLDERS is >> >> set >> >> to on. >> >> >> >> >> >> The order of the folders, and vcprojects added to the folders is not >> >> sorted. It is sorted correctly if USE_FOLDERS is not set. >> >> >> >> >> >> >> >> I have two questions, first, what is the appropriate mechanism for >> >> filing >> >> a bug? I will create a trivial testcase to show the issue. >> >> >> >> >> >> >> >> Second, in the meantime I have a way to fix the sln file, as a post >> >> process after its generated. What type of rule could I add to the >> >> CMakeLists.txt file to run after the sln has been generated/updated by >> >> cmake? >> >> >> >> Scott > > From scott.bloom at onshorecs.com Tue Jan 6 10:44:39 2015 From: scott.bloom at onshorecs.com (Scott Aron Bloom) Date: Tue, 6 Jan 2015 15:44:39 +0000 Subject: [CMake] Bug in SLN generation In-Reply-To: References: <6FD2E165340D9A429CF831C7A2D4F42E4E5864D4@WIN-R92V03RFJ85.onshorecs.local>, Message-ID: <8qq3ctxkcnjjbxxtepwnolho.1420559121065@email.android.com> I filed a bug yesterday, and may take a look at the source code and look into a coding thr patch this week. I did find the previous bug as well once I Google the right keywords... --Scott -------- Original message -------- From: Petr Kmoch Date:01/05/2015 23:50 (GMT-08:00) To: Scott Aron Bloom Cc: cmake at cmake.org Subject: Re: [CMake] Bug in SLN generation Hi Scott. To file a bug, use the Mantis tracker at http://public.kitware.com/Bug/ As for running custom processing post-generation, there is no way hook this, and a request for it was explicitly declined: http://public.kitware.com/Bug/view.php?id=13020 Petr On Mon, Jan 5, 2015 at 8:53 PM, Scott Aron Bloom > wrote: I have found a bug in SLN generation when the property USE_FOLDERS is set to on. The order of the folders, and vcprojects added to the folders is not sorted. It is sorted correctly if USE_FOLDERS is not set. I have two questions, first, what is the appropriate mechanism for filing a bug? I will create a trivial testcase to show the issue. Second, in the meantime I have a way to fix the sln file, as a post process after its generated. What type of rule could I add to the CMakeLists.txt file to run after the sln has been generated/updated by cmake? Scott -- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From scott.bloom at onshorecs.com Tue Jan 6 10:46:00 2015 From: scott.bloom at onshorecs.com (Scott Aron Bloom) Date: Tue, 6 Jan 2015 15:46:00 +0000 Subject: [CMake] Bug in SLN generation In-Reply-To: References: <6FD2E165340D9A429CF831C7A2D4F42E4E5864D4@WIN-R92V03RFJ85.onshorecs.local> , Message-ID: The other problem with the script technique, is most of my devs use cmake inside visual Studio.. --Scott -------- Original message -------- From: David Cole Date:01/06/2015 07:35 (GMT-08:00) To: Petr Kmoch Cc: Scott Aron Bloom , cmake at cmake.org Subject: Re: [CMake] Bug in SLN generation No, with the wrapper script technique, you'd have to train all your developers to run the wrapper script whenever any "CMake stuff" changes... On Tue, Jan 6, 2015 at 8:39 AM, Petr Kmoch wrote: > On Tue, Jan 6, 2015 at 2:29 PM, David Cole wrote: >> >> Two ways to do this occur to me: >> >> (1) wrap cmake with a two-line script that your project developers use: >> @call cmake -G "Visual Studio 12 2013" >> @call post-cmake.cmd > > > Would this work with re-runs triggered by CMake itself (e.g. by ZERO_CHECK)? > >> >> >> (2) do a file(WRITE ...) unconditionally somewhere in your >> CMakeLists.txt file, and then introduce a custom command that depends >> on that file, and a custom target for that command to live in, and >> then make all your other targets depend on that one. That way, the >> first thing that happens in a build is your "post-CMake" step. (this >> one will be a weird interactive experience in Visual Studio, though, >> if your custom command modifies the sln/vcxproj files...) >> >> Perhaps neither is "ideal," but either technique should be able to >> help you until an ideal solution can be implemented. >> >> >> HTH, >> David C. >> >> >> On Tue, Jan 6, 2015 at 2:50 AM, Petr Kmoch wrote: >> > Hi Scott. >> > >> > To file a bug, use the Mantis tracker at http://public.kitware.com/Bug/ >> > >> > As for running custom processing post-generation, there is no way hook >> > this, >> > and a request for it was explicitly declined: >> > http://public.kitware.com/Bug/view.php?id=13020 >> > >> > Petr >> > >> > On Mon, Jan 5, 2015 at 8:53 PM, Scott Aron Bloom >> > >> > wrote: >> >> >> >> I have found a bug in SLN generation when the property USE_FOLDERS is >> >> set >> >> to on. >> >> >> >> >> >> The order of the folders, and vcprojects added to the folders is not >> >> sorted. It is sorted correctly if USE_FOLDERS is not set. >> >> >> >> >> >> >> >> I have two questions, first, what is the appropriate mechanism for >> >> filing >> >> a bug? I will create a trivial testcase to show the issue. >> >> >> >> >> >> >> >> Second, in the meantime I have a way to fix the sln file, as a post >> >> process after its generated. What type of rule could I add to the >> >> CMakeLists.txt file to run after the sln has been generated/updated by >> >> cmake? >> >> >> >> Scott > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From irwin.zaid at physics.ox.ac.uk Tue Jan 6 10:54:16 2015 From: irwin.zaid at physics.ox.ac.uk (Irwin Zaid) Date: Tue, 6 Jan 2015 15:54:16 +0000 Subject: [CMake] FindCUDA ignores project dependencies when separable compilation is on In-Reply-To: References: <4634e484e7954171a22b8bebc07ae578@EXCHANGE-CAS1.physics.ox.ac.uk> <54AA8449.70404@physics.ox.ac.uk> <24de6f36f39c40caaf533f87173c6f83@EXCHANGE-CAS1.physics.ox.ac.uk> <54AAFAD3.2080102@physics.ox.ac.uk> <6c2cbb1f096c4cd29c49a0dbfeaec934@EXCHANGE-CAS2.physics.ox.ac.uk> <54AB138F.1010406@physics.ox.ac.uk> Message-ID: <54AC0528.6020302@physics.ox.ac.uk> Okay, an update on this. 1) This is fixed now, thank you. We just needed to add a custom target, as you said. 2) This is trickier and, unfortunately, still not working. We are already adding -fPIC to CMAKE_CXX_FLAGS, should that not be enough? I also tried adding it to both CMAKE_CXX_FLAGS_DEBUG and CMAKE_CXX_FLAGS_RELEASE, with no effect. Looking into FindCUDA.CMake at CUDA_LINK_SEPARABLE_COMPILATION_OBJECTS, I find code very similar to what you are describing. Are you saying that in addition to what is below, we need to add what you proposed? This is what I see. -- foreach(config ${CUDA_configuration_types}) string(TOUPPER ${config} config_upper) # Add config specific flags foreach(f ${CUDA_NVCC_FLAGS_${config_upper}}) list(APPEND config_specific_flags $<$:${f}>) endforeach() set(important_host_flags) _cuda_get_important_host_flags(important_host_flags ${CMAKE_${CUDA_C_OR_CXX}_FLAGS_${config_upper}}) foreach(f ${important_host_flags}) list(APPEND flags $<$:-Xcompiler> $<$:${f}>) endforeach() endforeach() James Bigler wrote: > 2. It looks as though CUDA_LINK_SEPARABLE_COMPILATION_OBJECTS is only > looking at the configuration specific flags. You can add the flag > specifically to all your configs (e.g. CMAKE_CXX_FLAGS_DEBUG) or you > could try adding these lines of code in your FindCUDA.cmake file > somewhere in CUDA_LINK_SEPARABLE_COMPILATION_OBJECTS after set(flags). > It looks as though this was overlooked (sorry). > > set(important_host_flags) > _cuda_get_important_host_flags(important_host_flags > ${CMAKE_${CUDA_C_OR_CXX}_FLAGS}) > foreach(f ${important_host_flags}) > list(APPEND flags -Xcompiler ${f}) > endforeach() > > > > On Mon, Jan 5, 2015 at 3:43 PM, Irwin Zaid > > wrote: > > Alright, this is a lot of progress! > > 1) We are using Makefiles. I agree with you about the dependency > graph, so I'll try and sort that out. I'll let you know what the > result is. > > 2) I just checked and, indeed, the *_intermediate_link.o file is > not being passed -fPIC. Is this our problem? What is the correct fix? > > Irwin > > James Bigler wrote: > > > > On Mon, Jan 5, 2015 at 1:57 PM, Irwin Zaid > > >> wrote: > > Hi James, > > Thanks for the quick reply! As I mentioned, we've hit two issues. > The first is the project dependencies one, which I'll try and > describe more a bit below. I'm not a CMake expert, so please bear > with me. > > The second is what I've put under 2). > > The only CMake build dependency changes when doing separable > compilation > are found in CUDA_LINK_SEPARABLE_____COMPILATION_OBJECTS. > Basically what > this does is create a new rule to build an intermediate link > file. For > everything but some versions of MSVC generators it adds a custom > command > to generate this intermediate link file. The other case adds a > custom > command that runs as a PRE_LINK command to generate the object > file (the > reasons for this is a bug in VS custom command dependency > scanning), but > this should happen during link phase and not compile phase. > > Nothing in here should change what happens before the target is > built, > though. > > > 1) Okay, I understand that, but I do think we saw a different > behaviour when we switched to separable compilation. Let me > describe > what we are doing. > > We generate part of our library from a simple program (call the > simple program 'gen', which generates a source file 'gen.hpp') > that > we want to execute before compiling our library (call our library > 'main'). We set this up with the following: > > - add_executable(...) is called for 'gen' > - add_custom_command(...) sets up a command that executes 'gen' > - set_source_files_properties(..____.) is called to set > 'gen.hpp' as > having the PROPERTY of GENERATED > - add_dependencies(main gen) is called to establish 'main' depends > on 'gen' > > So far, this has only failed for CUDA with separable compilation. > (It has worked for all of our other configurations. including CUDA > without separable compilation.) > > Have we done something wrong? Is there some additional information > we can look at to figure out what's going on? > > > What kind of generator are you using (e.g. makefile)? > > Here's what I'm thinking might be the problem, though I'm not > sure why > it would have worked without CUDA_SEPARABLE_COMPILATION. > > There's a dependency between gen and gen.hpp (encoded in the > call to > add_custom_command(OUTPUTS gen.hpp COMMAND gen)). > There's a dependency between main and gen (can't start > building main > until gen is built). > There's a dependency between gen.hpp and main (gen.hpp is an input > source to main, so it needs to be built as part of main). > > What I don't see is a dependency between gen.hpp and all the cuda > sources that might use it as input. So from a dependency graph > standpoint a makefile (if one is being used in this case) is > entirely > free to start compiling the CUDA code once the gen target has been > satisfied. > > What you need is another target that builds the gen.hpp file > which can > be forced to run before main starts to build. There are more > than one > way to do this, and I'm not sure what the best option is, but > you might > try this: > > add_custom_command(OUTPUTS gen.hpp ....) > add_custom_target(make_gen_hpp DEPENDS gen.hpp) > add_dependency(main make_gen_hpp) > > 2) A second problem we've run into is an error when trying to > link a > CUDA shared library with separable compilation. This is > specifically > a Linux problem, on Mac it is fine. A static library is also fine, > working for both Linux and Mac. > > The particular error is "relocation R_X86_64_32S against > `__nv_module_id' can not be used when making a shared object; > recompile with -fPIC". However, we are already compiling with > -fPIC. > I can confirm that -fPIC appears to be passed to both the host > compiler for non-CUDA source and via -Xcompiler -fPIC for CUDA > source. > > This error occurs when trying to link all the different object > files > together of our library. > > Do you have any idea of what this could be? > > > I'm not sure which object file wasn't compiled with -fPIC, but > I would > suspect it might be the intermediate link object file. FindCUDA is > supposed to pass this flag along (see > function(_cuda_get_important___host_flags)), but you might > want to verify > this with a 'make VERBOSE=1' and look for > _intermediate___link.o (substitute your target > name in or > leave it out of the search string). > > James > > From jamesbigler at gmail.com Tue Jan 6 11:30:47 2015 From: jamesbigler at gmail.com (James Bigler) Date: Tue, 6 Jan 2015 09:30:47 -0700 Subject: [CMake] FindCUDA ignores project dependencies when separable compilation is on In-Reply-To: <54AC0528.6020302@physics.ox.ac.uk> References: <4634e484e7954171a22b8bebc07ae578@EXCHANGE-CAS1.physics.ox.ac.uk> <54AA8449.70404@physics.ox.ac.uk> <24de6f36f39c40caaf533f87173c6f83@EXCHANGE-CAS1.physics.ox.ac.uk> <54AAFAD3.2080102@physics.ox.ac.uk> <6c2cbb1f096c4cd29c49a0dbfeaec934@EXCHANGE-CAS2.physics.ox.ac.uk> <54AB138F.1010406@physics.ox.ac.uk> <54AC0528.6020302@physics.ox.ac.uk> Message-ID: On Tue, Jan 6, 2015 at 8:54 AM, Irwin Zaid wrote: > Okay, an update on this. > > 2) This is trickier and, unfortunately, still not working. We are already > adding -fPIC to CMAKE_CXX_FLAGS, should that not be enough? I also tried > adding it to both CMAKE_CXX_FLAGS_DEBUG and CMAKE_CXX_FLAGS_RELEASE, with > no effect. > > Looking into FindCUDA.CMake at CUDA_LINK_SEPARABLE_COMPILATION_OBJECTS, I > find code very similar to what you are describing. Are you saying that in > addition to what is below, we need to add what you proposed? This is what I > see. > > -- > > It can be put here (before this foreach). > foreach(config ${CUDA_configuration_types}) > string(TOUPPER ${config} config_upper) > # Add config specific flags > foreach(f ${CUDA_NVCC_FLAGS_${config_upper}}) > list(APPEND config_specific_flags $<$:${f}>) > endforeach() > set(important_host_flags) > _cuda_get_important_host_flags(important_host_flags > ${CMAKE_${CUDA_C_OR_CXX}_FLAGS_${config_upper}}) > foreach(f ${important_host_flags}) > list(APPEND flags $<$:-Xcompiler> > $<$:${f}>) > endforeach() > endforeach() > > Or it can be put here (or after the foreach). I'm concerned that the flag didn't show up after adding it to the _DEBUG or _RELEASE variants. If you could add a few message commands around that might help see what is going on. The flag needs to be propagated. You could sprinkle a few commands like this: message("going to run COMMAND ${CUDA_NVCC_EXECUTABLE} ${nvcc_flags} -dlink ${object_files} -o ${output_file} ${flags}") -------------- next part -------------- An HTML attachment was scrubbed... URL: From irwin.zaid at physics.ox.ac.uk Tue Jan 6 12:05:51 2015 From: irwin.zaid at physics.ox.ac.uk (Irwin Zaid) Date: Tue, 6 Jan 2015 17:05:51 +0000 Subject: [CMake] FindCUDA ignores project dependencies when separable compilation is on In-Reply-To: <51d0f76d2f384f3ca5578a7697787274@EXCHANGE-CAS2.physics.ox.ac.uk> References: <4634e484e7954171a22b8bebc07ae578@EXCHANGE-CAS1.physics.ox.ac.uk> <54AA8449.70404@physics.ox.ac.uk> <24de6f36f39c40caaf533f87173c6f83@EXCHANGE-CAS1.physics.ox.ac.uk> <54AAFAD3.2080102@physics.ox.ac.uk> <6c2cbb1f096c4cd29c49a0dbfeaec934@EXCHANGE-CAS2.physics.ox.ac.uk> <54AB138F.1010406@physics.ox.ac.uk> <54AC0528.6020302@physics.ox.ac.uk> <51d0f76d2f384f3ca5578a7697787274@EXCHANGE-CAS2.physics.ox.ac.uk> Message-ID: <54AC15EF.9000800@physics.ox.ac.uk> Right, when I modify FindCUDA.cmake as you describe everything works. So that's good. Without doing that, I still don't see CMAKE_CXX_FLAGS_DEBUG propagating its flags to the intermediate link file. Did you mean to put message commands into CUDA_LINK_SEPARABLE_COMPILATION_OBJECTS itself? When I put them into my main CMakeLists.txt, nothing is printed for ${nvcc_flags} or the other variables. James Bigler wrote: > On Tue, Jan 6, 2015 at 8:54 AM, Irwin Zaid > > wrote: > > Okay, an update on this. > > 2) This is trickier and, unfortunately, still not working. We are > already adding -fPIC to CMAKE_CXX_FLAGS, should that not be > enough? I also tried adding it to both CMAKE_CXX_FLAGS_DEBUG and > CMAKE_CXX_FLAGS_RELEASE, with no effect. > > Looking into FindCUDA.CMake at > CUDA_LINK_SEPARABLE___COMPILATION_OBJECTS, I find code very > similar to what you are describing. Are you saying that in > addition to what is below, we need to add what you proposed? This > is what I see. > > -- > > > It can be put here (before this foreach). > > foreach(config ${CUDA_configuration_types}) > string(TOUPPER ${config} config_upper) > # Add config specific flags > foreach(f ${CUDA_NVCC_FLAGS_${config___upper}}) > list(APPEND config_specific_flags $<$:${f}>) > endforeach() > set(important_host_flags) > _cuda_get_important_host___flags(important_host_flags > ${CMAKE_${CUDA_C_OR_CXX}___FLAGS_${config_upper}}) > foreach(f ${important_host_flags}) > list(APPEND flags $<$:-__Xcompiler> > $<$:${f}>) > endforeach() > endforeach() > > > Or it can be put here (or after the foreach). > > I'm concerned that the flag didn't show up after adding it to the > _DEBUG or _RELEASE variants. If you could add a few message commands > around that might help see what is going on. The flag needs to be > propagated. > > You could sprinkle a few commands like this: > message("going to run COMMAND ${CUDA_NVCC_EXECUTABLE} ${nvcc_flags} > -dlink ${object_files} -o ${output_file} > ${flags}") > > From jamesbigler at gmail.com Tue Jan 6 12:22:40 2015 From: jamesbigler at gmail.com (James Bigler) Date: Tue, 6 Jan 2015 10:22:40 -0700 Subject: [CMake] FindCUDA ignores project dependencies when separable compilation is on In-Reply-To: <54AC15EF.9000800@physics.ox.ac.uk> References: <4634e484e7954171a22b8bebc07ae578@EXCHANGE-CAS1.physics.ox.ac.uk> <54AA8449.70404@physics.ox.ac.uk> <24de6f36f39c40caaf533f87173c6f83@EXCHANGE-CAS1.physics.ox.ac.uk> <54AAFAD3.2080102@physics.ox.ac.uk> <6c2cbb1f096c4cd29c49a0dbfeaec934@EXCHANGE-CAS2.physics.ox.ac.uk> <54AB138F.1010406@physics.ox.ac.uk> <54AC0528.6020302@physics.ox.ac.uk> <51d0f76d2f384f3ca5578a7697787274@EXCHANGE-CAS2.physics.ox.ac.uk> <54AC15EF.9000800@physics.ox.ac.uk> Message-ID: I meant putting messages into FindCUDA.cmake itself. Only certain flags are propagated for the intermediate link file compilation, because I've had a lot of trouble over the years for propagating all the host flags. This set of flags is filtered by the function _cuda_get_important_host_flags. Right now only the CMAKE_CXX_FLAGS_*CONFIG* are being processed. None of the flags in the configuration free variable are passed. That was the "patch" I wanted you to try. Why -fPIC in the configuration specific CMAKE_CXX_FLAGS wasn't working, I'm not sure. The code is there to do it. On Tue, Jan 6, 2015 at 10:05 AM, Irwin Zaid wrote: > Right, when I modify FindCUDA.cmake as you describe everything works. So > that's good. > > Without doing that, I still don't see CMAKE_CXX_FLAGS_DEBUG propagating > its flags to the intermediate link file. Did you mean to put message > commands into CUDA_LINK_SEPARABLE_COMPILATION_OBJECTS itself? When I put > them into my main CMakeLists.txt, nothing is printed for ${nvcc_flags} or > the other variables. > > James Bigler wrote: > >> On Tue, Jan 6, 2015 at 8:54 AM, Irwin Zaid > > wrote: >> >> Okay, an update on this. >> >> 2) This is trickier and, unfortunately, still not working. We are >> already adding -fPIC to CMAKE_CXX_FLAGS, should that not be >> enough? I also tried adding it to both CMAKE_CXX_FLAGS_DEBUG and >> CMAKE_CXX_FLAGS_RELEASE, with no effect. >> >> Looking into FindCUDA.CMake at >> CUDA_LINK_SEPARABLE___COMPILATION_OBJECTS, I find code very >> similar to what you are describing. Are you saying that in >> addition to what is below, we need to add what you proposed? This >> is what I see. >> >> -- >> >> >> It can be put here (before this foreach). >> >> foreach(config ${CUDA_configuration_types}) >> string(TOUPPER ${config} config_upper) >> # Add config specific flags >> foreach(f ${CUDA_NVCC_FLAGS_${config___upper}}) >> list(APPEND config_specific_flags $<$:${f}>) >> endforeach() >> set(important_host_flags) >> _cuda_get_important_host___flags(important_host_flags >> ${CMAKE_${CUDA_C_OR_CXX}___FLAGS_${config_upper}}) >> foreach(f ${important_host_flags}) >> list(APPEND flags $<$:-__Xcompiler> >> $<$:${f}>) >> endforeach() >> endforeach() >> >> >> Or it can be put here (or after the foreach). >> >> I'm concerned that the flag didn't show up after adding it to the _DEBUG >> or _RELEASE variants. If you could add a few message commands around that >> might help see what is going on. The flag needs to be propagated. >> >> You could sprinkle a few commands like this: >> message("going to run COMMAND ${CUDA_NVCC_EXECUTABLE} ${nvcc_flags} >> -dlink ${object_files} -o ${output_file} >> ${flags}") >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From braden at endoframe.com Tue Jan 6 12:34:50 2015 From: braden at endoframe.com (Braden McDaniel) Date: Tue, 06 Jan 2015 12:34:50 -0500 Subject: [CMake] Get the BINARY_DIR for a target? Message-ID: <1420565690.5364.4.camel@endoframe.com> Are there any properties on a target that I can query to get whatever was the CMAKE_CURRENT_BINARY_DIR when the target was defined? I'm aware of the LOCATION property; however, its generator-specific nature makes teasing the non-generator-specific part out of it rather challenging (without some other information about the target definition's location in the source tree, which is specifically what I'm trying to avoid). FWIW, I'm writing a function that takes a list of targets as input. -- Braden McDaniel From irwin.zaid at physics.ox.ac.uk Tue Jan 6 13:29:01 2015 From: irwin.zaid at physics.ox.ac.uk (Irwin Zaid) Date: Tue, 6 Jan 2015 18:29:01 +0000 Subject: [CMake] FindCUDA ignores project dependencies when separable compilation is on In-Reply-To: <6e226ac20e2d46a4805c68f614fd8c6b@EXCHANGE-CAS1.physics.ox.ac.uk> References: <4634e484e7954171a22b8bebc07ae578@EXCHANGE-CAS1.physics.ox.ac.uk> <54AA8449.70404@physics.ox.ac.uk> <24de6f36f39c40caaf533f87173c6f83@EXCHANGE-CAS1.physics.ox.ac.uk> <54AAFAD3.2080102@physics.ox.ac.uk> <6c2cbb1f096c4cd29c49a0dbfeaec934@EXCHANGE-CAS2.physics.ox.ac.uk> <54AB138F.1010406@physics.ox.ac.uk> <54AC0528.6020302@physics.ox.ac.uk> <51d0f76d2f384f3ca5578a7697787274@EXCHANGE-CAS2.physics.ox.ac.uk> <54AC15EF.9000800@physics.ox.ac.uk> <6e226ac20e2d46a4805c68f614fd8c6b@EXCHANGE-CAS1.physics.ox.ac.uk> Message-ID: <54AC296D.7020504@physics.ox.ac.uk> Okay, so I've gone and put the messages into FindCUDA.cmake. I specifically put them right before and after the foreach() in CUDA_LINK_SEPARARABLE_COMPILATION_OBJECTS. The output is the following. Is "$<$:-Xcompiler>;$<$:-fPIC>" supposed to be that way? That looks weird. -- going to run COMMAND /usr/local/cuda/bin/nvcc -m64;-ccbin;"/usr/bin/cc" -dlink /home/irwin/Repositories/libdynd/build/CMakeFiles/libdynd.dir/src/dynd/kernels/./libdynd_generated_assignment_kernels.cu.o;/home/irwin/Repositories/libdynd/build/CMakeFiles/libdynd.dir/src/dynd/func/./libdynd_generated_arithmetic.cu.o;/home/irwin/Repositories/libdynd/build/CMakeFiles/libdynd.dir/src/dynd/func/./libdynd_generated_elwise.cu.o;/home/irwin/Repositories/libdynd/build/CMakeFiles/libdynd.dir/src/dynd/kernels/./libdynd_generated_ckernel_builder.cu.o;/home/irwin/Repositories/libdynd/build/CMakeFiles/libdynd.dir/src/dynd/types/./libdynd_generated_dynd_complex.cu.o;/home/irwin/Repositories/libdynd/build/CMakeFiles/libdynd.dir/src/dynd/types/./libdynd_generated_dynd_float16.cu.o;/home/irwin/Repositories/libdynd/build/CMakeFiles/libdynd.dir/src/dynd/types/./libdynd_generated_dynd_float128.cu.o;/home/irwin/Repositories/libdynd/build/CMakeFiles/libdynd.dir/src/dynd/types/./libdynd_generated_dynd_int128.cu.o;/home/irwin/Repositories/libdynd/build/CMakeFiles/libdynd.dir/src/d ynd/types/./libdynd_generated_dynd_uint128.cu.o -o /home/irwin/Repositories/libdynd/build/CMakeFiles/libdynd.dir/./libdynd_intermediate_link.o going to run COMMAND /usr/local/cuda/bin/nvcc -m64;-ccbin;"/usr/bin/cc" -dlink /home/irwin/Repositories/libdynd/build/CMakeFiles/libdynd.dir/src/dynd/kernels/./libdynd_generated_assignment_kernels.cu.o;/home/irwin/Repositories/libdynd/build/CMakeFiles/libdynd.dir/src/dynd/func/./libdynd_generated_arithmetic.cu.o;/home/irwin/Repositories/libdynd/build/CMakeFiles/libdynd.dir/src/dynd/func/./libdynd_generated_elwise.cu.o;/home/irwin/Repositories/libdynd/build/CMakeFiles/libdynd.dir/src/dynd/kernels/./libdynd_generated_ckernel_builder.cu.o;/home/irwin/Repositories/libdynd/build/CMakeFiles/libdynd.dir/src/dynd/types/./libdynd_generated_dynd_complex.cu.o;/home/irwin/Repositories/libdynd/build/CMakeFiles/libdynd.dir/src/dynd/types/./libdynd_generated_dynd_float16.cu.o;/home/irwin/Repositories/libdynd/build/CMakeFiles/libdynd.dir/src/dynd/types/./libdynd_generated_dynd_float128.cu.o;/home/irwin/Repositories/libdynd/build/CMakeFiles/libdynd.dir/src/dynd/types/./libdynd_generated_dynd_int128.cu.o;/home/irwin/Repositories/libdynd/build/CMakeFiles/libdynd.dir/src/d ynd/types/./libdynd_generated_dynd_uint128.cu.o -o /home/irwin/Repositories/libdynd/build/CMakeFiles/libdynd.dir/./libdynd_intermediate_link.o $<$:-Xcompiler>;$<$:-fPIC> going to run COMMAND /usr/local/cuda/bin/nvcc -m64;-ccbin;"/usr/bin/cc" -dlink /home/irwin/Repositories/libdynd/build/tests/CMakeFiles/test_libdynd.dir/func/./test_libdynd_generated_test_apply.cu.o;/home/irwin/Repositories/libdynd/build/tests/CMakeFiles/test_libdynd.dir/func/./test_libdynd_generated_test_lift_arrfunc.cu.o -o /home/irwin/Repositories/libdynd/build/tests/CMakeFiles/test_libdynd.dir/./test_libdynd_intermediate_link.o going to run COMMAND /usr/local/cuda/bin/nvcc -m64;-ccbin;"/usr/bin/cc" -dlink /home/irwin/Repositories/libdynd/build/tests/CMakeFiles/test_libdynd.dir/func/./test_libdynd_generated_test_apply.cu.o;/home/irwin/Repositories/libdynd/build/tests/CMakeFiles/test_libdynd.dir/func/./test_libdynd_generated_test_lift_arrfunc.cu.o -o /home/irwin/Repositories/libdynd/build/tests/CMakeFiles/test_libdynd.dir/./test_libdynd_intermediate_link.o $<$:-Xcompiler>;$<$:-fPIC> James Bigler wrote: > I meant putting messages into FindCUDA.cmake itself. > > Only certain flags are propagated for the intermediate link file > compilation, because I've had a lot of trouble over the years for > propagating all the host flags. This set of flags is filtered by the > function _cuda_get_important_host_flags. Right now only the > CMAKE_CXX_FLAGS_*CONFIG* are being processed. None of the flags in the > configuration free variable are passed. That was the "patch" I wanted > you to try. Why -fPIC in the configuration specific CMAKE_CXX_FLAGS > wasn't working, I'm not sure. The code is there to do it. > > On Tue, Jan 6, 2015 at 10:05 AM, Irwin Zaid > wrote: > > Right, when I modify FindCUDA.cmake as you describe everything > works. So that's good. > > Without doing that, I still don't see CMAKE_CXX_FLAGS_DEBUG > propagating its flags to the intermediate link file. Did you mean to > put message commands into CUDA_LINK_SEPARABLE___COMPILATION_OBJECTS > itself? When I put them into my main CMakeLists.txt, nothing is > printed for ${nvcc_flags} or the other variables. > > James Bigler wrote: > > On Tue, Jan 6, 2015 at 8:54 AM, Irwin Zaid > > >> wrote: > > Okay, an update on this. > > 2) This is trickier and, unfortunately, still not working. We are > already adding -fPIC to CMAKE_CXX_FLAGS, should that not be > enough? I also tried adding it to both CMAKE_CXX_FLAGS_DEBUG and > CMAKE_CXX_FLAGS_RELEASE, with no effect. > > Looking into FindCUDA.CMake at > CUDA_LINK_SEPARABLE_____COMPILATION_OBJECTS, I find code very > similar to what you are describing. Are you saying that in > addition to what is below, we need to add what you proposed? This > is what I see. > > -- > > > It can be put here (before this foreach). > > foreach(config ${CUDA_configuration_types}) > string(TOUPPER ${config} config_upper) > # Add config specific flags > foreach(f ${CUDA_NVCC_FLAGS_${config_____upper}}) > list(APPEND config_specific_flags $<$:${f}>) > endforeach() > set(important_host_flags) > _cuda_get_important_host_____flags(important_host_flags > ${CMAKE_${CUDA_C_OR_CXX}_____FLAGS_${config_upper}}) > foreach(f ${important_host_flags}) > list(APPEND flags $<$:-____Xcompiler> > $<$:${f}>) > endforeach() > endforeach() > > > Or it can be put here (or after the foreach). > > I'm concerned that the flag didn't show up after adding it to > the _DEBUG or _RELEASE variants. If you could add a few message > commands around that might help see what is going on. The flag > needs to be propagated. > > You could sprinkle a few commands like this: > message("going to run COMMAND ${CUDA_NVCC_EXECUTABLE} > ${nvcc_flags} -dlink ${object_files} -o ${output_file} > ${flags}") > > > From jamesbigler at gmail.com Tue Jan 6 15:00:53 2015 From: jamesbigler at gmail.com (James Bigler) Date: Tue, 6 Jan 2015 13:00:53 -0700 Subject: [CMake] FindCUDA ignores project dependencies when separable compilation is on In-Reply-To: <54AC296D.7020504@physics.ox.ac.uk> References: <4634e484e7954171a22b8bebc07ae578@EXCHANGE-CAS1.physics.ox.ac.uk> <54AA8449.70404@physics.ox.ac.uk> <24de6f36f39c40caaf533f87173c6f83@EXCHANGE-CAS1.physics.ox.ac.uk> <54AAFAD3.2080102@physics.ox.ac.uk> <6c2cbb1f096c4cd29c49a0dbfeaec934@EXCHANGE-CAS2.physics.ox.ac.uk> <54AB138F.1010406@physics.ox.ac.uk> <54AC0528.6020302@physics.ox.ac.uk> <51d0f76d2f384f3ca5578a7697787274@EXCHANGE-CAS2.physics.ox.ac.uk> <54AC15EF.9000800@physics.ox.ac.uk> <6e226ac20e2d46a4805c68f614fd8c6b@EXCHANGE-CAS1.physics.ox.ac.uk> <54AC296D.7020504@physics.ox.ac.uk> Message-ID: James > On Jan 6, 2015, at 11:29 AM, Irwin Zaid wrote: > > Okay, so I've gone and put the messages into FindCUDA.cmake. I specifically put them right before and after the foreach() in CUDA_LINK_SEPARARABLE_COMPILATION_OBJECTS. The output is the following. > > Is "$<$:-Xcompiler>;$<$:-fPIC>" supposed to be that way? That looks weird. > Yeah. That looks right. It means the argument will only be run when the build configuration matches DEBUG. This is less exciting for Makefiles builds since there is only one configuration preset at a time, but for things like Visual Studio where you have multiple build configs from a single CMake configure this makes a custom command for each without having to rely on scripts to dispatch the correct command (that's how the rest of FindCUDA works by the way). As far as the rest of these, I'm concerned the fPIC flag comes and goes. Perhaps something is modifying the flags. Do the commands with fPIC actually get run with fPIC (use make VERBOSE=1)? > -- > > going to run COMMAND /usr/local/cuda/bin/nvcc -m64;-ccbin;"/usr/bin/cc" -dlink /home/irwin/Repositories/libdynd/build/CMakeFiles/libdynd.dir/src/dynd/kernels/./libdynd_generated_assignment_kernels.cu.o;/home/irwin/Repositories/libdynd/build/CMakeFiles/libdynd.dir/src/dynd/func/./libdynd_generated_arithmetic.cu.o;/home/irwin/Repositories/libdynd/build/CMakeFiles/libdynd.dir/src/dynd/func/./libdynd_generated_elwise.cu.o;/home/irwin/Repositories/libdynd/build/CMakeFiles/libdynd.dir/src/dynd/kernels/./libdynd_generated_ckernel_builder.cu.o;/home/irwin/Repositories/libdynd/build/CMakeFiles/libdynd.dir/src/dynd/types/./libdynd_generated_dynd_complex.cu.o;/home/irwin/Repositories/libdynd/build/CMakeFiles/libdynd.dir/src/dynd/types/./libdynd_generated_dynd_float16.cu.o;/home/irwin/Repositories/libdynd/build/CMakeFiles/libdynd.dir/src/dynd/types/./libdynd_generated_dynd_float128.cu.o;/home/irwin/Repositories/libdynd/build/CMakeFiles/libdynd.dir/src/dynd/types/./libdynd_generated_dynd_int128.cu.o;/home/irwin/Repositories/libdynd/build/CMakeFiles/libdynd.dir/src/d > ynd/types/./libdynd_generated_dynd_uint128.cu.o -o /home/irwin/Repositories/libdynd/build/CMakeFiles/libdynd.dir/./libdynd_intermediate_link.o > > going to run COMMAND /usr/local/cuda/bin/nvcc -m64;-ccbin;"/usr/bin/cc" -dlink /home/irwin/Repositories/libdynd/build/CMakeFiles/libdynd.dir/src/dynd/kernels/./libdynd_generated_assignment_kernels.cu.o;/home/irwin/Repositories/libdynd/build/CMakeFiles/libdynd.dir/src/dynd/func/./libdynd_generated_arithmetic.cu.o;/home/irwin/Repositories/libdynd/build/CMakeFiles/libdynd.dir/src/dynd/func/./libdynd_generated_elwise.cu.o;/home/irwin/Repositories/libdynd/build/CMakeFiles/libdynd.dir/src/dynd/kernels/./libdynd_generated_ckernel_builder.cu.o;/home/irwin/Repositories/libdynd/build/CMakeFiles/libdynd.dir/src/dynd/types/./libdynd_generated_dynd_complex.cu.o;/home/irwin/Repositories/libdynd/build/CMakeFiles/libdynd.dir/src/dynd/types/./libdynd_generated_dynd_float16.cu.o;/home/irwin/Repositories/libdynd/build/CMakeFiles/libdynd.dir/src/dynd/types/./libdynd_generated_dynd_float128.cu.o;/home/irwin/Repositories/libdynd/build/CMakeFiles/libdynd.dir/src/dynd/types/./libdynd_generated_dynd_int128.cu.o;/home/irwin/Repositories/libdynd/build/CMakeFiles/libdynd.dir/src/d > ynd/types/./libdynd_generated_dynd_uint128.cu.o -o /home/irwin/Repositories/libdynd/build/CMakeFiles/libdynd.dir/./libdynd_intermediate_link.o $<$:-Xcompiler>;$<$:-fPIC> > going to run COMMAND /usr/local/cuda/bin/nvcc -m64;-ccbin;"/usr/bin/cc" -dlink /home/irwin/Repositories/libdynd/build/tests/CMakeFiles/test_libdynd.dir/func/./test_libdynd_generated_test_apply.cu.o;/home/irwin/Repositories/libdynd/build/tests/CMakeFiles/test_libdynd.dir/func/./test_libdynd_generated_test_lift_arrfunc.cu.o -o /home/irwin/Repositories/libdynd/build/tests/CMakeFiles/test_libdynd.dir/./test_libdynd_intermediate_link.o > > going to run COMMAND /usr/local/cuda/bin/nvcc -m64;-ccbin;"/usr/bin/cc" -dlink /home/irwin/Repositories/libdynd/build/tests/CMakeFiles/test_libdynd.dir/func/./test_libdynd_generated_test_apply.cu.o;/home/irwin/Repositories/libdynd/build/tests/CMakeFiles/test_libdynd.dir/func/./test_libdynd_generated_test_lift_arrfunc.cu.o -o /home/irwin/Repositories/libdynd/build/tests/CMakeFiles/test_libdynd.dir/./test_libdynd_intermediate_link.o $<$:-Xcompiler>;$<$:-fPIC> > > James Bigler wrote: >> I meant putting messages into FindCUDA.cmake itself. >> >> Only certain flags are propagated for the intermediate link file >> compilation, because I've had a lot of trouble over the years for >> propagating all the host flags. This set of flags is filtered by the >> function _cuda_get_important_host_flags. Right now only the >> CMAKE_CXX_FLAGS_*CONFIG* are being processed. None of the flags in the >> configuration free variable are passed. That was the "patch" I wanted >> you to try. Why -fPIC in the configuration specific CMAKE_CXX_FLAGS >> wasn't working, I'm not sure. The code is there to do it. >> >> On Tue, Jan 6, 2015 at 10:05 AM, Irwin Zaid > > wrote: >> >> Right, when I modify FindCUDA.cmake as you describe everything >> works. So that's good. >> >> Without doing that, I still don't see CMAKE_CXX_FLAGS_DEBUG >> propagating its flags to the intermediate link file. Did you mean to >> put message commands into CUDA_LINK_SEPARABLE___COMPILATION_OBJECTS >> itself? When I put them into my main CMakeLists.txt, nothing is >> printed for ${nvcc_flags} or the other variables. >> >> James Bigler wrote: >> >> On Tue, Jan 6, 2015 at 8:54 AM, Irwin Zaid >> > >> > >> wrote: >> >> Okay, an update on this. >> >> 2) This is trickier and, unfortunately, still not working. We are >> already adding -fPIC to CMAKE_CXX_FLAGS, should that not be >> enough? I also tried adding it to both CMAKE_CXX_FLAGS_DEBUG and >> CMAKE_CXX_FLAGS_RELEASE, with no effect. >> >> Looking into FindCUDA.CMake at >> CUDA_LINK_SEPARABLE_____COMPILATION_OBJECTS, I find code very >> similar to what you are describing. Are you saying that in >> addition to what is below, we need to add what you proposed? This >> is what I see. >> >> -- >> >> >> It can be put here (before this foreach). >> >> foreach(config ${CUDA_configuration_types}) >> string(TOUPPER ${config} config_upper) >> # Add config specific flags >> foreach(f ${CUDA_NVCC_FLAGS_${config_____upper}}) >> list(APPEND config_specific_flags $<$:${f}>) >> endforeach() >> set(important_host_flags) >> _cuda_get_important_host_____flags(important_host_flags >> ${CMAKE_${CUDA_C_OR_CXX}_____FLAGS_${config_upper}}) >> foreach(f ${important_host_flags}) >> list(APPEND flags $<$:-____Xcompiler> >> $<$:${f}>) >> endforeach() >> endforeach() >> >> >> Or it can be put here (or after the foreach). >> >> I'm concerned that the flag didn't show up after adding it to >> the _DEBUG or _RELEASE variants. If you could add a few message >> commands around that might help see what is going on. The flag >> needs to be propagated. >> >> You could sprinkle a few commands like this: >> message("going to run COMMAND ${CUDA_NVCC_EXECUTABLE} >> ${nvcc_flags} -dlink ${object_files} -o ${output_file} >> ${flags}") >> >> >> From irwin.zaid at physics.ox.ac.uk Tue Jan 6 15:08:57 2015 From: irwin.zaid at physics.ox.ac.uk (Irwin Zaid) Date: Tue, 6 Jan 2015 20:08:57 +0000 Subject: [CMake] FindCUDA ignores project dependencies when separable compilation is on In-Reply-To: References: <4634e484e7954171a22b8bebc07ae578@EXCHANGE-CAS1.physics.ox.ac.uk> <54AA8449.70404@physics.ox.ac.uk> <24de6f36f39c40caaf533f87173c6f83@EXCHANGE-CAS1.physics.ox.ac.uk> <54AAFAD3.2080102@physics.ox.ac.uk> <6c2cbb1f096c4cd29c49a0dbfeaec934@EXCHANGE-CAS2.physics.ox.ac.uk> <54AB138F.1010406@physics.ox.ac.uk> <54AC0528.6020302@physics.ox.ac.uk> <51d0f76d2f384f3ca5578a7697787274@EXCHANGE-CAS2.physics.ox.ac.uk> <54AC15EF.9000800@physics.ox.ac.uk> <6e226ac20e2d46a4805c68f614fd8c6b@EXCHANGE-CAS1.physics.ox.ac.uk> <54AC296D.7020504@physics.ox.ac.uk> Message-ID: <54AC40D9.1000004@physics.ox.ac.uk> I just double-checked. The -fPIC is definitely there for each individual object file, but not for the *_intermediate_link.o. Irwin James Bigler wrote: > > > James > >> On Jan 6, 2015, at 11:29 AM, Irwin Zaid wrote: >> >> Okay, so I've gone and put the messages into FindCUDA.cmake. I specifically put them right before and after the foreach() in CUDA_LINK_SEPARARABLE_COMPILATION_OBJECTS. The output is the following. >> >> Is "$<$:-Xcompiler>;$<$:-fPIC>" supposed to be that way? That looks weird. >> > > Yeah. That looks right. It means the argument will only be run when the build configuration matches DEBUG. This is less exciting for Makefiles builds since there is only one configuration preset at a time, but for things like Visual Studio where you have multiple build configs from a single CMake configure this makes a custom command for each without having to rely on scripts to dispatch the correct command (that's how the rest of FindCUDA works by the way). > > As far as the rest of these, I'm concerned the fPIC flag comes and goes. Perhaps something is modifying the flags. Do the commands with fPIC actually get run with fPIC (use make VERBOSE=1)? > >> -- >> >> going to run COMMAND /usr/local/cuda/bin/nvcc -m64;-ccbin;"/usr/bin/cc" -dlink /home/irwin/Repositories/libdynd/build/CMakeFiles/libdynd.dir/src/dynd/kernels/./libdynd_generated_assignment_kernels.cu.o;/home/irwin/Repositories/libdynd/build/CMakeFiles/libdynd.dir/src/dynd/func/./libdynd_generated_arithmetic.cu.o;/home/irwin/Repositories/libdynd/build/CMakeFiles/libdynd.dir/src/dynd/func/./libdynd_generated_elwise.cu.o;/home/irwin/Repositories/libdynd/build/CMakeFiles/libdynd.dir/src/dynd/kernels/./libdynd_generated_ckernel_builder.cu.o;/home/irwin/Repositories/libdynd/build/CMakeFiles/libdynd.dir/src/dynd/types/./libdynd_generated_dynd_complex.cu.o;/home/irwin/Repositories/libdynd/build/CMakeFiles/libdynd.dir/src/dynd/types/./libdynd_generated_dynd_float16.cu.o;/home/irwin/Repositories/libdynd/build/CMakeFiles/libdynd.dir/src/dynd/types/./libdynd_generated_dynd_float128.cu.o;/home/irwin/Repositories/libdynd/build/CMakeFiles/libdynd.dir/src/dynd/types/./libdynd_generated_dy nd_int128.cu.o;/home/irwin/Repositories/libdynd/build/CMakeFiles/libdynd.dir/src/d >> ynd/types/./libdynd_generated_dynd_uint128.cu.o -o /home/irwin/Repositories/libdynd/build/CMakeFiles/libdynd.dir/./libdynd_intermediate_link.o >> >> going to run COMMAND /usr/local/cuda/bin/nvcc -m64;-ccbin;"/usr/bin/cc" -dlink /home/irwin/Repositories/libdynd/build/CMakeFiles/libdynd.dir/src/dynd/kernels/./libdynd_generated_assignment_kernels.cu.o;/home/irwin/Repositories/libdynd/build/CMakeFiles/libdynd.dir/src/dynd/func/./libdynd_generated_arithmetic.cu.o;/home/irwin/Repositories/libdynd/build/CMakeFiles/libdynd.dir/src/dynd/func/./libdynd_generated_elwise.cu.o;/home/irwin/Repositories/libdynd/build/CMakeFiles/libdynd.dir/src/dynd/kernels/./libdynd_generated_ckernel_builder.cu.o;/home/irwin/Repositories/libdynd/build/CMakeFiles/libdynd.dir/src/dynd/types/./libdynd_generated_dynd_complex.cu.o;/home/irwin/Repositories/libdynd/build/CMakeFiles/libdynd.dir/src/dynd/types/./libdynd_generated_dynd_float16.cu.o;/home/irwin/Repositories/libdynd/build/CMakeFiles/libdynd.dir/src/dynd/types/./libdynd_generated_dynd_float128.cu.o;/home/irwin/Repositories/libdynd/build/CMakeFiles/libdynd.dir/src/dynd/types/./libdynd_generated_dy nd_int128.cu.o;/home/irwin/Repositories/libdynd/build/CMakeFiles/libdynd.dir/src/d >> ynd/types/./libdynd_generated_dynd_uint128.cu.o -o /home/irwin/Repositories/libdynd/build/CMakeFiles/libdynd.dir/./libdynd_intermediate_link.o $<$:-Xcompiler>;$<$:-fPIC> >> going to run COMMAND /usr/local/cuda/bin/nvcc -m64;-ccbin;"/usr/bin/cc" -dlink /home/irwin/Repositories/libdynd/build/tests/CMakeFiles/test_libdynd.dir/func/./test_libdynd_generated_test_apply.cu.o;/home/irwin/Repositories/libdynd/build/tests/CMakeFiles/test_libdynd.dir/func/./test_libdynd_generated_test_lift_arrfunc.cu.o -o /home/irwin/Repositories/libdynd/build/tests/CMakeFiles/test_libdynd.dir/./test_libdynd_intermediate_link.o >> >> going to run COMMAND /usr/local/cuda/bin/nvcc -m64;-ccbin;"/usr/bin/cc" -dlink /home/irwin/Repositories/libdynd/build/tests/CMakeFiles/test_libdynd.dir/func/./test_libdynd_generated_test_apply.cu.o;/home/irwin/Repositories/libdynd/build/tests/CMakeFiles/test_libdynd.dir/func/./test_libdynd_generated_test_lift_arrfunc.cu.o -o /home/irwin/Repositories/libdynd/build/tests/CMakeFiles/test_libdynd.dir/./test_libdynd_intermediate_link.o $<$:-Xcompiler>;$<$:-fPIC> >> >> James Bigler wrote: >>> I meant putting messages into FindCUDA.cmake itself. >>> >>> Only certain flags are propagated for the intermediate link file >>> compilation, because I've had a lot of trouble over the years for >>> propagating all the host flags. This set of flags is filtered by the >>> function _cuda_get_important_host_flags. Right now only the >>> CMAKE_CXX_FLAGS_*CONFIG* are being processed. None of the flags in the >>> configuration free variable are passed. That was the "patch" I wanted >>> you to try. Why -fPIC in the configuration specific CMAKE_CXX_FLAGS >>> wasn't working, I'm not sure. The code is there to do it. >>> >>> On Tue, Jan 6, 2015 at 10:05 AM, Irwin Zaid>> > wrote: >>> >>> Right, when I modify FindCUDA.cmake as you describe everything >>> works. So that's good. >>> >>> Without doing that, I still don't see CMAKE_CXX_FLAGS_DEBUG >>> propagating its flags to the intermediate link file. Did you mean to >>> put message commands into CUDA_LINK_SEPARABLE___COMPILATION_OBJECTS >>> itself? When I put them into my main CMakeLists.txt, nothing is >>> printed for ${nvcc_flags} or the other variables. >>> >>> James Bigler wrote: >>> >>> On Tue, Jan 6, 2015 at 8:54 AM, Irwin Zaid >>> >> >>> >> >> wrote: >>> >>> Okay, an update on this. >>> >>> 2) This is trickier and, unfortunately, still not working. We are >>> already adding -fPIC to CMAKE_CXX_FLAGS, should that not be >>> enough? I also tried adding it to both CMAKE_CXX_FLAGS_DEBUG and >>> CMAKE_CXX_FLAGS_RELEASE, with no effect. >>> >>> Looking into FindCUDA.CMake at >>> CUDA_LINK_SEPARABLE_____COMPILATION_OBJECTS, I find code very >>> similar to what you are describing. Are you saying that in >>> addition to what is below, we need to add what you proposed? This >>> is what I see. >>> >>> -- >>> >>> >>> It can be put here (before this foreach). >>> >>> foreach(config ${CUDA_configuration_types}) >>> string(TOUPPER ${config} config_upper) >>> # Add config specific flags >>> foreach(f ${CUDA_NVCC_FLAGS_${config_____upper}}) >>> list(APPEND config_specific_flags $<$:${f}>) >>> endforeach() >>> set(important_host_flags) >>> _cuda_get_important_host_____flags(important_host_flags >>> ${CMAKE_${CUDA_C_OR_CXX}_____FLAGS_${config_upper}}) >>> foreach(f ${important_host_flags}) >>> list(APPEND flags $<$:-____Xcompiler> >>> $<$:${f}>) >>> endforeach() >>> endforeach() >>> >>> >>> Or it can be put here (or after the foreach). >>> >>> I'm concerned that the flag didn't show up after adding it to >>> the _DEBUG or _RELEASE variants. If you could add a few message >>> commands around that might help see what is going on. The flag >>> needs to be propagated. >>> >>> You could sprinkle a few commands like this: >>> message("going to run COMMAND ${CUDA_NVCC_EXECUTABLE} >>> ${nvcc_flags} -dlink ${object_files} -o ${output_file} >>> ${flags}") >>> >>> >>> From oliveridario89 at gmail.com Tue Jan 6 15:09:57 2015 From: oliveridario89 at gmail.com (Dario Oliveri) Date: Tue, 6 Jan 2015 21:09:57 +0100 Subject: [CMake] add_subdirectory cache configuration via cmake script Message-ID: How can I prevent variables cache pollution in CMAKE? My real problem is the following: I have library A and library B, both libraries have some cmake variable used to configure there and there and that's ok, but what when variables are semantically duplicated? Library A depends on Library B both libraries provide "CompileForLinux" cache variable, I want be able to just compile library A and check the checkbox for "CompileForLinux" just once. This example is the minimum of course, but it would be nice if there's someway to wrap variables of dependencies so that I can compile a library with less chance of "human error prone" misconfiguration and to provide final user of library A only the few real needed options/variables. Libray A is actually including library B using "add_subdirectory" So assume the following boolean cache variables: LIBA_STATIC LIBA_SHARED LIBA_OBJECT LIBB_STATIC LIBB_SHARED LIBB_OBJECT LIBA_EXCLUDE_MODULE1 LIBB_EXCLUDE_MODULE1 COMPILE_FOR_LINUX #from libA COMPILE_FOR_LINUX #from libB It would be nice letting LIB A to hide unecessary staff that can be configured by the cmake script without the user have to know it. Final expected list to be showed in Cmake-gui LIBA_STATIC # configure libB accordingly LIBA_SHARED LIBA_OBJECT LIBA_EXCLUDE_MODULE1 LIBB_EXCLUDE_MODULE1 #not hided by libA because necessary for final configuration COMPILE_FOR_LINUX #from libA I Hope you see how that can be tremendously usefulll especially in opensource cross-platform projects with many dependencies -------------- next part -------------- An HTML attachment was scrubbed... URL: From irwin.zaid at physics.ox.ac.uk Tue Jan 6 15:32:47 2015 From: irwin.zaid at physics.ox.ac.uk (Irwin Zaid) Date: Tue, 6 Jan 2015 20:32:47 +0000 Subject: [CMake] FindCUDA ignores project dependencies when separable compilation is on In-Reply-To: <8b196a38d5dc4badbce63d4d5f58a4ca@EXCHANGE-CAS1.physics.ox.ac.uk> References: <4634e484e7954171a22b8bebc07ae578@EXCHANGE-CAS1.physics.ox.ac.uk> <54AA8449.70404@physics.ox.ac.uk> <24de6f36f39c40caaf533f87173c6f83@EXCHANGE-CAS1.physics.ox.ac.uk> <54AAFAD3.2080102@physics.ox.ac.uk> <6c2cbb1f096c4cd29c49a0dbfeaec934@EXCHANGE-CAS2.physics.ox.ac.uk> <54AB138F.1010406@physics.ox.ac.uk> <54AC0528.6020302@physics.ox.ac.uk> <51d0f76d2f384f3ca5578a7697787274@EXCHANGE-CAS2.physics.ox.ac.uk> <54AC15EF.9000800@physics.ox.ac.uk> <6e226ac20e2d46a4805c68f614fd8c6b@EXCHANGE-CAS1.physics.ox.ac.uk> <54AC296D.7020504@physics.ox.ac.uk> <8b196a38d5dc4badbce63d4d5f58a4ca@EXCHANGE-CAS1.physics.ox.ac.uk> Message-ID: <54AC466F.5060103@physics.ox.ac.uk> Wait, hold on. The -fPIC does get passed to everything if I set the build mode to Debug by passing -DCMAKE_BUILD_TYPE=Debug to CMake. Is that what I should be doing? (Sorry about that, if yes.) If that's the case, what is the correct way to get -fPIC passed to the intermediate linking? Am I meant to always build in Debug mode just for that? Irwin Irwin Zaid wrote: > I just double-checked. The -fPIC is definitely there for each individual > object file, but not for the *_intermediate_link.o. > > Irwin > > James Bigler wrote: >> >> James >> >>> On Jan 6, 2015, at 11:29 AM, Irwin Zaid wrote: >>> >>> Okay, so I've gone and put the messages into FindCUDA.cmake. I specifically put them right before and after the foreach() in CUDA_LINK_SEPARARABLE_COMPILATION_OBJECTS. The output is the following. >>> >>> Is "$<$:-Xcompiler>;$<$:-fPIC>" supposed to be that way? That looks weird. >>> >> Yeah. That looks right. It means the argument will only be run when the build configuration matches DEBUG. This is less exciting for Makefiles builds since there is only one configuration preset at a time, but for things like Visual Studio where you have multiple build configs from a single CMake configure this makes a custom command for each without having to rely on scripts to dispatch the correct command (that's how the rest of FindCUDA works by the way). >> >> As far as the rest of these, I'm concerned the fPIC flag comes and goes. Perhaps something is modifying the flags. Do the commands with fPIC actually get run with fPIC (use make VERBOSE=1)? >> >>> -- >>> >>> going to run COMMAND /usr/local/cuda/bin/nvcc -m64;-ccbin;"/usr/bin/cc" -dlink /home/irwin/Repositories/libdynd/build/CMakeFiles/libdynd.dir/src/dynd/kernels/./libdynd_generated_assignment_kernels.cu.o;/home/irwin/Repositories/libdynd/build/CMakeFiles/libdynd.dir/src/dynd/func/./libdynd_generated_arithmetic.cu.o;/home/irwin/Repositories/libdynd/build/CMakeFiles/libdynd.dir/src/dynd/func/./libdynd_generated_elwise.cu.o;/home/irwin/Repositories/libdynd/build/CMakeFiles/libdynd.dir/src/dynd/kernels/./libdynd_generated_ckernel_builder.cu.o;/home/irwin/Repositories/libdynd/build/CMakeFiles/libdynd.dir/src/dynd/types/./libdynd_generated_dynd_complex.cu.o;/home/irwin/Repositories/libdynd/build/CMakeFiles/libdynd.dir/src/dynd/types/./libdynd_generated_dynd_float16.cu.o;/home/irwin/Repositories/libdynd/build/CMakeFiles/libdynd.dir/src/dynd/types/./libdynd_generated_dynd_float128.cu.o;/home/irwin/Repositories/libdynd/build/CMakeFiles/libdynd.dir/src/dynd/types/./libdynd_generated_d y > nd_int128.cu.o;/home/irwin/Repositories/libdynd/build/CMakeFiles/libdynd.dir/src/d >>> ynd/types/./libdynd_generated_dynd_uint128.cu.o -o /home/irwin/Repositories/libdynd/build/CMakeFiles/libdynd.dir/./libdynd_intermediate_link.o >>> >>> going to run COMMAND /usr/local/cuda/bin/nvcc -m64;-ccbin;"/usr/bin/cc" -dlink /home/irwin/Repositories/libdynd/build/CMakeFiles/libdynd.dir/src/dynd/kernels/./libdynd_generated_assignment_kernels.cu.o;/home/irwin/Repositories/libdynd/build/CMakeFiles/libdynd.dir/src/dynd/func/./libdynd_generated_arithmetic.cu.o;/home/irwin/Repositories/libdynd/build/CMakeFiles/libdynd.dir/src/dynd/func/./libdynd_generated_elwise.cu.o;/home/irwin/Repositories/libdynd/build/CMakeFiles/libdynd.dir/src/dynd/kernels/./libdynd_generated_ckernel_builder.cu.o;/home/irwin/Repositories/libdynd/build/CMakeFiles/libdynd.dir/src/dynd/types/./libdynd_generated_dynd_complex.cu.o;/home/irwin/Repositories/libdynd/build/CMakeFiles/libdynd.dir/src/dynd/types/./libdynd_generated_dynd_float16.cu.o;/home/irwin/Repositories/libdynd/build/CMakeFiles/libdynd.dir/src/dynd/types/./libdynd_generated_dynd_float128.cu.o;/home/irwin/Repositories/libdynd/build/CMakeFiles/libdynd.dir/src/dynd/types/./libdynd_generated_d y > nd_int128.cu.o;/home/irwin/Repositories/libdynd/build/CMakeFiles/libdynd.dir/src/d >>> ynd/types/./libdynd_generated_dynd_uint128.cu.o -o /home/irwin/Repositories/libdynd/build/CMakeFiles/libdynd.dir/./libdynd_intermediate_link.o $<$:-Xcompiler>;$<$:-fPIC> >>> going to run COMMAND /usr/local/cuda/bin/nvcc -m64;-ccbin;"/usr/bin/cc" -dlink /home/irwin/Repositories/libdynd/build/tests/CMakeFiles/test_libdynd.dir/func/./test_libdynd_generated_test_apply.cu.o;/home/irwin/Repositories/libdynd/build/tests/CMakeFiles/test_libdynd.dir/func/./test_libdynd_generated_test_lift_arrfunc.cu.o -o /home/irwin/Repositories/libdynd/build/tests/CMakeFiles/test_libdynd.dir/./test_libdynd_intermediate_link.o >>> >>> going to run COMMAND /usr/local/cuda/bin/nvcc -m64;-ccbin;"/usr/bin/cc" -dlink /home/irwin/Repositories/libdynd/build/tests/CMakeFiles/test_libdynd.dir/func/./test_libdynd_generated_test_apply.cu.o;/home/irwin/Repositories/libdynd/build/tests/CMakeFiles/test_libdynd.dir/func/./test_libdynd_generated_test_lift_arrfunc.cu.o -o /home/irwin/Repositories/libdynd/build/tests/CMakeFiles/test_libdynd.dir/./test_libdynd_intermediate_link.o $<$:-Xcompiler>;$<$:-fPIC> >>> >>> James Bigler wrote: >>>> I meant putting messages into FindCUDA.cmake itself. >>>> >>>> Only certain flags are propagated for the intermediate link file >>>> compilation, because I've had a lot of trouble over the years for >>>> propagating all the host flags. This set of flags is filtered by the >>>> function _cuda_get_important_host_flags. Right now only the >>>> CMAKE_CXX_FLAGS_*CONFIG* are being processed. None of the flags in the >>>> configuration free variable are passed. That was the "patch" I wanted >>>> you to try. Why -fPIC in the configuration specific CMAKE_CXX_FLAGS >>>> wasn't working, I'm not sure. The code is there to do it. >>>> >>>> On Tue, Jan 6, 2015 at 10:05 AM, Irwin Zaid>>> > wrote: >>>> >>>> Right, when I modify FindCUDA.cmake as you describe everything >>>> works. So that's good. >>>> >>>> Without doing that, I still don't see CMAKE_CXX_FLAGS_DEBUG >>>> propagating its flags to the intermediate link file. Did you mean to >>>> put message commands into CUDA_LINK_SEPARABLE___COMPILATION_OBJECTS >>>> itself? When I put them into my main CMakeLists.txt, nothing is >>>> printed for ${nvcc_flags} or the other variables. >>>> >>>> James Bigler wrote: >>>> >>>> On Tue, Jan 6, 2015 at 8:54 AM, Irwin Zaid >>>> >>> >>>> >>> >> wrote: >>>> >>>> Okay, an update on this. >>>> >>>> 2) This is trickier and, unfortunately, still not working. We are >>>> already adding -fPIC to CMAKE_CXX_FLAGS, should that not be >>>> enough? I also tried adding it to both CMAKE_CXX_FLAGS_DEBUG and >>>> CMAKE_CXX_FLAGS_RELEASE, with no effect. >>>> >>>> Looking into FindCUDA.CMake at >>>> CUDA_LINK_SEPARABLE_____COMPILATION_OBJECTS, I find code very >>>> similar to what you are describing. Are you saying that in >>>> addition to what is below, we need to add what you proposed? This >>>> is what I see. >>>> >>>> -- >>>> >>>> >>>> It can be put here (before this foreach). >>>> >>>> foreach(config ${CUDA_configuration_types}) >>>> string(TOUPPER ${config} config_upper) >>>> # Add config specific flags >>>> foreach(f ${CUDA_NVCC_FLAGS_${config_____upper}}) >>>> list(APPEND config_specific_flags $<$:${f}>) >>>> endforeach() >>>> set(important_host_flags) >>>> _cuda_get_important_host_____flags(important_host_flags >>>> ${CMAKE_${CUDA_C_OR_CXX}_____FLAGS_${config_upper}}) >>>> foreach(f ${important_host_flags}) >>>> list(APPEND flags $<$:-____Xcompiler> >>>> $<$:${f}>) >>>> endforeach() >>>> endforeach() >>>> >>>> >>>> Or it can be put here (or after the foreach). >>>> >>>> I'm concerned that the flag didn't show up after adding it to >>>> the _DEBUG or _RELEASE variants. If you could add a few message >>>> commands around that might help see what is going on. The flag >>>> needs to be propagated. >>>> >>>> You could sprinkle a few commands like this: >>>> message("going to run COMMAND ${CUDA_NVCC_EXECUTABLE} >>>> ${nvcc_flags} -dlink ${object_files} -o ${output_file} >>>> ${flags}") >>>> >>>> >>>> From braden at endoframe.com Tue Jan 6 16:21:17 2015 From: braden at endoframe.com (Braden McDaniel) Date: Tue, 06 Jan 2015 16:21:17 -0500 Subject: [CMake] Get the BINARY_DIR for a target? In-Reply-To: <1420565690.5364.4.camel@endoframe.com> References: <1420565690.5364.4.camel@endoframe.com> Message-ID: <1420579277.2592.3.camel@endoframe.com> On Tue, 2015-01-06 at 12:34 -0500, Braden McDaniel wrote: > Are there any properties on a target that I can query to get whatever > was the CMAKE_CURRENT_BINARY_DIR when the target was defined? > > I'm aware of the LOCATION property; however, its generator-specific > nature makes teasing the non-generator-specific part out of it rather > challenging (without some other information about the target > definition's location in the source tree, which is specifically what I'm > trying to avoid). FWIW, I'm writing a function that takes a list of > targets as input. It looks like I can add my own arbitrary property for this. So, my current solution is to wrap add_library with my own function that calls add_library and then sets MY_SPECIAL_PROPERTY on the target to the current value of CMAKE_CURRENT_BINARY_DIR. Later, I get the value of MY_SPECIAL_PROPERTY inside the function I described in my previous message. If someone knows of a better way, do tell. -- Braden McDaniel From jamesbigler at gmail.com Tue Jan 6 18:14:25 2015 From: jamesbigler at gmail.com (James Bigler) Date: Tue, 6 Jan 2015 16:14:25 -0700 Subject: [CMake] FindCUDA ignores project dependencies when separable compilation is on In-Reply-To: <54AC466F.5060103@physics.ox.ac.uk> References: <4634e484e7954171a22b8bebc07ae578@EXCHANGE-CAS1.physics.ox.ac.uk> <54AA8449.70404@physics.ox.ac.uk> <24de6f36f39c40caaf533f87173c6f83@EXCHANGE-CAS1.physics.ox.ac.uk> <54AAFAD3.2080102@physics.ox.ac.uk> <6c2cbb1f096c4cd29c49a0dbfeaec934@EXCHANGE-CAS2.physics.ox.ac.uk> <54AB138F.1010406@physics.ox.ac.uk> <54AC0528.6020302@physics.ox.ac.uk> <51d0f76d2f384f3ca5578a7697787274@EXCHANGE-CAS2.physics.ox.ac.uk> <54AC15EF.9000800@physics.ox.ac.uk> <6e226ac20e2d46a4805c68f614fd8c6b@EXCHANGE-CAS1.physics.ox.ac.uk> <54AC296D.7020504@physics.ox.ac.uk> <8b196a38d5dc4badbce63d4d5f58a4ca@EXCHANGE-CAS1.physics.ox.ac.uk> <54AC466F.5060103@physics.ox.ac.uk> Message-ID: Right, if you don't specify the CMAKE_BUILD_TYPE you are only getting the CMAKE_CXX_FLAGS and none of the build type specific flags such as CMAKE_CXX_FLAGS_DEBUG. There is still the issue that I wasn't bringing in the CMAKE_CXX_FLAGS (which is why my patch helped). James On Tue, Jan 6, 2015 at 1:32 PM, Irwin Zaid wrote: > Wait, hold on. The -fPIC does get passed to everything if I set the build > mode to Debug by passing -DCMAKE_BUILD_TYPE=Debug to CMake. Is that what I > should be doing? (Sorry about that, if yes.) > > If that's the case, what is the correct way to get -fPIC passed to the > intermediate linking? Am I meant to always build in Debug mode just for > that? > > Irwin > > Irwin Zaid wrote: > >> I just double-checked. The -fPIC is definitely there for each individual >> object file, but not for the *_intermediate_link.o. >> >> Irwin >> >> James Bigler wrote: >> >>> >>> James >>> >>> On Jan 6, 2015, at 11:29 AM, Irwin Zaid >>>> wrote: >>>> >>>> Okay, so I've gone and put the messages into FindCUDA.cmake. I >>>> specifically put them right before and after the foreach() in >>>> CUDA_LINK_SEPARARABLE_COMPILATION_OBJECTS. The output is the following. >>>> >>>> Is "$<$:-Xcompiler>;$<$:-fPIC>" supposed >>>> to be that way? That looks weird. >>>> >>>> Yeah. That looks right. It means the argument will only be run when >>> the build configuration matches DEBUG. This is less exciting for Makefiles >>> builds since there is only one configuration preset at a time, but for >>> things like Visual Studio where you have multiple build configs from a >>> single CMake configure this makes a custom command for each without having >>> to rely on scripts to dispatch the correct command (that's how the rest of >>> FindCUDA works by the way). >>> >>> As far as the rest of these, I'm concerned the fPIC flag comes and goes. >>> Perhaps something is modifying the flags. Do the commands with fPIC >>> actually get run with fPIC (use make VERBOSE=1)? >>> >>> -- >>>> >>>> going to run COMMAND /usr/local/cuda/bin/nvcc -m64;-ccbin;"/usr/bin/cc" >>>> -dlink /home/irwin/Repositories/libdynd/build/CMakeFiles/ >>>> libdynd.dir/src/dynd/kernels/./libdynd_generated_assignment_ >>>> kernels.cu.o;/home/irwin/Repositories/libdynd/build/ >>>> CMakeFiles/libdynd.dir/src/dynd/func/./libdynd_generated_ >>>> arithmetic.cu.o;/home/irwin/Repositories/libdynd/build/ >>>> CMakeFiles/libdynd.dir/src/dynd/func/./libdynd_generated_ >>>> elwise.cu.o;/home/irwin/Repositories/libdynd/build/ >>>> CMakeFiles/libdynd.dir/src/dynd/kernels/./libdynd_ >>>> generated_ckernel_builder.cu.o;/home/irwin/Repositories/ >>>> libdynd/build/CMakeFiles/libdynd.dir/src/dynd/types/./ >>>> libdynd_generated_dynd_complex.cu.o;/home/irwin/ >>>> Repositories/libdynd/build/CMakeFiles/libdynd.dir/src/ >>>> dynd/types/./libdynd_generated_dynd_float16.cu.o;/ >>>> home/irwin/Repositories/libdynd/build/CMakeFiles/ >>>> libdynd.dir/src/dynd/types/./libdynd_generated_dynd_ >>>> float128.cu.o;/home/irwin/Repositories/libdynd/build/ >>>> CMakeFiles/libdynd.dir/src/dynd/types/./libdynd_generated_d >>>> >>> y > >> nd_int128.cu.o;/home/irwin/Repositories/libdynd/build/ >> CMakeFiles/libdynd.dir/src/d >> >>> ynd/types/./libdynd_generated_dynd_uint128.cu.o -o >>>> /home/irwin/Repositories/libdynd/build/CMakeFiles/ >>>> libdynd.dir/./libdynd_intermediate_link.o >>>> >>>> going to run COMMAND /usr/local/cuda/bin/nvcc -m64;-ccbin;"/usr/bin/cc" >>>> -dlink /home/irwin/Repositories/libdynd/build/CMakeFiles/ >>>> libdynd.dir/src/dynd/kernels/./libdynd_generated_assignment_ >>>> kernels.cu.o;/home/irwin/Repositories/libdynd/build/ >>>> CMakeFiles/libdynd.dir/src/dynd/func/./libdynd_generated_ >>>> arithmetic.cu.o;/home/irwin/Repositories/libdynd/build/ >>>> CMakeFiles/libdynd.dir/src/dynd/func/./libdynd_generated_ >>>> elwise.cu.o;/home/irwin/Repositories/libdynd/build/ >>>> CMakeFiles/libdynd.dir/src/dynd/kernels/./libdynd_ >>>> generated_ckernel_builder.cu.o;/home/irwin/Repositories/ >>>> libdynd/build/CMakeFiles/libdynd.dir/src/dynd/types/./ >>>> libdynd_generated_dynd_complex.cu.o;/home/irwin/ >>>> Repositories/libdynd/build/CMakeFiles/libdynd.dir/src/ >>>> dynd/types/./libdynd_generated_dynd_float16.cu.o;/ >>>> home/irwin/Repositories/libdynd/build/CMakeFiles/ >>>> libdynd.dir/src/dynd/types/./libdynd_generated_dynd_ >>>> float128.cu.o;/home/irwin/Repositories/libdynd/build/ >>>> CMakeFiles/libdynd.dir/src/dynd/types/./libdynd_generated_d >>>> >>> y > >> nd_int128.cu.o;/home/irwin/Repositories/libdynd/build/ >> CMakeFiles/libdynd.dir/src/d >> >>> ynd/types/./libdynd_generated_dynd_uint128.cu.o -o >>>> /home/irwin/Repositories/libdynd/build/CMakeFiles/ >>>> libdynd.dir/./libdynd_intermediate_link.o >>>> $<$:-Xcompiler>;$<$:-fPIC> >>>> going to run COMMAND /usr/local/cuda/bin/nvcc -m64;-ccbin;"/usr/bin/cc" >>>> -dlink /home/irwin/Repositories/libdynd/build/tests/ >>>> CMakeFiles/test_libdynd.dir/func/./test_libdynd_generated_ >>>> test_apply.cu.o;/home/irwin/Repositories/libdynd/build/ >>>> tests/CMakeFiles/test_libdynd.dir/func/./test_libdynd_ >>>> generated_test_lift_arrfunc.cu.o -o /home/irwin/Repositories/ >>>> libdynd/build/tests/CMakeFiles/test_libdynd.dir/./ >>>> test_libdynd_intermediate_link.o >>>> >>>> going to run COMMAND /usr/local/cuda/bin/nvcc -m64;-ccbin;"/usr/bin/cc" >>>> -dlink /home/irwin/Repositories/libdynd/build/tests/ >>>> CMakeFiles/test_libdynd.dir/func/./test_libdynd_generated_ >>>> test_apply.cu.o;/home/irwin/Repositories/libdynd/build/ >>>> tests/CMakeFiles/test_libdynd.dir/func/./test_libdynd_ >>>> generated_test_lift_arrfunc.cu.o -o /home/irwin/Repositories/ >>>> libdynd/build/tests/CMakeFiles/test_libdynd.dir/./ >>>> test_libdynd_intermediate_link.o $<$:-Xcompiler>; >>>> $<$:-fPIC> >>>> >>>> James Bigler wrote: >>>> >>>>> I meant putting messages into FindCUDA.cmake itself. >>>>> >>>>> Only certain flags are propagated for the intermediate link file >>>>> compilation, because I've had a lot of trouble over the years for >>>>> propagating all the host flags. This set of flags is filtered by the >>>>> function _cuda_get_important_host_flags. Right now only the >>>>> CMAKE_CXX_FLAGS_*CONFIG* are being processed. None of the flags in the >>>>> configuration free variable are passed. That was the "patch" I wanted >>>>> you to try. Why -fPIC in the configuration specific CMAKE_CXX_FLAGS >>>>> wasn't working, I'm not sure. The code is there to do it. >>>>> >>>>> On Tue, Jan 6, 2015 at 10:05 AM, Irwin Zaid>>>> uk >>>>> > wrote: >>>>> >>>>> Right, when I modify FindCUDA.cmake as you describe everything >>>>> works. So that's good. >>>>> >>>>> Without doing that, I still don't see CMAKE_CXX_FLAGS_DEBUG >>>>> propagating its flags to the intermediate link file. Did you mean >>>>> to >>>>> put message commands into CUDA_LINK_SEPARABLE___ >>>>> COMPILATION_OBJECTS >>>>> itself? When I put them into my main CMakeLists.txt, nothing is >>>>> printed for ${nvcc_flags} or the other variables. >>>>> >>>>> James Bigler wrote: >>>>> >>>>> On Tue, Jan 6, 2015 at 8:54 AM, Irwin Zaid >>>>> >>>> >>>>> >>>> >> wrote: >>>>> >>>>> Okay, an update on this. >>>>> >>>>> 2) This is trickier and, unfortunately, still not working. We >>>>> are >>>>> already adding -fPIC to CMAKE_CXX_FLAGS, should that not be >>>>> enough? I also tried adding it to both CMAKE_CXX_FLAGS_DEBUG >>>>> and >>>>> CMAKE_CXX_FLAGS_RELEASE, with no effect. >>>>> >>>>> Looking into FindCUDA.CMake at >>>>> CUDA_LINK_SEPARABLE_____COMPILATION_OBJECTS, I find code very >>>>> similar to what you are describing. Are you saying that in >>>>> addition to what is below, we need to add what you proposed? >>>>> This >>>>> is what I see. >>>>> >>>>> -- >>>>> >>>>> >>>>> It can be put here (before this foreach). >>>>> >>>>> foreach(config ${CUDA_configuration_types}) >>>>> string(TOUPPER ${config} config_upper) >>>>> # Add config specific flags >>>>> foreach(f ${CUDA_NVCC_FLAGS_${config_____upper}}) >>>>> list(APPEND config_specific_flags $<$:${f}>) >>>>> endforeach() >>>>> set(important_host_flags) >>>>> _cuda_get_important_host_____flags(important_host_flags >>>>> ${CMAKE_${CUDA_C_OR_CXX}_____FLAGS_${config_upper}}) >>>>> foreach(f ${important_host_flags}) >>>>> list(APPEND flags $<$:-____Xcompiler> >>>>> $<$:${f}>) >>>>> endforeach() >>>>> endforeach() >>>>> >>>>> >>>>> Or it can be put here (or after the foreach). >>>>> >>>>> I'm concerned that the flag didn't show up after adding it to >>>>> the _DEBUG or _RELEASE variants. If you could add a few >>>>> message >>>>> commands around that might help see what is going on. The flag >>>>> needs to be propagated. >>>>> >>>>> You could sprinkle a few commands like this: >>>>> message("going to run COMMAND ${CUDA_NVCC_EXECUTABLE} >>>>> ${nvcc_flags} -dlink ${object_files} -o ${output_file} >>>>> ${flags}") >>>>> >>>>> >>>>> >>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From irwin.zaid at physics.ox.ac.uk Tue Jan 6 18:29:25 2015 From: irwin.zaid at physics.ox.ac.uk (Irwin Zaid) Date: Tue, 6 Jan 2015 23:29:25 +0000 Subject: [CMake] FindCUDA ignores project dependencies when separable compilation is on In-Reply-To: <833e51427f8c48fc8e4a337b73a9ad12@EXCHANGE-CAS1.physics.ox.ac.uk> References: <4634e484e7954171a22b8bebc07ae578@EXCHANGE-CAS1.physics.ox.ac.uk> <54AA8449.70404@physics.ox.ac.uk> <24de6f36f39c40caaf533f87173c6f83@EXCHANGE-CAS1.physics.ox.ac.uk> <54AAFAD3.2080102@physics.ox.ac.uk> <6c2cbb1f096c4cd29c49a0dbfeaec934@EXCHANGE-CAS2.physics.ox.ac.uk> <54AB138F.1010406@physics.ox.ac.uk> <54AC0528.6020302@physics.ox.ac.uk> <51d0f76d2f384f3ca5578a7697787274@EXCHANGE-CAS2.physics.ox.ac.uk> <54AC15EF.9000800@physics.ox.ac.uk> <6e226ac20e2d46a4805c68f614fd8c6b@EXCHANGE-CAS1.physics.ox.ac.uk> <54AC296D.7020504@physics.ox.ac.uk> <8b196a38d5dc4badbce63d4d5f58a4ca@EXCHANGE-CAS1.physics.ox.ac.uk> <54AC466F.5060103@physics.ox.ac.uk> <833e51427f8c48fc8e4a337b73a9ad12@EXCHANGE-CAS1.physics.ox.ac.uk> Message-ID: <54AC6FD5.5050103@physics.ox.ac.uk> Okay, so to conclude: Should we make a PR to include your patched code so CMAKE_CXX_FLAGS just works? I think this makes sense, as I would never have thought to do the DEBUG / RELEASE stuff. I can do the PR, unless you want to. And, of course, thanks for all your help! Irwin James Bigler wrote: > Right, if you don't specify the CMAKE_BUILD_TYPE you are only getting > the CMAKE_CXX_FLAGS and none of the build type specific flags such as > CMAKE_CXX_FLAGS_DEBUG. > > There is still the issue that I wasn't bringing in the CMAKE_CXX_FLAGS > (which is why my patch helped). > > James > > On Tue, Jan 6, 2015 at 1:32 PM, Irwin Zaid > > wrote: > > Wait, hold on. The -fPIC does get passed to everything if I set > the build mode to Debug by passing -DCMAKE_BUILD_TYPE=Debug to > CMake. Is that what I should be doing? (Sorry about that, if yes.) > > If that's the case, what is the correct way to get -fPIC passed to > the intermediate linking? Am I meant to always build in Debug mode > just for that? > > Irwin > > Irwin Zaid wrote: > > I just double-checked. The -fPIC is definitely there for each > individual > object file, but not for the *_intermediate_link.o. > > Irwin > > James Bigler wrote: > > > James > > On Jan 6, 2015, at 11:29 AM, Irwin > Zaid > wrote: > > Okay, so I've gone and put the messages into > FindCUDA.cmake. I specifically put them right before > and after the foreach() in > CUDA_LINK_SEPARARABLE___COMPILATION_OBJECTS. The > output is the following. > > Is > "$<$:-Xcompiler>__;$<$:-fPIC>" > supposed to be that way? That looks weird. > > Yeah. That looks right. It means the argument will only be > run when the build configuration matches DEBUG. This is > less exciting for Makefiles builds since there is only one > configuration preset at a time, but for things like Visual > Studio where you have multiple build configs from a single > CMake configure this makes a custom command for each > without having to rely on scripts to dispatch the correct > command (that's how the rest of FindCUDA works by the way). > > As far as the rest of these, I'm concerned the fPIC flag > comes and goes. Perhaps something is modifying the flags. > Do the commands with fPIC actually get run with fPIC (use > make VERBOSE=1)? > > -- > > going to run COMMAND /usr/local/cuda/bin/nvcc > -m64;-ccbin;"/usr/bin/cc" -dlink > /home/irwin/Repositories/__libdynd/build/CMakeFiles/__libdynd.dir/src/dynd/kernels/.__/libdynd_generated_assignment___kernels.cu.o;/home/irwin/__Repositories/libdynd/build/__CMakeFiles/libdynd.dir/src/__dynd/func/./libdynd_generated___arithmetic.cu.o;/home/irwin/__Repositories/libdynd/build/__CMakeFiles/libdynd.dir/src/__dynd/func/./libdynd_generated___elwise.cu.o;/home/irwin/__Repositories/libdynd/build/__CMakeFiles/libdynd.dir/src/__dynd/kernels/./libdynd___generated_ckernel_builder.cu > .__o;/home/irwin/Repositories/__libdynd/build/CMakeFiles/__libdynd.dir/src/dynd/types/./__libdynd_generated_dynd___complex.cu.o;/home/irwin/__Repositories/libdynd/build/__CMakeFiles/libdynd.dir/src/__dynd/types/./libdynd___generated_dynd_float16.cu.o;/__home/irwin/Repositories/__libdynd/build/CMakeFiles/__libdynd.dir/src/dynd/types/./__libdynd_generated_dynd___float128.cu.o;/home/irwin/__Repositories/libdynd/build/__CMakeFiles/libdynd.dir/src/__dynd/types/./libdynd___generated_d > > y > > nd_int128.cu.o;/home/irwin/__Repositories/libdynd/build/__CMakeFiles/libdynd.dir/src/d > > ynd/types/./libdynd_generated___dynd_uint128.cu.o -o > /home/irwin/Repositories/__libdynd/build/CMakeFiles/__libdynd.dir/./libdynd___intermediate_link.o > > going to run COMMAND /usr/local/cuda/bin/nvcc > -m64;-ccbin;"/usr/bin/cc" -dlink > /home/irwin/Repositories/__libdynd/build/CMakeFiles/__libdynd.dir/src/dynd/kernels/.__/libdynd_generated_assignment___kernels.cu.o;/home/irwin/__Repositories/libdynd/build/__CMakeFiles/libdynd.dir/src/__dynd/func/./libdynd_generated___arithmetic.cu.o;/home/irwin/__Repositories/libdynd/build/__CMakeFiles/libdynd.dir/src/__dynd/func/./libdynd_generated___elwise.cu.o;/home/irwin/__Repositories/libdynd/build/__CMakeFiles/libdynd.dir/src/__dynd/kernels/./libdynd___generated_ckernel_builder.cu > .__o;/home/irwin/Repositories/__libdynd/build/CMakeFiles/__libdynd.dir/src/dynd/types/./__libdynd_generated_dynd___complex.cu.o;/home/irwin/__Repositories/libdynd/build/__CMakeFiles/libdynd.dir/src/__dynd/types/./libdynd___generated_dynd_float16.cu.o;/__home/irwin/Repositories/__libdynd/build/CMakeFiles/__libdynd.dir/src/dynd/types/./__libdynd_generated_dynd___float128.cu.o;/home/irwin/__Repositories/libdynd/build/__CMakeFiles/libdynd.dir/src/__dynd/types/./libdynd___generated_d > > y > > nd_int128.cu.o;/home/irwin/__Repositories/libdynd/build/__CMakeFiles/libdynd.dir/src/d > > ynd/types/./libdynd_generated___dynd_uint128.cu.o -o > /home/irwin/Repositories/__libdynd/build/CMakeFiles/__libdynd.dir/./libdynd___intermediate_link.o > $<$:-Xcompiler>;__$<$:-fPIC> > going to run COMMAND /usr/local/cuda/bin/nvcc > -m64;-ccbin;"/usr/bin/cc" -dlink > /home/irwin/Repositories/__libdynd/build/tests/__CMakeFiles/test_libdynd.dir/__func/./test_libdynd_generated___test_apply.cu.o;/home/irwin/__Repositories/libdynd/build/__tests/CMakeFiles/test_libdynd.__dir/func/./test_libdynd___generated_test_lift_arrfunc.__cu.o > -o > /home/irwin/Repositories/__libdynd/build/tests/__CMakeFiles/test_libdynd.dir/./__test_libdynd_intermediate___link.o > > going to run COMMAND /usr/local/cuda/bin/nvcc > -m64;-ccbin;"/usr/bin/cc" -dlink > /home/irwin/Repositories/__libdynd/build/tests/__CMakeFiles/test_libdynd.dir/__func/./test_libdynd_generated___test_apply.cu.o;/home/irwin/__Repositories/libdynd/build/__tests/CMakeFiles/test_libdynd.__dir/func/./test_libdynd___generated_test_lift_arrfunc.__cu.o > -o > /home/irwin/Repositories/__libdynd/build/tests/__CMakeFiles/test_libdynd.dir/./__test_libdynd_intermediate___link.o > $<$:-Xcompiler>;__$<$:-fPIC> > > James Bigler wrote: > > I meant putting messages into FindCUDA.cmake itself. > > Only certain flags are propagated for the > intermediate link file > compilation, because I've had a lot of trouble > over the years for > propagating all the host flags. This set of flags > is filtered by the > function _cuda_get_important_host___flags. Right > now only the > CMAKE_CXX_FLAGS_*CONFIG* are being processed. None > of the flags in the > configuration free variable are passed. That was > the "patch" I wanted > you to try. Why -fPIC in the configuration > specific CMAKE_CXX_FLAGS > wasn't working, I'm not sure. The code is there to > do it. > > On Tue, Jan 6, 2015 at 10:05 AM, Irwin > Zaid > >> wrote: > > Right, when I modify FindCUDA.cmake as you > describe everything > works. So that's good. > > Without doing that, I still don't see > CMAKE_CXX_FLAGS_DEBUG > propagating its flags to the intermediate link > file. Did you mean to > put message commands into > CUDA_LINK_SEPARABLE_____COMPILATION_OBJECTS > itself? When I put them into my main > CMakeLists.txt, nothing is > printed for ${nvcc_flags} or the other variables. > > James Bigler wrote: > > On Tue, Jan 6, 2015 at 8:54 AM, Irwin Zaid > > > > ____ac.uk > > >>> wrote: > > Okay, an update on this. > > 2) This is trickier and, unfortunately, still not > working. We are > already adding -fPIC to CMAKE_CXX_FLAGS, should > that not be > enough? I also tried adding it to both > CMAKE_CXX_FLAGS_DEBUG and > CMAKE_CXX_FLAGS_RELEASE, with no effect. > > Looking into FindCUDA.CMake at > CUDA_LINK_SEPARABLE_______COMPILATION_OBJECTS, I > find code very > similar to what you are describing. Are you saying > that in > addition to what is below, we need to add what you > proposed? This > is what I see. > > -- > > > It can be put here (before this foreach). > > foreach(config ${CUDA_configuration_types}) > string(TOUPPER ${config} config_upper) > # Add config specific flags > foreach(f ${CUDA_NVCC_FLAGS_${config_______upper}}) > list(APPEND config_specific_flags > $<$:${f}>) > endforeach() > set(important_host_flags) > _cuda_get_important_host_______flags(important_host_flags > ${CMAKE_${CUDA_C_OR_CXX}_______FLAGS_${config_upper}}) > foreach(f ${important_host_flags}) > list(APPEND flags > $<$:-______Xcompiler> > $<$:${f}>) > endforeach() > endforeach() > > > Or it can be put here (or after the foreach). > > I'm concerned that the flag didn't show up after > adding it to > the _DEBUG or _RELEASE variants. If you could add > a few message > commands around that might help see what is going > on. The flag > needs to be propagated. > > You could sprinkle a few commands like this: > message("going to run COMMAND ${CUDA_NVCC_EXECUTABLE} > ${nvcc_flags} -dlink ${object_files} -o ${output_file} > ${flags}") > > > > From jamesbigler at gmail.com Tue Jan 6 18:50:33 2015 From: jamesbigler at gmail.com (James Bigler) Date: Tue, 6 Jan 2015 16:50:33 -0700 Subject: [CMake] FindCUDA ignores project dependencies when separable compilation is on In-Reply-To: <54AC6FD5.5050103@physics.ox.ac.uk> References: <4634e484e7954171a22b8bebc07ae578@EXCHANGE-CAS1.physics.ox.ac.uk> <54AA8449.70404@physics.ox.ac.uk> <24de6f36f39c40caaf533f87173c6f83@EXCHANGE-CAS1.physics.ox.ac.uk> <54AAFAD3.2080102@physics.ox.ac.uk> <6c2cbb1f096c4cd29c49a0dbfeaec934@EXCHANGE-CAS2.physics.ox.ac.uk> <54AB138F.1010406@physics.ox.ac.uk> <54AC0528.6020302@physics.ox.ac.uk> <51d0f76d2f384f3ca5578a7697787274@EXCHANGE-CAS2.physics.ox.ac.uk> <54AC15EF.9000800@physics.ox.ac.uk> <6e226ac20e2d46a4805c68f614fd8c6b@EXCHANGE-CAS1.physics.ox.ac.uk> <54AC296D.7020504@physics.ox.ac.uk> <8b196a38d5dc4badbce63d4d5f58a4ca@EXCHANGE-CAS1.physics.ox.ac.uk> <54AC466F.5060103@physics.ox.ac.uk> <833e51427f8c48fc8e4a337b73a9ad12@EXCHANGE-CAS1.physics.ox.ac.uk> <54AC6FD5.5050103@physics.ox.ac.uk> Message-ID: I've pushed a change into 'stage' [1] that I hope to get into 'next' (something isn't working with my ssh authentication). James [1] commit b4e54f9b8c748f78d16e9da055a7e0436d7654ef Author: James Bigler <@> Date: Tue Jan 6 16:28:05 2015 -0700 FindCUDA: Add relevant CMAKE_{C,CXX}_FLAGS for separable compilation Previously only the CMAKE_{C,CXX}_FLAGS_ flags were inspected for relevant flags when compiling the intermediate link file. We need to also consider the configuration agnostic flags, CMAKE_{C,CXX}_FLAGS as well. On Tue, Jan 6, 2015 at 4:29 PM, Irwin Zaid wrote: > Okay, so to conclude: > > Should we make a PR to include your patched code so CMAKE_CXX_FLAGS just > works? I think this makes sense, as I would never have thought to do the > DEBUG / RELEASE stuff. I can do the PR, unless you want to. > > And, of course, thanks for all your help! > > Irwin > > James Bigler wrote: > >> Right, if you don't specify the CMAKE_BUILD_TYPE you are only getting the >> CMAKE_CXX_FLAGS and none of the build type specific flags such as >> CMAKE_CXX_FLAGS_DEBUG. >> >> There is still the issue that I wasn't bringing in the CMAKE_CXX_FLAGS >> (which is why my patch helped). >> >> James >> >> On Tue, Jan 6, 2015 at 1:32 PM, Irwin Zaid > > wrote: >> >> Wait, hold on. The -fPIC does get passed to everything if I set >> the build mode to Debug by passing -DCMAKE_BUILD_TYPE=Debug to >> CMake. Is that what I should be doing? (Sorry about that, if yes.) >> >> If that's the case, what is the correct way to get -fPIC passed to >> the intermediate linking? Am I meant to always build in Debug mode >> just for that? >> >> Irwin >> >> Irwin Zaid wrote: >> >> I just double-checked. The -fPIC is definitely there for each >> individual >> object file, but not for the *_intermediate_link.o. >> >> Irwin >> >> James Bigler wrote: >> >> >> James >> >> On Jan 6, 2015, at 11:29 AM, Irwin >> Zaid> > wrote: >> >> Okay, so I've gone and put the messages into >> FindCUDA.cmake. I specifically put them right before >> and after the foreach() in >> CUDA_LINK_SEPARARABLE___COMPILATION_OBJECTS. The >> output is the following. >> >> Is >> "$<$:-Xcompiler> >> __;$<$:-fPIC>" >> supposed to be that way? That looks weird. >> >> Yeah. That looks right. It means the argument will only be >> run when the build configuration matches DEBUG. This is >> less exciting for Makefiles builds since there is only one >> configuration preset at a time, but for things like Visual >> Studio where you have multiple build configs from a single >> CMake configure this makes a custom command for each >> without having to rely on scripts to dispatch the correct >> command (that's how the rest of FindCUDA works by the way). >> >> As far as the rest of these, I'm concerned the fPIC flag >> comes and goes. Perhaps something is modifying the flags. >> Do the commands with fPIC actually get run with fPIC (use >> make VERBOSE=1)? >> >> -- >> >> going to run COMMAND /usr/local/cuda/bin/nvcc >> -m64;-ccbin;"/usr/bin/cc" -dlink >> /home/irwin/Repositories/__libdynd/build/CMakeFiles/__ >> libdynd.dir/src/dynd/kernels/.__/libdynd_generated_ >> assignment___kernels.cu.o;/home/irwin/__Repositories/ >> libdynd/build/__CMakeFiles/libdynd.dir/src/__dynd/func/./ >> libdynd_generated___arithmetic.cu.o;/home/irwin/__ >> Repositories/libdynd/build/__CMakeFiles/libdynd.dir/src/__ >> dynd/func/./libdynd_generated___elwise.cu.o;/home/irwin/__ >> Repositories/libdynd/build/__CMakeFiles/libdynd.dir/src/__dynd/kernels/./ >> libdynd___generated_ckernel_builder.cu >> .__o;/home/irwin/ >> Repositories/__libdynd/build/CMakeFiles/__libdynd.dir/src/ >> dynd/types/./__libdynd_generated_dynd___complex.cu.o; >> /home/irwin/__Repositories/libdynd/build/__CMakeFiles/ >> libdynd.dir/src/__dynd/types/./libdynd___generated_dynd_ >> float16.cu.o;/__home/irwin/Repositories/__libdynd/build/ >> CMakeFiles/__libdynd.dir/src/dynd/types/./__libdynd_ >> generated_dynd___float128.cu.o;/home/irwin/__Repositories/ >> libdynd/build/__CMakeFiles/libdynd.dir/src/__dynd/types/. >> /libdynd___generated_d >> >> y >> >> nd_int128.cu.o;/home/irwin/__Repositories/libdynd/build/__ >> CMakeFiles/libdynd.dir/src/d >> >> ynd/types/./libdynd_generated___dynd_uint128.cu.o -o >> /home/irwin/Repositories/__libdynd/build/CMakeFiles/__ >> libdynd.dir/./libdynd___intermediate_link.o >> >> going to run COMMAND /usr/local/cuda/bin/nvcc >> -m64;-ccbin;"/usr/bin/cc" -dlink >> /home/irwin/Repositories/__libdynd/build/CMakeFiles/__ >> libdynd.dir/src/dynd/kernels/.__/libdynd_generated_ >> assignment___kernels.cu.o;/home/irwin/__Repositories/ >> libdynd/build/__CMakeFiles/libdynd.dir/src/__dynd/func/./ >> libdynd_generated___arithmetic.cu.o;/home/irwin/__ >> Repositories/libdynd/build/__CMakeFiles/libdynd.dir/src/__ >> dynd/func/./libdynd_generated___elwise.cu.o;/home/irwin/__ >> Repositories/libdynd/build/__CMakeFiles/libdynd.dir/src/__dynd/kernels/./ >> libdynd___generated_ckernel_builder.cu >> .__o;/home/irwin/ >> Repositories/__libdynd/build/CMakeFiles/__libdynd.dir/src/ >> dynd/types/./__libdynd_generated_dynd___complex.cu.o; >> /home/irwin/__Repositories/libdynd/build/__CMakeFiles/ >> libdynd.dir/src/__dynd/types/./libdynd___generated_dynd_ >> float16.cu.o;/__home/irwin/Repositories/__libdynd/build/ >> CMakeFiles/__libdynd.dir/src/dynd/types/./__libdynd_ >> generated_dynd___float128.cu.o;/home/irwin/__Repositories/ >> libdynd/build/__CMakeFiles/libdynd.dir/src/__dynd/types/. >> /libdynd___generated_d >> >> y >> >> nd_int128.cu.o;/home/irwin/__Repositories/libdynd/build/__ >> CMakeFiles/libdynd.dir/src/d >> >> ynd/types/./libdynd_generated___dynd_uint128.cu.o -o >> /home/irwin/Repositories/__libdynd/build/CMakeFiles/__ >> libdynd.dir/./libdynd___intermediate_link.o >> $<$:-Xcompiler>;__$<$:-fPIC> >> going to run COMMAND /usr/local/cuda/bin/nvcc >> -m64;-ccbin;"/usr/bin/cc" -dlink >> /home/irwin/Repositories/__libdynd/build/tests/__ >> CMakeFiles/test_libdynd.dir/__func/./test_libdynd_generated_ >> __test_apply.cu.o;/home/irwin/__Repositories/libdynd/build/_ >> _tests/CMakeFiles/test_libdynd.__dir/func/./test_ >> libdynd___generated_test_lift_arrfunc.__cu.o >> -o >> /home/irwin/Repositories/__libdynd/build/tests/__ >> CMakeFiles/test_libdynd.dir/./__test_libdynd_intermediate___link.o >> >> going to run COMMAND /usr/local/cuda/bin/nvcc >> -m64;-ccbin;"/usr/bin/cc" -dlink >> /home/irwin/Repositories/__libdynd/build/tests/__ >> CMakeFiles/test_libdynd.dir/__func/./test_libdynd_generated_ >> __test_apply.cu.o;/home/irwin/__Repositories/libdynd/build/_ >> _tests/CMakeFiles/test_libdynd.__dir/func/./test_ >> libdynd___generated_test_lift_arrfunc.__cu.o >> -o >> /home/irwin/Repositories/__libdynd/build/tests/__ >> CMakeFiles/test_libdynd.dir/./__test_libdynd_intermediate___link.o >> $<$:-Xcompiler>;__$<$:-fPIC> >> >> James Bigler wrote: >> >> I meant putting messages into FindCUDA.cmake itself. >> >> Only certain flags are propagated for the >> intermediate link file >> compilation, because I've had a lot of trouble >> over the years for >> propagating all the host flags. This set of flags >> is filtered by the >> function _cuda_get_important_host___flags. Right >> now only the >> CMAKE_CXX_FLAGS_*CONFIG* are being processed. None >> of the flags in the >> configuration free variable are passed. That was >> the "patch" I wanted >> you to try. Why -fPIC in the configuration >> specific CMAKE_CXX_FLAGS >> wasn't working, I'm not sure. The code is there to >> do it. >> >> On Tue, Jan 6, 2015 at 10:05 AM, Irwin >> Zaid> >> > >> wrote: >> >> Right, when I modify FindCUDA.cmake as you >> describe everything >> works. So that's good. >> >> Without doing that, I still don't see >> CMAKE_CXX_FLAGS_DEBUG >> propagating its flags to the intermediate link >> file. Did you mean to >> put message commands into >> CUDA_LINK_SEPARABLE_____COMPILATION_OBJECTS >> itself? When I put them into my main >> CMakeLists.txt, nothing is >> printed for ${nvcc_flags} or the other variables. >> >> James Bigler wrote: >> >> On Tue, Jan 6, 2015 at 8:54 AM, Irwin Zaid >> > >> > > >> > ____ac.uk >> >> > >>> wrote: >> >> Okay, an update on this. >> >> 2) This is trickier and, unfortunately, still not >> working. We are >> already adding -fPIC to CMAKE_CXX_FLAGS, should >> that not be >> enough? I also tried adding it to both >> CMAKE_CXX_FLAGS_DEBUG and >> CMAKE_CXX_FLAGS_RELEASE, with no effect. >> >> Looking into FindCUDA.CMake at >> CUDA_LINK_SEPARABLE_______COMPILATION_OBJECTS, I >> find code very >> similar to what you are describing. Are you saying >> that in >> addition to what is below, we need to add what you >> proposed? This >> is what I see. >> >> -- >> >> >> It can be put here (before this foreach). >> >> foreach(config ${CUDA_configuration_types}) >> string(TOUPPER ${config} config_upper) >> # Add config specific flags >> foreach(f ${CUDA_NVCC_FLAGS_${config_______upper}}) >> list(APPEND config_specific_flags >> $<$:${f}>) >> endforeach() >> set(important_host_flags) >> _cuda_get_important_host______ >> _flags(important_host_flags >> ${CMAKE_${CUDA_C_OR_CXX}______ >> _FLAGS_${config_upper}}) >> foreach(f ${important_host_flags}) >> list(APPEND flags >> $<$:-______Xcompiler> >> $<$:${f}>) >> endforeach() >> endforeach() >> >> >> Or it can be put here (or after the foreach). >> >> I'm concerned that the flag didn't show up after >> adding it to >> the _DEBUG or _RELEASE variants. If you could add >> a few message >> commands around that might help see what is going >> on. The flag >> needs to be propagated. >> >> You could sprinkle a few commands like this: >> message("going to run COMMAND ${CUDA_NVCC_EXECUTABLE} >> ${nvcc_flags} -dlink ${object_files} -o ${output_file} >> ${flags}") >> >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From David.Karr at engilitycorp.com Tue Jan 6 19:10:37 2015 From: David.Karr at engilitycorp.com (David.Karr at engilitycorp.com) Date: Wed, 7 Jan 2015 00:10:37 +0000 Subject: [CMake] Unable to create project files with Visual Studio 2010 on Windows 7 Message-ID: I have just started using a new Windows 7 host with Visual Studio 2010 Professional. When I call CMake to generate my project files, I get the following output in CMakeError.log: ========================== Determining if the C compiler works failed with the following output: Change Dir: C:/________________________/__________/CMakeFiles/CMakeTmp Run Build Command:C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe cmTryCompileExec.vcxproj /p:Configuration=Debug Microsoft (R) Build Engine version 4.0.30319.17929 [Microsoft .NET Framework, version 4.0.30319.18034] Copyright (C) Microsoft Corporation. All rights reserved. Build started 1/6/2015 6:15:19 PM. Project "C:\________________________\__________\CMakeFiles\CMakeTmp\cmTryCompileExec.vcxproj" on node 1 (default targets). InitializeBuildStatus: Creating "cmTryCompileExec.dir\Debug\cmTryCompileExec.unsuccessfulbuild" because "AlwaysCreate" was specified. ClCompile: C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\CL.exe /c /Zi /nologo /W3 /WX- /Od /Ob0 /Oy- /D WIN32 /D _WINDOWS /D _DEBUG /D "CMAKE_INTDIR=\"Debug\"" /D _MBCS /Gm- /RTC1 /MDd /GS /fp:precise /Zc:wchar_t /Zc:forScope /Fo"cmTryCompileExec.dir\Debug\\" /Fd"C:/________________________/__________/CMakeFiles/CMakeTmp/Debug/cmTryCompileExec.pdb" /Gd /TC /analyze- /errorReport:queue testCCompiler.c /Zm1000 TRACKER : error TRK0002: Failed to execute command: ""C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\CL.exe" @C:\Users\nnnnnnnnnnnn\AppData\Local\Temp\tmp9db9bf329c554cb8be447cdb72535c4e.rsp". The requested operation requires elevation. [C:\________________________\__________\CMakeFiles\CMakeTmp\cmTryCompileExec.vcxproj] Done Building Project "C:\________________________\__________\CMakeFiles\CMakeTmp\cmTryCompileExec.vcxproj" (default targets) -- FAILED. Build FAILED. "C:\________________________\__________\CMakeFiles\CMakeTmp\cmTryCompileExec.vcxproj" (default target) (1) -> (ClCompile target) -> TRACKER : error TRK0002: Failed to execute command: ""C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\CL.exe" @C:\Users\nnnnnnnnnnnn\AppData\Local\Temp\tmp9db9bf329c554cb8be447cdb72535c4e.rsp". The requested operation requires elevation. [C:\________________________\__________\CMakeFiles\CMakeTmp\cmTryCompileExec.vcxproj] 0 Warning(s) 1 Error(s) Time Elapsed 00:00:00.10 ========================== The only thing I've changed in the output text is I replaced some user-specific directory names with underscores or "nnnnnnnnnnnn". This project previously built just fine on Windows XP. Moreover, my coworker, who as far as we can tell set up his Windows 7 host the same way I did (modulo some things that shouldn't matter, such as I have a copy of Emacs and he doesn't), is able to build the same project files without error. It may be noteworthy that after this failure, the file CMakeFiles\CMakeTmp\cmTryCompileExec.vcxproj does not exist, and there are no files whatsoever in CMakeFiles\CMakeTmp\cmTryCompileExec.dir\Debug. I have been trying all kinds of suggestions I have found by looking up the message "The requested operation requires elevation." I have tried setting ownership of the directories (it turns out I owned them all along), I have tried setting access rights (already set to full access), I tried turning off UAC, and I even tried repairing the installation of Visual Studio 2010. None of it made any difference. I've found some Web sites where some people have complained of problems when they had installed Visual Studio 2012 and tried to use Visual Studio 2010. But Visual Studio 2010 is the only version that has been installed on this host. This has had me dead in the water for at least a day, unable to make any progress on my actual project. Does anyone have any ideas about where to even begin to look for solutions I haven't already tried? David -------------- next part -------------- An HTML attachment was scrubbed... URL: From DLRdave at aol.com Wed Jan 7 10:58:09 2015 From: DLRdave at aol.com (David Cole) Date: Wed, 7 Jan 2015 10:58:09 -0500 Subject: [CMake] Unable to create project files with Visual Studio 2010 on Windows 7 In-Reply-To: References: Message-ID: The "The requested operation requires elevation." message indicates some sort of permissions problem (admin privileges...) Did you run VS and/or CMake as an admin one time, and then not as an admin a second time...? It should work with either all-non-admin runs or all-admin runs, but you probably can't mix-n-match from run to run. Can you start with a very simple hello world app, in a brand new "empty to start with" directory, and run CMake and VS without admin privileges? Or do you get exactly the same thing if you do that? D On Tue, Jan 6, 2015 at 7:10 PM, wrote: > I have just started using a new Windows 7 host with Visual Studio 2010 > Professional. When I call CMake to generate my project files, I get the > following output in CMakeError.log: > > ========================== > Determining if the C compiler works failed with the following output: > Change Dir: C:/________________________/__________/CMakeFiles/CMakeTmp > > Run Build Command:C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe > cmTryCompileExec.vcxproj /p:Configuration=Debug > Microsoft (R) Build Engine version 4.0.30319.17929 > [Microsoft .NET Framework, version 4.0.30319.18034] > Copyright (C) Microsoft Corporation. All rights reserved. > > Build started 1/6/2015 6:15:19 PM. > Project > "C:\________________________\__________\CMakeFiles\CMakeTmp\cmTryCompileExec.vcxproj" > on node 1 (default targets). > InitializeBuildStatus: > Creating "cmTryCompileExec.dir\Debug\cmTryCompileExec.unsuccessfulbuild" > because "AlwaysCreate" was specified. > ClCompile: > C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\CL.exe /c /Zi > /nologo /W3 /WX- /Od /Ob0 /Oy- /D WIN32 /D _WINDOWS /D _DEBUG /D > "CMAKE_INTDIR=\"Debug\"" /D _MBCS /Gm- /RTC1 /MDd /GS /fp:precise > /Zc:wchar_t /Zc:forScope /Fo"cmTryCompileExec.dir\Debug\\" > /Fd"C:/________________________/__________/CMakeFiles/CMakeTmp/Debug/cmTryCompileExec.pdb" > /Gd /TC /analyze- /errorReport:queue testCCompiler.c /Zm1000 > TRACKER : error TRK0002: Failed to execute command: ""C:\Program Files > (x86)\Microsoft Visual Studio 10.0\VC\bin\CL.exe" > @C:\Users\nnnnnnnnnnnn\AppData\Local\Temp\tmp9db9bf329c554cb8be447cdb72535c4e.rsp". > The requested operation requires elevation. > [C:\________________________\__________\CMakeFiles\CMakeTmp\cmTryCompileExec.vcxproj] > > > Done Building Project > "C:\________________________\__________\CMakeFiles\CMakeTmp\cmTryCompileExec.vcxproj" > (default targets) -- FAILED. > > Build FAILED. > > "C:\________________________\__________\CMakeFiles\CMakeTmp\cmTryCompileExec.vcxproj" > (default target) (1) -> > (ClCompile target) -> > TRACKER : error TRK0002: Failed to execute command: ""C:\Program Files > (x86)\Microsoft Visual Studio 10.0\VC\bin\CL.exe" > @C:\Users\nnnnnnnnnnnn\AppData\Local\Temp\tmp9db9bf329c554cb8be447cdb72535c4e.rsp". > The requested operation requires elevation. > [C:\________________________\__________\CMakeFiles\CMakeTmp\cmTryCompileExec.vcxproj] > > 0 Warning(s) > 1 Error(s) > > Time Elapsed 00:00:00.10 > ========================== > > The only thing I've changed in the output text is I replaced some > user-specific directory names with underscores or "nnnnnnnnnnnn". > > This project previously built just fine on Windows XP. Moreover, my > coworker, who as far as we can tell set up his Windows 7 host the same way I > did (modulo some things that shouldn't matter, such as I have a copy of > Emacs and he doesn't), is able to build the same project files without > error. > > It may be noteworthy that after this failure, the file > CMakeFiles\CMakeTmp\cmTryCompileExec.vcxproj does not exist, and there are > no files whatsoever in CMakeFiles\CMakeTmp\cmTryCompileExec.dir\Debug. > > I have been trying all kinds of suggestions I have found by looking up the > message "The requested operation requires elevation." I have tried setting > ownership of the directories (it turns out I owned them all along), I have > tried setting access rights (already set to full access), I tried turning > off UAC, and I even tried repairing the installation of Visual Studio 2010. > None of it made any difference. > > I've found some Web sites where some people have complained of problems when > they had installed Visual Studio 2012 and tried to use Visual Studio 2010. > But Visual Studio 2010 is the only version that has been installed on this > host. > > This has had me dead in the water for at least a day, unable to make any > progress on my actual project. Does anyone have any ideas about where to > even begin to look for solutions I haven't already tried? > > David > > > > > -- > > 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 From robert.maynard at kitware.com Wed Jan 7 11:27:20 2015 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 7 Jan 2015 11:27:20 -0500 Subject: [CMake] FindCUDA ignores project dependencies when separable compilation is on In-Reply-To: References: <4634e484e7954171a22b8bebc07ae578@EXCHANGE-CAS1.physics.ox.ac.uk> <54AA8449.70404@physics.ox.ac.uk> <24de6f36f39c40caaf533f87173c6f83@EXCHANGE-CAS1.physics.ox.ac.uk> <54AAFAD3.2080102@physics.ox.ac.uk> <6c2cbb1f096c4cd29c49a0dbfeaec934@EXCHANGE-CAS2.physics.ox.ac.uk> <54AB138F.1010406@physics.ox.ac.uk> <54AC0528.6020302@physics.ox.ac.uk> <51d0f76d2f384f3ca5578a7697787274@EXCHANGE-CAS2.physics.ox.ac.uk> <54AC15EF.9000800@physics.ox.ac.uk> <6e226ac20e2d46a4805c68f614fd8c6b@EXCHANGE-CAS1.physics.ox.ac.uk> <54AC296D.7020504@physics.ox.ac.uk> <8b196a38d5dc4badbce63d4d5f58a4ca@EXCHANGE-CAS1.physics.ox.ac.uk> <54AC466F.5060103@physics.ox.ac.uk> <833e51427f8c48fc8e4a337b73a9ad12@EXCHANGE-CAS1.physics.ox.ac.uk> <54AC6FD5.5050103@physics.ox.ac.uk> Message-ID: I have merged the branch into next for you. On Tue, Jan 6, 2015 at 6:50 PM, James Bigler wrote: > I've pushed a change into 'stage' [1] that I hope to get into 'next' > (something isn't working with my ssh authentication). > > James > > [1] commit b4e54f9b8c748f78d16e9da055a7e0436d7654ef > Author: James Bigler <@> > Date: Tue Jan 6 16:28:05 2015 -0700 > > FindCUDA: Add relevant CMAKE_{C,CXX}_FLAGS for separable compilation > > Previously only the CMAKE_{C,CXX}_FLAGS_ flags were inspected > for relevant flags when compiling the intermediate link file. We need > to also consider the configuration agnostic flags, CMAKE_{C,CXX}_FLAGS > as well. > > > On Tue, Jan 6, 2015 at 4:29 PM, Irwin Zaid > wrote: >> >> Okay, so to conclude: >> >> Should we make a PR to include your patched code so CMAKE_CXX_FLAGS just >> works? I think this makes sense, as I would never have thought to do the >> DEBUG / RELEASE stuff. I can do the PR, unless you want to. >> >> And, of course, thanks for all your help! >> >> Irwin >> >> James Bigler wrote: >>> >>> Right, if you don't specify the CMAKE_BUILD_TYPE you are only getting the >>> CMAKE_CXX_FLAGS and none of the build type specific flags such as >>> CMAKE_CXX_FLAGS_DEBUG. >>> >>> There is still the issue that I wasn't bringing in the CMAKE_CXX_FLAGS >>> (which is why my patch helped). >>> >>> James >>> >>> On Tue, Jan 6, 2015 at 1:32 PM, Irwin Zaid >> > wrote: >>> >>> Wait, hold on. The -fPIC does get passed to everything if I set >>> the build mode to Debug by passing -DCMAKE_BUILD_TYPE=Debug to >>> CMake. Is that what I should be doing? (Sorry about that, if yes.) >>> >>> If that's the case, what is the correct way to get -fPIC passed to >>> the intermediate linking? Am I meant to always build in Debug mode >>> just for that? >>> >>> Irwin >>> >>> Irwin Zaid wrote: >>> >>> I just double-checked. The -fPIC is definitely there for each >>> individual >>> object file, but not for the *_intermediate_link.o. >>> >>> Irwin >>> >>> James Bigler wrote: >>> >>> >>> James >>> >>> On Jan 6, 2015, at 11:29 AM, Irwin >>> Zaid>> > wrote: >>> >>> Okay, so I've gone and put the messages into >>> FindCUDA.cmake. I specifically put them right before >>> and after the foreach() in >>> CUDA_LINK_SEPARARABLE___COMPILATION_OBJECTS. The >>> output is the following. >>> >>> Is >>> >>> "$<$:-Xcompiler>__;$<$:-fPIC>" >>> supposed to be that way? That looks weird. >>> >>> Yeah. That looks right. It means the argument will only be >>> run when the build configuration matches DEBUG. This is >>> less exciting for Makefiles builds since there is only one >>> configuration preset at a time, but for things like Visual >>> Studio where you have multiple build configs from a single >>> CMake configure this makes a custom command for each >>> without having to rely on scripts to dispatch the correct >>> command (that's how the rest of FindCUDA works by the way). >>> >>> As far as the rest of these, I'm concerned the fPIC flag >>> comes and goes. Perhaps something is modifying the flags. >>> Do the commands with fPIC actually get run with fPIC (use >>> make VERBOSE=1)? >>> >>> -- >>> >>> going to run COMMAND /usr/local/cuda/bin/nvcc >>> -m64;-ccbin;"/usr/bin/cc" -dlink >>> >>> /home/irwin/Repositories/__libdynd/build/CMakeFiles/__libdynd.dir/src/dynd/kernels/.__/libdynd_generated_assignment___kernels.cu.o;/home/irwin/__Repositories/libdynd/build/__CMakeFiles/libdynd.dir/src/__dynd/func/./libdynd_generated___arithmetic.cu.o;/home/irwin/__Repositories/libdynd/build/__CMakeFiles/libdynd.dir/src/__dynd/func/./libdynd_generated___elwise.cu.o;/home/irwin/__Repositories/libdynd/build/__CMakeFiles/libdynd.dir/src/__dynd/kernels/./libdynd___generated_ckernel_builder.cu >>> >>> .__o;/home/irwin/Repositories/__libdynd/build/CMakeFiles/__libdynd.dir/src/dynd/types/./__libdynd_generated_dynd___complex.cu.o;/home/irwin/__Repositories/libdynd/build/__CMakeFiles/libdynd.dir/src/__dynd/types/./libdynd___generated_dynd_float16.cu.o;/__home/irwin/Repositories/__libdynd/build/CMakeFiles/__libdynd.dir/src/dynd/types/./__libdynd_generated_dynd___float128.cu.o;/home/irwin/__Repositories/libdynd/build/__CMakeFiles/libdynd.dir/src/__dynd/types/./libdynd___generated_d >>> >>> y >>> >>> >>> nd_int128.cu.o;/home/irwin/__Repositories/libdynd/build/__CMakeFiles/libdynd.dir/src/d >>> >>> ynd/types/./libdynd_generated___dynd_uint128.cu.o -o >>> >>> /home/irwin/Repositories/__libdynd/build/CMakeFiles/__libdynd.dir/./libdynd___intermediate_link.o >>> >>> going to run COMMAND /usr/local/cuda/bin/nvcc >>> -m64;-ccbin;"/usr/bin/cc" -dlink >>> >>> /home/irwin/Repositories/__libdynd/build/CMakeFiles/__libdynd.dir/src/dynd/kernels/.__/libdynd_generated_assignment___kernels.cu.o;/home/irwin/__Repositories/libdynd/build/__CMakeFiles/libdynd.dir/src/__dynd/func/./libdynd_generated___arithmetic.cu.o;/home/irwin/__Repositories/libdynd/build/__CMakeFiles/libdynd.dir/src/__dynd/func/./libdynd_generated___elwise.cu.o;/home/irwin/__Repositories/libdynd/build/__CMakeFiles/libdynd.dir/src/__dynd/kernels/./libdynd___generated_ckernel_builder.cu >>> >>> .__o;/home/irwin/Repositories/__libdynd/build/CMakeFiles/__libdynd.dir/src/dynd/types/./__libdynd_generated_dynd___complex.cu.o;/home/irwin/__Repositories/libdynd/build/__CMakeFiles/libdynd.dir/src/__dynd/types/./libdynd___generated_dynd_float16.cu.o;/__home/irwin/Repositories/__libdynd/build/CMakeFiles/__libdynd.dir/src/dynd/types/./__libdynd_generated_dynd___float128.cu.o;/home/irwin/__Repositories/libdynd/build/__CMakeFiles/libdynd.dir/src/__dynd/types/./libdynd___generated_d >>> >>> y >>> >>> >>> nd_int128.cu.o;/home/irwin/__Repositories/libdynd/build/__CMakeFiles/libdynd.dir/src/d >>> >>> ynd/types/./libdynd_generated___dynd_uint128.cu.o -o >>> >>> /home/irwin/Repositories/__libdynd/build/CMakeFiles/__libdynd.dir/./libdynd___intermediate_link.o >>> $<$:-Xcompiler>;__$<$:-fPIC> >>> going to run COMMAND /usr/local/cuda/bin/nvcc >>> -m64;-ccbin;"/usr/bin/cc" -dlink >>> >>> /home/irwin/Repositories/__libdynd/build/tests/__CMakeFiles/test_libdynd.dir/__func/./test_libdynd_generated___test_apply.cu.o;/home/irwin/__Repositories/libdynd/build/__tests/CMakeFiles/test_libdynd.__dir/func/./test_libdynd___generated_test_lift_arrfunc.__cu.o >>> -o >>> >>> /home/irwin/Repositories/__libdynd/build/tests/__CMakeFiles/test_libdynd.dir/./__test_libdynd_intermediate___link.o >>> >>> going to run COMMAND /usr/local/cuda/bin/nvcc >>> -m64;-ccbin;"/usr/bin/cc" -dlink >>> >>> /home/irwin/Repositories/__libdynd/build/tests/__CMakeFiles/test_libdynd.dir/__func/./test_libdynd_generated___test_apply.cu.o;/home/irwin/__Repositories/libdynd/build/__tests/CMakeFiles/test_libdynd.__dir/func/./test_libdynd___generated_test_lift_arrfunc.__cu.o >>> -o >>> >>> /home/irwin/Repositories/__libdynd/build/tests/__CMakeFiles/test_libdynd.dir/./__test_libdynd_intermediate___link.o >>> $<$:-Xcompiler>;__$<$:-fPIC> >>> >>> James Bigler wrote: >>> >>> I meant putting messages into FindCUDA.cmake itself. >>> >>> Only certain flags are propagated for the >>> intermediate link file >>> compilation, because I've had a lot of trouble >>> over the years for >>> propagating all the host flags. This set of flags >>> is filtered by the >>> function _cuda_get_important_host___flags. Right >>> now only the >>> CMAKE_CXX_FLAGS_*CONFIG* are being processed. None >>> of the flags in the >>> configuration free variable are passed. That was >>> the "patch" I wanted >>> you to try. Why -fPIC in the configuration >>> specific CMAKE_CXX_FLAGS >>> wasn't working, I'm not sure. The code is there to >>> do it. >>> >>> On Tue, Jan 6, 2015 at 10:05 AM, Irwin >>> Zaid>> >>> >> >> wrote: >>> >>> Right, when I modify FindCUDA.cmake as you >>> describe everything >>> works. So that's good. >>> >>> Without doing that, I still don't see >>> CMAKE_CXX_FLAGS_DEBUG >>> propagating its flags to the intermediate link >>> file. Did you mean to >>> put message commands into >>> CUDA_LINK_SEPARABLE_____COMPILATION_OBJECTS >>> itself? When I put them into my main >>> CMakeLists.txt, nothing is >>> printed for ${nvcc_flags} or the other variables. >>> >>> James Bigler wrote: >>> >>> On Tue, Jan 6, 2015 at 8:54 AM, Irwin Zaid >>> >> >>> >> > >>> >> ____ac.uk >>> >>> >> >>> wrote: >>> >>> Okay, an update on this. >>> >>> 2) This is trickier and, unfortunately, still not >>> working. We are >>> already adding -fPIC to CMAKE_CXX_FLAGS, should >>> that not be >>> enough? I also tried adding it to both >>> CMAKE_CXX_FLAGS_DEBUG and >>> CMAKE_CXX_FLAGS_RELEASE, with no effect. >>> >>> Looking into FindCUDA.CMake at >>> CUDA_LINK_SEPARABLE_______COMPILATION_OBJECTS, I >>> find code very >>> similar to what you are describing. Are you saying >>> that in >>> addition to what is below, we need to add what you >>> proposed? This >>> is what I see. >>> >>> -- >>> >>> >>> It can be put here (before this foreach). >>> >>> foreach(config ${CUDA_configuration_types}) >>> string(TOUPPER ${config} config_upper) >>> # Add config specific flags >>> foreach(f ${CUDA_NVCC_FLAGS_${config_______upper}}) >>> list(APPEND config_specific_flags >>> $<$:${f}>) >>> endforeach() >>> set(important_host_flags) >>> >>> _cuda_get_important_host_______flags(important_host_flags >>> >>> ${CMAKE_${CUDA_C_OR_CXX}_______FLAGS_${config_upper}}) >>> foreach(f ${important_host_flags}) >>> list(APPEND flags >>> $<$:-______Xcompiler> >>> $<$:${f}>) >>> endforeach() >>> endforeach() >>> >>> >>> Or it can be put here (or after the foreach). >>> >>> I'm concerned that the flag didn't show up after >>> adding it to >>> the _DEBUG or _RELEASE variants. If you could add >>> a few message >>> commands around that might help see what is going >>> on. The flag >>> needs to be propagated. >>> >>> You could sprinkle a few commands like this: >>> message("going to run COMMAND ${CUDA_NVCC_EXECUTABLE} >>> ${nvcc_flags} -dlink ${object_files} -o >>> ${output_file} >>> ${flags}") >>> >>> >>> >>> > > > -- > > 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 From David.Karr at engilitycorp.com Wed Jan 7 12:46:36 2015 From: David.Karr at engilitycorp.com (David.Karr at engilitycorp.com) Date: Wed, 7 Jan 2015 17:46:36 +0000 Subject: [CMake] Unable to create project files with Visual Studio 2010 on Windows 7 In-Reply-To: References: Message-ID: I tried this with a CMakeLists file that contains only a PROJECT and ADD_EXECUTABLE (with a single C++ source file). The only things present in the directory before running CMake were the C++ file, CMakeLists.txt, and a batch file that I used to run CMake. I still get the "requires elevation" error even when I run cmake.exe from a command line as administrator. It also doesn't seem to matter whether I select Visual Studio 10 or Visual Studio 10 Win64 as my generator. I thought maybe the problem was that I didn't "install" CMake, rather (as I've been doing for years, due to the way this project is version-controlled) I set CMAKE_ROOT to a directory that happens to contain the CMake files and then ran a copy of cmake.exe. I just tried the exercise again after doing a regular installation of CMake 3.1.0 (using default choices only) and came up with the same result. (Actually not quite: now -G "Visual Studio 10" says "The C compiler identification is unknown", and only -G "Visual Studio 10 Win64" produces the "elevation" error, whereas with my previous uninstalled version both generators resulted in "elevation".) David > -----Original Message----- > From: David Cole [mailto:DLRdave at aol.com] > Sent: Wednesday, January 07, 2015 10:58 AM > To: Karr, David A. @ EngilityCorp > Cc: cmake at cmake.org > Subject: Re: [CMake] Unable to create project files with Visual Studio > 2010 on Windows 7 > > The "The requested operation requires elevation." message indicates > some sort of permissions problem (admin privileges...) > > Did you run VS and/or CMake as an admin one time, and then not as an > admin a second time...? > > It should work with either all-non-admin runs or all-admin runs, but > you probably can't mix-n-match from run to run. > > Can you start with a very simple hello world app, in a brand new "empty > to start with" directory, and run CMake and VS without admin > privileges? > > Or do you get exactly the same thing if you do that? > > > D > > > > On Tue, Jan 6, 2015 at 7:10 PM, wrote: > > I have just started using a new Windows 7 host with Visual Studio > 2010 > > Professional. When I call CMake to generate my project files, I get > > the following output in CMakeError.log: > > > > ========================== > > Determining if the C compiler works failed with the following output: > > Change Dir: > C:/________________________/__________/CMakeFiles/CMakeTmp > > > > Run Build > > Command:C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe > > cmTryCompileExec.vcxproj /p:Configuration=Debug Microsoft (R) Build > > Engine version 4.0.30319.17929 [Microsoft .NET Framework, version > > 4.0.30319.18034] Copyright (C) Microsoft Corporation. All rights > > reserved. > > > > Build started 1/6/2015 6:15:19 PM. > > Project > > > "C:\________________________\__________\CMakeFiles\CMakeTmp\cmTryCompil > eExec.vcxproj" > > on node 1 (default targets). > > InitializeBuildStatus: > > Creating > "cmTryCompileExec.dir\Debug\cmTryCompileExec.unsuccessfulbuild" > > because "AlwaysCreate" was specified. > > ClCompile: > > C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\CL.exe > /c > > /Zi /nologo /W3 /WX- /Od /Ob0 /Oy- /D WIN32 /D _WINDOWS /D _DEBUG /D > > "CMAKE_INTDIR=\"Debug\"" /D _MBCS /Gm- /RTC1 /MDd /GS /fp:precise > > /Zc:wchar_t /Zc:forScope /Fo"cmTryCompileExec.dir\Debug\\" > > > /Fd"C:/________________________/__________/CMakeFiles/CMakeTmp/Debug/cm > TryCompileExec.pdb" > > /Gd /TC /analyze- /errorReport:queue testCCompiler.c /Zm1000 TRACKER > > : error TRK0002: Failed to execute command: ""C:\Program Files > > (x86)\Microsoft Visual Studio 10.0\VC\bin\CL.exe" > > > @C:\Users\nnnnnnnnnnnn\AppData\Local\Temp\tmp9db9bf329c554cb8be447cdb72 > 535c4e.rsp". > > The requested operation requires elevation. > > > [C:\________________________\__________\CMakeFiles\CMakeTmp\cmTryCompi > > leExec.vcxproj] > > > > > > Done Building Project > > > "C:\________________________\__________\CMakeFiles\CMakeTmp\cmTryCompil > eExec.vcxproj" > > (default targets) -- FAILED. > > > > Build FAILED. > > > > > "C:\________________________\__________\CMakeFiles\CMakeTmp\cmTryCompil > eExec.vcxproj" > > (default target) (1) -> > > (ClCompile target) -> > > TRACKER : error TRK0002: Failed to execute command: ""C:\Program > > Files (x86)\Microsoft Visual Studio 10.0\VC\bin\CL.exe" > > > @C:\Users\nnnnnnnnnnnn\AppData\Local\Temp\tmp9db9bf329c554cb8be447cdb72 > 535c4e.rsp". > > The requested operation requires elevation. > > > [C:\________________________\__________\CMakeFiles\CMakeTmp\cmTryCompi > > leExec.vcxproj] > > > > 0 Warning(s) > > 1 Error(s) > > > > Time Elapsed 00:00:00.10 > > ========================== > > > > The only thing I've changed in the output text is I replaced some > > user-specific directory names with underscores or "nnnnnnnnnnnn". > > > > This project previously built just fine on Windows XP. Moreover, my > > coworker, who as far as we can tell set up his Windows 7 host the > same > > way I did (modulo some things that shouldn't matter, such as I have a > > copy of Emacs and he doesn't), is able to build the same project > files > > without error. > > > > It may be noteworthy that after this failure, the file > > CMakeFiles\CMakeTmp\cmTryCompileExec.vcxproj does not exist, and > there > > are no files whatsoever in > CMakeFiles\CMakeTmp\cmTryCompileExec.dir\Debug. > > > > I have been trying all kinds of suggestions I have found by looking > up > > the message "The requested operation requires elevation." I have > tried > > setting ownership of the directories (it turns out I owned them all > > along), I have tried setting access rights (already set to full > > access), I tried turning off UAC, and I even tried repairing the > installation of Visual Studio 2010. > > None of it made any difference. > > > > I've found some Web sites where some people have complained of > > problems when they had installed Visual Studio 2012 and tried to use > Visual Studio 2010. > > But Visual Studio 2010 is the only version that has been installed on > > this host. > > > > This has had me dead in the water for at least a day, unable to make > > any progress on my actual project. Does anyone have any ideas about > > where to even begin to look for solutions I haven't already tried? > > > > David > > > > > > > > > > -- > > > > 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 From David.Karr at engilitycorp.com Wed Jan 7 13:18:17 2015 From: David.Karr at engilitycorp.com (David.Karr at engilitycorp.com) Date: Wed, 7 Jan 2015 18:18:17 +0000 Subject: [CMake] Unable to create project files with Visual Studio 2010 on Windows 7 References: Message-ID: A small correction: the problem with "The C compiler identification is unknown" seems to have been due to the fact that I forgot to open that particular command window as administrator. In a new command window, run as administrator, both -G "Visual Studio 10" and -G "Visual Studio 10 Win64" produce the "required elevation" error, same as before. Go figure. David > -----Original Message----- > From: Karr, David A. @ EngilityCorp > Sent: Wednesday, January 07, 2015 12:47 PM > To: 'David Cole' > Cc: cmake at cmake.org > Subject: RE: [CMake] Unable to create project files with Visual Studio > 2010 on Windows 7 > > I tried this with a CMakeLists file that contains only a PROJECT and > ADD_EXECUTABLE (with a single C++ source file). The only things present > in the directory before running CMake were the C++ file, > CMakeLists.txt, and a batch file that I used to run CMake. I still get > the "requires elevation" error even when I run cmake.exe from a command > line as administrator. It also doesn't seem to matter whether I select > Visual Studio 10 or Visual Studio 10 Win64 as my generator. > > I thought maybe the problem was that I didn't "install" CMake, rather > (as I've been doing for years, due to the way this project is version- > controlled) I set CMAKE_ROOT to a directory that happens to contain the > CMake files and then ran a copy of cmake.exe. I just tried the exercise > again after doing a regular installation of CMake 3.1.0 (using default > choices only) and came up with the same result. (Actually not quite: > now -G "Visual Studio 10" says "The C compiler identification is > unknown", and only -G "Visual Studio 10 Win64" produces the "elevation" > error, whereas with my previous uninstalled version both generators > resulted in "elevation".) > > David From jean-francois.rit at der.edf.fr Wed Jan 7 13:23:57 2015 From: jean-francois.rit at der.edf.fr (Jean-Francois Rit) Date: Wed, 07 Jan 2015 19:23:57 +0100 Subject: [CMake] [Ctest] How to collect tests results in a CTestSteer script Message-ID: <1420655037.28671.21.camel@dsp0657867> I would like to perform some action -- like copying files from the build dir -- conditionally on tests success, at the end of a CTestSteer script. The first task is to collect the tests results, after a ctest_test() has been run. How would I do this in script ? -- Jean-Fran?ois Rit Ing?nieur chercheur EDF R&D D?pt. mat?riaux et m?canique des composants Avenue des Renardi?res Ecuelles 77818 Moret-sur-Loing cedex France j-f.rit at edf.fr T?l: + 33 1 60 73 64 60 From DLRdave at aol.com Wed Jan 7 14:03:05 2015 From: DLRdave at aol.com (David Cole) Date: Wed, 7 Jan 2015 14:03:05 -0500 Subject: [CMake] Unable to create project files with Visual Studio 2010 on Windows 7 In-Reply-To: References: Message-ID: What do you mean when you say "I set CMAKE_ROOT to a directory" ?? That should not be necessary, no matter how you're running cmake... Is that an ENV var or a CMake variable you're setting somewhere? D On Wed, Jan 7, 2015 at 1:18 PM, wrote: > A small correction: the problem with "The C compiler identification is unknown" seems to have been due to the fact that I forgot to open that particular command window as administrator. In a new command window, run as administrator, both -G "Visual Studio 10" and -G "Visual Studio 10 Win64" produce the "required elevation" error, same as before. Go figure. > > David > >> -----Original Message----- >> From: Karr, David A. @ EngilityCorp >> Sent: Wednesday, January 07, 2015 12:47 PM >> To: 'David Cole' >> Cc: cmake at cmake.org >> Subject: RE: [CMake] Unable to create project files with Visual Studio >> 2010 on Windows 7 >> >> I tried this with a CMakeLists file that contains only a PROJECT and >> ADD_EXECUTABLE (with a single C++ source file). The only things present >> in the directory before running CMake were the C++ file, >> CMakeLists.txt, and a batch file that I used to run CMake. I still get >> the "requires elevation" error even when I run cmake.exe from a command >> line as administrator. It also doesn't seem to matter whether I select >> Visual Studio 10 or Visual Studio 10 Win64 as my generator. >> >> I thought maybe the problem was that I didn't "install" CMake, rather >> (as I've been doing for years, due to the way this project is version- >> controlled) I set CMAKE_ROOT to a directory that happens to contain the >> CMake files and then ran a copy of cmake.exe. I just tried the exercise >> again after doing a regular installation of CMake 3.1.0 (using default >> choices only) and came up with the same result. (Actually not quite: >> now -G "Visual Studio 10" says "The C compiler identification is >> unknown", and only -G "Visual Studio 10 Win64" produces the "elevation" >> error, whereas with my previous uninstalled version both generators >> resulted in "elevation".) >> >> David > > From domen.vrankar at gmail.com Wed Jan 7 15:54:09 2015 From: domen.vrankar at gmail.com (Domen Vrankar) Date: Wed, 7 Jan 2015 21:54:09 +0100 Subject: [CMake] Specifying a file owner In-Reply-To: <54A2F691.3020905@doolittle.us.com> References: <54A2F691.3020905@doolittle.us.com> Message-ID: > Hi, > > I was looking at https://www.cmake.org/Bug/view.php?id=3602 "Add > possibility to change file owner into install macro". I am also interested in this feature but mostly because of packaging limitations - implementing this feature would give CPackRPM the ability to set user and group for every file/directory/link that generated RPM will contain. This can already be done by a workaround - providing the file with user and group in CPACK_RPM__USER_FILELIST- but extending install command would be a more elegant solution. > I believe we should in fact support specifying the file owner, and > handle the case where that owner does not exist in the same way (from a > user experience) as we handle platforms that don't support SETUID - i.e. > do nothing (logging some kind of non-fatal error would be good). I am usually using install target for installing the entire project locally for testing and in such cases I prefer to have everything installed as current user in a subdirectory of my build directory. I believe that this use case should be solved by providing a new target - rootless_install - which ignores USER and GROUP setting in INSTALL commands. On the other hand when I want to install something permanently on my system after building the project I would prefer that user and group settings are applied and in such case I would prefer a fatal error if user/group permission can not be applied (preferably with CMake rolling back the changes that it already made on the file system - new feature?). This could be part of current install target. > Automatically creating a non-existing user would also be nice but is > orthogonal and should be handled as a separate feature request rather > than muddying the waters around this feature discussion. Not certain if I'd like this feature or not but I agree that it should be discussed as a separate feature. There was also a third case provided by Brad: 3.) What if installing into a DESTDIR that exists on a mount point and the user names should be translated to uids with $(DESTDIR)/etc/passwd instead of /etc/passwd? How should this be specified? I've already encountered a situation where I mounted a partition that had files with users and groups that were present in /etc/passwd but under different uids and gids so ls -l was showing numbers instead of names. In such case only root user may create new files since they will have a different uids and gids so nothing changes... I'd say that different uids for the same user name is users problem and should be ignored by CMake. Regards, Domen From David.Karr at engilitycorp.com Wed Jan 7 16:09:12 2015 From: David.Karr at engilitycorp.com (David.Karr at engilitycorp.com) Date: Wed, 7 Jan 2015 21:09:12 +0000 Subject: [CMake] Unable to create project files with Visual Studio 2010 on Windows 7 In-Reply-To: References: Message-ID: > What do you mean when you say "I set CMAKE_ROOT to a directory" ?? > > That should not be necessary, no matter how you're running cmake... > > Is that an ENV var or a CMake variable you're setting somewhere? CMAKE_ROOT was an ENV variable used by a script outside of CMake that (in the more complicated build that I was originally describing) would invoke the actual CMake executable. I've been using that script for so long I had forgotten where the requirement for CMAKE_ROOT came from. As it turns out, in at least one of the command windows where I tried the "hello world" test case, I did not actually set CMAKE_ROOT after all. That symbol (or lack of it) does not seem to have any bearing on the problem I'm experiencing. David From bill.hoffman at kitware.com Wed Jan 7 16:32:20 2015 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Wed, 07 Jan 2015 16:32:20 -0500 Subject: [CMake] Unable to create project files with Visual Studio 2010 on Windows 7 In-Reply-To: References: Message-ID: <54ADA5E4.6030002@kitware.com> On 1/6/2015 7:10 PM, David.Karr at engilitycorp.com wrote: > I have just started using a new Windows 7 host with Visual Studio 2010 > Professional. When I call CMake to generate my project files, I get the > following output in CMakeError.log: Does your visual studio work without CMake? Can you create a simple project with the IDE and build it? Can you then build that project from the command line like CMake does: C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe yourproject.vcxproj /p:Configuration=Debug -Bill From paul at mad-scientist.net Thu Jan 8 12:06:16 2015 From: paul at mad-scientist.net (Paul Smith) Date: Thu, 08 Jan 2015 12:06:16 -0500 Subject: [CMake] [3.1.0] [PATCH] CMP0054 in CMakeDetermineCXXCompiler.cmake Message-ID: <1420736776.32179.6.camel@mad-scientist.net> Hi all. I'm testing an upgrade to CMake 3.1.0 (from 2.8.12.2) and seeing a weird warning, but ONLY on Windows; it works fine on GNU/Linux and OSX: -- The C compiler identification is MSVC 16.0.40219.1 -- Check for working C compiler using: Visual Studio 10 2010 Win64 -- Check for working C compiler using: Visual Studio 10 2010 Win64 -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- The CXX compiler identification is MSVC 16.0.40219.1 CMake Warning (dev) at obj/REPOS/nuo3rdparty/common/cmake/share/cmake-3.1/Modules/CMakeDetermineCXXCompiler.cmake:106 (if): Policy CMP0054 is not set: Only interpret if() arguments as variables or keywords when unquoted. Run "cmake --help-policy CMP0054" for policy details. Use the cmake_policy command to set the policy and suppress this warning. Quoted variables like "MSVC" will no longer be dereferenced when the policy is set to NEW. Since the policy is not set the OLD behavior will be used. Call Stack (most recent call first): CMakeLists.txt:26 (enable_language) This warning is for project developers. Use -Wno-dev to suppress it. -- Check for working CXX compiler using: Visual Studio 10 2010 Win64 -- Check for working CXX compiler using: Visual Studio 10 2010 Win64 -- works If I apply the attached patch it seems to fix the problem...? -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-cmake-fix-CMakeDetermineCXXCompiler.patch Type: text/x-patch Size: 824 bytes Desc: not available URL: From walkup at us.ibm.com Thu Jan 8 12:44:35 2015 From: walkup at us.ibm.com (Bob Walkup) Date: Thu, 8 Jan 2015 12:44:35 -0500 Subject: [CMake] cmake FortranCInterface test fails in a linking step due to the -rdynamic option in Linux-GNU.cmake Message-ID: I am attempting to build an application that uses cmake, but encountered an issue that is present in the most recent cmake versions. The system is Linux, and the problem occurs with a FortranCInterface test, when the Fortran compiler is IBM XL Fortran (the problem does not arise with gfortran). The project's CMakeLists.txt file contains : include(FortranCInterface) ... FortranCInterface_VERIFY(CXX) ... With the XL Fortran compiler, the command that fails is : /opt/ibmcmp/xlf/15.1.1/bin/xlf90_r CMakeFiles/FortranCInterface.dir/main.F.o CMakeFiles/FortranCInterface.dir/call_sub.f.o CMakeFiles/FortranCInterface.dir/call_mod.f90.o -o FortranCInterface -rdynamic libsymbols.a libmyfort.a ***/opt/ibm/xlf/15.1.1/bin/.orig/xlf90_r: 1501-210 (S) command option ynamic contains an incorrect subargument*** The "-rdynamic" option is added by the cmake infrastructure via the file " Modules/Platform/Linux-GNU.cmake ", which contains : set(CMAKE_SHARED_LIBRARY_LINK_${lang}_FLAGS "-rdynamic") I think it would be preferable to replace "-rdynamic" with "-Wl,-export-dynamic" as follows: set(CMAKE_SHARED_LIBRARY_LINK_${lang}_FLAGS "-Wl,-export-dynamic") in the Linux-GNU.cmake file that is provided by cmake. I should mention that the system is Linux and that GNU compilers are used for C and C++. The problem is that the cmake infrastructure adds the "-rdynamic" option when the XL Fortran compiler script is used as the linker during the FortranCInterface test, but "-rdynamic" is an option that is specific to the GNU compiler set, and the "-r" conflicts with an XL Fortran compiler option, resulting in a linking failure. However, "-rdynamic" is fully equivalent to "-Wl,-export-dynamic", which explicitly passes the correct option to the GNU ld command (this is Linux), avoiding any such conflicts. I tried some other approaches including adding lines like these to the project's CMakeLists.txt file, without success : set(CMAKE_SHARED_LIBRARY_LINK_CXX_FLAGS "-Wl,-export-dynamic") set(CMAKE_SHARED_LIBRARY_LINK_C_FLAGS "-Wl,-export-dynamic") set(CMAKE_SHARED_LIBRARY_LINK_Fortran_FLAGS "-Wl,-export-dynamic") The "-rdynamic" option listed in the Linux-GNU.cmake file still got into the linking script and caused linking to fail. The only way that I found to work around the problem was to edit the Linux-GNU.cmake file in the cmake install path and replace "-rdynamic" with "-Wl.-export-dynamic", as indicated above. I believe that replacing "-rdynamic" with "-Wl,-export-dynamic" is generally valid on Linux systems, and is clearly preferable. If there are other ways to address this issue, I would like to learn about them. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Thu Jan 8 13:30:30 2015 From: brad.king at kitware.com (Brad King) Date: Thu, 08 Jan 2015 13:30:30 -0500 Subject: [CMake] cmake FortranCInterface test fails in a linking step due to the -rdynamic option in Linux-GNU.cmake In-Reply-To: References: Message-ID: <54AECCC6.2070203@kitware.com> On 1/8/2015 12:44 PM, Bob Walkup wrote: > I think it would be preferable to replace "-rdynamic" with > "-Wl,--export-dynamic" as follows: > > set(CMAKE_SHARED_LIBRARY_LINK_${lang}_FLAGS "-Wl,--export-dynamic") > > in the Linux-GNU.cmake file that is provided by cmake. What compiler id is reported when CMake enables Fortran? The Linux-GNU module's behavior should not be getting invoked for XL Fortran because the Fortran compiler id is "XL", not "GNU". I'd like to understand how the option makes it to the link line: /opt/ibmcmp/xlf/15.1.1/bin/xlf90_r ... -rdynamic ... Clearly it is choosing the Fortran compiler to drive the linker. However, this means that CMAKE_SHARED_LIBRARY_LINK_Fortran_FLAGS should be used to get the flags. How does that get -rdynamic into it? Are you running in a fresh build tree with no remnants from a gfortran build? You could run cmake with the "--trace" option to get very verbose output about how the execution proceeds. It will be too much to post to this list so try reading through it yourself or send it to me off list. Thanks, -Brad From ggarra13 at gmail.com Thu Jan 8 15:46:50 2015 From: ggarra13 at gmail.com (Gonzalo Garramuno) Date: Thu, 08 Jan 2015 17:46:50 -0300 Subject: [CMake] Creating an installer using cpack Message-ID: <54AEECBA.6090609@gmail.com> I have a cmake file to build my project (mrViewer). The project has additional script files that are not mentioned in my cmake file. The project also has dependencies on c libraries installed elsewhere (/usr/local, etc). The tgz,deb and rpm files currently contain just the main executable after a: ADD_EXECUTABLE( mrViewer WIN32 ${SOURCES} ) TARGET_LINK_LIBRARIES( mrViewer ${LIBRARIES} ) INSTALL( TARGETS mrViewer RUNTIME DESTINATION bin LIBRARY DESTINATION lib ) What I would like to have is a cmake sample file that shows how to: a) Install the script files respecting its local location. b) Install the c libraries in a local lib directory. for cpack packaging. Thank you very much in advance, Gonzalo From dschepler at scalable-networks.com Thu Jan 8 16:05:44 2015 From: dschepler at scalable-networks.com (Daniel Schepler) Date: Thu, 8 Jan 2015 21:05:44 +0000 Subject: [CMake] Creating an installer using cpack In-Reply-To: <54AEECBA.6090609@gmail.com> References: <54AEECBA.6090609@gmail.com> Message-ID: For (a): If by "respecting its local location", you mean you want the scripts to be in the same location in the installation directory as it is in the source directory, we've been using the functions below (in cmake/installutils.cmake). macro (split_install_args files_var install_args_var) set(split_install_args_in_install_args 0) set(${files_var}) set(${install_args_var}) foreach (arg ${ARGN}) if (arg STREQUAL "COMPONENT" OR arg STREQUAL "PERMISSIONS" OR arg STREQUAL "CONFIGURATIONS" OR arg STREQUAL "RENAME" OR arg STREQUAL "OPTIONAL" OR arg STREQUAL "PATTERN" OR arg STREQUAL "REGEX" OR arg STREQUAL "USE_SOURCE_PERMISSIONS") set(split_install_args_in_install_args 1) endif () if (split_install_args_in_install_args) list(APPEND ${install_args_var} "${arg}") else () list(APPEND ${files_var} "${arg}") endif () endforeach () endmacro () function (install_clone_aux basedir mode) string(LENGTH ${basedir} basedir_len) math(EXPR basedir_len_p1 "${basedir_len} + 1") split_install_args(install_files install_args ${ARGN}) foreach (file ${install_files}) get_filename_component(abspath ${file} ABSOLUTE) get_filename_component(abspath ${abspath} PATH) string(SUBSTRING ${abspath} 0 ${basedir_len_p1} abspath_head) if (abspath_head STREQUAL "${basedir}/") string(SUBSTRING ${abspath} ${basedir_len_p1} -1 abspath_tail) if (mode STREQUAL "DIRECTORY") install(${mode} ${file} DESTINATION ${abspath_tail} ${install_args} PATTERN ".svn" EXCLUDE) else () install(${mode} ${file} DESTINATION ${abspath_tail} ${install_args}) endif () else () message(SEND_ERROR "install_clone: ${file} seems to be outside the expected base directory ${basedir}") endif () endforeach () endfunction () function (install_clone mode) install_clone_aux(${CMAKE_SOURCE_DIR} ${mode} ${ARGN}) endfunction () function (install_clone_bin mode) install_clone_aux(${CMAKE_BINARY_DIR} ${mode} ${ARGN}) endfunction () Example usage: set(CMAKE_MODULE_PATH ${CMAKE_SOURCE_DIR}/cmake) include(installutils) install_clone(PROGRAMS script1.sh path/to/script2.sh) configure_file(script3.sh.in script3.sh) install_clone_bin(PROGRAMS script3.sh) For (b), you probably want to look at either BundleUtilities, or GetPrerequisites for more fine-grained control over what gets installed. This example is probably a bit involved, but it might give you an idea of what we do here to install some libraries even if they happen to be on what CMake considers the "system library path", but exclude the libraries we consider "system" libraries. # Install Qt plugins macro (install_external_lib libfile dest) install(FILES ${libfile} DESTINATION ${dest} COMPONENT gui) if (IS_SYMLINK ${libfile}) get_filename_component(libfile_link_target ${libfile} REALPATH) install(FILES ${libfile_link_target} DESTINATION ${dest} COMPONENT gui) endif () endmacro () foreach (qt_plugin accessible/qtaccessiblewidgets codecs/qcncodecs codecs/qjpcodecs codecs/qkrcodecs codecs/qtwcodecs graphicssystems/qglgraphicssystem graphicssystems/qtracegraphicssystem iconengines/qsvgicon imageformats/qgif imageformats/qico imageformats/qjpeg imageformats/qmng imageformats/qsvg imageformats/qtga imageformats/qtiff sqldrivers/qsqlite) if (WIN32) set(qt_plugin_file "${qt_plugin}4.dll") else () string(REGEX REPLACE "/([^/]*)$" "/lib\\1.so" qt_plugin_file "${qt_plugin}") endif () set(qt_plugin_file "${QT_PLUGINS_DIR}/${qt_plugin_file}") if (EXISTS "${qt_plugin_file}") get_filename_component(plugin_dest_dir ${qt_plugin} PATH) install_external_lib(${qt_plugin_file} gui/lib/${BUILD_PLATFORM_BASE}/plugins/${plugin_dest_dir}) endif () endforeach () # The following is used to install required libraries if (WIN32) set(search_path ${QT_BINARY_DIR}) else () set(search_path ${QT_LIBRARY_DIR}) endif () foreach (lib_for_search_path ${EXPAT_LIBRARY} ${GLUT_LIBRARIES}) if (lib_for_search_path STREQUAL "optimized" OR lib_for_search_path STREQUAL "debug" OR lib_for_search_path STREQUAL "general") # ignore these markers else () get_filename_component(search_dir ${lib_for_search_path} PATH) list(APPEND search_path ${search_dir}) if (WIN32 AND search_dir MATCHES "/lib") string(REPLACE "/lib" "/bin" search_dir ${search_dir}) if (EXISTS ${search_dir}) list(APPEND search_path ${search_dir}) endif () endif () endif () endforeach () list(SORT search_path) list(REMOVE_DUPLICATES search_path) if (WIN32) install(CODE " message(STATUS \"Calculating required libraries...\") include(GetPrerequisites) set(search_path \"${search_path}\") get_prerequisites(\$ENV{DESTDIR}\${CMAKE_INSTALL_PREFIX}/gui/lib/${BUILD_PLATFORM_BASE}/${BUILD_TARGET_GUI_NAME}.exe prereqs 1 1 \"\" \"\${search_path}\") file(GLOB_RECURSE qt_plugins \$ENV{DESTDIR}\${CMAKE_INSTALL_PREFIX}/gui/lib/${BUILD_PLATFORM_BASE}/plugins/*.dll) foreach (plugin_file \${qt_plugins}) get_prerequisites(\${plugin_file} prereqs 1 1 \"\" \"\${search_path}\") endforeach () foreach (libfile \${prereqs}) gp_resolve_item(\"\" \${libfile} \"\" \"\${search_path}\" libfile_abs) file(INSTALL \${libfile_abs} DESTINATION \$ENV{DESTDIR}\${CMAKE_INSTALL_PREFIX}/gui/lib/${BUILD_PLATFORM_BASE}) endforeach () " COMPONENT gui) set(CMAKE_INSTALL_SYSTEM_RUNTIME_DESTINATION gui/lib/${BUILD_PLATFORM_BASE}) include(InstallRequiredSystemLibraries) else () # Linux install(CODE " message(STATUS \"Calculating required libraries...\") include(GetPrerequisites) set(search_path \"${search_path}\") get_prerequisites(\$ENV{DESTDIR}\${CMAKE_INSTALL_PREFIX}/gui/lib/${BUILD_PLATFORM_BASE}/${BUILD_TARGET_GUI_NAME} prereqs 0 1 \"\" \"\${search_path}\") file(GLOB_RECURSE qt_plugins \$ENV{DESTDIR}\${CMAKE_INSTALL_PREFIX}/gui/lib/${BUILD_PLATFORM_BASE}/*.so) foreach (plugin_file \${qt_plugins}) get_prerequisites(\${plugin_file} prereqs 0 1 \"\" \"\${search_path}\") endforeach () foreach (libfile \${prereqs}) if (NOT (libfile MATCHES \"/(lib(c|dl|drm|fontconfig|freetype|gcc_s|gfortran|GL|GLU|glapi|gomp|ICE|idn|m|png12|pthread|resolv|rt|SM|stdc\\\\+\\\\+|X11|X11-xcb|Xau|Xaw|Xaw7|xcb-dri2|xcb-glx|xcb|Xdamage|Xdmcp|Xext|Xfixes|Xmu|Xpm|Xrandr|Xrender|Xt|Xxf86vm|z)\\\\.so(\\\\.|\\\$))\")) file(INSTALL \${libfile} DESTINATION \$ENV{DESTDIR}\${CMAKE_INSTALL_PREFIX}/gui/lib/${BUILD_PLATFORM_BASE}) if (IS_SYMLINK \${libfile}) get_filename_component(libfile_target \${libfile} REALPATH) file(INSTALL \${libfile_target} DESTINATION \$ENV{DESTDIR}\${CMAKE_INSTALL_PREFIX}/gui/lib/${BUILD_PLATFORM_BASE}) endif () endif () endforeach () " COMPONENT gui) endif () -- Daniel Schepler -----Original Message----- From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Gonzalo Garramuno Sent: Thursday, January 08, 2015 12:47 PM To: cmake at cmake.org Subject: [CMake] Creating an installer using cpack I have a cmake file to build my project (mrViewer). The project has additional script files that are not mentioned in my cmake file. The project also has dependencies on c libraries installed elsewhere (/usr/local, etc). The tgz,deb and rpm files currently contain just the main executable after a: ADD_EXECUTABLE( mrViewer WIN32 ${SOURCES} ) TARGET_LINK_LIBRARIES( mrViewer ${LIBRARIES} ) INSTALL( TARGETS mrViewer RUNTIME DESTINATION bin LIBRARY DESTINATION lib ) What I would like to have is a cmake sample file that shows how to: a) Install the script files respecting its local location. b) Install the c libraries in a local lib directory. for cpack packaging. Thank you very much in advance, Gonzalo -- 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 From d3ck0r at gmail.com Thu Jan 8 16:13:01 2015 From: d3ck0r at gmail.com (J Decker) Date: Thu, 8 Jan 2015 13:13:01 -0800 Subject: [CMake] Creating an installer using cpack In-Reply-To: <54AEECBA.6090609@gmail.com> References: <54AEECBA.6090609@gmail.com> Message-ID: On Thu, Jan 8, 2015 at 12:46 PM, Gonzalo Garramuno wrote: > I have a cmake file to build my project (mrViewer). The project has > additional script files that are not mentioned in my cmake file. > The project also has dependencies on c libraries installed elsewhere > (/usr/local, etc). > > The tgz,deb and rpm files currently contain just the main executable after > a: > > ADD_EXECUTABLE( mrViewer WIN32 ${SOURCES} ) > TARGET_LINK_LIBRARIES( mrViewer ${LIBRARIES} ) > INSTALL( TARGETS mrViewer > RUNTIME DESTINATION bin > LIBRARY DESTINATION lib > ) > > # this will put the directory'scripts' into bin... resulting with bin/scripts/* install(DIRECTORY scripts DESTINATION bin ) # with a trailing slash on the name, the name is not included... so you can rename # the source directory on the way out... install(DIRECTORY script_sources/ DESTINATION bin/scripts ) > What I would like to have is a cmake sample file that shows how to: > > a) Install the script files respecting its local location. > b) Install the c libraries in a local lib directory. > > for cpack packaging. > http://www.cmake.org/Wiki/CMake:Packaging_With_CPack a lot of SET()... followed by include( CPack ) > > Thank you very much in advance, > > Gonzalo > -- > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From David.Karr at engilitycorp.com Thu Jan 8 17:33:10 2015 From: David.Karr at engilitycorp.com (David.Karr at engilitycorp.com) Date: Thu, 8 Jan 2015 22:33:10 +0000 Subject: [CMake] Unable to create project files with Visual Studio 2010 on Windows 7 In-Reply-To: <54ADA5E4.6030002@kitware.com> References: <54ADA5E4.6030002@kitware.com> Message-ID: > On 1/6/2015 7:10 PM, David.Karr at engilitycorp.com wrote: > > I have just started using a new Windows 7 host with Visual Studio > 2010 > > Professional. When I call CMake to generate my project files, I get > > the following output in CMakeError.log: > Does your visual studio work without CMake? Can you create a simple > project with the IDE and build it? Can you then build that project > from the command line like CMake does: > > C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe > yourproject.vcxproj /p:Configuration=Debug Indeed I have tried several ways to create and build projects without using CMake at all, and so far no luck--I still get "requires elevation" errors. I don't have a solution for my problem yet but it appears that whatever it is that is stopping me from building projects, CMake does not cause the problem. Thanks to everyone for the helpful advice, which significantly narrowed down the possible sources of error. David From nkwmailinglists at gmail.com Thu Jan 8 17:58:51 2015 From: nkwmailinglists at gmail.com (Kent Williams) Date: Thu, 8 Jan 2015 16:58:51 -0600 Subject: [CMake] ExternalProject git checkout --depth=1 ??? Message-ID: I'm building the Mozilla Spidermonkey JS interpreter as an ExternalProject. So far so good, but I had a question/feature request: Wouldn't it be grand to be able to add --depth 1 to the git clone? This is perfect for grabbing giant repositories. Mozilla is more than 3 gigabytes with a full clone, and a depth=1 checkout is a 1/3 that. -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at mad-scientist.net Thu Jan 8 18:52:01 2015 From: paul at mad-scientist.net (Paul Smith) Date: Thu, 08 Jan 2015 18:52:01 -0500 Subject: [CMake] Are CMAKE_CXX_FLAGS supposed to go on the link line? Message-ID: <1420761121.3404.4.camel@mad-scientist.net> It seems different generators are handling this differently, which is frustrating (I've tried with both CMake 3.1.0 and 2.8.12.2)... or else there's something very bizarre about my cmake files. The new doc layout looks nice, but it really needs an infusion of detail. Here's the doc for CMAKE_CXX_FLAGS: http://www.cmake.org/cmake/help/v3.1/variable/CMAKE_LANG_FLAGS.html which isn't so helpful for my question :-). If I'm on OSX, then when I set CMAKE_CXX_FLAGS and do not set CMAKE_EXE_LINKER_FLAGS, for example, and I use the Xcode generator, then I see: * CMAKE_CXX_FLAGS show up on the compilation line * CMAKE_CXX_FLAGS do NOT show up in the linker line On the other hand if I'm on OSX and I use the Unix Makefiles generator, then I see: * CMAKE_CXX_FLAGS show up on the compilation line * CMAKE_CXX_FLAGS ALSO show up in the linker line I assume the Xcode output is correct and the makefile output (with CMAKE_CXX_FLAGS in both) is not correct... but there's nothing I can find in the docs that says this explicitly. I've printed the contents of the CMAKE_CXX_FLAGS and CMAKE_EXE_LINKER_FLAGS at the end of my CMakeLists.txt and they're just what I expect. It's just that the link line has extra flags, when invoked from make. Can anyone else reproduce this? From yngve.levinsen at gmail.com Fri Jan 9 08:31:17 2015 From: yngve.levinsen at gmail.com (Yngve Inntjore Levinsen) Date: Fri, 09 Jan 2015 14:31:17 +0100 Subject: [CMake] ExternalProject git checkout --depth=1 ??? In-Reply-To: References: Message-ID: <54AFD825.8040602@gmail.com> Hi, Have a look here: http://www.cmake.org/Bug/view.php?id=15291 You should be able to use, for the time being, DOWNLOAD_COMMAND and UPDATE_COMMAND to achieve this. (have not tested myself) Hope this helps. Cheers, Yngve On 08/01/15 23:58, Kent Williams wrote: > I'm building the Mozilla Spidermonkey JS interpreter as an > ExternalProject. > > So far so good, but I had a question/feature request: Wouldn't it be > grand to be able to add --depth 1 to the git clone? This is perfect > for grabbing giant repositories. Mozilla is more than 3 gigabytes with > a full clone, and a depth=1 checkout is a 1/3 that. > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ggarra13 at gmail.com Fri Jan 9 10:52:23 2015 From: ggarra13 at gmail.com (Gonzalo Garramuno) Date: Fri, 09 Jan 2015 12:52:23 -0300 Subject: [CMake] Creating an installer using cpack In-Reply-To: References: <54AEECBA.6090609@gmail.com> <54AF0F3B.2040505@gmail.com> Message-ID: <54AFF937.8080402@gmail.com> On 08/01/15 21:56, J Decker wrote: > I don't think you should install libraries like that... things in > binary would be build products, can you possibly just install the libs > as normal > > INSTALL( Target <...> LIBRARY DESTINATION lib ) The lib files are not built by cmake but are dependencies for my program. The lib files are symbolic links to the /usr/local/lib directory. For example: Release/lib/libfltk2.so.2.0 -> /usr/local/lib/libfltk2.so.2.0 With the tgz installer, the symlinks are flattened to their respective files. However, with the deb installer, the symlinks are kept. I would like the symlink to be flattened also in the deb installer. Then all would be peachy. From David.Karr at engilitycorp.com Fri Jan 9 11:57:10 2015 From: David.Karr at engilitycorp.com (David.Karr at engilitycorp.com) Date: Fri, 9 Jan 2015 16:57:10 +0000 Subject: [CMake] Unable to create project files with Visual Studio 2010 on Windows 7 In-Reply-To: References: <54ADA5E4.6030002@kitware.com> Message-ID: > Indeed I have tried several ways to create and build projects without > using CMake at all, and so far no luck--I still get "requires > elevation" errors. I don't have a solution for my problem yet but it > appears that whatever it is that is stopping me from building projects, > CMake does not cause the problem. > > Thanks to everyone for the helpful advice, which significantly narrowed > down the possible sources of error. Although this is not really a CMake problem, this thread now comes up in the Google search results for symptoms similar to mine, so it seems useful to post a resolution in case someone else comes upon this thread for that reason. Running the IDE as administrator (not as simple as just "opening" an .sln file, unfortunately), I found another underlying error for which an answer is given at http://stackoverflow.com/a/10890428 . In summary, after I did a web-based installation of Visual Studio 2010 Service Pack 1, I was able to build a project created in the IDE, I was able use CMake to generate projects, and I was able to build the projects generated by CMake. Incidentally, when I first got CMake and the compilers to run correctly, I was only able to do it by running CMake or DEVENV as administrator. Not so coincidentally, somehow during all the installing/uninstalling/attempted fixes I had applied, CL.EXE had been set to run as Administrator for all users. It turns out that when I UNDID this setting (so CL.EXE does not always run as Administrator), CMake and the compilers succeeded without my having to take any special steps to run anything as administrator. Go figure. David From ggarra13 at gmail.com Fri Jan 9 12:43:03 2015 From: ggarra13 at gmail.com (=?ISO-8859-1?Q?Gonzalo_Garramu=F1o?=) Date: Fri, 09 Jan 2015 14:43:03 -0300 Subject: [CMake] NSIS builder creating invalid exe Message-ID: <54B01327.6060609@gmail.com> I updated my CMakeLists.txt to create an NSIS installer under a Nmake Makefile. The packaging works without errors when run with 'nmake package'. However, the resulting exe file when run, returns: Bad file number. The problem happens on both builds for win32 and win64. The NSIS installer is 3.0a1 and cmake v3.0.1. From domen.vrankar at gmail.com Fri Jan 9 15:04:32 2015 From: domen.vrankar at gmail.com (Domen Vrankar) Date: Fri, 9 Jan 2015 21:04:32 +0100 Subject: [CMake] Creating an installer using cpack In-Reply-To: <54AFF937.8080402@gmail.com> References: <54AEECBA.6090609@gmail.com> <54AF0F3B.2040505@gmail.com> <54AFF937.8080402@gmail.com> Message-ID: > The lib files are not built by cmake but are dependencies for my program. You could move external libraries wih something like this: install(FILES /some/location/libsomething.so DESTINATION lib) > The lib files are symbolic links to the /usr/local/lib directory. For > example: > > Release/lib/libfltk2.so.2.0 -> /usr/local/lib/libfltk2.so.2.0 > > With the tgz installer, the symlinks are flattened to their respective > files. > However, with the deb installer, the symlinks are kept. > I would like the symlink to be flattened also in the deb installer. Then all > would be peachy. Hm... I'd expect tgz installer to preserve symlinks as well... From my point of view deb installer works correctly since external libraries should be in a separate package or part of your package but copied with install commands. One other reason for preserving symlinks would be that with symlink flattening case you would have to complicate packaging functionality for cases where you want to package a library libftk2.so and a symbolic link to it libftk2.so.2.0 (and that is the usual way when installing libraries on Linux - back compatibility with multiple versions of the same library and so on...). Regards, Domen From d3ck0r at gmail.com Fri Jan 9 15:30:54 2015 From: d3ck0r at gmail.com (J Decker) Date: Fri, 9 Jan 2015 12:30:54 -0800 Subject: [CMake] Creating an installer using cpack In-Reply-To: <54AFF937.8080402@gmail.com> References: <54AEECBA.6090609@gmail.com> <54AF0F3B.2040505@gmail.com> <54AFF937.8080402@gmail.com> Message-ID: need to use install( PROGRAMS ... ) then On Fri, Jan 9, 2015 at 7:52 AM, Gonzalo Garramuno wrote: > On 08/01/15 21:56, J Decker wrote: > >> I don't think you should install libraries like that... things in binary >> would be build products, can you possibly just install the libs as normal >> >> INSTALL( Target <...> LIBRARY DESTINATION lib ) >> > The lib files are not built by cmake but are dependencies for my program. > > The lib files are symbolic links to the /usr/local/lib directory. For > example: > > Release/lib/libfltk2.so.2.0 -> /usr/local/lib/libfltk2.so.2.0 > > With the tgz installer, the symlinks are flattened to their respective > files. > However, with the deb installer, the symlinks are kept. > I would like the symlink to be flattened also in the deb installer. Then > all would be peachy. > > install( PROGRAM .... ) will keep executable permissions... (as opposed to using FILES or DIRECTORY ) not sure about symlinks.... http://www.cmake.org/cmake/help/v3.0/command/install.html only references symbolic links once, and that's for Install( TARGET ... ) " Either NAMELINK_ONLY or NAMELINK_SKIP may be specified as a LIBRARY option. On some platforms a versioned shared library has a symbolic link such as:" -- > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From post at hendrik-sattler.de Fri Jan 9 15:46:36 2015 From: post at hendrik-sattler.de (Hendrik Sattler) Date: Fri, 09 Jan 2015 21:46:36 +0100 Subject: [CMake] Creating an installer using cpack In-Reply-To: References: <54AEECBA.6090609@gmail.com> <54AF0F3B.2040505@gmail.com> <54AFF937.8080402@gmail.com> Message-ID: <3795FF0B-50BB-4CFB-BD45-19BFF01FFF06@hendrik-sattler.de> Hi, on Linux, libraries don't need the executable permission set. HS Am 9. Januar 2015 21:30:54 MEZ, schrieb J Decker : >need to use install( PROGRAMS ... ) then > > > >On Fri, Jan 9, 2015 at 7:52 AM, Gonzalo Garramuno >wrote: > >> On 08/01/15 21:56, J Decker wrote: >> >>> I don't think you should install libraries like that... things in >binary >>> would be build products, can you possibly just install the libs as >normal >>> >>> INSTALL( Target <...> LIBRARY DESTINATION lib ) >>> >> The lib files are not built by cmake but are dependencies for my >program. >> >> The lib files are symbolic links to the /usr/local/lib directory. For >> example: >> >> Release/lib/libfltk2.so.2.0 -> /usr/local/lib/libfltk2.so.2.0 >> >> With the tgz installer, the symlinks are flattened to their >respective >> files. >> However, with the deb installer, the symlinks are kept. >> I would like the symlink to be flattened also in the deb installer. >Then >> all would be peachy. >> >> install( PROGRAM .... ) will keep executable permissions... (as >opposed >to using FILES or DIRECTORY ) not sure about symlinks.... > >http://www.cmake.org/cmake/help/v3.0/command/install.html only >references >symbolic links once, and that's for Install( TARGET ... ) " Either >NAMELINK_ONLY or NAMELINK_SKIP may be specified as a LIBRARY option. On >some platforms a versioned shared library has a symbolic link such as:" > >-- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For >more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at http://www.kitware.com/ >> opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake >> > > >------------------------------------------------------------------------ > >-- > >Powered by www.kitware.com > >Please keep messages on-topic and check the CMake FAQ at: >http://www.cmake.org/Wiki/CMake_FAQ > >Kitware offers various services to support the CMake community. For >more information on each offering, please visit: > >CMake Support: http://cmake.org/cmake/help/support.html >CMake Consulting: http://cmake.org/cmake/help/consulting.html >CMake Training Courses: http://cmake.org/cmake/help/training.html > >Visit other Kitware open-source projects at >http://www.kitware.com/opensource/opensource.html > >Follow this link to subscribe/unsubscribe: >http://public.kitware.com/mailman/listinfo/cmake -------------- next part -------------- An HTML attachment was scrubbed... URL: From domen.vrankar at gmail.com Fri Jan 9 15:54:04 2015 From: domen.vrankar at gmail.com (Domen Vrankar) Date: Fri, 9 Jan 2015 21:54:04 +0100 Subject: [CMake] Creating an installer using cpack In-Reply-To: References: <54AEECBA.6090609@gmail.com> <54AF0F3B.2040505@gmail.com> <54AFF937.8080402@gmail.com> Message-ID: > install( PROGRAM .... ) will keep executable permissions... (as opposed to > using FILES or DIRECTORY ) not sure about symlinks.... Hm forgot about this one... Had problems with it years ago on AIX and stopped using it back then (it removed baked in paths to libraries from executables)... Time to try it out again :) > http://www.cmake.org/cmake/help/v3.0/command/install.html only references > symbolic links once, and that's for Install( TARGET ... ) " Either > NAMELINK_ONLY or NAMELINK_SKIP may be specified as a LIBRARY option. On some > platforms a versioned shared library has a symbolic link such as:" You can create a symlink with a custom command or by using execute_process with cmake -E create_symlink command and then moving it into package with for eg install(DIRECTORY ...). Regards, Domen From d3ck0r at gmail.com Fri Jan 9 15:55:59 2015 From: d3ck0r at gmail.com (J Decker) Date: Fri, 9 Jan 2015 12:55:59 -0800 Subject: [CMake] Creating an installer using cpack In-Reply-To: References: <54AEECBA.6090609@gmail.com> <54AF0F3B.2040505@gmail.com> <54AFF937.8080402@gmail.com> Message-ID: On Fri, Jan 9, 2015 at 12:54 PM, Domen Vrankar wrote: > > install( PROGRAM .... ) will keep executable permissions... (as opposed > to > > using FILES or DIRECTORY ) not sure about symlinks.... > > Hm forgot about this one... Had problems with it years ago on AIX and > stopped using it back then (it removed baked in paths to libraries > from executables)... Time to try it out again :) > > > http://www.cmake.org/cmake/help/v3.0/command/install.html only > references > > symbolic links once, and that's for Install( TARGET ... ) " Either > > NAMELINK_ONLY or NAMELINK_SKIP may be specified as a LIBRARY option. On > some > > platforms a versioned shared library has a symbolic link such as:" > > You can create a symlink with a custom command or by using > execute_process with cmake -E create_symlink command and then moving > it into package with for eg install(DIRECTORY ...). > > the symlinks already exist in the source directory (it sounds like) the problem is they're not being packaged/extracted right.... > Regards, > Domen > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.hoffman at kitware.com Fri Jan 9 17:22:29 2015 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Fri, 09 Jan 2015 17:22:29 -0500 Subject: [CMake] NSIS builder creating invalid exe In-Reply-To: <54B01327.6060609@gmail.com> References: <54B01327.6060609@gmail.com> Message-ID: <54B054A5.6010005@kitware.com> On 1/9/2015 12:43 PM, Gonzalo Garramu?o wrote: > I updated my CMakeLists.txt to create an NSIS installer under a Nmake > Makefile. > The packaging works without errors when run with 'nmake package'. > > However, the resulting exe file when run, returns: > Bad file number. > > The problem happens on both builds for win32 and win64. > The NSIS installer is 3.0a1 and cmake v3.0.1. Try running it from explorer and not the command line. It might be asking to raise permissions since it is an installer. -Bill From ggarra13 at gmail.com Fri Jan 9 17:36:23 2015 From: ggarra13 at gmail.com (=?UTF-8?B?R29uemFsbyBHYXJyYW11w7Fv?=) Date: Fri, 09 Jan 2015 19:36:23 -0300 Subject: [CMake] Creating an installer using cpack In-Reply-To: References: <54AEECBA.6090609@gmail.com> <54AF0F3B.2040505@gmail.com> <54AFF937.8080402@gmail.com> Message-ID: <54B057E7.4030309@gmail.com> On 09/01/2015 05:55 p.m., J Decker wrote: > > > the symlinks already exist in the source directory (it sounds like) > the problem is they're not being packaged/extracted right... Correct. I changed my symlink script with one that copies the libraries and all problems are gone. Now I am tackling NSIS problems on Windows. Thanks to all for your help. Gonzalo -------------- next part -------------- An HTML attachment was scrubbed... URL: From oliveridario89 at gmail.com Sat Jan 10 02:46:12 2015 From: oliveridario89 at gmail.com (Dario Oliveri) Date: Sat, 10 Jan 2015 08:46:12 +0100 Subject: [CMake] Wrap CACHE variables Message-ID: How can I wrap cache variables from CMake scripts? Let's say I have a CMake project, it depends on any third part library (says SFML or SDL), that project expose a plenty of CACHE variables so that configuring them for each build manually is a pain. How can I configure from MY project THOSE variables so that the final user/builder does not have to setup that garbage stuff? (say my project has only 3 cache variables "build_win32", "build_max", "build_linux", I know how to setup corresponding flags in dependencies, so why I can't do that via script? having several dependencies could lead to hundreds of Cache variables, configuring a cross platform build becomes unmaintainable and error prone, also not every user would be able to do that because require knowing details about dependencies) The assumption is that a project will not use pre-built binaries for dependencies but will instead include and in-build them (this has plenty advantages, including ability to re-run unit tests also for dependencies, catch misconfigurations in build system early, ability to really support every compiler without having to redownload stuff or compile it manually, this is the true power of CMAKE, just missing 1 detail to go): add_subdirectory(FOLDER_TO_SDL folder_to_my_bin_dir/SDL) -------------- next part -------------- An HTML attachment was scrubbed... URL: From DLRdave at aol.com Sat Jan 10 10:29:36 2015 From: DLRdave at aol.com (David Cole) Date: Sat, 10 Jan 2015 10:29:36 -0500 Subject: [CMake] Wrap CACHE variables In-Reply-To: References: Message-ID: Have you considered having a "superbuild" and using ExternalProject_Add to build the dependencies? http://www.cmake.org/cmake/help/v3.1/module/ExternalProject.html Excellent examples of using ExternalProject for a superbuild live in the OpenChemistry and Slicer projects. https://github.com/OpenChemistry/openchemistry https://github.com/Slicer/Slicer HTH, David C. On Sat, Jan 10, 2015 at 2:46 AM, Dario Oliveri wrote: > How can I wrap cache variables from CMake scripts? Let's say I have a CMake > project, it depends on any third part library (says SFML or SDL), that > project expose a plenty of CACHE variables so that configuring them for each > build manually is a pain. > > How can I configure from MY project THOSE variables so that the final > user/builder does not have to setup that garbage stuff? (say my project has > only 3 cache variables "build_win32", "build_max", "build_linux", I know how > to setup corresponding flags in dependencies, so why I can't do that via > script? having several dependencies could lead to hundreds of Cache > variables, configuring a cross platform build becomes unmaintainable and > error prone, also not every user would be able to do that because require > knowing details about dependencies) > > The assumption is that a project will not use pre-built binaries for > dependencies but will instead include and in-build them (this has plenty > advantages, including ability to re-run unit tests also for dependencies, > catch misconfigurations in build system early, ability to really support > every compiler without having to redownload stuff or compile it manually, > this is the true power of CMAKE, just missing 1 detail to go): > > > add_subdirectory(FOLDER_TO_SDL folder_to_my_bin_dir/SDL) > > -- > > 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 From ggarra13 at gmail.com Sat Jan 10 10:43:58 2015 From: ggarra13 at gmail.com (Gonzalo Garramuno) Date: Sat, 10 Jan 2015 12:43:58 -0300 Subject: [CMake] NSIS builder creating invalid exe In-Reply-To: <54B054A5.6010005@kitware.com> References: <54B01327.6060609@gmail.com> <54B054A5.6010005@kitware.com> Message-ID: <54B148BE.4070703@gmail.com> On 09/01/15 19:22, Bill Hoffman wrote: > On 1/9/2015 12:43 PM, Gonzalo Garramu?o wrote: >> I updated my CMakeLists.txt to create an NSIS installer under a Nmake >> Makefile. >> The packaging works without errors when run with 'nmake package'. >> >> However, the resulting exe file when run, returns: >> Bad file number. >> >> The problem happens on both builds for win32 and win64. >> The NSIS installer is 3.0a1 and cmake v3.0.1. > Try running it from explorer and not the command line. It might be > asking to raise permissions since it is an installer. > > -Bill > Yes, that was it. Thanks for pointing out a problem with mingw bash. From ggarra13 at gmail.com Sat Jan 10 12:01:25 2015 From: ggarra13 at gmail.com (=?ISO-8859-1?Q?Gonzalo_Garramu=F1o?=) Date: Sat, 10 Jan 2015 14:01:25 -0300 Subject: [CMake] NSIS startup menu and icons Message-ID: <54B15AE5.2000501@gmail.com> I have created an NSIS section for my CMakeLists.txt and I am trying to pack and install my application (mrViewer). The package builds correctly and runs just fine, but the mrViewer icon is missing in desktop and in the menu entry and the startup menu has a mrViewer entry that leads nowhere instead of running my program. I am sure it is a path issue somewhere but I don't know how to debug it, so I am asking for help here. I have the following: add_executable( mrViewer WIN32 ${SOURCES} ) target_link_libraries( mrViewer ${LIBRARIES} ) install( TARGETS mrViewer RUNTIME DESTINATION ${mrViewerPackageName}/bin LIBRARY DESTINATION ${mrViewerPackageName}/lib ) set(CPACK_NSIS_MUI_ICON ${PROJECT_SOURCE_DIR}/mrViewer/src/icons/viewer.ico) set(CPACK_NSIS_MUI_UNICON ${PROJECT_SOURCE_DIR}/mrViewer/src/icons/viewer.ico) if (CMAKE_BUILD_ARCH EQUAL 32) set(CPACK_NSIS_INSTALL_ROOT "$PROGRAMFILES") elseif (CMAKE_BUILD_ARCH EQUAL 64) set(CPACK_NSIS_INSTALL_ROOT "$PROGRAMFILES64") endif (CMAKE_BUILD_ARCH EQUAL 32) SET( CPACK_NSIS_MODIFY_PATH ON ) SET( CPACK_CREATE_DESKTOP_LINKS ON ) set(CPACK_PACKAGE_INSTALL_DIRECTORY ${mrViewerPackageName}) set(CPACK_PACKAGE_VERSION_MAJOR ${mrViewerVersionMajor}) set(CPACK_PACKAGE_VERSION_MINOR ${mrViewerVersionMinor}) set(CPACK_PACKAGE_VERSION_PATCH ${mrViewerVersionPatch}) set(CPACK_PACKAGE_CONTACT http://mrviewer.sourceforge.net) # set(CPACK_PACKAGE_DESCRIPTION_FILE ${PROJECT_SOURCE_DIR}/README.txt) set(CPACK_PACKAGE_DESCRIPTION_SUMMARY "mrViewer provides professional flipbook, audio and video playback.") set(CPACK_PACKAGE_EXECUTABLES mrViewer mrViewer ) set(CPACK_PACKAGE_INSTALL_REGISTRY_KEY ${mrViewerPackageName} ) set(CPACK_RESOURCE_FILE_LICENSE ${PROJECT_SOURCE_DIR}/LICENSE.txt) set(CPACK_PACKAGE_FILE_NAME ${mrViewerPackageName}) set(CPACK_NSIS_INSTALLED_ICON_NAME bin\\\\mrViewer.exe) And find attached the resulting project.nsi file. -------------- next part -------------- ; CPack install script designed for a nmake build ;-------------------------------- ; You must define these values !define VERSION "0.1.1" !define PATCH "1" !define INST_DIR "F:/code/applications/mrViewer/BUILD/Windows-6.1-64/Release/tmp/_CPack_Packages/win64/NSIS/mrViewer-2.6.7-Windows-64" ;-------------------------------- ;Variables Var MUI_TEMP Var STARTMENU_FOLDER Var SV_ALLUSERS Var START_MENU Var DO_NOT_ADD_TO_PATH Var ADD_TO_PATH_ALL_USERS Var ADD_TO_PATH_CURRENT_USER Var INSTALL_DESKTOP Var IS_DEFAULT_INSTALLDIR ;-------------------------------- ;Include Modern UI !include "MUI.nsh" ;Default installation folder InstallDir "$PROGRAMFILES64\mrViewer-2.6.7-Windows-64" ;-------------------------------- ;General ;Name and file Name "mrViewer-2.6.7-Windows-64" OutFile "F:/code/applications/mrViewer/BUILD/Windows-6.1-64/Release/tmp/_CPack_Packages/win64/NSIS/mrViewer-2.6.7-Windows-64.exe" ;Set compression SetCompressor lzma ;Require administrator access RequestExecutionLevel admin !include Sections.nsh ;--- Component support macros: --- ; The code for the add/remove functionality is from: ; http://nsis.sourceforge.net/Add/Remove_Functionality ; It has been modified slightly and extended to provide ; inter-component dependencies. Var AR_SecFlags Var AR_RegFlags ; Loads the "selected" flag for the section named SecName into the ; variable VarName. !macro LoadSectionSelectedIntoVar SecName VarName SectionGetFlags ${${SecName}} $${VarName} IntOp $${VarName} $${VarName} & ${SF_SELECTED} ;Turn off all other bits !macroend ; Loads the value of a variable... can we get around this? !macro LoadVar VarName IntOp $R0 0 + $${VarName} !macroend ; Sets the value of a variable !macro StoreVar VarName IntValue IntOp $${VarName} 0 + ${IntValue} !macroend !macro InitSection SecName ; This macro reads component installed flag from the registry and ;changes checked state of the section on the components page. ;Input: section index constant name specified in Section command. ClearErrors ;Reading component status from registry ReadRegDWORD $AR_RegFlags HKLM "Software\Microsoft\Windows\CurrentVersion\Uninstall\mrViewer-2.6.7-Windows-64\Components\${SecName}" "Installed" IfErrors "default_${SecName}" ;Status will stay default if registry value not found ;(component was never installed) IntOp $AR_RegFlags $AR_RegFlags & ${SF_SELECTED} ;Turn off all other bits SectionGetFlags ${${SecName}} $AR_SecFlags ;Reading default section flags IntOp $AR_SecFlags $AR_SecFlags & 0xFFFE ;Turn lowest (enabled) bit off IntOp $AR_SecFlags $AR_RegFlags | $AR_SecFlags ;Change lowest bit ; Note whether this component was installed before !insertmacro StoreVar ${SecName}_was_installed $AR_RegFlags IntOp $R0 $AR_RegFlags & $AR_RegFlags ;Writing modified flags SectionSetFlags ${${SecName}} $AR_SecFlags "default_${SecName}:" !insertmacro LoadSectionSelectedIntoVar ${SecName} ${SecName}_selected !macroend !macro FinishSection SecName ; This macro reads section flag set by user and removes the section ;if it is not selected. ;Then it writes component installed flag to registry ;Input: section index constant name specified in Section command. SectionGetFlags ${${SecName}} $AR_SecFlags ;Reading section flags ;Checking lowest bit: IntOp $AR_SecFlags $AR_SecFlags & ${SF_SELECTED} IntCmp $AR_SecFlags 1 "leave_${SecName}" ;Section is not selected: ;Calling Section uninstall macro and writing zero installed flag !insertmacro "Remove_${${SecName}}" WriteRegDWORD HKLM "Software\Microsoft\Windows\CurrentVersion\Uninstall\mrViewer-2.6.7-Windows-64\Components\${SecName}" \ "Installed" 0 Goto "exit_${SecName}" "leave_${SecName}:" ;Section is selected: WriteRegDWORD HKLM "Software\Microsoft\Windows\CurrentVersion\Uninstall\mrViewer-2.6.7-Windows-64\Components\${SecName}" \ "Installed" 1 "exit_${SecName}:" !macroend !macro RemoveSection_CPack SecName ; This macro is used to call section's Remove_... macro ;from the uninstaller. ;Input: section index constant name specified in Section command. !insertmacro "Remove_${${SecName}}" !macroend ; Determine whether the selection of SecName changed !macro MaybeSelectionChanged SecName !insertmacro LoadVar ${SecName}_selected SectionGetFlags ${${SecName}} $R1 IntOp $R1 $R1 & ${SF_SELECTED} ;Turn off all other bits ; See if the status has changed: IntCmp $R0 $R1 "${SecName}_unchanged" !insertmacro LoadSectionSelectedIntoVar ${SecName} ${SecName}_selected IntCmp $R1 ${SF_SELECTED} "${SecName}_was_selected" !insertmacro "Deselect_required_by_${SecName}" goto "${SecName}_unchanged" "${SecName}_was_selected:" !insertmacro "Select_${SecName}_depends" "${SecName}_unchanged:" !macroend ;--- End of Add/Remove macros --- ;-------------------------------- ;Interface Settings !define MUI_HEADERIMAGE !define MUI_ABORTWARNING ;-------------------------------- ; path functions !verbose 3 !include "WinMessages.NSH" !verbose 4 ;---------------------------------------- ; based upon a script of "Written by KiCHiK 2003-01-18 05:57:02" ;---------------------------------------- !verbose 3 !include "WinMessages.NSH" !verbose 4 ;==================================================== ; get_NT_environment ; Returns: the selected environment ; Output : head of the stack ;==================================================== !macro select_NT_profile UN Function ${UN}select_NT_profile StrCmp $ADD_TO_PATH_ALL_USERS "1" 0 environment_single DetailPrint "Selected environment for all users" Push "all" Return environment_single: DetailPrint "Selected environment for current user only." Push "current" Return FunctionEnd !macroend !insertmacro select_NT_profile "" !insertmacro select_NT_profile "un." ;---------------------------------------------------- !define NT_current_env 'HKCU "Environment"' !define NT_all_env 'HKLM "SYSTEM\CurrentControlSet\Control\Session Manager\Environment"' !ifndef WriteEnvStr_RegKey !ifdef ALL_USERS !define WriteEnvStr_RegKey \ 'HKLM "SYSTEM\CurrentControlSet\Control\Session Manager\Environment"' !else !define WriteEnvStr_RegKey 'HKCU "Environment"' !endif !endif ; AddToPath - Adds the given dir to the search path. ; Input - head of the stack ; Note - Win9x systems requires reboot Function AddToPath Exch $0 Push $1 Push $2 Push $3 # don't add if the path doesn't exist IfFileExists "$0\*.*" "" AddToPath_done ReadEnvStr $1 PATH ; if the path is too long for a NSIS variable NSIS will return a 0 ; length string. If we find that, then warn and skip any path ; modification as it will trash the existing path. StrLen $2 $1 IntCmp $2 0 CheckPathLength_ShowPathWarning CheckPathLength_Done CheckPathLength_Done CheckPathLength_ShowPathWarning: Messagebox MB_OK|MB_ICONEXCLAMATION "Warning! PATH too long installer unable to modify PATH!" Goto AddToPath_done CheckPathLength_Done: Push "$1;" Push "$0;" Call StrStr Pop $2 StrCmp $2 "" "" AddToPath_done Push "$1;" Push "$0\;" Call StrStr Pop $2 StrCmp $2 "" "" AddToPath_done GetFullPathName /SHORT $3 $0 Push "$1;" Push "$3;" Call StrStr Pop $2 StrCmp $2 "" "" AddToPath_done Push "$1;" Push "$3\;" Call StrStr Pop $2 StrCmp $2 "" "" AddToPath_done Call IsNT Pop $1 StrCmp $1 1 AddToPath_NT ; Not on NT StrCpy $1 $WINDIR 2 FileOpen $1 "$1\autoexec.bat" a FileSeek $1 -1 END FileReadByte $1 $2 IntCmp $2 26 0 +2 +2 # DOS EOF FileSeek $1 -1 END # write over EOF FileWrite $1 "$\r$\nSET PATH=%PATH%;$3$\r$\n" FileClose $1 SetRebootFlag true Goto AddToPath_done AddToPath_NT: StrCmp $ADD_TO_PATH_ALL_USERS "1" ReadAllKey ReadRegStr $1 ${NT_current_env} "PATH" Goto DoTrim ReadAllKey: ReadRegStr $1 ${NT_all_env} "PATH" DoTrim: StrCmp $1 "" AddToPath_NTdoIt Push $1 Call Trim Pop $1 StrCpy $0 "$1;$0" AddToPath_NTdoIt: StrCmp $ADD_TO_PATH_ALL_USERS "1" WriteAllKey WriteRegExpandStr ${NT_current_env} "PATH" $0 Goto DoSend WriteAllKey: WriteRegExpandStr ${NT_all_env} "PATH" $0 DoSend: SendMessage ${HWND_BROADCAST} ${WM_WININICHANGE} 0 "STR:Environment" /TIMEOUT=5000 AddToPath_done: Pop $3 Pop $2 Pop $1 Pop $0 FunctionEnd ; RemoveFromPath - Remove a given dir from the path ; Input: head of the stack Function un.RemoveFromPath Exch $0 Push $1 Push $2 Push $3 Push $4 Push $5 Push $6 IntFmt $6 "%c" 26 # DOS EOF Call un.IsNT Pop $1 StrCmp $1 1 unRemoveFromPath_NT ; Not on NT StrCpy $1 $WINDIR 2 FileOpen $1 "$1\autoexec.bat" r GetTempFileName $4 FileOpen $2 $4 w GetFullPathName /SHORT $0 $0 StrCpy $0 "SET PATH=%PATH%;$0" Goto unRemoveFromPath_dosLoop unRemoveFromPath_dosLoop: FileRead $1 $3 StrCpy $5 $3 1 -1 # read last char StrCmp $5 $6 0 +2 # if DOS EOF StrCpy $3 $3 -1 # remove DOS EOF so we can compare StrCmp $3 "$0$\r$\n" unRemoveFromPath_dosLoopRemoveLine StrCmp $3 "$0$\n" unRemoveFromPath_dosLoopRemoveLine StrCmp $3 "$0" unRemoveFromPath_dosLoopRemoveLine StrCmp $3 "" unRemoveFromPath_dosLoopEnd FileWrite $2 $3 Goto unRemoveFromPath_dosLoop unRemoveFromPath_dosLoopRemoveLine: SetRebootFlag true Goto unRemoveFromPath_dosLoop unRemoveFromPath_dosLoopEnd: FileClose $2 FileClose $1 StrCpy $1 $WINDIR 2 Delete "$1\autoexec.bat" CopyFiles /SILENT $4 "$1\autoexec.bat" Delete $4 Goto unRemoveFromPath_done unRemoveFromPath_NT: StrCmp $ADD_TO_PATH_ALL_USERS "1" unReadAllKey ReadRegStr $1 ${NT_current_env} "PATH" Goto unDoTrim unReadAllKey: ReadRegStr $1 ${NT_all_env} "PATH" unDoTrim: StrCpy $5 $1 1 -1 # copy last char StrCmp $5 ";" +2 # if last char != ; StrCpy $1 "$1;" # append ; Push $1 Push "$0;" Call un.StrStr ; Find `$0;` in $1 Pop $2 ; pos of our dir StrCmp $2 "" unRemoveFromPath_done ; else, it is in path # $0 - path to add # $1 - path var StrLen $3 "$0;" StrLen $4 $2 StrCpy $5 $1 -$4 # $5 is now the part before the path to remove StrCpy $6 $2 "" $3 # $6 is now the part after the path to remove StrCpy $3 $5$6 StrCpy $5 $3 1 -1 # copy last char StrCmp $5 ";" 0 +2 # if last char == ; StrCpy $3 $3 -1 # remove last char StrCmp $ADD_TO_PATH_ALL_USERS "1" unWriteAllKey WriteRegExpandStr ${NT_current_env} "PATH" $3 Goto unDoSend unWriteAllKey: WriteRegExpandStr ${NT_all_env} "PATH" $3 unDoSend: SendMessage ${HWND_BROADCAST} ${WM_WININICHANGE} 0 "STR:Environment" /TIMEOUT=5000 unRemoveFromPath_done: Pop $6 Pop $5 Pop $4 Pop $3 Pop $2 Pop $1 Pop $0 FunctionEnd ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; Uninstall sutff ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ########################################### # Utility Functions # ########################################### ;==================================================== ; IsNT - Returns 1 if the current system is NT, 0 ; otherwise. ; Output: head of the stack ;==================================================== ; IsNT ; no input ; output, top of the stack = 1 if NT or 0 if not ; ; Usage: ; Call IsNT ; Pop $R0 ; ($R0 at this point is 1 or 0) !macro IsNT un Function ${un}IsNT Push $0 ReadRegStr $0 HKLM "SOFTWARE\Microsoft\Windows NT\CurrentVersion" CurrentVersion StrCmp $0 "" 0 IsNT_yes ; we are not NT. Pop $0 Push 0 Return IsNT_yes: ; NT!!! Pop $0 Push 1 FunctionEnd !macroend !insertmacro IsNT "" !insertmacro IsNT "un." ; StrStr ; input, top of stack = string to search for ; top of stack-1 = string to search in ; output, top of stack (replaces with the portion of the string remaining) ; modifies no other variables. ; ; Usage: ; Push "this is a long ass string" ; Push "ass" ; Call StrStr ; Pop $R0 ; ($R0 at this point is "ass string") !macro StrStr un Function ${un}StrStr Exch $R1 ; st=haystack,old$R1, $R1=needle Exch ; st=old$R1,haystack Exch $R2 ; st=old$R1,old$R2, $R2=haystack Push $R3 Push $R4 Push $R5 StrLen $R3 $R1 StrCpy $R4 0 ; $R1=needle ; $R2=haystack ; $R3=len(needle) ; $R4=cnt ; $R5=tmp loop: StrCpy $R5 $R2 $R3 $R4 StrCmp $R5 $R1 done StrCmp $R5 "" done IntOp $R4 $R4 + 1 Goto loop done: StrCpy $R1 $R2 "" $R4 Pop $R5 Pop $R4 Pop $R3 Pop $R2 Exch $R1 FunctionEnd !macroend !insertmacro StrStr "" !insertmacro StrStr "un." Function Trim ; Added by Pelaca Exch $R1 Push $R2 Loop: StrCpy $R2 "$R1" 1 -1 StrCmp "$R2" " " RTrim StrCmp "$R2" "$\n" RTrim StrCmp "$R2" "$\r" RTrim StrCmp "$R2" ";" RTrim GoTo Done RTrim: StrCpy $R1 "$R1" -1 Goto Loop Done: Pop $R2 Exch $R1 FunctionEnd Function ConditionalAddToRegisty Pop $0 Pop $1 StrCmp "$0" "" ConditionalAddToRegisty_EmptyString WriteRegStr SHCTX "Software\Microsoft\Windows\CurrentVersion\Uninstall\mrViewer-2.6.7-Windows-64" \ "$1" "$0" ;MessageBox MB_OK "Set Registry: '$1' to '$0'" DetailPrint "Set install registry entry: '$1' to '$0'" ConditionalAddToRegisty_EmptyString: FunctionEnd ;-------------------------------- !ifdef CPACK_USES_DOWNLOAD Function DownloadFile IfFileExists $INSTDIR\* +2 CreateDirectory $INSTDIR Pop $0 ; Skip if already downloaded IfFileExists $INSTDIR\$0 0 +2 Return StrCpy $1 "" try_again: NSISdl::download "$1/$0" "$INSTDIR\$0" Pop $1 StrCmp $1 "success" success StrCmp $1 "Cancelled" cancel MessageBox MB_OK "Download failed: $1" cancel: Return success: FunctionEnd !endif ;-------------------------------- ; Installation types ;-------------------------------- ; Component sections ;-------------------------------- ; Define some macro setting for the gui !define MUI_ICON "F:/code/applications/mrViewer/mrViewer/src/icons/viewer.ico" ;-------------------------------- ;Pages !insertmacro MUI_PAGE_WELCOME !insertmacro MUI_PAGE_LICENSE "F:/code/applications/mrViewer/LICENSE.txt" Page custom InstallOptionsPage !insertmacro MUI_PAGE_DIRECTORY ;Start Menu Folder Page Configuration !define MUI_STARTMENUPAGE_REGISTRY_ROOT "SHCTX" !define MUI_STARTMENUPAGE_REGISTRY_KEY "Software\Humanity\mrViewer-2.6.7-Windows-64" !define MUI_STARTMENUPAGE_REGISTRY_VALUENAME "Start Menu Folder" !insertmacro MUI_PAGE_STARTMENU Application $STARTMENU_FOLDER !insertmacro MUI_PAGE_INSTFILES !insertmacro MUI_PAGE_FINISH !insertmacro MUI_UNPAGE_CONFIRM !insertmacro MUI_UNPAGE_INSTFILES ;-------------------------------- ;Languages !insertmacro MUI_LANGUAGE "English" ;first language is the default language !insertmacro MUI_LANGUAGE "Albanian" !insertmacro MUI_LANGUAGE "Arabic" !insertmacro MUI_LANGUAGE "Basque" !insertmacro MUI_LANGUAGE "Belarusian" !insertmacro MUI_LANGUAGE "Bosnian" !insertmacro MUI_LANGUAGE "Breton" !insertmacro MUI_LANGUAGE "Bulgarian" !insertmacro MUI_LANGUAGE "Croatian" !insertmacro MUI_LANGUAGE "Czech" !insertmacro MUI_LANGUAGE "Danish" !insertmacro MUI_LANGUAGE "Dutch" !insertmacro MUI_LANGUAGE "Estonian" !insertmacro MUI_LANGUAGE "Farsi" !insertmacro MUI_LANGUAGE "Finnish" !insertmacro MUI_LANGUAGE "French" !insertmacro MUI_LANGUAGE "German" !insertmacro MUI_LANGUAGE "Greek" !insertmacro MUI_LANGUAGE "Hebrew" !insertmacro MUI_LANGUAGE "Hungarian" !insertmacro MUI_LANGUAGE "Icelandic" !insertmacro MUI_LANGUAGE "Indonesian" !insertmacro MUI_LANGUAGE "Irish" !insertmacro MUI_LANGUAGE "Italian" !insertmacro MUI_LANGUAGE "Japanese" !insertmacro MUI_LANGUAGE "Korean" !insertmacro MUI_LANGUAGE "Kurdish" !insertmacro MUI_LANGUAGE "Latvian" !insertmacro MUI_LANGUAGE "Lithuanian" !insertmacro MUI_LANGUAGE "Luxembourgish" !insertmacro MUI_LANGUAGE "Macedonian" !insertmacro MUI_LANGUAGE "Malay" !insertmacro MUI_LANGUAGE "Mongolian" !insertmacro MUI_LANGUAGE "Norwegian" !insertmacro MUI_LANGUAGE "Polish" !insertmacro MUI_LANGUAGE "Portuguese" !insertmacro MUI_LANGUAGE "PortugueseBR" !insertmacro MUI_LANGUAGE "Romanian" !insertmacro MUI_LANGUAGE "Russian" !insertmacro MUI_LANGUAGE "Serbian" !insertmacro MUI_LANGUAGE "SerbianLatin" !insertmacro MUI_LANGUAGE "SimpChinese" !insertmacro MUI_LANGUAGE "Slovak" !insertmacro MUI_LANGUAGE "Slovenian" !insertmacro MUI_LANGUAGE "Spanish" !insertmacro MUI_LANGUAGE "Swedish" !insertmacro MUI_LANGUAGE "Thai" !insertmacro MUI_LANGUAGE "TradChinese" !insertmacro MUI_LANGUAGE "Turkish" !insertmacro MUI_LANGUAGE "Ukrainian" !insertmacro MUI_LANGUAGE "Welsh" ;-------------------------------- ;Reserve Files ;These files should be inserted before other files in the data block ;Keep these lines before any File command ;Only for solid compression (by default, solid compression is enabled for BZIP2 and LZMA) ReserveFile "NSIS.InstallOptions.ini" !insertmacro MUI_RESERVEFILE_INSTALLOPTIONS ;-------------------------------- ;Installer Sections Section "-Core installation" ;Use the entire tree produced by the INSTALL target. Keep the ;list of directories here in sync with the RMDir commands below. SetOutPath "$INSTDIR" File /r "${INST_DIR}\*.*" ;Store installation folder WriteRegStr SHCTX "Software\Humanity\mrViewer-2.6.7-Windows-64" "" $INSTDIR ;Create uninstaller WriteUninstaller "$INSTDIR\Uninstall.exe" Push "DisplayName" Push "mrViewer-2.6.7-Windows-64" Call ConditionalAddToRegisty Push "DisplayVersion" Push "0.1.1" Call ConditionalAddToRegisty Push "Publisher" Push "Humanity" Call ConditionalAddToRegisty Push "UninstallString" Push "$INSTDIR\Uninstall.exe" Call ConditionalAddToRegisty Push "NoRepair" Push "1" Call ConditionalAddToRegisty !ifdef CPACK_NSIS_ADD_REMOVE ;Create add/remove functionality Push "ModifyPath" Push "$INSTDIR\AddRemove.exe" Call ConditionalAddToRegisty !else Push "NoModify" Push "1" Call ConditionalAddToRegisty !endif ; Optional registration Push "DisplayIcon" Push "$INSTDIR\bin\mrViewer.exe" Call ConditionalAddToRegisty Push "HelpLink" Push "" Call ConditionalAddToRegisty Push "URLInfoAbout" Push "" Call ConditionalAddToRegisty Push "Contact" Push "" Call ConditionalAddToRegisty !insertmacro MUI_INSTALLOPTIONS_READ $INSTALL_DESKTOP "NSIS.InstallOptions.ini" "Field 5" "State" !insertmacro MUI_STARTMENU_WRITE_BEGIN Application ;Create shortcuts CreateDirectory "$SMPROGRAMS\$STARTMENU_FOLDER" CreateShortCut "$SMPROGRAMS\$STARTMENU_FOLDER\bin//mrViewer.lnk" "$INSTDIR\bin\mrViewer.exe" CreateShortCut "$SMPROGRAMS\$STARTMENU_FOLDER\Uninstall.lnk" "$INSTDIR\Uninstall.exe" ;Read a value from an InstallOptions INI file !insertmacro MUI_INSTALLOPTIONS_READ $DO_NOT_ADD_TO_PATH "NSIS.InstallOptions.ini" "Field 2" "State" !insertmacro MUI_INSTALLOPTIONS_READ $ADD_TO_PATH_ALL_USERS "NSIS.InstallOptions.ini" "Field 3" "State" !insertmacro MUI_INSTALLOPTIONS_READ $ADD_TO_PATH_CURRENT_USER "NSIS.InstallOptions.ini" "Field 4" "State" ; Write special uninstall registry entries Push "StartMenu" Push "$STARTMENU_FOLDER" Call ConditionalAddToRegisty Push "DoNotAddToPath" Push "$DO_NOT_ADD_TO_PATH" Call ConditionalAddToRegisty Push "AddToPathAllUsers" Push "$ADD_TO_PATH_ALL_USERS" Call ConditionalAddToRegisty Push "AddToPathCurrentUser" Push "$ADD_TO_PATH_CURRENT_USER" Call ConditionalAddToRegisty Push "InstallToDesktop" Push "$INSTALL_DESKTOP" Call ConditionalAddToRegisty !insertmacro MUI_STARTMENU_WRITE_END SectionEnd Section "-Add to path" Push $INSTDIR\bin StrCmp "ON" "ON" 0 doNotAddToPath StrCmp $DO_NOT_ADD_TO_PATH "1" doNotAddToPath 0 Call AddToPath doNotAddToPath: SectionEnd ;-------------------------------- ; Create custom pages Function InstallOptionsPage !insertmacro MUI_HEADER_TEXT "Install Options" "Choose options for installing mrViewer-2.6.7-Windows-64" !insertmacro MUI_INSTALLOPTIONS_DISPLAY "NSIS.InstallOptions.ini" FunctionEnd ;-------------------------------- ; determine admin versus local install Function un.onInit ClearErrors UserInfo::GetName IfErrors noLM Pop $0 UserInfo::GetAccountType Pop $1 StrCmp $1 "Admin" 0 +3 SetShellVarContext all ;MessageBox MB_OK 'User "$0" is in the Admin group' Goto done StrCmp $1 "Power" 0 +3 SetShellVarContext all ;MessageBox MB_OK 'User "$0" is in the Power Users group' Goto done noLM: ;Get installation folder from registry if available done: FunctionEnd ;--- Add/Remove callback functions: --- !macro SectionList MacroName ;This macro used to perform operation on multiple sections. ;List all of your components in following manner here. !macroend Section -FinishComponents ;Removes unselected components and writes component status to registry !insertmacro SectionList "FinishSection" !ifdef CPACK_NSIS_ADD_REMOVE ; Get the name of the installer executable System::Call 'kernel32::GetModuleFileNameA(i 0, t .R0, i 1024) i r1' StrCpy $R3 $R0 ; Strip off the last 13 characters, to see if we have AddRemove.exe StrLen $R1 $R0 IntOp $R1 $R0 - 13 StrCpy $R2 $R0 13 $R1 StrCmp $R2 "AddRemove.exe" addremove_installed ; We're not running AddRemove.exe, so install it CopyFiles $R3 $INSTDIR\AddRemove.exe addremove_installed: !endif SectionEnd ;--- End of Add/Remove callback functions --- ;-------------------------------- ; Component dependencies Function .onSelChange !insertmacro SectionList MaybeSelectionChanged FunctionEnd ;-------------------------------- ;Uninstaller Section Section "Uninstall" ReadRegStr $START_MENU SHCTX \ "Software\Microsoft\Windows\CurrentVersion\Uninstall\mrViewer-2.6.7-Windows-64" "StartMenu" ;MessageBox MB_OK "Start menu is in: $START_MENU" ReadRegStr $DO_NOT_ADD_TO_PATH SHCTX \ "Software\Microsoft\Windows\CurrentVersion\Uninstall\mrViewer-2.6.7-Windows-64" "DoNotAddToPath" ReadRegStr $ADD_TO_PATH_ALL_USERS SHCTX \ "Software\Microsoft\Windows\CurrentVersion\Uninstall\mrViewer-2.6.7-Windows-64" "AddToPathAllUsers" ReadRegStr $ADD_TO_PATH_CURRENT_USER SHCTX \ "Software\Microsoft\Windows\CurrentVersion\Uninstall\mrViewer-2.6.7-Windows-64" "AddToPathCurrentUser" ;MessageBox MB_OK "Add to path: $DO_NOT_ADD_TO_PATH all users: $ADD_TO_PATH_ALL_USERS" ReadRegStr $INSTALL_DESKTOP SHCTX \ "Software\Microsoft\Windows\CurrentVersion\Uninstall\mrViewer-2.6.7-Windows-64" "InstallToDesktop" ;MessageBox MB_OK "Install to desktop: $INSTALL_DESKTOP " ;Remove files we installed. ;Keep the list of directories here in sync with the File commands above. Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\avcodec-56.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\avdevice-56.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\avfilter-5.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\avformat-56.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\avutil-54.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\CORE_RL_bzlib_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\CORE_RL_jbig_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\CORE_RL_jp2_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\CORE_RL_jpeg_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\CORE_RL_lcms_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\CORE_RL_libxml_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\CORE_RL_Magick++_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\CORE_RL_magick_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\CORE_RL_png_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\CORE_RL_tiff_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\CORE_RL_ttf_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\CORE_RL_wand_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\CORE_RL_xlib_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\CORE_RL_zlib_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\ctlparser.exe" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\ctlparser.exe.manifest" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\exrenvmap.exe" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\exrheader.exe" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\exrmakepreview.exe" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\exrmaketiled.exe" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\exrstdattr.exe" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\ffmpeg.exe" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\ffplay.exe" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\ffprobe.exe" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\glew32.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\Half.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\Iex-2_2.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IexMath-2_2.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IlmCtl.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IlmCtlMath.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IlmCtlSimd.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IlmImf-2_2.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IlmImfCtl.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IlmImfUtil-2_2.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IlmThread-2_2.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\Imath-2_2.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_aai_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_art_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_avs_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_bgr_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_bmp_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_braille_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_cals_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_caption_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_cin_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_cip_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_clipboard_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_clip_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_cmyk_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_cut_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_dcm_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_dds_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_debug_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_dib_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_djvu_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_dng_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_dot_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_dps_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_dpx_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_emf_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_ept_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_exr_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_fax_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_fits_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_fpx_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_gif_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_gradient_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_gray_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_hald_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_hdr_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_histogram_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_hrz_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_html_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_icon_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_info_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_inline_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_ipl_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_jbig_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_jp2_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_jpeg_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_label_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_mac_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_magick_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_map_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_matte_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_mat_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_meta_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_miff_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_mono_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_mpc_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_mpeg_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_mpr_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_msl_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_mtv_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_mvg_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_null_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_otb_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_palm_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_pattern_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_pcd_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_pcl_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_pcx_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_pdb_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_pdf_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_pes_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_pict_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_pix_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_plasma_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_png_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_pnm_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_preview_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_ps2_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_ps3_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_psd_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_ps_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_pwp_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_raw_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_rgb_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_rla_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_rle_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_scr_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_sct_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_sfw_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_sgi_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_stegano_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_sun_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_svg_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_tga_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_thumbnail_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_tiff_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_tile_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_tim_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_txt_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_uil_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_url_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_uyvy_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_vicar_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_vid_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_viff_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_wbmp_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_webp_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_wpg_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_xbm_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_xcf_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_xc_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_xpm_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_xps_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_xtrn_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_xwd_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_x_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_ycbcr_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\IM_MOD_RL_yuv_.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\libeay32.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\libiconv-2.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\libintl-8.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\libpq.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\mrViewer.desktop" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\mrViewer.exe" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\mrViewer.exe.manifest" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\mrViewer.png" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\mrViewer.sh" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\msvcp100.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\msvcp90.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\msvcr100.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\msvcr90.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\postproc-53.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\readme.txt" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\ssleay32.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\swresample-1.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\swscale-3.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\sysntfy.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\bin\zlib.dll" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\ctl\ODT_monitor.ctl" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\ctl\RT_change_saturation.ctl~" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\ctl\RT_linear_to_HDTV_Rec709.ctl" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\ctl\RT_transform_exr.ctl" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\ctl\transform_RRT.ctl" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\ctl\utilities.ctl" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\3dview.html" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\about.html" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\asset_tracking.html" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\color_area.html" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\color_management.html" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\connections.html" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\conventions.html" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\creating_database.html" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\CtlManual.pdf" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\edl_edit.html" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\environment_variables.html" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\envvars_database.html" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\ffmpeg.html" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\fileformats.html" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\histogram.html" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\hotkeys.html" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\images\3DLut.png" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\images\3DView.png" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\images\About_Codecs.png" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\images\About_CPU.png" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\images\About_Formats.png" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\images\About_Main.png" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\images\About_Motion_Estimation.png" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\images\About_Protocols.png" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\images\assets_images.png" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\images\assets_shots.png" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\images\audioControl.gif" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\images\colorAreaWindow.png" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\images\Connections.png" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\images\draw_images.png" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\images\EDLedit.png" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\images\Fbutton.gif" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\images\FPScontrol.gif" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\images\histogramWindow.png" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\images\imageInfoWindow.png" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\images\LogWindow.png" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\images\loopControl.gif" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\images\mainWindow.png" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\images\mrViewer.png" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\images\PaintWindow.png" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\images\pixelBar.gif" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\images\playbackControls.gif" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\images\Preferences3DLut.png" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\images\Preferences3DLutsPaths.png" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\images\PreferencesCache.png" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\images\PreferencesColors.png" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\images\PreferencesDatabase.png" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\images\PreferencesDefaultODT.png" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\images\PreferencesDefaultRT.png" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\images\PreferencesLoading.png" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\images\PreferencesPlayback.png" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\images\PreferencesSound.png" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\images\PreferencesUI.png" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\images\PreferencesVideo.png" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\images\preferencesViewWindow.png" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\images\reelList.png" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\images\TimelineBar.gif" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\images\timelineControl.gif" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\images\topToolbar.gif" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\images\UserInterface.png" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\images\vectorscopeWindow.png" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\image_area.html" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\image_information.html" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\index.html" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\installation.html" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\install_postgreSQL.html" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\interface.html" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\libraries\LICENSE" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\licenses.html" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\log.html" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\main.html" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\main_toolbar.html" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\mrViewer.html" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\paint.html" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\pixel_toolbar.html" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\preferences.html" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\preferencesUI.html" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\preferences_audio.html" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\preferences_cache.html" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\preferences_loading.html" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\preferences_lut.html" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\preferences_lut_odt.html" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\preferences_lut_paths.html" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\preferences_lut_rt.html" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\preferences_playback.html" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\preferences_video.html" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\preferences_view.html" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\rails\accessing_project.html" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\rails\envvars_assets.html" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\rails\installing.html" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\rails\searching_assets.html" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\reel_list.html" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\setup_monitor.html" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\starting.html" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\stylesheet.css" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\timeline.html" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\toc.html" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\troubleshooting_all.html" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\troubleshooting_linux.html" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\troubleshooting_windows.html" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\using_CTL.html" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\using_ICC_with_CTL.html" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\vectorscope.html" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\shaders\CMakeLists.txt" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\shaders\rgba.arbfp1" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\shaders\rgba.cg" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\shaders\rgba.fp30" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\shaders\rgba.glsl" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\shaders\YByRy.arbfp1" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\shaders\YByRy.cg" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\shaders\YByRy.fp30" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\shaders\YByRy.glsl" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\shaders\YCbCr.arbfp1" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\shaders\YCbCr.cg" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\shaders\YCbCr.fp30" Delete "$INSTDIR\mrViewer-2.6.7-Windows-64\shaders\YCbCr.glsl" RMDir "$INSTDIR\mrViewer-2.6.7-Windows-64\bin" RMDir "$INSTDIR\mrViewer-2.6.7-Windows-64\ctl" RMDir "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\images" RMDir "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\libraries" RMDir "$INSTDIR\mrViewer-2.6.7-Windows-64\docs\rails" RMDir "$INSTDIR\mrViewer-2.6.7-Windows-64\docs" RMDir "$INSTDIR\mrViewer-2.6.7-Windows-64\lib\ImageMagick-6.7.4\modules-Q32\coders" RMDir "$INSTDIR\mrViewer-2.6.7-Windows-64\lib\ImageMagick-6.7.4\modules-Q32" RMDir "$INSTDIR\mrViewer-2.6.7-Windows-64\lib\ImageMagick-6.7.4" RMDir "$INSTDIR\mrViewer-2.6.7-Windows-64\lib" RMDir "$INSTDIR\mrViewer-2.6.7-Windows-64\shaders" RMDir "$INSTDIR\mrViewer-2.6.7-Windows-64" !ifdef CPACK_NSIS_ADD_REMOVE ;Remove the add/remove program Delete "$INSTDIR\AddRemove.exe" !endif ;Remove the uninstaller itself. Delete "$INSTDIR\Uninstall.exe" DeleteRegKey SHCTX "Software\Microsoft\Windows\CurrentVersion\Uninstall\mrViewer-2.6.7-Windows-64" ;Remove the installation directory if it is empty. RMDir "$INSTDIR" ; Remove the registry entries. DeleteRegKey SHCTX "Software\Humanity\mrViewer-2.6.7-Windows-64" ; Removes all optional components !insertmacro SectionList "RemoveSection_CPack" !insertmacro MUI_STARTMENU_GETFOLDER Application $MUI_TEMP Delete "$SMPROGRAMS\$MUI_TEMP\Uninstall.lnk" Delete "$SMPROGRAMS\$MUI_TEMP\bin//mrViewer.lnk" ;Delete empty start menu parent diretories StrCpy $MUI_TEMP "$SMPROGRAMS\$MUI_TEMP" startMenuDeleteLoop: ClearErrors RMDir $MUI_TEMP GetFullPathName $MUI_TEMP "$MUI_TEMP\.." IfErrors startMenuDeleteLoopDone StrCmp "$MUI_TEMP" "$SMPROGRAMS" startMenuDeleteLoopDone startMenuDeleteLoop startMenuDeleteLoopDone: ; If the user changed the shortcut, then untinstall may not work. This should ; try to fix it. StrCpy $MUI_TEMP "$START_MENU" Delete "$SMPROGRAMS\$MUI_TEMP\Uninstall.lnk" ;Delete empty start menu parent diretories StrCpy $MUI_TEMP "$SMPROGRAMS\$MUI_TEMP" secondStartMenuDeleteLoop: ClearErrors RMDir $MUI_TEMP GetFullPathName $MUI_TEMP "$MUI_TEMP\.." IfErrors secondStartMenuDeleteLoopDone StrCmp "$MUI_TEMP" "$SMPROGRAMS" secondStartMenuDeleteLoopDone secondStartMenuDeleteLoop secondStartMenuDeleteLoopDone: DeleteRegKey /ifempty SHCTX "Software\Humanity\mrViewer-2.6.7-Windows-64" Push $INSTDIR\bin StrCmp $DO_NOT_ADD_TO_PATH_ "1" doNotRemoveFromPath 0 Call un.RemoveFromPath doNotRemoveFromPath: SectionEnd ;-------------------------------- ; determine admin versus local install ; Is install for "AllUsers" or "JustMe"? ; Default to "JustMe" - set to "AllUsers" if admin or on Win9x ; This function is used for the very first "custom page" of the installer. ; This custom page does not show up visibly, but it executes prior to the ; first visible page and sets up $INSTDIR properly... ; Choose different default installation folder based on SV_ALLUSERS... ; "Program Files" for AllUsers, "My Documents" for JustMe... Function .onInit StrCmp "" "ON" 0 inst ReadRegStr $0 HKLM "Software\Microsoft\Windows\CurrentVersion\Uninstall\mrViewer-2.6.7-Windows-64" "UninstallString" StrCmp $0 "" inst MessageBox MB_YESNOCANCEL|MB_ICONEXCLAMATION \ "mrViewer-2.6.7-Windows-64 is already installed. $\n$\nDo you want to uninstall the old version before installing the new one?" \ IDYES uninst IDNO inst Abort ;Run the uninstaller uninst: ClearErrors StrLen $2 "\Uninstall.exe" StrCpy $3 $0 -$2 # remove "\Uninstall.exe" from UninstallString to get path ExecWait '$0 _?=$3' ;Do not copy the uninstaller to a temp file IfErrors uninst_failed inst uninst_failed: MessageBox MB_OK|MB_ICONSTOP "Uninstall failed." Abort inst: ; Reads components status for registry !insertmacro SectionList "InitSection" ; check to see if /D has been used to change ; the install directory by comparing it to the ; install directory that is expected to be the ; default StrCpy $IS_DEFAULT_INSTALLDIR 0 StrCmp "$INSTDIR" "$PROGRAMFILES64\mrViewer-2.6.7-Windows-64" 0 +2 StrCpy $IS_DEFAULT_INSTALLDIR 1 StrCpy $SV_ALLUSERS "JustMe" ; if default install dir then change the default ; if it is installed for JustMe StrCmp "$IS_DEFAULT_INSTALLDIR" "1" 0 +2 StrCpy $INSTDIR "$DOCUMENTS\mrViewer-2.6.7-Windows-64" ClearErrors UserInfo::GetName IfErrors noLM Pop $0 UserInfo::GetAccountType Pop $1 StrCmp $1 "Admin" 0 +4 SetShellVarContext all ;MessageBox MB_OK 'User "$0" is in the Admin group' StrCpy $SV_ALLUSERS "AllUsers" Goto done StrCmp $1 "Power" 0 +4 SetShellVarContext all ;MessageBox MB_OK 'User "$0" is in the Power Users group' StrCpy $SV_ALLUSERS "AllUsers" Goto done noLM: StrCpy $SV_ALLUSERS "AllUsers" ;Get installation folder from registry if available done: StrCmp $SV_ALLUSERS "AllUsers" 0 +3 StrCmp "$IS_DEFAULT_INSTALLDIR" "1" 0 +2 StrCpy $INSTDIR "$PROGRAMFILES64\mrViewer-2.6.7-Windows-64" StrCmp "ON" "ON" 0 noOptionsPage !insertmacro MUI_INSTALLOPTIONS_EXTRACT "NSIS.InstallOptions.ini" noOptionsPage: FunctionEnd From becker.tobi at gmail.com Sun Jan 11 14:03:49 2015 From: becker.tobi at gmail.com (Tobias Becker) Date: Sun, 11 Jan 2015 20:03:49 +0100 Subject: [CMake] Discuss Adding return values/dynamic function invokation to cmake Message-ID: Hi All, I've been thinking aboutallowing return values/ function evaluation in the cmake script language. Especially if there are any downsides e.g. compatibility issues/language inconsistency. What I mean is the following syntax: ``` function(func1) return(1) endfunction() function(add lhs rhs) math(EXPR res "${lhs} + ${rhs}") return(${res}) endfunction() set(result ${func1()}) # checks to see if function is defined and if so invokes it idicated by parenthesis assert(${result} EQUAL 1) set(result ${add(${func1()} 2}) # inner function is evaluated first and result is pasted in outer function assert(${result} EQUAL 3) message(INFO "${add(1 3)}") # --> prints 4 set(function_name add) message(INFO "${function_name}(3 5)}") # --> prints 8 ``` This could replace generator expressions with a cleaner and more general alternative and also it would allow cmake to become much easier to use. I'd also like to know if someone could point me to where in the cmake codebase the "${}" evaluation expression is actually processed. If you have any critique of this idea then I would also be happy - else I'll try to fork cmake and implement this. Cheers! Tobias -------------- next part -------------- An HTML attachment was scrubbed... URL: From ramey at rrsd.com Sun Jan 11 14:21:46 2015 From: ramey at rrsd.com (Robert Ramey) Date: Sun, 11 Jan 2015 12:21:46 -0700 (MST) Subject: [CMake] my.cdash.org problems Message-ID: <1421004106374-7589444.post@n2.nabble.com> I want to show all the tests run in the past year. For this I use the URL Safe Numerics Dashboard So far so good. But I have a number of problems: a) when I run the experimental target on my Cmake setup, I get an error message: Uploaded: /Users/robertramey/WorkingProjects/safe_numerics_gcc-4.8.1/Testing/20150111-1903/Test.xml Errors occurred during submission. Errors while running CTest make[3]: *** [CMakeFiles/Experimental] Error 8 make[2]: *** [CMakeFiles/Experimental.dir/all] Error 2 make[1]: *** [CMakeFiles/Experimental.dir/rule] Error 2 make: *** [Experimental] Error 2 my CTestConfig.cmake is: set(CTEST_PROJECT_NAME "Safe Numerics") set(CTEST_NIGHTLY_START_TIME "01:00:00 UTC") set(CTEST_DROP_METHOD "http") set(CTEST_DROP_SITE "my.cdash.org") # set(CTEST_DROP_LOCATION "/cdash/submit.php?project=MyProject") set(CTEST_DROP_LOCATION "/index.php?project=Safe+Numerics") set(CTEST_DROP_SITE_CDASH TRUE) What do I have to do make this work and add another line to my test dashboard? b)when I log in to http://my.cdash.org I get a screen with a simple message No update data as of Sunday, January 11 2015 - 00:00 EST 211 days ago: 13 tests not run on Darwin-clang++ 211 days ago: 10 warnings introduced on Darwin-clang++ which OK. BUT I don't see how to get the display I get to above which shows all the test results for the past year. How do I get there? Robert Ramey -- View this message in context: http://cmake.3232098.n2.nabble.com/my-cdash-org-problems-tp7589444.html Sent from the CMake mailing list archive at Nabble.com. From brad.king at kitware.com Sun Jan 11 14:58:11 2015 From: brad.king at kitware.com (Brad King) Date: Sun, 11 Jan 2015 14:58:11 -0500 Subject: [CMake] cmake FortranCInterface test fails in a linking step due to the -rdynamic option in Linux-GNU.cmake In-Reply-To: <54AECCC6.2070203@kitware.com> References: <54AECCC6.2070203@kitware.com> Message-ID: <54B2D5D3.2010005@kitware.com> On 1/8/2015 1:30 PM, Brad King wrote: > The Linux-GNU module's behavior should not be getting invoked > for XL Fortran because the Fortran compiler id is "XL", not "GNU". > > I'd like to understand how the option makes it to the link line: To follow up on-list, it turns out that CMakeFortranInformation.cmake was initializing the CMAKE_SHARED_LIBRARY_LINK_Fortran_FLAGS value from the C version since no platform modules set it explicitly for XL Fortran. The fix is: XL: Fix link flags for executables on Linux with XL compilers http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4729547a -Brad From rob.a.mcdonald at gmail.com Sun Jan 11 15:02:38 2015 From: rob.a.mcdonald at gmail.com (Rob McDonald) Date: Sun, 11 Jan 2015 12:02:38 -0800 Subject: [CMake] Matlab producing image files for use with LaTeX Message-ID: I am familiar with UseLATEX, but would like to take the automation of my document build system a step or two further. Solutions that build on UseLATEX -- or a totally separate approach, are OK. I often use Matlab to create *.pdf figures -- which are then used in a LaTeX document. I would like my build setup to notice when a Matlab *.m file has changed - and then re-run it to re-generate the dependent *.pdf - and then LaTeX for the final document. If that works, I would like to take things a step further and specify that the *.m files may depend on some external data files of arbitrary formats. The whole system should notice and update when those data files are updated. Bonus points for a system that detects as much of the dependencies automagically (like #include ing header files). Any suggestions? Rob From apaku at gmx.de Sun Jan 11 16:27:49 2015 From: apaku at gmx.de (Andreas Pakulat) Date: Sun, 11 Jan 2015 22:27:49 +0100 Subject: [CMake] Tweak CMake project to include non-buildable files in the CodeBlocks project file Message-ID: Hi, I'm using QtCreator with CMake and have several files that are included in targets depending on the platform on which I build. Files that are not enabled on the current platform will not be included by CMake in the CodeBlocks file which in turn is used by QtCreator. Since QtCreator only picks up files listed in the CodeBlocks project file for its project view I cannot easily open certain files using QtCreator. I'm wondering wether CMake has a mechanism that would make these files show up in the CodeBlocks project file without them being actually compiled by the project build (I'm using Ninja for that part)? I was thinking of something similar to what can be used to create groups etc. for VS projects. Andreas -------------- next part -------------- An HTML attachment was scrubbed... URL: From oliveridario89 at gmail.com Sun Jan 11 16:55:40 2015 From: oliveridario89 at gmail.com (Dario Oliveri) Date: Sun, 11 Jan 2015 22:55:40 +0100 Subject: [CMake] Tweak CMake project to include non-buildable files in the CodeBlocks project file In-Reply-To: References: Message-ID: It is very simple for each of the files you want to include in the build (I use txt example so that you know it can work for arbitrary types): --- set_source_files_properties( comment.txt PROPERTIES HEADER_FILE_ONLY true) --- then you can include that file in the build to let it shows up in the IDE file --- #example when adding a static library (works the same also for executables) add_library( ${arg1} STATIC ${sourcefiles} #files you need to REALLY BUILD comment.txt #this file would be added, but not builded ) --- 2015-01-11 22:27 GMT+01:00 Andreas Pakulat : > Hi, > > I'm using QtCreator with CMake and have several files that are included in > targets depending on the platform on which I build. > > Files that are not enabled on the current platform will not be included by > CMake in the CodeBlocks file which in turn is used by QtCreator. > > Since QtCreator only picks up files listed in the CodeBlocks project file > for its project view I cannot easily open certain files using QtCreator. > > I'm wondering wether CMake has a mechanism that would make these files > show up in the CodeBlocks project file without them being actually compiled > by the project build (I'm using Ninja for that part)? I was thinking of > something similar to what can be used to create groups etc. for VS projects. > > Andreas > > -- > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From apaku at gmx.de Mon Jan 12 05:40:22 2015 From: apaku at gmx.de (Andreas Pakulat) Date: Mon, 12 Jan 2015 11:40:22 +0100 Subject: [CMake] Tweak CMake project to include non-buildable files in the CodeBlocks project file In-Reply-To: References: Message-ID: Hi, On Sun, Jan 11, 2015 at 10:55 PM, Dario Oliveri wrote: > It is very simple for each of the files you want to include in the build > (I use txt example so that you know it can work for arbitrary types): > > --- > set_source_files_properties( comment.txt PROPERTIES HEADER_FILE_ONLY true) > --- > then you can include that file in the build to let it shows up in the IDE > file > > --- > #example when adding a static library (works the same also for executables) > add_library( ${arg1} STATIC > ${sourcefiles} #files you need to REALLY BUILD > comment.txt #this file would be added, but not builded > ) > --- > Ah, that works. Its a little ugly in the CMake files but I guess I can live with that. Ideally I was hoping to simply have a 'complete' list including actual sources and sources for other platforms and hand that to a special function - without passing the source-for-other-platform to the actual target. Oh well, I have to stop dreaming :) Andreas -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Mon Jan 12 05:50:42 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Mon, 12 Jan 2015 11:50:42 +0100 Subject: [CMake] Tweak CMake project to include non-buildable files in the CodeBlocks project file In-Reply-To: References: Message-ID: <54B3A702.3030409@gmail.com> On 01/12/2015 11:40 AM, Andreas Pakulat wrote: > Ah, that works. Its a little ugly in the CMake files but I guess I can > live with that. Ideally I was hoping to simply have a 'complete' list > including actual sources and sources for other platforms and hand that > to a special function - without passing the source-for-other-platform to > the actual target. Oh well, I have to stop dreaming :) You can also use add_custom_target(my_new_target SOURCES src1.cpp src2.cpp). That will list the given sources in the IDE without adding build semantics to them. Since this lists the sources as part of a new target rather than an existing target this will be visually distinct from the other approach in some IDEs but should afaik make no difference in QtCreator. In case you stick with HEADER_FILE_ONLY a custom function() might help with the ugly. Nils From mylesenglish at gmail.com Mon Jan 12 06:26:01 2015 From: mylesenglish at gmail.com (Myles English) Date: Mon, 12 Jan 2015 11:26:01 +0000 Subject: [CMake] Matlab producing image files for use with LaTeX In-Reply-To: References: Message-ID: <87fvbgz0r1.fsf@gmail.com> Hello Rob, Rob McDonald writes: > I am familiar with UseLATEX, but would like to take the automation of > my document build system a step or two further. Solutions that build > on UseLATEX -- or a totally separate approach, are OK. > > I often use Matlab to create *.pdf figures -- which are then used in a > LaTeX document. I would like my build setup to notice when a Matlab > *.m file has changed - and then re-run it to re-generate the dependent > *.pdf - and then LaTeX for the final document. I haven't done it myself, but How about using emacs? An emacs daemon could notice when files change and call emacs org-mode functions (optionally via a call to CMake) to call Matlab to regenerate the plots, then org-mode export as LaTeX. A part of CMakeLists.txt to call emacs function may be like this: add_custom_command( OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/mainThesis.tex COMMAND emacs -Q --batch --eval \"(progn (add-to-list 'load-path (expand-file-name \\"~/.emacs.d/plugins/org-mode/lisp/\\")) (require 'org) .....etc. > If that works, I would like to take things a step further and specify > that the *.m files may depend on some external data files of arbitrary > formats. The whole system should notice and update when those data > files are updated. A cron job to download the data locally (using curl or wget) then the emacs daemon could monitor those also. > > Bonus points for a system that detects as much of the dependencies > automagically (like #include ing header files). Emacs Org-mode source blocks store a hash so they only re-run if necessary. Myles From apaku at gmx.de Mon Jan 12 07:47:42 2015 From: apaku at gmx.de (Andreas Pakulat) Date: Mon, 12 Jan 2015 13:47:42 +0100 Subject: [CMake] Tweak CMake project to include non-buildable files in the CodeBlocks project file In-Reply-To: <54B3A702.3030409@gmail.com> References: <54B3A702.3030409@gmail.com> Message-ID: Hi Nils, On Mon, Jan 12, 2015 at 11:50 AM, Nils Gladitz wrote: > On 01/12/2015 11:40 AM, Andreas Pakulat wrote: > >> Ah, that works. Its a little ugly in the CMake files but I guess I can >> live with that. Ideally I was hoping to simply have a 'complete' list >> including actual sources and sources for other platforms and hand that >> to a special function - without passing the source-for-other-platform to >> the actual target. Oh well, I have to stop dreaming :) >> > > You can also use add_custom_target(my_new_target SOURCES src1.cpp > src2.cpp). > > That will list the given sources in the IDE without adding build semantics > to them. > > Since this lists the sources as part of a new target rather than an > existing target this will be visually distinct from the other approach in > some IDEs but should afaik make no difference in QtCreator. > Thanks for that idea, having a dedicated target wouldn't be so bad even if its visible. With a bit of restructuring of the cmakelists.txt this may actually make the file quite a bit more 'declarative' and less convoluted. Andreas -------------- next part -------------- An HTML attachment was scrubbed... URL: From kmorel at sandia.gov Mon Jan 12 11:10:24 2015 From: kmorel at sandia.gov (Moreland, Kenneth) Date: Mon, 12 Jan 2015 16:10:24 +0000 Subject: [CMake] Matlab producing image files for use with LaTeX Message-ID: Unlike Myles' answer, I'm going to assume that by noticing *.m files have changed you mean that the changes are picked up when a make build is run, not necessarily using a daemon to pick up exactly when the change occurs. You should be able to set a trail of dependencies for make to pick up the change in the .m file and rebuild accordingly. The first step, of course, is to make commands to create the pdf file. Then add the output file to the DEPENDS command of ADD_LATEX_DOCUMENT. Make sure that the pdf file you create is in the same build directory where the LaTeX command is run so that your image is picked up. The CMake commands would look something like this: add_custom_command( OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/MatlabCreated.pdf DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/MatlabCreated.m COMMAND ) add_latex_document(MyDoc.tex DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/MatlabCreated.pdf ) I don't know Matlab well enough to know whether there is a mechanism to follow source file dependencies. You could always try writing your own or Google searching to see if anyone else has done it in CMake, but one step at a time. -Ken On 1/11/15, 1:02 PM, "Rob McDonald" wrote: >I am familiar with UseLATEX, but would like to take the automation of >my document build system a step or two further. Solutions that build >on UseLATEX -- or a totally separate approach, are OK. > >I often use Matlab to create *.pdf figures -- which are then used in a >LaTeX document. I would like my build setup to notice when a Matlab >*.m file has changed - and then re-run it to re-generate the dependent >*.pdf - and then LaTeX for the final document. > >If that works, I would like to take things a step further and specify >that the *.m files may depend on some external data files of arbitrary >formats. The whole system should notice and update when those data >files are updated. > >Bonus points for a system that detects as much of the dependencies >automagically (like #include ing header files). > >Any suggestions? > >Rob >-- > >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 From julien.jomier at kitware.com Mon Jan 12 11:12:58 2015 From: julien.jomier at kitware.com (Julien Jomier) Date: Mon, 12 Jan 2015 17:12:58 +0100 Subject: [CMake] Fwd: my.cdash.org problems In-Reply-To: <54B3E551.8020907@kitware.com> References: <1421004106374-7589444.post@n2.nabble.com> <54B3E551.8020907@kitware.com> Message-ID: <54B3F28A.4000501@kitware.com> Hi Robert, Regarding your questions: 1) You should use the following CTEST_DROP_LOCATION: set(CTEST_DROP_LOCATION "/submit.php?project=Safe+Numerics") 2) For the free version of hosted cdash, the builds are deleted every 30 days. That's why you will not be able to see the builds submitted 211 days ago. Hope that helps, Julien > Subject: [CMake] my.cdash.org problems > Date: Sun, 11 Jan 2015 12:21:46 -0700 (MST) > From: Robert Ramey > To: cmake at cmake.org > > I want to show all the tests run in the past year. For this I use the URL > Safe Numerics Dashboard > > > > So far so good. But I have a number of problems: > > a) when I run the experimental target on my Cmake setup, I get an error > message: > > > Uploaded: > /Users/robertramey/WorkingProjects/safe_numerics_gcc-4.8.1/Testing/20150111-1903/Test.xml > > Errors occurred during submission. > Errors while running CTest > make[3]: *** [CMakeFiles/Experimental] Error 8 > make[2]: *** [CMakeFiles/Experimental.dir/all] Error 2 > make[1]: *** [CMakeFiles/Experimental.dir/rule] Error 2 > make: *** [Experimental] Error 2 > > my CTestConfig.cmake is: > > set(CTEST_PROJECT_NAME "Safe Numerics") > set(CTEST_NIGHTLY_START_TIME "01:00:00 UTC") > > set(CTEST_DROP_METHOD "http") > set(CTEST_DROP_SITE "my.cdash.org") > # set(CTEST_DROP_LOCATION "/cdash/submit.php?project=MyProject") > set(CTEST_DROP_LOCATION "/index.php?project=Safe+Numerics") > set(CTEST_DROP_SITE_CDASH TRUE) > > What do I have to do make this work and add another line to my test > dashboard? > > b)when I log in to http://my.cdash.org I get a screen with a simple message > > No update data as of Sunday, January 11 2015 - 00:00 EST > 211 days ago: 13 tests not run on Darwin-clang++ > 211 days ago: 10 warnings introduced on Darwin-clang++ > > which OK. BUT I don't see how to get the display I get to above which > shows > all the test results for the past year. How do I get there? > > Robert Ramey > > > > > > -- > View this message in context: > http://cmake.3232098.n2.nabble.com/my-cdash-org-problems-tp7589444.html > Sent from the CMake mailing list archive at Nabble.com. From david.thompson at kitware.com Mon Jan 12 11:59:08 2015 From: david.thompson at kitware.com (David Thompson) Date: Mon, 12 Jan 2015 11:59:08 -0500 Subject: [CMake] Simultaneous makes? In-Reply-To: References: Message-ID: <7FF94248-A110-4399-89CA-367F8FCC9659@kitware.com> Hi Chris, > One of my co-workers likes to start multiple makes in various parts of his project source tree. Under our old Makefile-based, build-in-source system, this worked fine. Under our new CMake-based, out-of-source build system, this causes problems, since any make might cause CMake to rebuild its internal files. > > Is this a "don't do that" problem, or can CMake be used in a manner where it is smart enough not to step on its own toes? One workaround would be to run cmake manually before setting off multiple "(cd blah; make)" processes in the background. CMake should not need to run multiple times per "make" invocation unless you are doing something very strange. Also, if you are using your personal knowledge of project dependencies and know it is OK to skip some steps, you might try making the "/fast" version of targets in those subdirectories without rebuilding their indirect dependencies (e.g., if "make foo" works, you can "make foo/fast" to avoid rebuilding other targets that foo depends on). I am less sure that this avoids re-runs of CMake, but I don't recall it doing that in general. David From ramey at rrsd.com Mon Jan 12 13:11:45 2015 From: ramey at rrsd.com (Robert Ramey) Date: Mon, 12 Jan 2015 11:11:45 -0700 (MST) Subject: [CMake] linking gcc on osx Message-ID: <1421086305151-7589456.post@n2.nabble.com> I use my Mac OSX to test my code against gcc 4.8. I've installed the appropriate command line tools and the compiler/linker works fine from the command line. My CMakeLists.txt project file works fine to generate an Xcode project for build and test. I can also use it to generate a makefile project for unix. (after deleting cache etc...). The executable compile with the appropriate compiler. BUT they won't link with the standard library !!! That is, I get Any help would be appreciated Robert Ramey -- View this message in context: http://cmake.3232098.n2.nabble.com/linking-gcc-on-osx-tp7589456.html Sent from the CMake mailing list archive at Nabble.com. From ramey at rrsd.com Mon Jan 12 13:22:17 2015 From: ramey at rrsd.com (Robert Ramey) Date: Mon, 12 Jan 2015 11:22:17 -0700 (MST) Subject: [CMake] linking gcc on osx In-Reply-To: <1421086305151-7589456.post@n2.nabble.com> References: <1421086305151-7589456.post@n2.nabble.com> Message-ID: <1421086937577-7589457.post@n2.nabble.com> That's it !!!! I changed to C++ compiler to g++ and re-generated the project and it build and linked. Thanks a lot. Robert Ramey -- View this message in context: http://cmake.3232098.n2.nabble.com/linking-gcc-on-osx-tp7589456p7589457.html Sent from the CMake mailing list archive at Nabble.com. From ggarra13 at gmail.com Mon Jan 12 15:53:49 2015 From: ggarra13 at gmail.com (Gonzalo Garramuno) Date: Mon, 12 Jan 2015 17:53:49 -0300 Subject: [CMake] NSIS startup menu and icons In-Reply-To: <54B15AE5.2000501@gmail.com> References: <54B15AE5.2000501@gmail.com> Message-ID: <54B4345D.4040405@gmail.com> On 10/01/15 14:01, Gonzalo Garramu?o wrote: > I have created an NSIS section for my CMakeLists.txt and I am trying > to pack and install my application (mrViewer). I managed to make it all work by flattening the destination, so that instead of ${mrViewerPackageName}/bin, it remains as bin only. Also I found that this works: SET(CPACK_PACKAGE_EXECUTABLES "mrViewer" "mrViewer" ) SET( CPACK_CREATE_DESKTOP_LINKS "mrViewer" ) but this, which according to the docs should, does not: SET(CPACK_PACKAGE_EXECUTABLES "mrViewer" "mrViewer-64" ) SET( CPACK_CREATE_DESKTOP_LINKS "mrViewer-64" ) From mark.j.abraham at gmail.com Tue Jan 13 02:44:29 2015 From: mark.j.abraham at gmail.com (Mark Abraham) Date: Tue, 13 Jan 2015 08:44:29 +0100 Subject: [CMake] Matlab producing image files for use with LaTeX In-Reply-To: References: Message-ID: Hi, Another example along Kenneth's lines: https://github.com/gromacs/gromacs/blob/master/docs/manual/CMakeLists.txt Mark On Mon, Jan 12, 2015 at 5:10 PM, Moreland, Kenneth wrote: > Unlike Myles' answer, I'm going to assume that by noticing *.m files have > changed you mean that the changes are picked up when a make build is run, > not necessarily using a daemon to pick up exactly when the change occurs. > > You should be able to set a trail of dependencies for make to pick up the > change in the .m file and rebuild accordingly. The first step, of course, > is to make commands to create the pdf file. Then add the output file to > the DEPENDS command of ADD_LATEX_DOCUMENT. Make sure that the pdf file you > create is in the same build directory where the LaTeX command is run so > that your image is picked up. The CMake commands would look something like > this: > > > add_custom_command( > OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/MatlabCreated.pdf > DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/MatlabCreated.m > COMMAND > ) > > add_latex_document(MyDoc.tex > DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/MatlabCreated.pdf > ) > > > I don't know Matlab well enough to know whether there is a mechanism to > follow source file dependencies. You could always try writing your own or > Google searching to see if anyone else has done it in CMake, but one step > at a time. > > -Ken > > > > On 1/11/15, 1:02 PM, "Rob McDonald" wrote: > > >I am familiar with UseLATEX, but would like to take the automation of > >my document build system a step or two further. Solutions that build > >on UseLATEX -- or a totally separate approach, are OK. > > > >I often use Matlab to create *.pdf figures -- which are then used in a > >LaTeX document. I would like my build setup to notice when a Matlab > >*.m file has changed - and then re-run it to re-generate the dependent > >*.pdf - and then LaTeX for the final document. > > > >If that works, I would like to take things a step further and specify > >that the *.m files may depend on some external data files of arbitrary > >formats. The whole system should notice and update when those data > >files are updated. > > > >Bonus points for a system that detects as much of the dependencies > >automagically (like #include ing header files). > > > >Any suggestions? > > > >Rob > >-- > > > >Powered by www.kitware.com > > > >Please keep messages on-topic and check the CMake FAQ at: > >http://www.cmake.org/Wiki/CMake_FAQ > > > >Kitware offers various services to support the CMake community. For more > >information on each offering, please visit: > > > >CMake Support: http://cmake.org/cmake/help/support.html > >CMake Consulting: http://cmake.org/cmake/help/consulting.html > >CMake Training Courses: http://cmake.org/cmake/help/training.html > > > >Visit other Kitware open-source projects at > >http://www.kitware.com/opensource/opensource.html > > > >Follow this link to subscribe/unsubscribe: > >http://public.kitware.com/mailman/listinfo/cmake > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lode.leroy at gmail.com Tue Jan 13 08:02:09 2015 From: lode.leroy at gmail.com (Lode Leroy) Date: Tue, 13 Jan 2015 14:02:09 +0100 Subject: [CMake] cmake + vc12 Message-ID: Is there a way to see the executed command when using "NMake Makefiles"? I would like to see the "cl /c /flag1 /flag2 file.cpp" etc... -- lode From Arjen.Markus at deltares.nl Tue Jan 13 08:05:06 2015 From: Arjen.Markus at deltares.nl (Arjen Markus) Date: Tue, 13 Jan 2015 13:05:06 +0000 Subject: [CMake] cmake + vc12 In-Reply-To: References: Message-ID: <8CF085736108634681FD03EC36E6A0723D9824B6@V-EXC-C02.DIRECTORY.INTRA> Hello lode, You can use: nmake verbose=1 to have the commands printed. Regards, Arjen > -----Original Message----- > From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Lode Leroy > Sent: Tuesday, January 13, 2015 2:02 PM > To: cmake at cmake.org > Subject: [CMake] cmake + vc12 > > Is there a way to see the executed command when using "NMake Makefiles"? > I would like to see the "cl /c /flag1 /flag2 file.cpp" etc... > > -- lode > -- > > 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 > DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. -------------- next part -------------- An HTML attachment was scrubbed... URL: From blowekamp at mail.nih.gov Tue Jan 13 10:29:35 2015 From: blowekamp at mail.nih.gov (Lowekamp, Bradley (NIH/NLM/LHC) [C]) Date: Tue, 13 Jan 2015 15:29:35 +0000 Subject: [CMake] Issue parsing command lines with '=' in value of defined variables Message-ID: Hello, I encountered this issue only on windows why trying to use the ExternalData module with a file called: "slice_01524_z-5.0034um.tif" I am tested with CMake 3.0.2 and 2.8.12.2 on widows for this test. Here is the test script: foreach(i RANGE ${CMAKE_ARGC}) message(STATUS "ARGV${i}: ${CMAKE_ARGV${i}}") endforeach() message(STATUS "ExternalData file: ${file}") Some runs: $ cmake -Dfile=good.tif -P EqualTest.cmake -- ARGV0: c:\Program Files (x86)\CMake 2.8\bin\cmake.exe -- ARGV1: -Dfile=good.tif -- ARGV2: -P -- ARGV3: EqualTest.cmake -- ARGV4: -- ExternalData file: good.tif [OK] $ cmake -Dfile=slice_01524_z=5.0034um.tif -P EqualTest.cmake -- ARGV0: c:\Program Files (x86)\CMake 2.8\bin\cmake.exe -- ARGV1: -Dfile=slice_01524_z=5.0034um.tif -- ARGV2: -P -- ARGV3: EqualTest.cmake -- ARGV4: -- ExternalData file: slice_01524_z=5.0034um.tif [OK] $ cmake -Dfile=InLens/slice_01524_z=5.0034um.tif -P EqualTest.cmake -- ARGV0: c:\Program Files (x86)\CMake 2.8\bin\cmake.exe -- ARGV1: -Dfile=InLens/slice_01524_z=5.0034um.tif -- ARGV2: -P -- ARGV3: EqualTest.cmake -- ARGV4: -- ExternalData file: InLens/slice_01524_z=5.0034um.tif [OK] $ cmake -Dfile=C:/slice_01524_z=5.0034um.tif -P EqualTest.cmake -- ARGV0: c:\Program Files (x86)\CMake 2.8\bin\cmake.exe -- ARGV1: -Dfile=C:/slice_01524_z=5.0034um.tif -- ARGV2: -P -- ARGV3: EqualTest.cmake -- ARGV4: -- ExternalData file: [FAIL] So it looks like when the value has the dive and an equal sign no value is assigned. Bug? Thanks, Brad From brandon.ess at gmail.com Tue Jan 13 12:18:47 2015 From: brandon.ess at gmail.com (leemachine) Date: Tue, 13 Jan 2015 10:18:47 -0700 (MST) Subject: [CMake] Include path perference Message-ID: <1421169527150-7589463.post@n2.nabble.com> Hello all, I am using CMAKE 2.8.7: My question is I have a project that looks for dependencies (libraries and headers) in both the source tree (*CMAKE_SOURCE_DIR* and *CMAKE_CURRENT_SOURCE_DIR* as well as the *CMAKE_INSTALL_PREFIX*. The issue I am having is I'm making changes to the source tree that are not compatible with the header files installed in the *CMAKE_INSTALL_PREFIX*. In all the cmake message prints statements I make it returns the expected results. CMAKE is using .cc and .h files in the source tree even though the .h files are also in the *CMAKE_INSTALL_PREFIX*. When compiling I get an error relating to the incompatablity I mentioned. GCC is using the header files in the *CMAKE_INSTALL_PREFIX* and the .cc files in *CMAKE_CURRENT_SOURCE_DIR* How do I tell CMAKE to NOT use the header files in the *CMAKE_INSTALL_PREFIX*? I understand a fresh *CMAKE_INSTALL_PREFIX* would resolve this issue, but I'm looking for a workaround to that as well. Thanks, -Brandon -- View this message in context: http://cmake.3232098.n2.nabble.com/Include-path-perference-tp7589463.html Sent from the CMake mailing list archive at Nabble.com. From pa at letnes.com Tue Jan 13 14:03:17 2015 From: pa at letnes.com (Paul Anton Letnes) Date: Tue, 13 Jan 2015 20:03:17 +0100 Subject: [CMake] [3.1.0] [PATCH] CMP0054 in CMakeDetermineCXXCompiler.cmake In-Reply-To: <1420736776.32179.6.camel@mad-scientist.net> References: <1420736776.32179.6.camel@mad-scientist.net> Message-ID: Just wanted to say that I've seen the same issue on my system: Visual studio 2013, Win 7 64 Cmake 3.1.0-rc2 Intel fortran 2015 (used for the fortran bits of a mixed c/c++/fortran solution) Cheers Paul PS: I envy your email address. Sent from my phone > On 08 Jan 2015, at 18:06, Paul Smith wrote: > > Hi all. I'm testing an upgrade to CMake 3.1.0 (from 2.8.12.2) and > seeing a weird warning, but ONLY on Windows; it works fine on GNU/Linux > and OSX: > > -- The C compiler identification is MSVC 16.0.40219.1 > -- Check for working C compiler using: Visual Studio 10 2010 Win64 > -- Check for working C compiler using: Visual Studio 10 2010 Win64 -- works > -- Detecting C compiler ABI info > -- Detecting C compiler ABI info - done > -- The CXX compiler identification is MSVC 16.0.40219.1 > CMake Warning (dev) at obj/REPOS/nuo3rdparty/common/cmake/share/cmake-3.1/Modules/CMakeDetermineCXXCompiler.cmake:106 (if): > Policy CMP0054 is not set: Only interpret if() arguments as variables or > keywords when unquoted. Run "cmake --help-policy CMP0054" for policy > details. Use the cmake_policy command to set the policy and suppress this > warning. > > Quoted variables like "MSVC" will no longer be dereferenced when the policy > is set to NEW. Since the policy is not set the OLD behavior will be used. > Call Stack (most recent call first): > CMakeLists.txt:26 (enable_language) > This warning is for project developers. Use -Wno-dev to suppress it. > > -- Check for working CXX compiler using: Visual Studio 10 2010 Win64 > -- Check for working CXX compiler using: Visual Studio 10 2010 Win64 -- works > > If I apply the attached patch it seems to fix the problem...? > > > <0002-cmake-fix-CMakeDetermineCXXCompiler.patch> > -- > > 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 From sharma.shubhra07 at gmail.com Tue Jan 13 19:04:43 2015 From: sharma.shubhra07 at gmail.com (Shubhra Sharma) Date: Tue, 13 Jan 2015 16:04:43 -0800 Subject: [CMake] CMake Error at cmake/FindWX.cmake:317 (MESSAGE): No wxWidgets installation could be found. Message-ID: Hi, I'm trying to get pgagent to work. So, I compiled and installed the dependencies for the same. One such dependency is wxWidgets-2.8.12 when I run the following cmd I get the error below: # cmake pgAgent-3.4.0-Source CMake Error at cmake/FindWX.cmake:317 (MESSAGE): No wxWidgets installation could be found. Call Stack (most recent call first): CMakeLists.txt:95 (FIND_PACKAGE) -- Configuring incomplete, errors occurred! See also "/root/CMakeFiles/CMakeOutput.log". But I have installed wxWidgets-2.8.12 from src using ./configure && make &&make install ldconfig # which wx-config /usr/local/bin/wx-config # wx-config --version 2.8.12 I've spent two days trying to resolve this but to no avail. Any help is appreciated. Thanks, Shubhra -------------- next part -------------- An HTML attachment was scrubbed... URL: From loose at astron.nl Wed Jan 14 05:45:50 2015 From: loose at astron.nl (Marcel Loose) Date: Wed, 14 Jan 2015 11:45:50 +0100 Subject: [CMake] Include path perference In-Reply-To: <1421169527150-7589463.post@n2.nabble.com> References: <1421169527150-7589463.post@n2.nabble.com> Message-ID: <54B648DE.4070202@astron.nl> On 13/01/15 18:18, leemachine wrote: > Hello all, > > I am using CMAKE 2.8.7: > > My question is I have a project that looks for dependencies (libraries and > headers) in both the source tree (*CMAKE_SOURCE_DIR* and > *CMAKE_CURRENT_SOURCE_DIR* as well as the *CMAKE_INSTALL_PREFIX*. The issue > I am having is I'm making changes to the source tree that are not compatible > with the header files installed in the *CMAKE_INSTALL_PREFIX*. > > In all the cmake message prints statements I make it returns the expected > results. CMAKE is using .cc and .h files in the source tree even though the > .h files are also in the *CMAKE_INSTALL_PREFIX*. > > When compiling I get an error relating to the incompatablity I mentioned. > GCC is using the header files in the *CMAKE_INSTALL_PREFIX* and the .cc > files in *CMAKE_CURRENT_SOURCE_DIR* > > How do I tell CMAKE to NOT use the header files in the > *CMAKE_INSTALL_PREFIX*? > > I understand a fresh *CMAKE_INSTALL_PREFIX* would resolve this issue, but > I'm looking for a workaround to that as well. > > Thanks, > > -Brandon > > > > -- > View this message in context: http://cmake.3232098.n2.nabble.com/Include-path-perference-tp7589463.html > Sent from the CMake mailing list archive at Nabble.com. Hi Brandon, I'm confused as to why you would want to look for dependencies in CMAKE_INSTALL_PREFIX at all. The header files in there will (obviously) always be (at least) one cycle behind with those in your source tree. Cheers, Marcel Loose. -------------- next part -------------- A non-text attachment was scrubbed... Name: loose.vcf Type: text/x-vcard Size: 292 bytes Desc: not available URL: From biddisco at cscs.ch Wed Jan 14 07:11:51 2015 From: biddisco at cscs.ch (Biddiscombe, John A.) Date: Wed, 14 Jan 2015 12:11:51 +0000 Subject: [CMake] evaluate a generator experssion Message-ID: <50320452A334BD42A5EC72BAD21450991E552102@MBX110.d.ethz.ch> Hello list I've got some test scripts which are called with test names and such like and I am using cmake expansion of vars to get from this "$" to "$" which is correct. But unfortunately, when I use file(WRITE "stuff containing above string") the file is written with "$" inside it, and not the full path/name of the target as I'd hoped. Is there a way to force the evaluation of the generator expression so it is correctly written out into the launch script? thanks JB -- John Biddiscombe, email:biddisco @.at.@ cscs.ch http://www.cscs.ch/ CSCS, Swiss National Supercomputing Centre | Tel: +41 (91) 610.82.07 Via Trevano 131, 6900 Lugano, Switzerland | Fax: +41 (91) 610.82.82 -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Wed Jan 14 07:17:21 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Wed, 14 Jan 2015 13:17:21 +0100 Subject: [CMake] evaluate a generator experssion In-Reply-To: <50320452A334BD42A5EC72BAD21450991E552102@MBX110.d.ethz.ch> References: <50320452A334BD42A5EC72BAD21450991E552102@MBX110.d.ethz.ch> Message-ID: <54B65E51.3010708@gmail.com> On 14.01.2015 13:11, Biddiscombe, John A. wrote: > > file(WRITE ?stuff containing above string?) > > the file is written with "$" inside it, > and not the full path/name of the target as I?d hoped. > > Is there a way to force the evaluation of the generator expression so > it is correctly written out into the launch script? > file(WRITE) is run at configuration time. Generator expressions are evaluated after configuration has finished (at generation time). You can use file(GENERATE) to create files with generator expressions expanded at generation time. Nils -------------- next part -------------- An HTML attachment was scrubbed... URL: From biddisco at cscs.ch Wed Jan 14 07:26:55 2015 From: biddisco at cscs.ch (Biddiscombe, John A.) Date: Wed, 14 Jan 2015 12:26:55 +0000 Subject: [CMake] evaluate a generator experssion In-Reply-To: <54B65E51.3010708@gmail.com> References: <50320452A334BD42A5EC72BAD21450991E552102@MBX110.d.ethz.ch> <54B65E51.3010708@gmail.com> Message-ID: <50320452A334BD42A5EC72BAD21450991E55213C@MBX110.d.ethz.ch> Nils Marvellous. Just what I needed. Works like a charm. and only 5 minutes between posting my question and getting the answer. Many thanks indeed JB From: Nils Gladitz [mailto:nilsgladitz at gmail.com] Sent: 14 January 2015 13:17 To: Biddiscombe, John A.; cmake at cmake.org Subject: Re: [CMake] evaluate a generator experssion On 14.01.2015 13:11, Biddiscombe, John A. wrote: file(WRITE "stuff containing above string") the file is written with "$>" inside it, and not the full path/name of the target as I'd hoped. Is there a way to force the evaluation of the generator expression so it is correctly written out into the launch script? file(WRITE) is run at configuration time. Generator expressions are evaluated after configuration has finished (at generation time). You can use file(GENERATE) to create files with generator expressions expanded at generation time. Nils -------------- next part -------------- An HTML attachment was scrubbed... URL: From bob.mosleh.sadri at oracle.com Wed Jan 14 17:43:21 2015 From: bob.mosleh.sadri at oracle.com (Bob Mosleh Sadri) Date: Wed, 14 Jan 2015 14:43:21 -0800 Subject: [CMake] supported platforms by Cmake Message-ID: <54B6F109.5050600@oracle.com> Hi experts We are planning to use a new build system for our c++ code. We build for Windows, Linux, AIX, Solaris and HP. I would like to know if cmake is a good option for us. When I look at the cmake.org download page, I can see only support for Windows and Linux. Where can I get downloads for the rest of platforms? I was wondering if there is a good support for the rest of platforms. Even if there are support for different platforms, are there supporting different versions of OS? While investigating the build systems, Cmake seems to be very popular. However, I am wondering if it is a good choice for us, since we need to support all these 5 platforms. Please advice. Thanks Bob -- Oracle Bob Mosleh Sadri Green Oracle Oracle is committed to developing practices and products that help protect the environment -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: oracle_sig_logo.gif Type: image/gif Size: 658 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: green-for-email-sig_0.gif Type: image/gif Size: 356 bytes Desc: not available URL: From david.thompson at kitware.com Wed Jan 14 19:25:11 2015 From: david.thompson at kitware.com (David Thompson) Date: Wed, 14 Jan 2015 19:25:11 -0500 Subject: [CMake] supported platforms by Cmake In-Reply-To: <54B6F109.5050600@oracle.com> References: <54B6F109.5050600@oracle.com> Message-ID: Hi Bob, You can see what platforms CMake is tested on here: https://open.cdash.org/index.php?project=CMake We just don't distribute binary packages on all of those platforms. David > On Jan 14, 2015, at 5:43 PM, Bob Mosleh Sadri wrote: > > Hi experts > We are planning to use a new build system for our c++ code. We build for Windows, Linux, AIX, Solaris and HP. I would like to know if cmake is a good option for us. When I look at the cmake.org download page, I can see only support for Windows and Linux. Where can I get downloads for the rest of platforms? I was wondering if there is a good support for the rest of platforms. Even if there are support for different platforms, are there supporting different versions of OS? > While investigating the build systems, Cmake seems to be very popular. However, I am wondering if it is a good choice for us, since we need to support all these 5 platforms. > > Please advice. > Thanks > Bob > -- > > Bob Mosleh Sadri > > > Oracle is committed to developing practices and products that help protect the environment > -- > > 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 From ldemailly at fb.com Wed Jan 14 23:33:31 2015 From: ldemailly at fb.com (Laurent Demailly) Date: Thu, 15 Jan 2015 04:33:31 +0000 Subject: [CMake] set(CMAKE_CXX_STANDARD 11) on macos - "...CMake does not know the compile flags to use to enable it." Message-ID: Hi all, I have a very simple CMakeLists.txt ? am using cmake 3.1 to be able to easily request C++ 11 ? it works fine on ubuntu but not on MacOS with Xcode 6 and command line tools installed: $ cat CMakeLists.txt cmake_minimum_required(VERSION 3.1) project("Test1" C CXX) # We need C++ 11 set(CMAKE_CXX_STANDARD 11) set(CMAKE_CXX_STANDARD_REQUIRED on) file(WRITE test1.cpp "int main(int argc, char** argv) {auto x=argc; return x;}") add_executable(test1 test1.cpp) $ cmake31 . -- The C compiler identification is AppleClang 6.0.0.6000056 -- The CXX compiler identification is AppleClang 6.0.0.6000056 -- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ -- Check for working CXX compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Configuring done CMake Error in CMakeLists.txt: Target "test1" requires the language dialect "CXX11" (with compiler extensions), but CMake does not know the compile flags to use to enable it. This is with CXX=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ CXXFLAGS="-std=c++11" But same without that Any idea why Cmake complains and how to not make it complain ? Help/pointer greatly appreciated Thanks Laurent -------------- next part -------------- An HTML attachment was scrubbed... URL: From domen.vrankar at gmail.com Thu Jan 15 02:57:19 2015 From: domen.vrankar at gmail.com (Domen Vrankar) Date: Thu, 15 Jan 2015 08:57:19 +0100 Subject: [CMake] supported platforms by Cmake In-Reply-To: References: <54B6F109.5050600@oracle.com> Message-ID: 2015-01-15 1:25 GMT+01:00 David Thompson : > Hi Bob, > > You can see what platforms CMake is tested on here: > > https://open.cdash.org/index.php?project=CMake > > We just don't distribute binary packages on all of those platforms. > > David > >> On Jan 14, 2015, at 5:43 PM, Bob Mosleh Sadri wrote: >> >> Hi experts >> We are planning to use a new build system for our c++ code. We build for Windows, Linux, AIX, Solaris and HP. I would like to know if cmake is a good option for us. When I look at the cmake.org download page, I can see only support for Windows and Linux. Where can I get downloads for the rest of platforms? I was wondering if there is a good support for the rest of platforms. Even if there are support for different platforms, are there supporting different versions of OS? >> While investigating the build systems, Cmake seems to be very popular. However, I am wondering if it is a good choice for us, since we need to support all these 5 platforms. I am using CMake on AIX as well - not on the testing list (don't know why) but you can see the results if you click on "See full feed" on the page linked by David. Regards, Domen From ggarra13 at gmail.com Thu Jan 15 10:07:15 2015 From: ggarra13 at gmail.com (Gonzalo Garramuno) Date: Thu, 15 Jan 2015 12:07:15 -0300 Subject: [CMake] Linux KDE4/Gnome menus and desktop icons Message-ID: <54B7D7A3.1060504@gmail.com> Title says it all. How can I get my application listed in the KDE4/Gnome menus and create a desktop icon for it? I tried placing an INSTALL( FILE ) of: /usr/share/applications/mrViewer.desktop /usr/share/pixmaps/mrViewer.xpm But the above does not work and seems it used to work for KDE3. Any help is appreciated. From rcdailey.lists at gmail.com Thu Jan 15 10:29:01 2015 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Thu, 15 Jan 2015 09:29:01 -0600 Subject: [CMake] C# project integration with CMake 3.1 Message-ID: I have a managed C++ (CLI) project that I build using CMake. I have another C# project (Visual Studio 2013) that I maintain outside of CMake that needs to reference the managed C++ DLL output by CMake. What is the best approach for this? The C# project is technically a completely separate product (tool) and wouldn't be in the same solution with the CMake projects. I've read that the C# project can be setup for use with configure_file() and then output somewhere in the binary dir. However, updates to the project (settings modifications through VIsual Studio, and adding C# files) would be lost, as they would not affect the original file that was used by configure_file(). If configure_file() is the best option, how do I overcome the issue of updating the visual studio project? Might not matter anyway since this will require the C# project to be accessible to CMake which it may not be in the future (once the Tool is moved into its own Git repository as a separate product, which will happen soon). I've also thought of creating an install project for the managed C++ project. This would definitely allow the tool to be disconnected, but how do I create a predictable install path for the C# project? Each developer may have their own drive letters on Windows, or maybe set CMAKE_INSTALL_PREFIX to something other than Program Files. Any advice is greatly appreciated. I'm pretty much blocked on this. From yves.frederix+cmake at gmail.com Thu Jan 15 11:47:17 2015 From: yves.frederix+cmake at gmail.com (Yves Frederix) Date: Thu, 15 Jan 2015 17:47:17 +0100 Subject: [CMake] VS2012 builds using v3.1.0 are a lot slower than v2.8.12 Message-ID: Hi all, I recently made the upgrade from v2.8.12 to v3.1.0. Unfortunately, I am now experiencing a serious decrease in build speed for the VS2012 Win64 builds. I have searched the cmake mailings but I was unable to find a reference to a similar issue. To give an idea about the difference I am observing: a full build (Release, Win64, "cmake --build") using 2.8.12 takes about 7 minutes, while for 3.0.1 it takes 24 minutes to complete the same build. Both builds are based on the same settings (some compilation settings are specified explicitly by our own scripts, but not that many), which gives the impression that the difference might be due to a change in default compilation settings generated by cmake for the Visual Studio generators since 2.8.12. Might this be the case? And if so, what might be a solution? If more information or tests from my end would be required, please do not hesitate to let me know as I am certainly willing to dig a bit deeper into this!. Thanks! Best regards, Yves From norulez at me.com Thu Jan 15 11:49:40 2015 From: norulez at me.com (NoRulez) Date: Thu, 15 Jan 2015 17:49:40 +0100 Subject: [CMake] CPack in CMake 3.1.0 doesn't install files Message-ID: <52A2C443-8D57-4723-996E-CFBD9AAFC931@me.com> Hello, we have only upgraded to the last release 3.1.0 from 3.0.2 and get the following when cpack is executed in a CTestScript: error: fixup_bundle: not a valid bundle The files are ceated, but they are not copied to the _CPack_Packages folder Then I found out that the variable "CMAKE_INSTALL_CONFIG_NAME" is empty in the cmake_install.cmake files Any hints? Best Regards From brad.king at kitware.com Thu Jan 15 12:59:24 2015 From: brad.king at kitware.com (Brad King) Date: Thu, 15 Jan 2015 12:59:24 -0500 Subject: [CMake] VS2012 builds using v3.1.0 are a lot slower than v2.8.12 In-Reply-To: References: Message-ID: <54B7FFFC.4080300@kitware.com> On 01/15/2015 11:47 AM, Yves Frederix wrote: > I recently made the upgrade from v2.8.12 to v3.1.0. Unfortunately, I > am now experiencing a serious decrease in build speed for the VS2012 > Win64 builds. [snip] > gives the impression that the difference might be due to a change in > default compilation settings generated by cmake for the Visual Studio > generators since 2.8.12. Are you building the same configuration in both cases? Use cmake --build . --config Debug or cmake --build . --config Release to specify the configuration. You could also compare the .vcxproj files that are generated. Thanks, -Brad From yves.frederix+cmake at gmail.com Fri Jan 16 05:24:17 2015 From: yves.frederix+cmake at gmail.com (Yves Frederix) Date: Fri, 16 Jan 2015 11:24:17 +0100 Subject: [CMake] VS2012 builds using v3.1.0 are a lot slower than v2.8.12 In-Reply-To: <54B7FFFC.4080300@kitware.com> References: <54B7FFFC.4080300@kitware.com> Message-ID: > Are you building the same configuration in both cases? > Use > > cmake --build . --config Debug > > or > > cmake --build . --config Release Yes, I used "--config Release" in both cases. > > to specify the configuration. You could also compare the .vcxproj > files that are generated. I had a look at the vcxproj files. There were some differences, but nothing that might explain the observed behavior I think. However, I did run some additional tests. The project I am working on is quite large, so I reduced the number of project files in the solution file. The following shows timings for a solution with 3 project files called "Crypto", "Crypto_s" and "Crypto_test" (the latter depends on Crypto_s, but when it is built, Crypto_s is already up-to-date). 3.1.0: ALL Crypto Crypto_s Crypto_test real 0m38.211s 0m14.023s 0m7.003s 0m14.691s 2.8.12: ALL Crypto Crypto_s Crypto_test real 0m27.230s 0m17.110s 0m10.231s 0m18.618s Or in other words, for building individual projects, a build with 3.1.0 is always faster than 2.8.12. On the other hand, for the 'ALL' target 2.8.12 is significantly faster. This made me wonder if it maybe had to do with default settings for parallelization in the builds. So I tried, and if I explicitly "set CL=/MP" for the 3.1.0 build, build time reduces from 38 seconds to 24 seconds which is what I would expect. Could this be the cause and was there a change in default settings? Regards, Yves > > Thanks, > -Brad > From norulez at me.com Fri Jan 16 06:09:15 2015 From: norulez at me.com (NoRulez) Date: Fri, 16 Jan 2015 12:09:15 +0100 Subject: [CMake] CPack in CMake 3.1.0 doesn't install files In-Reply-To: <52A2C443-8D57-4723-996E-CFBD9AAFC931@me.com> References: <52A2C443-8D57-4723-996E-CFBD9AAFC931@me.com> Message-ID: If I switch back to 3.0.2 everything is working like a charm Best Regards > Am 15.01.2015 um 17:49 schrieb NoRulez : > > Hello, > > we have only upgraded to the last release 3.1.0 from 3.0.2 and get the following when cpack is executed in a CTestScript: > > error: fixup_bundle: not a valid bundle > > The files are ceated, but they are not copied to the _CPack_Packages folder > > Then I found out that the variable "CMAKE_INSTALL_CONFIG_NAME" is empty in the cmake_install.cmake files > > Any hints? > > Best Regards > > -- > > 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 From dankolle at mail.de Fri Jan 16 06:16:11 2015 From: dankolle at mail.de (Daniel Kollmann) Date: Fri, 16 Jan 2015 12:16:11 +0100 Subject: [CMake] VS2013 64bit build does not include debug information Message-ID: <000201d0317d$d6037c10$820a7430$@mail.de> Hello everybody, I am using Cmake to generate my VS2013 solutions. My problem right now is that no debug information is included as well as no debug preprocessor symbols are set (DEBUG _DEBUG WIN32 _WINDOWS). I run cmake without CMAKE_BUILD_TYPE specified as I select that in VS. So I need to stick to build type specific variables. But those do not seem to work. This is my command line: " cmake.exe -H. -B"../../../../Intermediate/Creator" -G "Visual Studio 12 2013 Win64" " My CMakeLists.txt roughly looks like this: if(WIN32) set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /EHsc") set(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG} /MTd") endif() project(Creator) set(COMPILE_DEFINITIONS_DEBUG "${COMPILE_DEFINITIONS_DEBUG} -DCHECK_MEMORY_LEAKS=1") . When I use add_definitions() or add_compile_options() they work fine but are of course not build type dependent outside of cmake. Any suggestion what I could to have cmake set the default debug definitions and compiler options for my project? Thanks Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Fri Jan 16 11:03:54 2015 From: brad.king at kitware.com (Brad King) Date: Fri, 16 Jan 2015 11:03:54 -0500 Subject: [CMake] VS2012 builds using v3.1.0 are a lot slower than v2.8.12 In-Reply-To: References: <54B7FFFC.4080300@kitware.com> Message-ID: <54B9366A.1040006@kitware.com> On 01/16/2015 05:24 AM, Yves Frederix wrote: > 3.1.0: > ALL Crypto Crypto_s Crypto_test > real 0m38.211s 0m14.023s 0m7.003s 0m14.691s > > 2.8.12: > ALL Crypto Crypto_s Crypto_test > real 0m27.230s 0m17.110s 0m10.231s 0m18.618s Interesting, thanks for the timings. > This made me wonder if it maybe had to do with default settings for > parallelization in the builds. So I tried, and if I explicitly "set > CL=/MP" for the 3.1.0 build, build time reduces from 38 seconds to 24 > seconds which is what I would expect. Could this be the cause and was > there a change in default settings? I don't think such a change was made intentionally. To help narrow it down, could you please do the timings for CMake 3.0.2 as well? Thanks, -Brad From yves.frederix+cmake at gmail.com Fri Jan 16 11:24:35 2015 From: yves.frederix+cmake at gmail.com (Yves Frederix) Date: Fri, 16 Jan 2015 17:24:35 +0100 Subject: [CMake] VS2012 builds using v3.1.0 are a lot slower than v2.8.12 In-Reply-To: <54B9366A.1040006@kitware.com> References: <54B7FFFC.4080300@kitware.com> <54B9366A.1040006@kitware.com> Message-ID: Hi, >> 3.1.0: >> ALL Crypto Crypto_s Crypto_test >> real 0m38.211s 0m14.023s 0m7.003s 0m14.691s >> >> 2.8.12: >> ALL Crypto Crypto_s Crypto_test >> real 0m27.230s 0m17.110s 0m10.231s 0m18.618s > > Interesting, thanks for the timings. > >> This made me wonder if it maybe had to do with default settings for >> parallelization in the builds. So I tried, and if I explicitly "set >> CL=/MP" for the 3.1.0 build, build time reduces from 38 seconds to 24 >> seconds which is what I would expect. Could this be the cause and was >> there a change in default settings? > > I don't think such a change was made intentionally. To help narrow > it down, could you please do the timings for CMake 3.0.2 as well? The behavior seems to be the same for 3.0.2: 3.0.2: ALL Crypto Crypto_s Crypto_test real 0m38.756s 0m14.113s 0m7.150s 0m15.106s Regards, Yves From irwin.zaid at physics.ox.ac.uk Fri Jan 16 11:25:06 2015 From: irwin.zaid at physics.ox.ac.uk (Irwin Zaid) Date: Fri, 16 Jan 2015 16:25:06 +0000 Subject: [CMake] Passing -x=cu to FindCUDA, and specifying libraries to nvcc Message-ID: <54B93B62.5010107@physics.ox.ac.uk> Hi all (and James), I just have two other quick questions about FindCUDA. Here we go! 1) I have a project that tries to keep all its CUDA code in .cpp files. I'm currently making this work with a lot of dummy .cu files that simply include the .cpp, but I'd like to get rid of these. nvcc does support a -x flag for specifying whether it should treat files as .c, .cpp, or .cu. However, FindCUDA seems unable to handle this and things break immediately. Is it because FindCUDA uses the file extension to determine what action to take? Is there a way to force FindCUDA to either treat everything as a CUDA file, or treat specific files as CUDA files? 2) Is there a way to tell FindCUDA that a library needs to be linked in nvcc? What I have is a library built with nvcc that should go through the device linker. If I just pass it to target_link_libraries, then nvcc doesn't get it and only the host linker does. Also, I'm in a subproject (think of a test program), and I find that using NVCC_FLAGS doesn't get it there either. What has worked is simply passing it as an option to cuda_add_executable, but that feels a little raw. Thanks all (and James), Irwin From jamesbigler at gmail.com Fri Jan 16 12:08:37 2015 From: jamesbigler at gmail.com (James Bigler) Date: Fri, 16 Jan 2015 10:08:37 -0700 Subject: [CMake] Passing -x=cu to FindCUDA, and specifying libraries to nvcc In-Reply-To: <54B93B62.5010107@physics.ox.ac.uk> References: <54B93B62.5010107@physics.ox.ac.uk> Message-ID: On Fri, Jan 16, 2015 at 9:25 AM, Irwin Zaid wrote: > Hi all (and James), > > I just have two other quick questions about FindCUDA. Here we go! > > 1) I have a project that tries to keep all its CUDA code in .cpp files. > I'm currently making this work with a lot of dummy .cu files that simply > include the .cpp, but I'd like to get rid of these. > > nvcc does support a -x flag for specifying whether it should treat files > as .c, .cpp, or .cu. However, FindCUDA seems unable to handle this and > things break immediately. Is it because FindCUDA uses the file extension to > determine what action to take? > > Is there a way to force FindCUDA to either treat everything as a CUDA > file, or treat specific files as CUDA files? > > FindCUDA only looks for .cu files. In CUDA_WRAP_SRCS: get_source_file_property(_is_header ${file} HEADER_FILE_ONLY) if(${file} MATCHES "\\.cu$" AND NOT _is_header) What benefit is there in keeping cuda code in .cpp files? > 2) Is there a way to tell FindCUDA that a library needs to be linked in > nvcc? What I have is a library built with nvcc that should go through the > device linker. If I just pass it to target_link_libraries, then nvcc > doesn't get it and only the host linker does. > > You can't use nvcc to link. CMake makes this difficult, and in VS it is impossible. Instead what I've done for device linking is to create an intermediate object file that is the product of linking. FindCUDA supports separable compilation for a single executable module, but not for multiple ones. I had an example laying around for doing this, but I'm not sure where it ended up. Basically you add a prelink custom command that takes the objects and libraries that contain device code for your target executable module and link them using nvcc producing another object file that is then linked into the final executable module using the host linker. Also, I'm in a subproject (think of a test program), and I find that using > NVCC_FLAGS doesn't get it there either. What has worked is simply passing > it as an option to cuda_add_executable, but that feels a little raw. > > I'm not sure what is going wrong. If you do this: set(CUDA_NVCC_FLAGS -arch sm_20) add_subdirectory(tests) then CUDA_NVCC_FLAGS should have "-arch;sm_20" defined in tests/CMakeLists.txt. James -------------- next part -------------- An HTML attachment was scrubbed... URL: From irwin.zaid at physics.ox.ac.uk Fri Jan 16 12:15:32 2015 From: irwin.zaid at physics.ox.ac.uk (Irwin Zaid) Date: Fri, 16 Jan 2015 17:15:32 +0000 Subject: [CMake] Passing -x=cu to FindCUDA, and specifying libraries to nvcc In-Reply-To: References: <54B93B62.5010107@physics.ox.ac.uk> Message-ID: <54B94734.7010105@physics.ox.ac.uk> Hi James, Thanks for the quick reply. Some thoughts... > FindCUDA only looks for .cu files. In CUDA_WRAP_SRCS: > > get_source_file_property(_is_header ${file} HEADER_FILE_ONLY) > if(${file} MATCHES "\\.cu$" AND NOT _is_header) > > What benefit is there in keeping cuda code in .cpp files? It allows us to write code that supports both a host library when there is no GPU and a CUDA library. We've gotten very good at this, and keep all our code in .cpp files. Would it be possible to add a flag or option that disables that checking? I'd even be happy with it as a global "everything is CUDA" flag. NVCC does support this with '-x=cu'. > You can't use nvcc to link. CMake makes this difficult, and in VS it is > impossible. Instead what I've done for device linking is to create an > intermediate object file that is the product of linking. FindCUDA > supports separable compilation for a single executable module, but not > for multiple ones. I had an example laying around for doing this, but > I'm not sure where it ended up. Basically you add a prelink custom > command that takes the objects and libraries that contain device code > for your target executable module and link them using nvcc producing > another object file that is then linked into the final executable module > using the host linker. I follow you here. I do this as well in a different part. I agree it's hard, so things may be as good as they can be. > I'm not sure what is going wrong. If you do this: > > set(CUDA_NVCC_FLAGS -arch sm_20) > add_subdirectory(tests) > > then CUDA_NVCC_FLAGS should have "-arch;sm_20" defined in > tests/CMakeLists.txt. Ah, I meant that the subproject itself can't modify CUDA_NVCC_FLAGS. The flags itself are passed from the superproject fine. I think this isn't really an issue though, the device linking is probably good enough. Irwin From jamesbigler at gmail.com Fri Jan 16 12:35:35 2015 From: jamesbigler at gmail.com (James Bigler) Date: Fri, 16 Jan 2015 10:35:35 -0700 Subject: [CMake] Passing -x=cu to FindCUDA, and specifying libraries to nvcc In-Reply-To: <54B94734.7010105@physics.ox.ac.uk> References: <54B93B62.5010107@physics.ox.ac.uk> <54B94734.7010105@physics.ox.ac.uk> Message-ID: On Fri, Jan 16, 2015 at 10:15 AM, Irwin Zaid wrote: > Hi James, > > Thanks for the quick reply. Some thoughts... > > FindCUDA only looks for .cu files. In CUDA_WRAP_SRCS: >> >> get_source_file_property(_is_header ${file} HEADER_FILE_ONLY) >> if(${file} MATCHES "\\.cu$" AND NOT _is_header) >> >> What benefit is there in keeping cuda code in .cpp files? >> > > It allows us to write code that supports both a host library when there is > no GPU and a CUDA library. We've gotten very good at this, and keep all our > code in .cpp files. > > Would it be possible to add a flag or option that disables that checking? > I'd even be happy with it as a global "everything is CUDA" flag. NVCC does > support this with '-x=cu'. > > I would feel better about a flag that changes the the match string. If you want to cook up a patch, I'll take a look at it (I don't have much time to devote to this). It should be something along the lines of. 1. Add a new CUDA variable called CUDA_FILE_MATCH_REGEX that defaults to "\\.cu$". 2. Add documentation for it at the beginning along with the other things. 3. Replace the before mentioned if statement to use the new variable. I think this will allow you get precisely what you want, but also allow for somewhat arbitrary matches for anyone else who might have slightly different needs. > You can't use nvcc to link. CMake makes this difficult, and in VS it is >> impossible. Instead what I've done for device linking is to create an >> intermediate object file that is the product of linking. FindCUDA >> supports separable compilation for a single executable module, but not >> for multiple ones. I had an example laying around for doing this, but >> I'm not sure where it ended up. Basically you add a prelink custom >> command that takes the objects and libraries that contain device code >> for your target executable module and link them using nvcc producing >> another object file that is then linked into the final executable module >> using the host linker. >> > > I follow you here. I do this as well in a different part. I agree it's > hard, so things may be as good as they can be. > > I'm not sure what is going wrong. If you do this: >> >> set(CUDA_NVCC_FLAGS -arch sm_20) >> add_subdirectory(tests) >> >> then CUDA_NVCC_FLAGS should have "-arch;sm_20" defined in >> tests/CMakeLists.txt. >> > > Ah, I meant that the subproject itself can't modify CUDA_NVCC_FLAGS. The > flags itself are passed from the superproject fine. I think this isn't > really an issue though, the device linking is probably good enough. > > Irwin > You can set the value in the parent scope. set(CUDA_NVCC_FLAGS -arch sm_20) message("CUDA_NVCC_FLAGS = ${CUDA_NVCC_FLAGS}") add_subdirectory(tests) message("CUDA_NVCC_FLAGS = ${CUDA_NVCC_FLAGS}") if in tests/CMakeLists.txt you do set(CUDA_NVCC_FLAGS -arch sm_35 PARENT_SCOPE) your output would be CUDA_NVCC_FLAGS = -arch;sm_20 CUDA_NVCC_FLAGS = -arch;sm_35 -------------- next part -------------- An HTML attachment was scrubbed... URL: From irwin.zaid at physics.ox.ac.uk Fri Jan 16 13:18:18 2015 From: irwin.zaid at physics.ox.ac.uk (Irwin Zaid) Date: Fri, 16 Jan 2015 18:18:18 +0000 Subject: [CMake] Passing -x=cu to FindCUDA, and specifying libraries to nvcc In-Reply-To: <1ce72d88832943b894ceeac32710e74d@EXCHANGE-CAS1.physics.ox.ac.uk> References: <54B93B62.5010107@physics.ox.ac.uk> <54B94734.7010105@physics.ox.ac.uk> <1ce72d88832943b894ceeac32710e74d@EXCHANGE-CAS1.physics.ox.ac.uk> Message-ID: <54B955EA.7070800@physics.ox.ac.uk> > I would feel better about a flag that changes the the match string. If > you want to cook up a patch, I'll take a look at it (I don't have much > time to devote to this). > > It should be something along the lines of. > > 1. Add a new CUDA variable called CUDA_FILE_MATCH_REGEX that defaults to > "\\.cu$". > 2. Add documentation for it at the beginning along with the other things. > 3. Replace the before mentioned if statement to use the new variable. > > I think this will allow you get precisely what you want, but also allow > for somewhat arbitrary matches for anyone else who might have slightly > different needs. Sounds good, thanks. I think there's a need for this, and I'll probably do it at some point in the near future. I'll let you know when there's a PR. Irwin From domen.vrankar at gmail.com Fri Jan 16 16:33:55 2015 From: domen.vrankar at gmail.com (Domen Vrankar) Date: Fri, 16 Jan 2015 22:33:55 +0100 Subject: [CMake] different behaviour between file GLOB and GLOB_RECURSE Message-ID: Hi all, I wanted to glob recursively for all files and directories and noticed a difference in behaviour between the recursive and non recursive version - recursive version doesn't list directories (I am using latest version from git master - 3.1.2...). I also noticed that documentation for file(GLOB ...) and file(GLOB_RECURSE ...) is only mentioning listing of files but with GLOB you can list directories as well. Is the difference between the two by design or a bug? Thanks, Domen From eblot.ml at gmail.com Fri Jan 16 17:38:16 2015 From: eblot.ml at gmail.com (Emmanuel Blot) Date: Fri, 16 Jan 2015 23:38:16 +0100 Subject: [CMake] Sublime Text 2 - Ninja generator Message-ID: Hi, Is there a way from CMake to provide the build system "path" for a build target? Sublime Text 2 builds with the defaut system path, which makes the project build to fail. When the project is built from the shell from which ST is started there is no issue has the current PATH env. var. is used. Adding a "path" definition for all the build systems in the generated sublime-project file fixes this issue. Thanks, Manu From ldemailly at fb.com Fri Jan 16 19:40:01 2015 From: ldemailly at fb.com (Laurent Demailly) Date: Sat, 17 Jan 2015 00:40:01 +0000 Subject: [CMake] set(CMAKE_CXX_STANDARD 11) on macos - "...CMake does not know the compile flags to use to enable it." Message-ID: Answering my own question : this is fixed on trunk http://www.cmake.org/Bug/view.php?id=15355 Laurent From: Laurent Demailly > Date: Wednesday, January 14, 2015 at 8:33 PM To: "cmake at cmake.org" > Subject: [CMake] set(CMAKE_CXX_STANDARD 11) on macos - "...CMake does not know the compile flags to use to enable it." Hi all, I have a very simple CMakeLists.txt ? am using cmake 3.1 to be able to easily request C++ 11 ? it works fine on ubuntu but not on MacOS with Xcode 6 and command line tools installed: $ cat CMakeLists.txt cmake_minimum_required(VERSION 3.1) project("Test1" C CXX) # We need C++ 11 set(CMAKE_CXX_STANDARD 11) set(CMAKE_CXX_STANDARD_REQUIRED on) file(WRITE test1.cpp "int main(int argc, char** argv) {auto x=argc; return x;}") add_executable(test1 test1.cpp) $ cmake31 . -- The C compiler identification is AppleClang 6.0.0.6000056 -- The CXX compiler identification is AppleClang 6.0.0.6000056 -- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ -- Check for working CXX compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Configuring done CMake Error in CMakeLists.txt: Target "test1" requires the language dialect "CXX11" (with compiler extensions), but CMake does not know the compile flags to use to enable it. This is with CXX=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ CXXFLAGS="-std=c++11" But same without that Any idea why Cmake complains and how to not make it complain ? Help/pointer greatly appreciated Thanks Laurent -------------- next part -------------- An HTML attachment was scrubbed... URL: From yves.frederix+cmake at gmail.com Sat Jan 17 12:20:06 2015 From: yves.frederix+cmake at gmail.com (Yves Frederix) Date: Sat, 17 Jan 2015 18:20:06 +0100 Subject: [CMake] VS2012 builds using v3.1.0 are a lot slower than v2.8.12 In-Reply-To: References: <54B7FFFC.4080300@kitware.com> <54B9366A.1040006@kitware.com> Message-ID: Hi, I also tested with the build of an 'open' project (the crypto example was part of a work-related project). The results below are for the compilation of OpenCV (latest git from https://github.com/itseez/opencv), again with VS2012 Win64, Release only and no tweaking of the CMake settings. 3.1.0: 10m50s 2.8.12: 4m02s 3.1.0 (/MP): 6m29s 2.8.12 (/MP): 3m48s This does not look entirely the same as for the Crypto example, but the performance decrease is at least very much visible. Best regards, Yves On Fri, Jan 16, 2015 at 5:24 PM, Yves Frederix wrote: > Hi, > >>> 3.1.0: >>> ALL Crypto Crypto_s Crypto_test >>> real 0m38.211s 0m14.023s 0m7.003s 0m14.691s >>> >>> 2.8.12: >>> ALL Crypto Crypto_s Crypto_test >>> real 0m27.230s 0m17.110s 0m10.231s 0m18.618s >> >> Interesting, thanks for the timings. >> >>> This made me wonder if it maybe had to do with default settings for >>> parallelization in the builds. So I tried, and if I explicitly "set >>> CL=/MP" for the 3.1.0 build, build time reduces from 38 seconds to 24 >>> seconds which is what I would expect. Could this be the cause and was >>> there a change in default settings? >> >> I don't think such a change was made intentionally. To help narrow >> it down, could you please do the timings for CMake 3.0.2 as well? > > The behavior seems to be the same for 3.0.2: > > 3.0.2: > ALL Crypto Crypto_s Crypto_test > real 0m38.756s 0m14.113s 0m7.150s 0m15.106s > > > Regards, > Yves From rcdailey.lists at gmail.com Sat Jan 17 19:36:19 2015 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Sat, 17 Jan 2015 18:36:19 -0600 Subject: [CMake] List of compile features from command line? Message-ID: Can I use cmake to spit out a list of supported compile features based on my already-configured project? I'm not sure how I'm expected to get the list of features otherwise. The documentation does not explain this. From rcdailey.lists at gmail.com Sat Jan 17 20:09:38 2015 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Sat, 17 Jan 2015 19:09:38 -0600 Subject: [CMake] Clang not using C++11 on Linux Message-ID: I'm running a custom built CMake 3.1 on Ubuntu Server 12. I have Clang 3.4 installed. At the top of my root CMakeLists.txt, I have enabled C++11 like so: cmake_minimum_required( VERSION 3.1 ) if( UNIX ) set( CMAKE_CXX_FLAGS "-std=c++11 -stdlib=libc++" ) endif() project( FrontEnd ) However when I build, it fails: fe at BLD01:~/frontend/build$ make [ 0%] Copying third party binaries [ 0%] Built target copy_dlls [ 0%] Building CXX object Core/UI/CMakeFiles/UI.dir/Source/Animations/AnimationManager.cpp.o In file included from /home/fe/frontend/Core/UI/Source/Animations/AnimationManager.cpp:27: In file included from /home/fe/frontend/Core/UI/Source/Main/stdinc.h:292: In file included from /home/fe/frontend/Core/UI/Source/Logs/ErrorLog.h:18: /home/fe/frontend/Core/UI/Source/Logs/LogLevels.h:18:9: warning: scoped enumerations are a C++11 extension [-Wc++11-extensions] How do I get C++11 working? From eike at sf-mail.de Sun Jan 18 03:58:24 2015 From: eike at sf-mail.de (Rolf Eike Beer) Date: Sun, 18 Jan 2015 09:58:24 +0100 Subject: [CMake] Clang not using C++11 on Linux In-Reply-To: References: Message-ID: <4103834.LZEzgaVAiL@caliban.sf-tec.de> Am Samstag, 17. Januar 2015, 19:09:38 schrieb Robert Dailey: > I'm running a custom built CMake 3.1 on Ubuntu Server 12. I have Clang > 3.4 installed. At the top of my root CMakeLists.txt, I have enabled > C++11 like so: > > cmake_minimum_required( VERSION 3.1 ) > if( UNIX ) > set( CMAKE_CXX_FLAGS "-std=c++11 -stdlib=libc++" ) > endif() > project( FrontEnd ) [?] > How do I get C++11 working? Set the compiler flags after project(). The compiler is detected in project(), and then CMake initializes all the flag variables, so you changes will get overwritten. If you just want to enable C++11 with CMake 3.1 then do set(CMAKE_CXX_STANDARD 11) after the project call and CMake will take care of the rest. 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 robert.bielik at dirac.se Mon Jan 19 08:50:07 2015 From: robert.bielik at dirac.se (Robert Bielik) Date: Mon, 19 Jan 2015 14:50:07 +0100 Subject: [CMake] Xcode strip linked product Message-ID: <3D662481-D1E7-489E-8DA4-69384BA281CC@dirac.se> Hi all, Using CMake 3.0.1, when generating for Xcode, the setting Strip linked product is set to Yes for ALL targets (Debug/Release?), which of course disables any possibility to debug. How can I make CMake set this to NO for Debug ? TIA /Rob From robert.bielik at dirac.se Mon Jan 19 09:00:06 2015 From: robert.bielik at dirac.se (Robert Bielik) Date: Mon, 19 Jan 2015 15:00:06 +0100 Subject: [CMake] Xcode strip linked product In-Reply-To: <3D662481-D1E7-489E-8DA4-69384BA281CC@dirac.se> References: <3D662481-D1E7-489E-8DA4-69384BA281CC@dirac.se> Message-ID: Ok, my bad, I found the place where it is set, via: SET_TARGET_PROPERTIES(mytarget PROPERTIES XCODE_ATTRIBUTE_STRIP_INSTALLED_PRODUCT ?YES?) However, I?d need to set it per, so something like SET_TARGET_PROPERTIES(mytarget PROPERTIES XCODE_ATTRIBUTE_STRIP_INSTALLED_PRODUCT_DEBUG "NO?) It doesn?t seem to work ? Regards /R From Alan.Thompson at glasgow.ac.uk Mon Jan 19 11:06:43 2015 From: Alan.Thompson at glasgow.ac.uk (Alan.Thompson at glasgow.ac.uk) Date: Mon, 19 Jan 2015 16:06:43 +0000 (GMT) Subject: [CMake] CPack. Modifying the installation prefix when building relocateable RPMs. v3.0.1 Message-ID: I am trying to build rpms for projects so they can be installed together using a modified yum into a user defined area as /// hence the rpms should look like /// The only way I could find to do this was to set(CPACK_PACKAGING_INSTALL_PREFIX ) set(CPACK_INSTALL_PREFIX //) and then call an install script which simply does SET(CPACK_SET_DESTDIR "") This doesn't make make much sense and I feel I must have missed something out particularly as I am using version 3.0.1 and the above is not necessarily compatible with other versions. I'd be grateful for any advice or a more sensible approach Thank you Stan Thompson From laurent.duchesne at calculquebec.ca Mon Jan 19 12:58:47 2015 From: laurent.duchesne at calculquebec.ca (Laurent Duchesne) Date: Mon, 19 Jan 2015 12:58:47 -0500 Subject: [CMake] FindGDAL.cmake Message-ID: Dear all, There is a problem with the FindGDAL.cmake module. It will use the gdal-config binary to find the library name & (lib) path, but not for the include path. Attached is a patch that will use gdal-config --cflags to find the correct location for the gdal.h file. I just moved the find_path section after the gdal-config one, and added ${_gdal_cpath} in the HINTS section. Regards, -- Laurent Duchesne Conseiller en Calcul Haute Performance Calcul Qu?bec, Universit? Laval 418-656-2131 #5811 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: FindGDAL-gdal-config-cflags.patch Type: application/octet-stream Size: 1634 bytes Desc: not available URL: From rcdailey.lists at gmail.com Mon Jan 19 14:42:13 2015 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Mon, 19 Jan 2015 13:42:13 -0600 Subject: [CMake] Specify 32-bit compilation to Clang Message-ID: I'm running CMake 3.1 on Mint 64-bit OS. I need to generate an Eclipse project using Ninja that uses Clang to build a 32-bit application. When I do this: add_definitions("-m32") For some reason my code is not able to include STL headers (files not found). Any reason for this? Is there a more proper way to specify 32-bit compilation so STL include paths are set? From brad.king at kitware.com Mon Jan 19 14:44:25 2015 From: brad.king at kitware.com (Brad King) Date: Mon, 19 Jan 2015 14:44:25 -0500 Subject: [CMake] VS2012 builds using v3.1.0 are a lot slower than v2.8.12 In-Reply-To: References: <54B7FFFC.4080300@kitware.com> <54B9366A.1040006@kitware.com> Message-ID: <54BD5E99.1010703@kitware.com> On 01/17/2015 12:20 PM, Yves Frederix wrote: > I also tested with the build of an 'open' project (the crypto example > was part of a work-related project). The results below are for the > compilation of OpenCV (latest git from > https://github.com/itseez/opencv), again with VS2012 Win64, Release > only and no tweaking of the CMake settings. > > 3.1.0: 10m50s > 2.8.12: 4m02s > 3.1.0 (/MP): 6m29s > 2.8.12 (/MP): 3m48s I cannot reproduce that. On my machine for OpenCV (as of commit 5e92a777) I get about the same time for either version of CMake. 3.1.0 : 8m57s 2.8.12.2 : 8m58s 3.1.0 (/MP): 4m52s 2.8.12.2 (/MP): 4m57s Check in your cases that 3.1.0 does not activate additional parts of the project that are not built under 2.8.12. Also please try a command-line build with just "msbuild" instead of going through "cmake --build": msbuild ALL_BUILD.vcxproj /p:Configuration=Release /p:VisualStudioVersion=12.0 That will take one more layer out of the test cases. -Brad From gjasny at googlemail.com Mon Jan 19 14:48:43 2015 From: gjasny at googlemail.com (Gregor Jasny) Date: Mon, 19 Jan 2015 20:48:43 +0100 Subject: [CMake] Specify 32-bit compilation to Clang In-Reply-To: References: Message-ID: <54BD5F9B.7010106@googlemail.com> Hello Robert, On 19/01/15 20:42, Robert Dailey wrote: > I'm running CMake 3.1 on Mint 64-bit OS. I need to generate an Eclipse > project using Ninja that uses Clang to build a 32-bit application. > > When I do this: > > add_definitions("-m32") > > For some reason my code is not able to include STL headers (files not > found). Any reason for this? Is there a more proper way to specify > 32-bit compilation so STL include paths are set? You could try setting this two variables at configure time: -DCMAKE_C_COMPILER_ARG1=-m32 -DCMAKE_CXX_COMPILER_ARG1=-m32 Hope this helps, Gregpor From rcdailey.lists at gmail.com Mon Jan 19 15:08:39 2015 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Mon, 19 Jan 2015 14:08:39 -0600 Subject: [CMake] Specify 32-bit compilation to Clang In-Reply-To: <54BD5F9B.7010106@googlemail.com> References: <54BD5F9B.7010106@googlemail.com> Message-ID: I have done this and it fails while linking the test program during configuration: /usr/bin/ld: cannot find crtbegin.o: no such file or directory /usr/bin/ld: cannot find -lgcc /usr/bin/ld: cannot find -lgcc_s Any ideas? On Mon, Jan 19, 2015 at 1:48 PM, Gregor Jasny wrote: > Hello Robert, > > On 19/01/15 20:42, Robert Dailey wrote: >> I'm running CMake 3.1 on Mint 64-bit OS. I need to generate an Eclipse >> project using Ninja that uses Clang to build a 32-bit application. >> >> When I do this: >> >> add_definitions("-m32") >> >> For some reason my code is not able to include STL headers (files not >> found). Any reason for this? Is there a more proper way to specify >> 32-bit compilation so STL include paths are set? > > You could try setting this two variables at configure time: > -DCMAKE_C_COMPILER_ARG1=-m32 -DCMAKE_CXX_COMPILER_ARG1=-m32 > > Hope this helps, > Gregpor From nilsgladitz at gmail.com Mon Jan 19 15:12:10 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Mon, 19 Jan 2015 21:12:10 +0100 Subject: [CMake] Specify 32-bit compilation to Clang In-Reply-To: References: <54BD5F9B.7010106@googlemail.com> Message-ID: <54BD651A.2080309@gmail.com> On 19.01.2015 21:08, Robert Dailey wrote: > I have done this and it fails while linking the test program during > configuration: > > /usr/bin/ld: cannot find crtbegin.o: no such file or directory > /usr/bin/ld: cannot find -lgcc > /usr/bin/ld: cannot find -lgcc_s > > Any ideas? > Try installing the g++-multilib package. Nils From domen.vrankar at gmail.com Mon Jan 19 15:30:02 2015 From: domen.vrankar at gmail.com (Domen Vrankar) Date: Mon, 19 Jan 2015 21:30:02 +0100 Subject: [CMake] CPack. Modifying the installation prefix when building relocateable RPMs. v3.0.1 In-Reply-To: References: Message-ID: 2015-01-19 17:06 GMT+01:00 : > I am trying to build rpms for projects so they can be installed together > using a modified yum into a user defined area as > /// > hence the rpms should look like > /// > > The only way I could find to do this was to > set(CPACK_PACKAGING_INSTALL_PREFIX ) > set(CPACK_INSTALL_PREFIX //) > and then call an install script which simply does > SET(CPACK_SET_DESTDIR "") Maybe I don't understand the problem but writing something like this: install(TARGET some_target DESTINATION "${INSTALL_PREFIX}/some_location") where install_prefix could be set as "${CURRENT_PROJECT}/${CURRENT_PLATFORM}" (should be a relative path) and then write: set(CPACK_PACKAGING_INSTALL_PREFIX "${RELOCATABLE}") where relocatable can be "/" should produce what you want. If you really don't want to write "${INSTALL_PREFIX}" for each install location then your solution would probably be the best way to go but IMO setting install location is the cleaner solution. Regards, Domen From andrew.amaclean at gmail.com Mon Jan 19 16:11:20 2015 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Tue, 20 Jan 2015 08:11:20 +1100 Subject: [CMake] Using C++11 features and Cmake 3.1 Message-ID: This is a bit long but it should help those using C++11 features in CMake 3.1. This is an extract from my CMakeLists.txt file that uses C++11 in a cross-platform manner. It also lists the available C++11 features and shows you how to set up defines that can be used in your code. The ancillary files that reside in a subdirectory called CMake: CMakeOptions.cmake - sets global options. DetermineCompilerFlags.cmake - self explanatory. SetCompilerFeatures.cmake - this is important as CMake3.1 doesn't know about C++11 features in XCode (CLang) and MSVC. So it checks for appropriate versions in the case of MSVC and sets the cxx flags for CLang. Here is a cut down version of the top-level CMakeLists.txt file: ################################ #----------------------------------------------------------------------------- # Don't build anything unless the version of CMake is high enough. # Note: The cmake_minimum_required command also sets the policy version. # This will request NEW behavior for all policies introduced in the # corresponding version of CMake or earlier. # Policies introduced in later versions are marked as not set in # order to produce proper warning messages. cmake_minimum_required(VERSION 3.1) #----------------------------------------------------------------------------- # Set policies as needed. foreach(p # This is just a placeholder for CMPs that may appear in newer versions. # CMP???? # CMake 3.1+ ) if(POLICY ${p}) cmake_policy(SET ${p} NEW) endif() endforeach() #----------------------------------------------------------------------------- project ( XXX ) #----------------------------------------------------------------------------- # We will enforce an out of source build. STRING(COMPARE EQUAL "${${PROJECT_NAME}_SOURCE_DIR}" "${${PROJECT_NAME}_BINARY_DIR}" INSOURCE) if(INSOURCE) MESSAGE(FATAL_ERROR "${PROJECT_NAME} requires an out of source build. Please create a separate binary directory and run CMake there.") endif(INSOURCE) #----------------------------------------------------------------------------- # Directory where the CMakeFiles are set ( CMAKE_FILE_DIR ${PROJECT_SOURCE_DIR}/CMake ) #----------------------------------------------------------------------------- # Any global options include(${CMAKE_FILE_DIR}/CMakeOptions.cmake) #----------------------------------------------------------------------------- # What are the CMake known C++ features? get_property(cxx_features GLOBAL PROPERTY CMAKE_CXX_KNOWN_FEATURES) message(STATUS "This CMake version supports these C++ features:") foreach(i ${cxx_features}) message(STATUS "${i}") endforeach() message(STATUS "Compiler ID/Version: ${CMAKE_CXX_COMPILER_ID} ${CMAKE_CXX_COMPILER_VERSION}") #----------------------------------------------------------------------------- # We need these features. set(needed_features cxx_auto_type cxx_lambdas cxx_range_for ) #----------------------------------------------------------------------------- # We may need to define flags based on the needed features. foreach(i ${needed_features}) string(TOUPPER ${i} s) add_definitions("-D${s}") endforeach() #----------------------------------------------------------------------------- # Set the compiler warning level and other compiler settings. include(${CMAKE_FILE_DIR}/DetermineCompilerFlags.cmake) include(${CMAKE_FILE_DIR}/SetCompilerFeatures.cmake) #----------------------------------------------------------------------------- # Get the version info. # Versioning #----------------------------------------------------------------------------- # set( TARGET_BASE_NAME "${PROJECT_NAME}" ) set( LIB_NAME "${TARGET_BASE_NAME}Lib" ) set( EXE_NAME "${TARGET_BASE_NAME}" ) #----------------------------------------------------------------------------- # We need these C++11 features. set(needed_features cxx_lambdas cxx_auto_type) #----------------------------------------------------------------------------- # We may need to define flags based on the needed features. foreach(i ${needed_features}) string(TOUPPER ${i} s) add_definitions("-D${s}") endforeach() #----------------------------------------------------------------------------- # Paths to directories include_directories( # ... ) add_subdirectory(${???}) # For the library called e.g. yy. add_subdirectory(${???}) # For the executable called e.g. MyExecutable. ################################ Then in the subdirectories, do this in the case of a library (note the use of SetCompilerFeatures), ################################ #----------------------------------------------------------------------------- # The name of the library. # set(KIT yy) set(LIB_NAME ${LIB_PREFIX}${KIT}) #----------------------------------------------------------------------------- # The directory in which the source files are. set(${KIT}_DIR ${CMAKE_CURRENT_SOURCE_DIR}) #----------------------------------------------------------------------------- set(${KIT}_Srcs ... ) set(${KIT}_Incs ... ) add_library( ${LIB_NAME} ${${KIT}_Srcs} ${${KIT}_Incs} ) SetCompilerFeatures(${LIB_NAME}) ################################ Do this for the executable: ################################ set(KIT ${EG}MyExecutable) # Source files set( Srcs ... ) # Include files set( Incs ) add_executable( ${KIT} ${Srcs} ${Incs} ) SetCompilerFeatures(${KIT}) target_link_libraries( ${KIT} yy ) install(TARGETS ${KIT} BUNDLE DESTINATION . COMPONENT Runtime RUNTIME DESTINATION bin COMPONENT Runtime # LIBRARY DESTINATION lib # ARCHIVE DESTINATION lib ) ################################ I hope this helps. Andrew -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- option(BUILD_TESTING "Build the tests." OFF) option(BUILD_EXAMPLES "Build the examples." OFF) -------------- next part -------------- # Modified from: vtkDetermineCompilerFlags.cmake # A GCC compiler. IF(CMAKE_COMPILER_IS_GNUCXX) SET(CMAKE_CXX_FLAGS "-Wall -Wextra") SET(CMAKE_C_FLAGS "-Wall -Wextra") ENDIF(CMAKE_COMPILER_IS_GNUCXX) IF(MSVC) # Use the highest warning level for visual c++ compiler. SET(CMAKE_CXX_WARNING_LEVEL 4) IF(CMAKE_CXX_FLAGS MATCHES "/W[0-4]") STRING(REGEX REPLACE "/W[0-4]" "/W4" CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}") ELSE(CMAKE_CXX_FLAGS MATCHES "/W[0-4]") SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /W4") ENDIF(CMAKE_CXX_FLAGS MATCHES "/W[0-4]") ENDIF(MSVC) # Disable deprecation warnings for standard C and STL functions in VS2005 # and later IF(MSVC_VERSION EQUAL 1400 OR MSVC_VERSION GREATER 1400 OR MSVC10) ADD_DEFINITIONS(-D_CRT_SECURE_NO_DEPRECATE -D_CRT_NONSTDC_NO_DEPRECATE -D_CRT_SECURE_NO_WARNINGS) ADD_DEFINITIONS(-D_SCL_SECURE_NO_DEPRECATE -D_SCL_SECURE_NO_WARNINGS) ENDIF(MSVC_VERSION EQUAL 1400 OR MSVC_VERSION GREATER 1400 OR MSVC10) # Enable /MP flag for Visual Studio 2008 and greater IF(MSVC_VERSION GREATER 1400) SET(CMAKE_CXX_MP_FLAG OFF CACHE BOOL "Build with /MP flag enabled") SET(PROCESSOR_COUNT "$ENV{NUMBER_OF_PROCESSORS}") SET(CMAKE_CXX_MP_NUM_PROCESSORS CACHE ${PROCESSOR_COUNT} "The maximum number of processes for the /MP flag") IF (CMAKE_CXX_MP_FLAG) SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /MP${CMAKE_CXX_MP_NUM_PROCESSORS}") SET(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} /MP${CMAKE_CXX_MP_NUM_PROCESSORS}") ENDIF (CMAKE_CXX_MP_FLAG) ENDIF(MSVC_VERSION GREATER 1400) -------------- next part -------------- function(SetCompilerFeatures TGT_NAME) #---------------------------------------------------------- # Set C++11 compatibility. #---------------------------------------------------------- if ("${CMAKE_CXX_COMPILER_ID}" STREQUAL "GNU") if(NOT(TGT_NAME STREQUAL "")) target_compile_features(${TGT_NAME} PUBLIC ${needed_features}) endif() elseif ("${CMAKE_CXX_COMPILER_ID}" STREQUAL "MSVC") # Pick a MSVC version that supports what you need. if (MSVC_VERSION LESS "1800") message(FATAL_ERROR "No suitable compiler exists.") endif() elseif ("${CMAKE_CXX_COMPILER_ID}" STREQUAL "AppleClang") set(CMAKE_CXX_FLAGS "-std=c++11 -stdlib=libc++") else() message(FATAL_ERROR "No suitable compiler exists.") endif() endfunction() From ldemailly at fb.com Mon Jan 19 16:35:53 2015 From: ldemailly at fb.com (Laurent Demailly) Date: Mon, 19 Jan 2015 21:35:53 +0000 Subject: [CMake] detecting __attribute__((weak)) support Message-ID: I searched and didn't find yet ? would it be reasonable to have built in support in cmake for knowing if the platform/compiler supports weak symbols ? I'm porting the following autconf fragment: AC_CACHE_CHECK( [for weak symbol support], [folly_cv_prog_cc_weak_symbols], [AC_LINK_IFELSE( [AC_LANG_SOURCE[ extern "C" void configure_link_extern_weak_test() __attribute__((weak)); int main(int argc, char** argv) { return configure_link_extern_weak_test == nullptr; }]], [folly_cv_prog_cc_weak_symbols="yes"], [folly_cv_prog_cc_weak_symbols="no"])]) if test "$folly_cv_prog_cc_weak_symbols" = yes; then AC_DEFINE([HAVE_WEAK_SYMBOLS], [1], [Define to 1 if the linker supports weak symbols.]) fi And I'm not sure what's the best way to do such recipe in Cmake ? (by hand for now pending possible support in 3.2+ maybe) Laurent From ldemailly at fb.com Mon Jan 19 18:35:27 2015 From: ldemailly at fb.com (Laurent Demailly) Date: Mon, 19 Jan 2015 23:35:27 +0000 Subject: [CMake] detecting __attribute__((weak)) support Message-ID: Pending (possible) built-in support in cmake, looks like I could use check_cxx_source_compiles( "extern \"C\" void cmkcheckweak() __attribute__((weak)); int main(int argc, char** argv) { return cmkcheckweak == nullptr; // works with (void*)0; }" HAVE_WEAK_SYMBOLS) But that doesn't work because check_cxx_source_compiles doesn't (by default - how do I tell it to?) use the compiler flags (like -std=gnu++11) needed to compile this (while in this case there is an easy workaround - how do I do this in general) Filled the 2 issues: http://public.kitware.com/Bug/view.php?id=15359 for weak symbol knowledge by cmake http://public.kitware.com/Bug/view.php?id=15361 for check_cxx_source_compiles Thanks! Laurent On 1/19/15, 1:35 PM, "Laurent Demailly" wrote: >I searched and didn't find yet ? would it be reasonable to have built in >support in cmake for knowing if the platform/compiler supports weak >symbols ? > >I'm porting the following autconf fragment: > >AC_CACHE_CHECK( > [for weak symbol support], > [folly_cv_prog_cc_weak_symbols], > [AC_LINK_IFELSE( > [AC_LANG_SOURCE[ > extern "C" void configure_link_extern_weak_test() >__attribute__((weak)); > int main(int argc, char** argv) { > return configure_link_extern_weak_test == nullptr; > }]], > [folly_cv_prog_cc_weak_symbols="yes"], > [folly_cv_prog_cc_weak_symbols="no"])]) > >if test "$folly_cv_prog_cc_weak_symbols" = yes; then > AC_DEFINE([HAVE_WEAK_SYMBOLS], [1], > [Define to 1 if the linker supports weak symbols.]) >fi > >And I'm not sure what's the best way to do such recipe in Cmake ? >(by hand for now pending possible support in 3.2+ maybe) > > >Laurent From chrysalisx at gmail.com Mon Jan 19 19:16:10 2015 From: chrysalisx at gmail.com (Walter Gray) Date: Mon, 19 Jan 2015 16:16:10 -0800 Subject: [CMake] custom command usage requirements? Message-ID: <54BD9E4A.5030406@gmail.com> Hey All - I'm trying to add a custom command to some targets to copy files using a usage requirements kind of pattern, but I'm running into some limitations in CMake that seem somewhat arbitrary. To set the stage, imagine the following toy example: DirectoryA's CMakeLists File: include_directory(B) include_directory(C) DirectoryB's CMakeLists File: add_executable(TestEXE ...) target_link_libraries(TestEXE PUBLIC TestLibrary) #for each dependency of TestEXE add_custom_command(TARGET TestEXE POST_BUILD ...) #for each dependency of the dependency... DirectoryC's CMakeLists File: add_library(TestLibrary STATIC ...) find_packge(SharedLib REQUIRED) target_link_libraries(TestLibrary PUBLIC TestSharedLib::TestSharedLib) Somewhere in the SharedLib find module: add_library(TestSharedLib::TestSharedLib SHARED IMPORTED) #A library with a dll component that must be copied set_property(TARGET TestSharedLib::TestSharedLib PROPERTY IMPORTED_LOCATION path/to/my/library.dll) Things I tried: -Iterate over all the target's link libraries, and for every dependant shared library target, add a custom command to copy the dll. This failed because at the point of DirectoryB, it may be that there are dependencies (such as TestLibrary in the above example) which are not yet defined. One could impose a strict ordering requirement, but nothing else in CMake (AFIK) imposes such a requirement. -Add a resolve_dependencies() function call after each library is declared, or just once at the very end of the root cmakelists file. Using a global property, it keeps track of all exe targets which want dll's copied and traverses that list, adding copy commands to targets that depend on the newly declared library. Fails because you cannot call add_custom_command on a target outside of it's declaration file. Also crappy because it imposes a requirement on the user to call said function. -As above, but make the custom command reference a property on the target in a generator expression, then append any files that need copying to that property. So far the most workable, but the property cannot contain generator expressions which may present a problem. The core of the problem is that within the directory where the exe is defined, TestLibrary is unknown, and in DirectoryC or even DirectoryA, I cannot call add_custom_command on the TestEXE due to an arbitrary limitation cmake imposes (the target is defined, you can edit it, but you can't add commands to it. This means that I can't look up any property of TestLibrary to discover it's dependencies, and I can't find out that it depends on TestSharedLib, which references a .dll file I want to copy into TestEXE's TARGET_DIR. What I *can* do is make the TestEXE's custom command reference a property on TestEXE in a generator expression to get the list of dlls it depends on, but that property cannot itself contain any generator expressions (as would be ideal to deal with differing dlls for debug and release mode or the like). As it stands, I have something that kinda works, but feels kinda ugly. Any one of several different things would give me the functionality I need. In order of usefulness: 1) Allow recursive generator expression resolution: $ where MY_PROP=$<$:mything_d.dll>$<$:mything.dll>. I cannot tell you how many headaches this kind of functionality would save me and unless I'm very mistaken I don't think it would involve very much work. 2) Generic support for INTERFACE_* properties. Only kinda works, since you can't link with MODULE libraries, which contain .dll files I'd want to copy. Could be exposed by an extra argument in define_property() Definitely a crappier version of 1, since with 1 I could just append $ to MY_PROP on the original target. 3) Allow add_custom_command wherever the target is defined. If you can get and set properties on it, it seems weird that you can't do this. 4) Make custom commands inheritable as usage requirements. This would be very weird, but would get the job done. If anyone has any other ideas or feedback, it would be very welcome. I'd be very, very interested in seeing 1) make it into a future cmake release regardless though. From cxjohnson at gmail.com Mon Jan 19 20:14:23 2015 From: cxjohnson at gmail.com (Chris Johnson) Date: Mon, 19 Jan 2015 19:14:23 -0600 Subject: [CMake] Library include path question Message-ID: A common and useful method for avoiding name conflicts and keeping files well-organized is to place them in a subdirectory unique to the library. For example, the libraries for Graphviz and Postgres often install their API header files in directories named /include/graphviz and /include/libpq. So on my local development system, these libraries' API header files are in /usr/local/include/graphviz/*.h and /usr/local/include/libpq/*.h. This is the convention that we use for our internal projects as well. C++ code which needs to include these files by necessity must name that subdirectory. For example, to use Postgres's API defined in libpq-fs.h, the C++ code must look like this: #include We do the same for our internal libraries, for example, to use the "projectlib" library from some program, the code would resemble: #include In the library itself, however, the code is like this: foo.h: ----- class Foo { public: Foo(); }; foo.cpp ------- #include "foo.h" Foo::Foo() { // constructor code } // etc. That is, note that the header and source files are in the SAME directory. CMake does not handle this well when trying to compile a program using the library. CMake wants to look in the source directory or the build directory for the header file, and those directory paths do not have the "projectlib" prefix which is what the source code for the program expects (#include ). I've kludged around this by adding a function which does some ugly directory creation in the build directory and then copies the headers to where the source expects to find them. But I think there's something about CMake I am not understanding correctly, or a feature I should be using that I am unaware of, in order to make this all work without writing code in my CMakeLists.txt files to copy source files to expected places. This library file layout for headers and source is very common in the Unix world, and we've modeled our largish (500 directories, dozens of libraries) project on it. Is there something about CMake I need to learn to make this work more cleanly? Thanks, ..chris Most libraries correctly put their headers into ./include/ 39 # but CMake wants to look in the source or build dir, which doesn't have 40 # as a prefix. That prefix is used in the source files in 41 # their #include "libdirname/libheader.h" statements. Headers will not be 42 # found with that prefix when obtained from the source or build dir by CMake. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dschepler at scalable-networks.com Mon Jan 19 20:30:56 2015 From: dschepler at scalable-networks.com (Daniel Schepler) Date: Tue, 20 Jan 2015 01:30:56 +0000 Subject: [CMake] Library include path question In-Reply-To: References: Message-ID: How about something like (in the top-level directory for the projectlib sources): add_library(projectlib STATIC projectlib/foo.h projectlib/foo.cpp ...) target_include_directories(projectlib PUBLIC . PRIVATE projectlib) (Note that this will add the top-level directory as well as the projectlib subdirectory for building projectlib sources - which is probably what you want in order to be able to resolve inter-header dependencies.) -- Daniel Schepler ________________________________ From: CMake [cmake-bounces at cmake.org] on behalf of Chris Johnson [cxjohnson at gmail.com] Sent: Monday, January 19, 2015 5:14 PM To: cmake at cmake.org Subject: [CMake] Library include path question A common and useful method for avoiding name conflicts and keeping files well-organized is to place them in a subdirectory unique to the library. For example, the libraries for Graphviz and Postgres often install their API header files in directories named /include/graphviz and /include/libpq. So on my local development system, these libraries' API header files are in /usr/local/include/graphviz/*.h and /usr/local/include/libpq/*.h. This is the convention that we use for our internal projects as well. C++ code which needs to include these files by necessity must name that subdirectory. For example, to use Postgres's API defined in libpq-fs.h, the C++ code must look like this: #include We do the same for our internal libraries, for example, to use the "projectlib" library from some program, the code would resemble: #include In the library itself, however, the code is like this: foo.h: ----- class Foo { public: Foo(); }; foo.cpp ------- #include "foo.h" Foo::Foo() { // constructor code } // etc. That is, note that the header and source files are in the SAME directory. CMake does not handle this well when trying to compile a program using the library. CMake wants to look in the source directory or the build directory for the header file, and those directory paths do not have the "projectlib" prefix which is what the source code for the program expects (#include ). I've kludged around this by adding a function which does some ugly directory creation in the build directory and then copies the headers to where the source expects to find them. But I think there's something about CMake I am not understanding correctly, or a feature I should be using that I am unaware of, in order to make this all work without writing code in my CMakeLists.txt files to copy source files to expected places. This library file layout for headers and source is very common in the Unix world, and we've modeled our largish (500 directories, dozens of libraries) project on it. Is there something about CMake I need to learn to make this work more cleanly? Thanks, ..chris Most libraries correctly put their headers into ./include/ 39 # but CMake wants to look in the source or build dir, which doesn't have 40 # as a prefix. That prefix is used in the source files in 41 # their #include "libdirname/libheader.h" statements. Headers will not be 42 # found with that prefix when obtained from the source or build dir by CMake. -------------- next part -------------- An HTML attachment was scrubbed... URL: From roolebo at gmail.com Mon Jan 19 20:56:37 2015 From: roolebo at gmail.com (Roman Bolshakov) Date: Tue, 20 Jan 2015 04:56:37 +0300 Subject: [CMake] Library include path question In-Reply-To: References: Message-ID: <1AE538F9-D191-4050-AA43-E5448F964E6E@gmail.com> We use similar layout in a set of components, but in order to do that we just store library interface headers in /include/ directory. And layout of library directory is the following: src/ - internal headers and implementation include/ - external headers CMakeLists.txt Then you can define the following to expose the directory for clients of the library within the same CMake project: target_include_directories( PRIVATE src PUBLIC include ) Another way to achieve that is to expose library's parent directory as include interface. That's a case if all your sources, external and internal headers are stored under the library directory: get_filename_component(PARENT_DIR ${CMAKE_CURRENT_SOURCE_DIR} DIRECTORY) target_include_directories( INTEFACE ${PARENT_DIR} ) As downside, that would make all headers (even internal) visible to the clients of the library. If you have two separate CMake projects (i.e. two git repos) you can change layout of the headers on install step without changing anything in source tree. e.g. we have external and internal headers in src directory: target_include_directories( PRIVATE "$" INTERFACE "$>" ) install (FILES src/foo.h src/bar.h DESTINATION include/ COMPONENT devel ) In all the cases, I assume usage requirements model (target_link_libraries) is used for consumption of the library. -Roman > 20 ???. 2015 ?., ? 4:14, Chris Johnson ???????(?): > > A common and useful method for avoiding name conflicts and keeping files well-organized is to place them in a subdirectory unique to the library. For example, the libraries for Graphviz and Postgres often install their API header files in directories named /include/graphviz and /include/libpq. So on my local development system, these libraries' API header files are in /usr/local/include/graphviz/*.h and /usr/local/include/libpq/*.h. > > This is the convention that we use for our internal projects as well. > > C++ code which needs to include these files by necessity must name that subdirectory. For example, to use Postgres's API defined in libpq-fs.h, the C++ code must look like this: > > #include > > We do the same for our internal libraries, for example, to use the "projectlib" library from some program, the code would resemble: > > #include > > In the library itself, however, the code is like this: > > foo.h: > ----- > class Foo { > public: > Foo(); > }; > > foo.cpp > ------- > #include "foo.h" > > Foo::Foo() { > // constructor code > } > // etc. > > That is, note that the header and source files are in the SAME directory. > > > CMake does not handle this well when trying to compile a program using the library. CMake wants to look in the source directory or the build directory for the header file, and those directory paths do not have the "projectlib" prefix which is what the source code for the program expects (#include ). > > I've kludged around this by adding a function which does some ugly directory creation in the build directory and then copies the headers to where the source expects to find them. > > But I think there's something about CMake I am not understanding correctly, or a feature I should be using that I am unaware of, in order to make this all work without writing code in my CMakeLists.txt files to copy source files to expected places. This library file layout for headers and source is very common in the Unix world, and we've modeled our largish (500 directories, dozens of libraries) project on it. > > Is there something about CMake I need to learn to make this work more cleanly? > > > Thanks, > ..chris > > > > > > > Most libraries correctly put their headers into ./include/ > 39 # but CMake wants to look in the source or build dir, which doesn't have > 40 # as a prefix. That prefix is used in the source files in > 41 # their #include "libdirname/libheader.h" statements. Headers will not be > 42 # found with that prefix when obtained from the source or build dir by CMake. > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake -------------- next part -------------- An HTML attachment was scrubbed... URL: From norulez at me.com Tue Jan 20 02:37:00 2015 From: norulez at me.com (NoRulez) Date: Tue, 20 Jan 2015 08:37:00 +0100 Subject: [CMake] CPack in CMake 3.1.0 doesn't install files In-Reply-To: References: <52A2C443-8D57-4723-996E-CFBD9AAFC931@me.com> Message-ID: No one? Has something changed between 3.0.2 to 3.1.0 which prevents cpack to copy the generated *.exe file to the _CPack_Packages directory? Or did i need an additional variable to be set in 3.1.0? Thanks in advance Best Regards > Am 16.01.2015 um 12:09 schrieb NoRulez : > > If I switch back to 3.0.2 everything is working like a charm > > Best Regards > >> Am 15.01.2015 um 17:49 schrieb NoRulez : >> >> Hello, >> >> we have only upgraded to the last release 3.1.0 from 3.0.2 and get the following when cpack is executed in a CTestScript: >> >> error: fixup_bundle: not a valid bundle >> >> The files are ceated, but they are not copied to the _CPack_Packages folder >> >> Then I found out that the variable "CMAKE_INSTALL_CONFIG_NAME" is empty in the cmake_install.cmake files >> >> Any hints? >> >> Best Regards >> >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake From lars.bilke at ufz.de Tue Jan 20 06:16:28 2015 From: lars.bilke at ufz.de (Lars Bilke) Date: Tue, 20 Jan 2015 12:16:28 +0100 Subject: [CMake] ExternalData_Add_Test get referenced files Message-ID: <2251F561-BC75-4DD3-A25B-0F68054B92DB@ufz.de> Dear CMake-user, I am using the ExternalData-module to create CTest tests which require data files managed by ExternalData. I successfully used the DATA{}-syntax. Now I need (at a later point in CMake) the referenced files for each test. Is it possible to retrieve this information? Is it stored in some test properties? Thanks! Lars From yves.frederix+cmake at gmail.com Tue Jan 20 07:10:06 2015 From: yves.frederix+cmake at gmail.com (Yves Frederix) Date: Tue, 20 Jan 2015 13:10:06 +0100 Subject: [CMake] VS2012 builds using v3.1.0 are a lot slower than v2.8.12 In-Reply-To: <54BD5E99.1010703@kitware.com> References: <54B7FFFC.4080300@kitware.com> <54B9366A.1040006@kitware.com> <54BD5E99.1010703@kitware.com> Message-ID: >> 3.1.0: 10m50s >> 2.8.12: 4m02s >> 3.1.0 (/MP): 6m29s >> 2.8.12 (/MP): 3m48s > > I cannot reproduce that. On my machine for OpenCV (as of commit > 5e92a777) I get about the same time for either version of CMake. > > 3.1.0 : 8m57s > 2.8.12.2 : 8m58s > 3.1.0 (/MP): 4m52s > 2.8.12.2 (/MP): 4m57s > > Check in your cases that 3.1.0 does not activate additional parts of > the project that are not built under 2.8.12. > > Also please try a command-line build with just "msbuild" instead of > going through "cmake --build": > > msbuild ALL_BUILD.vcxproj /p:Configuration=Release /p:VisualStudioVersion=12.0 (shouldn't this have been VisualStudioVersion=11.0?) So here are the timings: 3.1.0: 11m52s 2.8.12: 11m21s When keeping an eye on the resource monitor, I can also see that, while "cmake --build ." makes use of all the CPU cores (for 2.8.12) , this is not the case while running msbuild manually. Yves From robert.maynard at kitware.com Tue Jan 20 08:24:17 2015 From: robert.maynard at kitware.com (Robert Maynard) Date: Tue, 20 Jan 2015 08:24:17 -0500 Subject: [CMake] List of compile features from command line? In-Reply-To: References: Message-ID: I believe you can use WriteCompilerDetectionHeader to write out a file that will list support. The list of compile features you can request is documented at http://www.cmake.org/cmake/help/v3.1/prop_gbl/CMAKE_CXX_KNOWN_FEATURES.html On Sat, Jan 17, 2015 at 7:36 PM, Robert Dailey wrote: > Can I use cmake to spit out a list of supported compile features based > on my already-configured project? I'm not sure how I'm expected to get > the list of features otherwise. The documentation does not explain > this. > -- > > 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 From DLRdave at aol.com Tue Jan 20 08:54:26 2015 From: DLRdave at aol.com (David Cole) Date: Tue, 20 Jan 2015 08:54:26 -0500 Subject: [CMake] VS2012 builds using v3.1.0 are a lot slower than v2.8.12 In-Reply-To: References: <54B7FFFC.4080300@kitware.com> <54B9366A.1040006@kitware.com> <54BD5E99.1010703@kitware.com> Message-ID: If you open the "Tools > Options" dialog in Visual Studio, and navigate to the "Projects and Solutions > Build and Run" tab, what is your "maximum number of parallel project builds" value? For maximum parallel build capability, it should be set to the same as the number of cores you have. D On Tue, Jan 20, 2015 at 7:10 AM, Yves Frederix wrote: >>> 3.1.0: 10m50s >>> 2.8.12: 4m02s >>> 3.1.0 (/MP): 6m29s >>> 2.8.12 (/MP): 3m48s >> >> I cannot reproduce that. On my machine for OpenCV (as of commit >> 5e92a777) I get about the same time for either version of CMake. >> >> 3.1.0 : 8m57s >> 2.8.12.2 : 8m58s >> 3.1.0 (/MP): 4m52s >> 2.8.12.2 (/MP): 4m57s >> >> Check in your cases that 3.1.0 does not activate additional parts of >> the project that are not built under 2.8.12. >> >> Also please try a command-line build with just "msbuild" instead of >> going through "cmake --build": >> >> msbuild ALL_BUILD.vcxproj /p:Configuration=Release /p:VisualStudioVersion=12.0 > > (shouldn't this have been VisualStudioVersion=11.0?) > > So here are the timings: > > 3.1.0: 11m52s > 2.8.12: 11m21s > > When keeping an eye on the resource monitor, I can also see that, > while "cmake --build ." makes use of all the CPU cores (for 2.8.12) , > this is not the case while running msbuild manually. > > Yves > -- > > 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 From brad.king at kitware.com Tue Jan 20 09:01:18 2015 From: brad.king at kitware.com (Brad King) Date: Tue, 20 Jan 2015 09:01:18 -0500 Subject: [CMake] VS2012 builds using v3.1.0 are a lot slower than v2.8.12 In-Reply-To: References: <54B7FFFC.4080300@kitware.com> <54B9366A.1040006@kitware.com> <54BD5E99.1010703@kitware.com> Message-ID: <54BE5FAE.3000400@kitware.com> On 01/20/2015 07:10 AM, Yves Frederix wrote: >> msbuild ALL_BUILD.vcxproj /p:Configuration=Release /p:VisualStudioVersion=12.0 > (shouldn't this have been VisualStudioVersion=11.0?) Yes, but I was testing with VS 2013. > When keeping an eye on the resource monitor, I can also see that, > while "cmake --build ." makes use of all the CPU cores (for 2.8.12) , > this is not the case while running msbuild manually. Through 2.8.12.2 the "cmake --build" mode would read the output of the build and write it again to its own output pipes. When there is a lot of output this can probably take some CPU. There was an option "--use-stderr" to change to share the pipes so that they pass through directly to the terminal. 3.0 and above always do this and the "--use-stderr" option is ignored, so it should not have that problem. -Brad From yves.frederix+cmake at gmail.com Tue Jan 20 09:12:06 2015 From: yves.frederix+cmake at gmail.com (Yves Frederix) Date: Tue, 20 Jan 2015 15:12:06 +0100 Subject: [CMake] VS2012 builds using v3.1.0 are a lot slower than v2.8.12 In-Reply-To: References: <54B7FFFC.4080300@kitware.com> <54B9366A.1040006@kitware.com> <54BD5E99.1010703@kitware.com> Message-ID: > If you open the "Tools > Options" dialog in Visual Studio, and > navigate to the "Projects and Solutions > Build and Run" tab, what is > your "maximum number of parallel project builds" value? This is set to 8, which is what I expect as I have 4 cores with hyperthreading (also to windows they show as 8 cores). > > For maximum parallel build capability, it should be set to the same as > the number of cores you have. Yves Tue, Jan 20, 2015 at 7:10 AM, Yves Frederix > wrote: >>>> 3.1.0: 10m50s >>>> 2.8.12: 4m02s >>>> 3.1.0 (/MP): 6m29s >>>> 2.8.12 (/MP): 3m48s >>> >>> I cannot reproduce that. On my machine for OpenCV (as of commit >>> 5e92a777) I get about the same time for either version of CMake. >>> >>> 3.1.0 : 8m57s >>> 2.8.12.2 : 8m58s >>> 3.1.0 (/MP): 4m52s >>> 2.8.12.2 (/MP): 4m57s >>> >>> Check in your cases that 3.1.0 does not activate additional parts of >>> the project that are not built under 2.8.12. >>> >>> Also please try a command-line build with just "msbuild" instead of >>> going through "cmake --build": >>> >>> msbuild ALL_BUILD.vcxproj /p:Configuration=Release /p:VisualStudioVersion=12.0 >> >> (shouldn't this have been VisualStudioVersion=11.0?) >> >> So here are the timings: >> >> 3.1.0: 11m52s >> 2.8.12: 11m21s >> >> When keeping an eye on the resource monitor, I can also see that, >> while "cmake --build ." makes use of all the CPU cores (for 2.8.12) , >> this is not the case while running msbuild manually. >> >> Yves >> -- >> >> 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 From rcdailey.lists at gmail.com Tue Jan 20 10:48:56 2015 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Tue, 20 Jan 2015 09:48:56 -0600 Subject: [CMake] Specify 32-bit compilation to Clang In-Reply-To: <54BD651A.2080309@gmail.com> References: <54BD5F9B.7010106@googlemail.com> <54BD651A.2080309@gmail.com> Message-ID: On Mon, Jan 19, 2015 at 2:12 PM, Nils Gladitz wrote: > On 19.01.2015 21:08, Robert Dailey wrote: >> >> I have done this and it fails while linking the test program during >> configuration: >> >> /usr/bin/ld: cannot find crtbegin.o: no such file or directory >> /usr/bin/ld: cannot find -lgcc >> /usr/bin/ld: cannot find -lgcc_s >> >> Any ideas? >> > > Try installing the g++-multilib package. Installed this as you instructed, deleted CMakeCache.txt and re-ran generation. Got the errors below: -- The C compiler identification is Clang 3.5.0 -- The CXX compiler identification is Clang 3.5.0 -- Check for working C compiler using: Ninja -- Check for working C compiler using: Ninja -- broken CMake Error at /usr/share/cmake-3.1/Modules/CMakeTestCCompiler.cmake:61 (message ): The C compiler "/usr/bin/clang" is not able to compile a simple test program. It fails with the following output: Change Dir: /home/robert/frontend_build/CMakeFiles/CMakeTmp Run Build Command:"/home/robert/ninja/ninja" "cmTryCompileExec2104404287" [1/2] Building C object CMakeFiles/cmTryCompileExec2104404287.dir/testCCompiler.c.o [2/2] Linking C executable cmTryCompileExec2104404287 FAILED: : && /usr/bin/clang -m32 CMakeFiles/cmTryCompileExec2104404287.dir/testCCompiler.c.o -o cmTryCompileExec2104404287 -rdynamic && : /usr/bin/ld: skipping incompatible /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/libgcc.a when searching for -lgcc /usr/bin/ld: cannot find -lgcc /usr/bin/ld: skipping incompatible /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/libgcc_s.so when searching for -lgcc_s /usr/bin/ld: cannot find -lgcc_s clang: error: linker command failed with exit code 1 (use -v to see invocation) ninja: build stopped: subcommand failed. From nilsgladitz at gmail.com Tue Jan 20 10:58:10 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Tue, 20 Jan 2015 16:58:10 +0100 Subject: [CMake] Specify 32-bit compilation to Clang In-Reply-To: References: <54BD5F9B.7010106@googlemail.com> <54BD651A.2080309@gmail.com> Message-ID: <54BE7B12.4010004@gmail.com> On 01/20/2015 04:48 PM, Robert Dailey wrote: > On Mon, Jan 19, 2015 at 2:12 PM, Nils Gladitz wrote: >> On 19.01.2015 21:08, Robert Dailey wrote: >>> >>> I have done this and it fails while linking the test program during >>> configuration: >>> >>> /usr/bin/ld: cannot find crtbegin.o: no such file or directory >>> /usr/bin/ld: cannot find -lgcc >>> /usr/bin/ld: cannot find -lgcc_s >>> >>> Any ideas? >>> >> >> Try installing the g++-multilib package. > > Installed this as you instructed, deleted CMakeCache.txt and re-ran > generation. Got the errors below: > > > /usr/bin/ld: skipping incompatible > /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/libgcc.a when searching for -lgcc From the diagnostic it looks like clang shares gcc 4.8's libraries. Is the system wide default gcc 4.8 as well? e.g. does "gcc --version" report 4.8.x? If it isn't installing g++-4.8-multilib might help (If 4.8 is the default g++-multilib will already have installed it). Nils From post at hendrik-sattler.de Tue Jan 20 11:30:58 2015 From: post at hendrik-sattler.de (Hendrik Sattler) Date: Tue, 20 Jan 2015 17:30:58 +0100 Subject: [CMake] VS2012 builds using v3.1.0 are a lot slower than v2.8.12 In-Reply-To: References: <54B7FFFC.4080300@kitware.com> <54B9366A.1040006@kitware.com> <54BD5E99.1010703@kitware.com> Message-ID: <3C1F9187-4820-4383-BBFB-C39EF763A0CD@hendrik-sattler.de> Hi, but msbuild does not use this setting from VS, only devenv does. See option /m HS Am 20. Januar 2015 14:54:26 MEZ, schrieb David Cole via CMake : >If you open the "Tools > Options" dialog in Visual Studio, and >navigate to the "Projects and Solutions > Build and Run" tab, what is >your "maximum number of parallel project builds" value? > >For maximum parallel build capability, it should be set to the same as >the number of cores you have. > > >D > > >On Tue, Jan 20, 2015 at 7:10 AM, Yves Frederix > wrote: >>>> 3.1.0: 10m50s >>>> 2.8.12: 4m02s >>>> 3.1.0 (/MP): 6m29s >>>> 2.8.12 (/MP): 3m48s >>> >>> I cannot reproduce that. On my machine for OpenCV (as of commit >>> 5e92a777) I get about the same time for either version of CMake. >>> >>> 3.1.0 : 8m57s >>> 2.8.12.2 : 8m58s >>> 3.1.0 (/MP): 4m52s >>> 2.8.12.2 (/MP): 4m57s >>> >>> Check in your cases that 3.1.0 does not activate additional parts of >>> the project that are not built under 2.8.12. >>> >>> Also please try a command-line build with just "msbuild" instead of >>> going through "cmake --build": >>> >>> msbuild ALL_BUILD.vcxproj /p:Configuration=Release >/p:VisualStudioVersion=12.0 >> >> (shouldn't this have been VisualStudioVersion=11.0?) >> >> So here are the timings: >> >> 3.1.0: 11m52s >> 2.8.12: 11m21s >> >> When keeping an eye on the resource monitor, I can also see that, >> while "cmake --build ." makes use of all the CPU cores (for 2.8.12) , >> this is not the case while running msbuild manually. >> >> Yves >> -- >> >> 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 From robert.maynard at kitware.com Tue Jan 20 12:40:01 2015 From: robert.maynard at kitware.com (Robert Maynard) Date: Tue, 20 Jan 2015 12:40:01 -0500 Subject: [CMake] CPack in CMake 3.1.0 doesn't install files In-Reply-To: References: <52A2C443-8D57-4723-996E-CFBD9AAFC931@me.com> Message-ID: Hi, I haven't seen this issue but if you have a self-contained and reduced (preferably plain CMake ) test case, I would be happy to run it and verify if this is a regression. On Tue, Jan 20, 2015 at 2:37 AM, NoRulez wrote: > No one? > > Has something changed between 3.0.2 to 3.1.0 which prevents cpack to copy the generated *.exe file to the _CPack_Packages directory? Or did i need an additional variable to be set in 3.1.0? > > Thanks in advance > > Best Regards > > >> Am 16.01.2015 um 12:09 schrieb NoRulez : >> >> If I switch back to 3.0.2 everything is working like a charm >> >> Best Regards >> >>> Am 15.01.2015 um 17:49 schrieb NoRulez : >>> >>> Hello, >>> >>> we have only upgraded to the last release 3.1.0 from 3.0.2 and get the following when cpack is executed in a CTestScript: >>> >>> error: fixup_bundle: not a valid bundle >>> >>> The files are ceated, but they are not copied to the _CPack_Packages folder >>> >>> Then I found out that the variable "CMAKE_INSTALL_CONFIG_NAME" is empty in the cmake_install.cmake files >>> >>> Any hints? >>> >>> Best Regards >>> >>> -- >>> >>> Powered by www.kitware.com >>> >>> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ >>> >>> Kitware offers various services to support the CMake community. For more information on each offering, please visit: >>> >>> CMake Support: http://cmake.org/cmake/help/support.html >>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>> >>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html >>> >>> Follow this link to subscribe/unsubscribe: >>> http://public.kitware.com/mailman/listinfo/cmake >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake > -- > > 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 From tom.kacvinsky at vectorcast.com Tue Jan 20 12:57:55 2015 From: tom.kacvinsky at vectorcast.com (Tom Kacvinsky) Date: Tue, 20 Jan 2015 12:57:55 -0500 Subject: [CMake] Problem with library link order Message-ID: HI, I am using cmake 2.8,11.2 on Linux. I am having a problem with the order of libraries on the link line. In particular, there are some static archives we build that depend on a third party static archive (one we don't build - it comes with the Ada compiler we are using), yet the tghird part archive is on the link line (as given by the link.txt file) *before* the static archives we build. There are also problems with duplicated shared libraries and a few other issues related to linking. I have not bee able to suss out what cmake is doing to construct the list of link libraries used, and how it orders them. It is very important that we have the right order of libraries Unfortunately, our cmake files are too complicated to post here, and also depend on a working Ada compiler plus the plplot projects Ada support cmake "modules". Coming up with a simple reproducer is also difficult given the latter constaints. Can anyone point me in the right direction? If there is a heuristic I can follow - like ordering our libraries in target_link_libraries() differently - I would like to hear about it. Thanks, Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From ma at o-nigiri.me Tue Jan 20 13:57:44 2015 From: ma at o-nigiri.me (Ma O-Nigiri) Date: Tue, 20 Jan 2015 10:57:44 -0800 Subject: [CMake] Out of Source CMakeLists Message-ID: I'm porting a makefile based project over to CMake and would like to keep my CMakeLists in a separate set of directories: Source Tree (i.e. /myproject) ??? src ??? ??? framework ? ??? Utilities ? ??? a.cpp ? ??? a.h ??? tests ??? a_test.cpp CMakeLists Out of Source Tree (i.e. /myprojectcmakes) ??? cmake ? ??? FindGMock.cmake ? ??? FindGTest.cmake ??? CMakeLists.txt ??? src ??? CMakeLists.txt ??? framework ? ??? Utilities ? ??? CMakeLists.txt ??? tests ??? CMakeLists.txt Is this possible? I tried fiddling with some of the path variables and it didn't pan out. Cheers, Ma -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.hoffman at kitware.com Tue Jan 20 14:59:16 2015 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Tue, 20 Jan 2015 14:59:16 -0500 Subject: [CMake] Out of Source CMakeLists In-Reply-To: References: Message-ID: <54BEB394.40103@kitware.com> On 1/20/2015 1:57 PM, Ma O-Nigiri wrote: > I'm porting a makefile based project over to CMake and would like to > keep my CMakeLists in a separate set of directories: Why not keep the CMakeLists.txt in the project tree, but never do an in source build? Then the makefiles that cmake creates will never conflict with the existing ones. src/Makefile src/CMakeLists.txt build -> This starts as an empty directory that is filled by CMake with build files. -Bill From ggarra13 at gmail.com Tue Jan 20 15:00:23 2015 From: ggarra13 at gmail.com (Gonzalo Garramuno) Date: Tue, 20 Jan 2015 17:00:23 -0300 Subject: [CMake] Out of Source CMakeLists In-Reply-To: References: Message-ID: <54BEB3D7.4040707@gmail.com> On 20/01/15 15:57, Ma O-Nigiri wrote: > > Is this possible? I tried fiddling with some of the path variables and > it didn't pan out. I believe what you want is not possible. However, you can have: cmake/modules FindOpenEXR.cmake mytool CMakeLists.txt ( with add_subdirectory( src ) ) src/ CMakeLists.txt (with compilation directives ) file.cpp To compile, you create a build directory, like: $ cd (root of project) $ mkdir build-linux64 $ cd build-linux64 $ cmake .. $ make && make install This keeps all the files that cmake creates out of your source tree. From ma at o-nigiri.me Tue Jan 20 15:35:47 2015 From: ma at o-nigiri.me (Ma O-Nigiri) Date: Tue, 20 Jan 2015 12:35:47 -0800 Subject: [CMake] Out of Source CMakeLists In-Reply-To: <54BEB3D7.4040707@gmail.com> References: <54BEB3D7.4040707@gmail.com> Message-ID: Thanks guys - you both hit on my fallback plan. I had a feeling it wouldn't be trivial to get that working without actually adding some functionality to cmake itself. I'll just keep my builds out of tree so I don't interfere with the existing build system! Cheers On Tue, Jan 20, 2015 at 12:00 PM, Gonzalo Garramuno wrote: > On 20/01/15 15:57, Ma O-Nigiri wrote: > >> >> Is this possible? I tried fiddling with some of the path variables and it >> didn't pan out. >> > I believe what you want is not possible. However, you can have: > > cmake/modules > FindOpenEXR.cmake > mytool > CMakeLists.txt ( with add_subdirectory( src ) ) > src/ > CMakeLists.txt (with compilation directives ) > file.cpp > > To compile, you create a build directory, like: > $ cd (root of project) > $ mkdir build-linux64 > $ cd build-linux64 > $ cmake .. > $ make && make install > > This keeps all the files that cmake creates out of your source tree. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at mad-scientist.net Tue Jan 20 15:40:43 2015 From: paul at mad-scientist.net (Paul Smith) Date: Tue, 20 Jan 2015 15:40:43 -0500 Subject: [CMake] VS2012 builds using v3.1.0 are a lot slower than v2.8.12 In-Reply-To: <3C1F9187-4820-4383-BBFB-C39EF763A0CD@hendrik-sattler.de> References: <54B7FFFC.4080300@kitware.com> <54B9366A.1040006@kitware.com> <54BD5E99.1010703@kitware.com> <3C1F9187-4820-4383-BBFB-C39EF763A0CD@hendrik-sattler.de> Message-ID: <1421786443.5495.5.camel@mad-scientist.net> > Am 20. Januar 2015 14:54:26 MEZ, schrieb David Cole via CMake > : > >If you open the "Tools > Options" dialog in Visual Studio, and > >navigate to the "Projects and Solutions > Build and Run" tab, what is > >your "maximum number of parallel project builds" value? > > > >For maximum parallel build capability, it should be set to the same > >as the number of cores you have. On Tue, 2015-01-20 at 17:30 +0100, Hendrik Sattler wrote: > but msbuild does not use this setting from VS, only devenv does. So, I've discovered we're having this problem as well... on 3 of our 6 Windows build servers!! Looking at the logs I can see that on systems where it's "slow", "cmake --build" is choosing to use msbuild (and we don't have any added flags to have it run in parallel). On the other three systems where the build is "fast", "cmake --build" is choosing to use devenv (and is building in parallel by default). All these systems have Visual Studio 2010 and Visual Studio 2008 installed, but we invoke the builds on them identically in all cases (and these builds are using a generator of 'Visual Studio 10 x64'). Where can I go to find out more about how cmake --build chooses whether to use msbuild vs. devenv? It has to be something more complicated than just the generator used, otherwise all of these systems would use msbuild. FYI, I'm using CMake 3.1.0. From nilsgladitz at gmail.com Tue Jan 20 15:57:07 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Tue, 20 Jan 2015 21:57:07 +0100 Subject: [CMake] VS2012 builds using v3.1.0 are a lot slower than v2.8.12 In-Reply-To: <1421786443.5495.5.camel@mad-scientist.net> References: <54B7FFFC.4080300@kitware.com> <54B9366A.1040006@kitware.com> <54BD5E99.1010703@kitware.com> <3C1F9187-4820-4383-BBFB-C39EF763A0CD@hendrik-sattler.de> <1421786443.5495.5.camel@mad-scientist.net> Message-ID: <54BEC123.7030804@gmail.com> On 20.01.2015 21:40, Paul Smith wrote: >> Where can I go to find out more about how cmake --build chooses whether >> to use msbuild vs. devenv? It has to be something more complicated than >> just the generator used, otherwise all of these systems would use >> msbuild. I think devenv is used instead of msbuild when the solution has fortran projects. Nils From paul at mad-scientist.net Tue Jan 20 16:02:05 2015 From: paul at mad-scientist.net (Paul Smith) Date: Tue, 20 Jan 2015 16:02:05 -0500 Subject: [CMake] VS2012 builds using v3.1.0 are a lot slower than v2.8.12 In-Reply-To: <54BEC123.7030804@gmail.com> References: <54B7FFFC.4080300@kitware.com> <54B9366A.1040006@kitware.com> <54BD5E99.1010703@kitware.com> <3C1F9187-4820-4383-BBFB-C39EF763A0CD@hendrik-sattler.de> <1421786443.5495.5.camel@mad-scientist.net> <54BEC123.7030804@gmail.com> Message-ID: <1421787725.5495.6.camel@mad-scientist.net> On Tue, 2015-01-20 at 21:57 +0100, Nils Gladitz wrote: > On 20.01.2015 21:40, Paul Smith wrote: > >> Where can I go to find out more about how cmake --build chooses whether > >> to use msbuild vs. devenv? It has to be something more complicated than > >> just the generator used, otherwise all of these systems would use > >> msbuild. > > I think devenv is used instead of msbuild when the solution has fortran > projects. I certainly don't have any Fortran projects--!! All C/C++. From paul at mad-scientist.net Tue Jan 20 16:46:52 2015 From: paul at mad-scientist.net (Paul Smith) Date: Tue, 20 Jan 2015 16:46:52 -0500 Subject: [CMake] VS2012 builds using v3.1.0 are a lot slower than v2.8.12 In-Reply-To: <1421787725.5495.6.camel@mad-scientist.net> References: <54B7FFFC.4080300@kitware.com> <54B9366A.1040006@kitware.com> <54BD5E99.1010703@kitware.com> <3C1F9187-4820-4383-BBFB-C39EF763A0CD@hendrik-sattler.de> <1421786443.5495.5.camel@mad-scientist.net> <54BEC123.7030804@gmail.com> <1421787725.5495.6.camel@mad-scientist.net> Message-ID: <1421790412.5495.9.camel@mad-scientist.net> On Tue, 2015-01-20 at 16:02 -0500, Paul Smith wrote: > > I think devenv is used instead of msbuild when the solution has > > fortran projects. > > I certainly don't have any Fortran projects--!! I think I figured it out: on our build servers we don't delete everything and start over from scratch all the time (only for our official release builds). We recently upgraded our cmake from 2.8.12.2 to 3.1.0 and I think that the systems where we were seeing this problem had CMakeCache.txt files left over from when we were using CMake 2.8.12.2, and those files had CMAKE_MAKE_PROGRAM set (we never set it by hand, even back then, but maybe the older version of cmake added it to the cache on its own?) to devenv. Certainly when I went in and looked at CMakeCache.txt that value was set to "devenv.exe". If I regenerated the CMakeCache.txt from scratch, it was no longer set. From rcdailey.lists at gmail.com Tue Jan 20 19:56:11 2015 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Tue, 20 Jan 2015 18:56:11 -0600 Subject: [CMake] Specify 32-bit compilation to Clang In-Reply-To: <54BE7B12.4010004@gmail.com> References: <54BD5F9B.7010106@googlemail.com> <54BD651A.2080309@gmail.com> <54BE7B12.4010004@gmail.com> Message-ID: On Tue, Jan 20, 2015 at 9:58 AM, Nils Gladitz wrote: > On 01/20/2015 04:48 PM, Robert Dailey wrote: >> >> On Mon, Jan 19, 2015 at 2:12 PM, Nils Gladitz >> wrote: >>> >>> On 19.01.2015 21:08, Robert Dailey wrote: >>>> >>>> >>>> I have done this and it fails while linking the test program during >>>> configuration: >>>> >>>> /usr/bin/ld: cannot find crtbegin.o: no such file or directory >>>> /usr/bin/ld: cannot find -lgcc >>>> /usr/bin/ld: cannot find -lgcc_s >>>> >>>> Any ideas? >>>> >>> >>> Try installing the g++-multilib package. >> >> >> Installed this as you instructed, deleted CMakeCache.txt and re-ran >> generation. Got the errors below: >> > > >> >> /usr/bin/ld: skipping incompatible >> /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/libgcc.a when searching for >> -lgcc > > > From the diagnostic it looks like clang shares gcc 4.8's libraries. > > Is the system wide default gcc 4.8 as well? > e.g. does "gcc --version" report 4.8.x? > > If it isn't installing g++-4.8-multilib might help (If 4.8 is the default > g++-multilib will already have installed it). Here are the results: robert at robert-VirtualBox ~ $ gcc --version gcc (Ubuntu 4.8.2-19ubuntu1) 4.8.2 Copyright (C) 2013 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. robert at robert-VirtualBox ~ $ sudo apt-get install g++-4.8-multilib [sudo] password for robert: Reading package lists... Done Building dependency tree Reading state information... Done g++-4.8-multilib is already the newest version. g++-4.8-multilib set to manually installed. 0 upgraded, 0 newly installed, 0 to remove and 172 not upgraded. From d3ck0r at gmail.com Tue Jan 20 22:07:54 2015 From: d3ck0r at gmail.com (J Decker) Date: Tue, 20 Jan 2015 19:07:54 -0800 Subject: [CMake] Problem with library link order In-Reply-To: References: Message-ID: library link order is exactly as you specify in target_link_libraries... each line following the last of the prior list.... so reording your library link list should be doable On Tue, Jan 20, 2015 at 9:57 AM, Tom Kacvinsky wrote: > HI, > > I am using cmake 2.8,11.2 on Linux. I am having a problem with the order > of libraries on the link line. In particular, there are some static > archives we build that depend on a third party static archive (one we don't > build - it comes with the Ada compiler we are using), yet the tghird part > archive is on the link line (as given by the link.txt file) *before* the > static archives we build. There are also problems with duplicated shared > libraries and a few other issues related to linking. I have not bee able > to suss out what cmake is doing to construct the list of link libraries > used, and how it orders them. It is very important that we have the right > order of libraries > > Unfortunately, our cmake files are too complicated to post here, and also > depend on a working Ada compiler plus the plplot projects Ada support cmake > "modules". Coming up with a simple reproducer is also difficult given the > latter constaints. > > Can anyone point me in the right direction? If there is a heuristic I can > follow - like ordering our libraries in target_link_libraries() differently > - I would like to hear about it. > > Thanks, > > Tom > > -- > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From norulez at me.com Wed Jan 21 04:00:04 2015 From: norulez at me.com (NoRulez) Date: Wed, 21 Jan 2015 10:00:04 +0100 Subject: [CMake] CPack in CMake 3.1.0 doesn't install files In-Reply-To: References: <52A2C443-8D57-4723-996E-CFBD9AAFC931@me.com> Message-ID: <3D148401-325C-4F20-BD97-82C8EF3F216B@me.com> Hi, it should also not work when you build a test project in release mode and then in the build directory type "cpack -G ZIP" for example. (Without the -C option) In the CTestScript is also added the -C option to ensure it uses the release mode, but it doesn't work either. When you then open the cmake_install.cmake files, you will see that the CMAKE_INSTALL_CONFIG_NAME variable is empty on line 15. In CMake 3.0.2 the variable is set with the value "Release". Best Regards > Am 20.01.2015 um 18:40 schrieb Robert Maynard : > > Hi, > > I haven't seen this issue but if you have a self-contained and reduced > (preferably plain CMake ) test case, I would be happy to run it and > verify if this is a regression. > >> On Tue, Jan 20, 2015 at 2:37 AM, NoRulez wrote: >> No one? >> >> Has something changed between 3.0.2 to 3.1.0 which prevents cpack to copy the generated *.exe file to the _CPack_Packages directory? Or did i need an additional variable to be set in 3.1.0? >> >> Thanks in advance >> >> Best Regards >> >> >>> Am 16.01.2015 um 12:09 schrieb NoRulez : >>> >>> If I switch back to 3.0.2 everything is working like a charm >>> >>> Best Regards >>> >>>> Am 15.01.2015 um 17:49 schrieb NoRulez : >>>> >>>> Hello, >>>> >>>> we have only upgraded to the last release 3.1.0 from 3.0.2 and get the following when cpack is executed in a CTestScript: >>>> >>>> error: fixup_bundle: not a valid bundle >>>> >>>> The files are ceated, but they are not copied to the _CPack_Packages folder >>>> >>>> Then I found out that the variable "CMAKE_INSTALL_CONFIG_NAME" is empty in the cmake_install.cmake files >>>> >>>> Any hints? >>>> >>>> Best Regards >>>> >>>> -- >>>> >>>> Powered by www.kitware.com >>>> >>>> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ >>>> >>>> Kitware offers various services to support the CMake community. For more information on each offering, please visit: >>>> >>>> CMake Support: http://cmake.org/cmake/help/support.html >>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>>> >>>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html >>>> >>>> Follow this link to subscribe/unsubscribe: >>>> http://public.kitware.com/mailman/listinfo/cmake >>> -- >>> >>> Powered by www.kitware.com >>> >>> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ >>> >>> Kitware offers various services to support the CMake community. For more information on each offering, please visit: >>> >>> CMake Support: http://cmake.org/cmake/help/support.html >>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>> >>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html >>> >>> Follow this link to subscribe/unsubscribe: >>> http://public.kitware.com/mailman/listinfo/cmake >> -- >> >> 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 From nilsgladitz at gmail.com Wed Jan 21 04:40:51 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Wed, 21 Jan 2015 10:40:51 +0100 Subject: [CMake] Specify 32-bit compilation to Clang In-Reply-To: References: <54BD5F9B.7010106@googlemail.com> <54BD651A.2080309@gmail.com> <54BE7B12.4010004@gmail.com> Message-ID: <54BF7423.9000005@gmail.com> I am not sure what else it could be. Here are some queries I did on my system where it seems to be working; perhaps it will help you backtrack the issue: Ubuntu 14.04.1 LTS (64-bit) # gcc --version : gcc (Ubuntu 4.8.2-19ubuntu1) 4.8.2 # clang --version : Ubuntu clang version 3.4-1ubuntu3 (tags/RELEASE_34/final) (based on LLVM 3.4) # clang++ -m32 -Wl,--verbose test.cpp|grep libgcc attempt to open /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/32/libgcc_s.so succeeded -lgcc_s (/usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/32/libgcc_s.so) # file a.out a.out: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=e15359bda06cce657369b3ae9d526c926deea6f2, not stripped # apt-file search /usr/lib/gcc/x86_64-linux-gnu/4.8/32/libgcc_s.so lib32gcc-4.8-dev: /usr/lib/gcc/x86_64-linux-gnu/4.8/32/libgcc_s.so g++-multilib has an indirect dependency on lib32gcc-4.8-dev. Nils From yves.frederix+cmake at gmail.com Wed Jan 21 05:53:06 2015 From: yves.frederix+cmake at gmail.com (Yves Frederix) Date: Wed, 21 Jan 2015 11:53:06 +0100 Subject: [CMake] VS2012 builds using v3.1.0 are a lot slower than v2.8.12 In-Reply-To: <1421790412.5495.9.camel@mad-scientist.net> References: <54B7FFFC.4080300@kitware.com> <54B9366A.1040006@kitware.com> <54BD5E99.1010703@kitware.com> <3C1F9187-4820-4383-BBFB-C39EF763A0CD@hendrik-sattler.de> <1421786443.5495.5.camel@mad-scientist.net> <54BEC123.7030804@gmail.com> <1421787725.5495.6.camel@mad-scientist.net> <1421790412.5495.9.camel@mad-scientist.net> Message-ID: Ok, so it all seems to boil down to the following: - 2.8.12: "cmake --build" uses devenv to build, which in turn picks up a setting ("maximum number of parallel project builds") from the VS IDE at build time. As this was set to 8 on my machine, by default the build used parallellization with 8 cores with a fast parallel build as a result. I verified that after changing this setting in the IDE to 1, the build no longer works in parallel, with longer build times as a result. - 3.x: "cmake --build" uses MSBuild, which uses a command line switch /m to control the same behavior. In absence of this command line switch, the default behavior is equivalent to /m1 (see https://msdn.microsoft.com/en-us/library/ms164311.aspx), which means a non-parallel build and longer build times than for 2.8.12. A way to test this in practice, is to run a build command with native build options like 'cmake --build . --config Release -- /m'. I checked and this indeed works as expected. The above explains all my initial observations. However, the fix is not very handy. As I understood, one does not know until build time what exact build (devenv or msbuild) will be used by CMake, so simply always adding '-- /m' to the build command will not work (devenv doesn't like /m). Assuming that changing the default command line options to MSBuild inside CMake is not a valid solution, I am wondering if there is currently a way to set additional build options for MSBuild only from inside the CMakeLists.txt file? Or, alternatively, is there a way to check which build program will be used before actually running the build? Yves On Tue, Jan 20, 2015 at 10:46 PM, Paul Smith wrote: > On Tue, 2015-01-20 at 16:02 -0500, Paul Smith wrote: >> > I think devenv is used instead of msbuild when the solution has >> > fortran projects. >> >> I certainly don't have any Fortran projects--!! > > I think I figured it out: on our build servers we don't delete > everything and start over from scratch all the time (only for our > official release builds). > > We recently upgraded our cmake from 2.8.12.2 to 3.1.0 and I think that > the systems where we were seeing this problem had CMakeCache.txt files > left over from when we were using CMake 2.8.12.2, and those files had > CMAKE_MAKE_PROGRAM set (we never set it by hand, even back then, but > maybe the older version of cmake added it to the cache on its own?) to > devenv. > > Certainly when I went in and looked at CMakeCache.txt that value was set > to "devenv.exe". If I regenerated the CMakeCache.txt from scratch, it > was no longer set. > > -- > > 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 From tom.kacvinsky at vectorcast.com Wed Jan 21 08:33:25 2015 From: tom.kacvinsky at vectorcast.com (Tom Kacvinsky) Date: Wed, 21 Jan 2015 08:33:25 -0500 Subject: [CMake] Problem with library link order In-Reply-To: References: Message-ID: Unfortunately, that is not what I've found. There are libraries we build that have their own target_link_libraries, and if these libraries are used on the target_link_libraries for an executable, its dependencies are also pulled into the executables link line. This is expected, handling of transitive dependencies. What is not expected is when I add libraries we don't build, or object files, the link order gets messed up. That and we see duplicates of libraries. For instance, when I pull in the the Qt libraries, they always show up twice. Perhaps this is because of transitive dependencies. In any case, there appears to be no fine grain control of link libraries/ordering and it is driving me nuts. I'll see if I can come up with a reproducer. It'll be a while before I can get one to the list. Tom On Tue, Jan 20, 2015 at 10:07 PM, J Decker wrote: > library link order is exactly as you specify in target_link_libraries... > each line following the last of the prior list.... so reording your library > link list should be doable > > On Tue, Jan 20, 2015 at 9:57 AM, Tom Kacvinsky < > tom.kacvinsky at vectorcast.com> wrote: > >> HI, >> >> I am using cmake 2.8,11.2 on Linux. I am having a problem with the order >> of libraries on the link line. In particular, there are some static >> archives we build that depend on a third party static archive (one we don't >> build - it comes with the Ada compiler we are using), yet the tghird part >> archive is on the link line (as given by the link.txt file) *before* the >> static archives we build. There are also problems with duplicated shared >> libraries and a few other issues related to linking. I have not bee able >> to suss out what cmake is doing to construct the list of link libraries >> used, and how it orders them. It is very important that we have the right >> order of libraries >> >> Unfortunately, our cmake files are too complicated to post here, and also >> depend on a working Ada compiler plus the plplot projects Ada support cmake >> "modules". Coming up with a simple reproducer is also difficult given the >> latter constaints. >> >> Can anyone point me in the right direction? If there is a heuristic I >> can follow - like ordering our libraries in target_link_libraries() >> differently - I would like to hear about it. >> >> Thanks, >> >> Tom >> >> -- >> >> 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 >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Wed Jan 21 09:05:32 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 21 Jan 2015 09:05:32 -0500 Subject: [CMake] VS2012 builds using v3.1.0 are a lot slower than v2.8.12 In-Reply-To: References: <54B7FFFC.4080300@kitware.com> <54B9366A.1040006@kitware.com> <54BD5E99.1010703@kitware.com> <3C1F9187-4820-4383-BBFB-C39EF763A0CD@hendrik-sattler.de> <1421786443.5495.5.camel@mad-scientist.net> <54BEC123.7030804@gmail.com> <1421787725.5495.6.camel@mad-scientist.net> <1421790412.5495.9.camel@mad-scientist.net> Message-ID: <54BFB22C.3020708@kitware.com> On 01/20/2015 03:40 PM, Paul Smith wrote: > Where can I go to find out more about how cmake --build chooses whether > to use msbuild vs. devenv? The behavior was updated in 3.0 and is now described here: http://www.cmake.org/cmake/help/v3.0/variable/CMAKE_MAKE_PROGRAM.html In 2.8.12 and below we always stored CMAKE_MAKE_PROGRAM in CMakeCache.txt instead of waiting until build time to choose it. This was problematic because it was initialized before configuring the project so we could not know whether devenv had to be chosen for Intel Fortran support or not, so it always chose devenv if available. However, devenv does not work when using an alternative PlatformToolset with CMAKE_GENERATOR_TOOLSET: http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/46795/focus=46969 Therefore we had to switch to build-time selection of the build tool. The change was mentioned in the 3.0 release notes: http://www.cmake.org/cmake/help/v3.0/release/3.0.0.html#other-changes "Selection of the proper msbuild or devenv tool is now performed as late as possible when the solution (.sln) file is available so it can depend on project content." On 01/21/2015 05:53 AM, Yves Frederix wrote: > options like 'cmake --build . --config Release -- /m'. I checked and > this indeed works as expected. Yes. > The above explains all my initial observations. However, the fix is > not very handy. As I understood, one does not know until build time > what exact build (devenv or msbuild) will be used by CMake MSBuild will be used for VS >= 10 unless Fortran code is involved. You can also add -DCMAKE_MAKE_PROGRAM=/path/to/msbuild.exe to explicitly specify it. Once that is in CMakeCache.txt then it will always be used by "cmake --build". -Brad From post at hendrik-sattler.de Wed Jan 21 11:00:49 2015 From: post at hendrik-sattler.de (Hendrik Sattler) Date: Wed, 21 Jan 2015 17:00:49 +0100 Subject: [CMake] VS2012 builds using v3.1.0 are a lot slower than v2.8.12 In-Reply-To: <54BFB22C.3020708@kitware.com> References: <54B7FFFC.4080300@kitware.com> <54B9366A.1040006@kitware.com> <54BD5E99.1010703@kitware.com> <3C1F9187-4820-4383-BBFB-C39EF763A0CD@hendrik-sattler.de> <1421786443.5495.5.camel@mad-scientist.net> <54BEC123.7030804@gmail.com> <1421787725.5495.6.camel@mad-scientist.net> <1421790412.5495.9.camel@mad-scientist.net> <54BFB22C.3020708@kitware.com> Message-ID: <9B8B4A7E-47D8-4D4F-B5C5-FE8CAD3C0407@hendrik-sattler.de> Hi, This makes cmake --build much less predictable across cmake versions and cmake projects. How can I find out if msbuild is chosen without inspecting the cmake project? Specifying this manually is not really an option... too complicated. Or like that: - run CMake - get the CMAKE_VS_MSBUILD... from cache and at set CMAKE_MAKE_PROGRAM from it. @Paul: You can probably modify the CMAKE_VS_MSBUILD... variable to add /m. But to compile in parallel should be s decision of the user, not the project, and thus a decision of the caller of cmake --build. HS Am 21. Januar 2015 15:05:32 MEZ, schrieb Brad King : >On 01/20/2015 03:40 PM, Paul Smith wrote: >> Where can I go to find out more about how cmake --build chooses >whether >> to use msbuild vs. devenv? > >The behavior was updated in 3.0 and is now described here: > > http://www.cmake.org/cmake/help/v3.0/variable/CMAKE_MAKE_PROGRAM.html > >In 2.8.12 and below we always stored CMAKE_MAKE_PROGRAM in >CMakeCache.txt >instead of waiting until build time to choose it. This was problematic >because it was initialized before configuring the project so we could >not >know whether devenv had to be chosen for Intel Fortran support or not, >so it always chose devenv if available. However, devenv does not work >when using an alternative PlatformToolset with CMAKE_GENERATOR_TOOLSET: > >http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/46795/focus=46969 > >Therefore we had to switch to build-time selection of the build tool. >The change was mentioned in the 3.0 release notes: > > http://www.cmake.org/cmake/help/v3.0/release/3.0.0.html#other-changes > "Selection of the proper msbuild or devenv tool is now performed as > late as possible when the solution (.sln) file is available so it > can depend on project content." > >On 01/21/2015 05:53 AM, Yves Frederix wrote: >> options like 'cmake --build . --config Release -- /m'. I checked and >> this indeed works as expected. > >Yes. > >> The above explains all my initial observations. However, the fix is >> not very handy. As I understood, one does not know until build time >> what exact build (devenv or msbuild) will be used by CMake > >MSBuild will be used for VS >= 10 unless Fortran code is involved. You >can also add -DCMAKE_MAKE_PROGRAM=/path/to/msbuild.exe to explicitly >specify it. Once that is in CMakeCache.txt then it will always be used >by "cmake --build". > >-Brad From rcdailey.lists at gmail.com Wed Jan 21 11:07:03 2015 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Wed, 21 Jan 2015 10:07:03 -0600 Subject: [CMake] Specify 32-bit compilation to Clang In-Reply-To: <54BF7423.9000005@gmail.com> References: <54BD5F9B.7010106@googlemail.com> <54BD651A.2080309@gmail.com> <54BE7B12.4010004@gmail.com> <54BF7423.9000005@gmail.com> Message-ID: Thanks for your help so far. Your 3rd command produced the output below. I'll keep looking into this but just wanted to share. I'm not sure why it isn't working, and I'm not completely familiar with linux development so it will take me a while to figure this out. robert at robert-OptiPlex-745 ~ $ clang++ -m32 -Wl,--verbose test.cpp|grep libgcc /usr/bin/ld: skipping incompatible /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/libstdc++.so when searching for -lstdc++ /usr/bin/ld: skipping incompatible /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/libstdc++.a when searching for -lstdc++ /usr/bin/ld: cannot find -lstdc++ /usr/bin/ld: skipping incompatible /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/libgcc_s.so when searching for -lgcc_s attempt to open /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/libgcc_s.so succeeded /usr/bin/ld: cannot find -lgcc_s attempt to open /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/libgcc_s.a failed attempt to open /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/../../../i386-linux-gnu/libgcc_s.so failed /usr/bin/ld: skipping incompatible /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/libgcc.a when searching for -lgcc attempt to open /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/../../../i386-linux-gnu/libgcc_s.a failed attempt to open /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/../../../../lib32/libgcc_s.so failed attempt to open /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/../../../../lib32/libgcc_s.a failed /usr/bin/ldattempt to open /usr/bin/../lib/i386-linux-gnu/libgcc_s.so failed : cannot find -lgcc attempt to open /usr/bin/../lib/i386-linux-gnu/libgcc_s.a failed attempt to open /usr/bin/../lib32/libgcc_s.so failed attempt to open /usr/bin/../lib32/libgcc_s.a failed attempt to open /lib/i386-linux-gnu/libgcc_s.so failed attempt to open /lib/i386-linux-gnu/libgcc_s.a failed attempt to open /lib/../lib32/libgcc_s.so failed attempt to open /lib/../lib32/libgcc_s.a failed attempt to open /usr/lib/i386-linux-gnu/libgcc_s.so failed attempt to open /usr/lib/i386-linux-gnu/libgcc_s.a failed attempt to open /usr/lib/../lib32/libgcc_s.so failed attempt to open /usr/lib/../lib32/libgcc_s.a failed attempt to open /usr/lib/x86_64-linux-gnu/../../lib32/libgcc_s.so failed attempt to open /usr/lib/x86_64-linux-gnu/../../lib32/libgcc_s.a failed attempt to open /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/../../../libgcc_s.so failed attempt to open /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/../../../libgcc_s.a failed attempt to open /usr/bin/../lib/libgcc_s.so failed attempt to open /usr/bin/../lib/libgcc_s.a failed attempt to open /lib/libgcc_s.so failed attempt to open /lib/libgcc_s.a failed attempt to open /usr/lib/libgcc_s.so failed attempt to open /usr/lib/libgcc_s.a failed attempt to open /usr/i386-linux-gnu/lib32/libgcc_s.so failed attempt to open /usr/i386-linux-gnu/lib32/libgcc_s.a failed attempt to open /usr/x86_64-linux-gnu/lib32/libgcc_s.so failed attempt to open /usr/x86_64-linux-gnu/lib32/libgcc_s.a failed attempt to open //usr/local/lib/i386-linux-gnu/libgcc_s.so failed attempt to open //usr/local/lib/i386-linux-gnu/libgcc_s.a failed attempt to open //usr/local/lib32/libgcc_s.so failed attempt to open //usr/local/lib32/libgcc_s.a failed attempt to open //lib/i386-linux-gnu/libgcc_s.so failed attempt to open //lib/i386-linux-gnu/libgcc_s.a failed attempt to open //lib32/libgcc_s.so failed attempt to open //lib32/libgcc_s.a failed attempt to open //usr/lib/i386-linux-gnu/libgcc_s.so failed attempt to open //usr/lib/i386-linux-gnu/libgcc_s.a failed attempt to open //usr/lib32/libgcc_s.so failed attempt to open //usr/lib32/libgcc_s.a failed attempt to open //usr/local/lib/libgcc_s.so failed attempt to open //usr/local/lib/libgcc_s.a failed attempt to open //lib/libgcc_s.so failed attempt to open //lib/libgcc_s.a failed attempt to open //usr/lib/libgcc_s.so failed attempt to open //usr/lib/libgcc_s.a failed attempt to open /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/libgcc.so failed attempt to open /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/libgcc.a succeeded attempt to open /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/../../../i386-linux-gnu/libgcc.so failed attempt to open /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/../../../i386-linux-gnu/libgcc.a failed attempt to open /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/../../../../lib32/libgcc.so failed attempt to open /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/../../../../lib32/libgcc.a failed attempt to open /usr/bin/../lib/i386-linux-gnu/libgcc.so failed attempt to open /usr/bin/../lib/i386-linux-gnu/libgcc.a failed attempt to open /usr/bin/../lib32/libgcc.so failed attempt to open /usr/bin/../lib32/libgcc.a failed attempt to open /lib/i386-linux-gnu/libgcc.so failed attempt to open /lib/i386-linux-gnu/libgcc.a failed attempt to open /lib/../lib32/libgcc.so failed attempt to open /lib/../lib32/libgcc.a failed attempt to open /usr/lib/i386-linux-gnu/libgcc.so failed attempt to open /usr/lib/i386-linux-gnu/libgcc.a failed attempt to open /usr/lib/../lib32/libgcc.so failed attempt to open /usr/lib/../lib32/libgcc.a failed attempt to open /usr/lib/x86_64-linux-gnu/../../lib32/libgcc.so failed attempt to open /usr/lib/x86_64-linux-gnu/../../lib32/libgcc.a failed attempt to open /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/../../../libgcc.so failed attempt to open /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/../../../libgcc.a failed attempt to open /usr/bin/../lib/libgcc.so failed attempt to open /usr/bin/../lib/libgcc.a failed attempt to open /lib/libgcc.so failed attempt to open /lib/libgcc.a failed attempt to open /usr/lib/libgcc.so failed attempt to open /usr/lib/libgcc.a failed attempt to open /usr/i386-linux-gnu/lib32/libgcc.so failed attempt to open /usr/i386-linux-gnu/lib32/libgcc.a failed attempt to open /usr/x86_64-linux-gnu/lib32/libgcc.so failed attempt to open /usr/x86_64-linux-gnu/lib32/libgcc.a failed attempt to open //usr/local/lib/i386-linux-gnu/libgcc.so failed attempt to open //usr/local/lib/i386-linux-gnu/libgcc.a failed attempt to open //usr/local/lib32/libgcc.so failed attempt to open //usr/local/lib32/libgcc.a failed attempt to open //lib/i386-linux-gnu/libgcc.so failed attempt to open //lib/i386-linux-gnu/libgcc.a failed attempt to open //lib32/libgcc.so failed attempt to open //lib32/libgcc.a failed attempt to open //usr/lib/i386-linux-gnu/libgcc.so failed attempt to open //usr/lib/i386-linux-gnu/libgcc.a failed attempt to open //usr/lib32/libgcc.so failed attempt to open //usr/lib32/libgcc.a failed attempt to open //usr/local/lib/libgcc.so failed attempt to open //usr/local/lib/libgcc.a failed attempt to open //lib/libgcc.so failed attempt to open //lib/libgcc.a failed attempt to open //usr/lib/libgcc.so failed attempt to open //usr/lib/libgcc.a failed clang: error: linker command failed with exit code 1 (use -v to see invocation) On Wed, Jan 21, 2015 at 3:40 AM, Nils Gladitz wrote: > I am not sure what else it could be. > Here are some queries I did on my system where it seems to be working; > perhaps it will help you backtrack the issue: > > Ubuntu 14.04.1 LTS (64-bit) > > # gcc --version : > gcc (Ubuntu 4.8.2-19ubuntu1) 4.8.2 > > # clang --version : > Ubuntu clang version 3.4-1ubuntu3 (tags/RELEASE_34/final) (based on LLVM > 3.4) > > # clang++ -m32 -Wl,--verbose test.cpp|grep libgcc > attempt to open /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/32/libgcc_s.so > succeeded > -lgcc_s (/usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/32/libgcc_s.so) > > # file a.out > a.out: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), > dynamically linked (uses shared libs), for GNU/Linux 2.6.24, > BuildID[sha1]=e15359bda06cce657369b3ae9d526c926deea6f2, not stripped > > # apt-file search /usr/lib/gcc/x86_64-linux-gnu/4.8/32/libgcc_s.so > lib32gcc-4.8-dev: /usr/lib/gcc/x86_64-linux-gnu/4.8/32/libgcc_s.so > > g++-multilib has an indirect dependency on lib32gcc-4.8-dev. > > Nils From brad.king at kitware.com Wed Jan 21 11:12:09 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 21 Jan 2015 11:12:09 -0500 Subject: [CMake] cmake --build parallel options (was: VS2012 builds using v3.1.0 are a lot slower than v2.8.12) In-Reply-To: <9B8B4A7E-47D8-4D4F-B5C5-FE8CAD3C0407@hendrik-sattler.de> References: <54B7FFFC.4080300@kitware.com> <54B9366A.1040006@kitware.com> <54BD5E99.1010703@kitware.com> <3C1F9187-4820-4383-BBFB-C39EF763A0CD@hendrik-sattler.de> <1421786443.5495.5.camel@mad-scientist.net> <54BEC123.7030804@gmail.com> <1421787725.5495.6.camel@mad-scientist.net> <1421790412.5495.9.camel@mad-scientist.net> <54BFB22C.3020708@kitware.com> <9B8B4A7E-47D8-4D4F-B5C5-FE8CAD3C0407@hendrik-sattler.de> Message-ID: <54BFCFD9.6060400@kitware.com> On 01/21/2015 11:00 AM, Hendrik Sattler wrote: > This makes cmake --build much less predictable across cmake versions and cmake projects. > How can I find out if msbuild is chosen without inspecting the cmake project? One can't, but that is a fault of VS and/or Intel Fortran for having cases that require devenv or msbuild, not a fault of CMake for trying to deal with it. Since 3.0 we always picks msbuild unless Fortran is involved. This is fairly predictable moving forward. > - get the CMAKE_VS_MSBUILD... from cache and at set CMAKE_MAKE_PROGRAM from it. > > @Paul: You can probably modify the CMAKE_VS_MSBUILD... variable to add /m. The CMAKE_VS_MSBUILD_COMMAND variable: http://www.cmake.org/cmake/help/v3.1/variable/CMAKE_VS_MSBUILD_COMMAND.html is not cached. It is available to CMakeLists.txt code. > But to compile in parallel should be s decision of the user, not the > project, and thus a decision of the caller of cmake --build. Rather than requiring users to run cmake --build . -- $tool_specific_parallel_option to get a parallel build we could instead extend the "cmake --build" command to support an option mapping to the right parallel option underneath: cmake --build . --parallel cmake --build . --parallel=$n -Brad From paul at mad-scientist.net Wed Jan 21 11:21:59 2015 From: paul at mad-scientist.net (Paul Smith) Date: Wed, 21 Jan 2015 11:21:59 -0500 Subject: [CMake] cmake --build parallel options (was: VS2012 builds using v3.1.0 are a lot slower than v2.8.12) In-Reply-To: <54BFCFD9.6060400@kitware.com> References: <54B7FFFC.4080300@kitware.com> <54B9366A.1040006@kitware.com> <54BD5E99.1010703@kitware.com> <3C1F9187-4820-4383-BBFB-C39EF763A0CD@hendrik-sattler.de> <1421786443.5495.5.camel@mad-scientist.net> <54BEC123.7030804@gmail.com> <1421787725.5495.6.camel@mad-scientist.net> <1421790412.5495.9.camel@mad-scientist.net> <54BFB22C.3020708@kitware.com> <9B8B4A7E-47D8-4D4F-B5C5-FE8CAD3C0407@hendrik-sattler.de> <54BFCFD9.6060400@kitware.com> Message-ID: <1421857319.5495.11.camel@mad-scientist.net> On Wed, 2015-01-21 at 11:12 -0500, Brad King wrote: > Rather than requiring users to run > > cmake --build . -- $tool_specific_parallel_option > > to get a parallel build we could instead extend the "cmake --build" > command to support an option mapping to the right parallel option > underneath: > > cmake --build . --parallel > cmake --build . --parallel=$n Unfortunately (for you guys :-)) I think this will end up being the only reliably portable answer... It was what I was going to suggest before I saw this email :-p :-) From brad.king at kitware.com Wed Jan 21 15:12:49 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 21 Jan 2015 15:12:49 -0500 Subject: [CMake] Problem with library link order In-Reply-To: References: Message-ID: <54C00841.7020303@kitware.com> On 01/20/2015 12:57 PM, Tom Kacvinsky wrote: > there are some static archives we build that depend on a third party > static archive (one we don't build - it comes with the Ada compiler > we are using), yet the third part archive is on the link line (as > given by the link.txt file) *before* the static archives we build. If you have a library add_library(mylib STATIC mylib.c) and it depends on a third-party library then tell CMake so: target_link_libraries(mylib otherlib) Then CMake will guarantee that an occurrence of otherlib appears on the link line after mylib. > duplicated shared libraries These generally don't hurt anything. CMake 3.1 will de-duplicate shared libraries that come from logical targets (created via add_library either as a build target or as an imported library). > Can anyone point me in the right direction? FYI, the ordering algorithm is documented in source comments here: http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmComputeLinkDepends.cxx;hb=v3.1.0#l25 -Brad From shooki.robinson at gmail.com Wed Jan 21 21:41:45 2015 From: shooki.robinson at gmail.com (Joshua Robinson) Date: Wed, 21 Jan 2015 21:41:45 -0500 Subject: [CMake] add_executable question Message-ID: Greetings, Can I add a variable, was set before, to add_executable ? set(PROJ_NAME Test01) ,,, file( GLOB ${PROJ_NAME}_SRC "*.h" "*.cpp" ) add_executable( ${PROJ_NAME} ${PROJ_NAME}_SRC) ... error in add_executable(..) Any help is appreciated. Best Regards, Joshua Robinson -------------- next part -------------- An HTML attachment was scrubbed... URL: From scott.bloom at onshorecs.com Wed Jan 21 23:14:30 2015 From: scott.bloom at onshorecs.com (Scott Aron Bloom) Date: Thu, 22 Jan 2015 04:14:30 +0000 Subject: [CMake] Pre-compiled headers Message-ID: <6FD2E165340D9A429CF831C7A2D4F42E4E5CA754@WIN-R92V03RFJ85.onshorecs.local> Is there any builtin CMake support for compiler independent support for pre-compiled headers? I have found a couple of hacks out there for MSVC, and some for gcc.. but nothing that is all inclusive, and frankly none that look up to the quality of CMake :) Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.noulard at gmail.com Thu Jan 22 02:05:06 2015 From: eric.noulard at gmail.com (Eric Noulard) Date: Thu, 22 Jan 2015 08:05:06 +0100 Subject: [CMake] add_executable question In-Reply-To: References: Message-ID: 2015-01-22 3:41 GMT+01:00 Joshua Robinson : > > Greetings, > > Can I add a variable, was set before, to add_executable ? > I guess yes. However if "PROJ_NAME" value was used in project(Test01 C CXX) then there may be a conflict between "project name" and a "target name" > > set(PROJ_NAME Test01) > ,,, > file( GLOB ${PROJ_NAME}_SRC "*.h" "*.cpp" ) > Globbing for source is a bad practice (unless it is for generated files) which make it difficult to properly track dependencies. You may search the ML archive for discussion about that. > add_executable( ${PROJ_NAME} ${PROJ_NAME}_SRC) > ... > > error in add_executable(..) > what kind of error? Please give us more information like the exact error spitted out by cmake. -- Eric L'?lection n'est pas la d?mocratie -- http://www.le-message.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From iosif.neitzke+cmake at gmail.com Thu Jan 22 02:30:19 2015 From: iosif.neitzke+cmake at gmail.com (Iosif Neitzke) Date: Thu, 22 Jan 2015 01:30:19 -0600 Subject: [CMake] add_executable question In-Reply-To: References: Message-ID: set( PROJ_NAME Test01 ) file( GLOB ${PROJ_NAME}_SRC *.h *.cpp ) add_executable( ${PROJ_NAME} ${${PROJ_NAME}_SRC} ) On Thu, Jan 22, 2015 at 1:05 AM, Eric Noulard wrote: > > > 2015-01-22 3:41 GMT+01:00 Joshua Robinson : >> >> >> Greetings, >> >> Can I add a variable, was set before, to add_executable ? > > > I guess yes. However if "PROJ_NAME" value was used in > > project(Test01 C CXX) > > then there may be a conflict between "project name" and a "target name" >> >> >> set(PROJ_NAME Test01) >> ,,, >> file( GLOB ${PROJ_NAME}_SRC "*.h" "*.cpp" ) > > > Globbing for source is a bad practice (unless it is for generated files) > which make it difficult to properly track dependencies. > You may search the ML archive for discussion about that. > >> >> add_executable( ${PROJ_NAME} ${PROJ_NAME}_SRC) >> ... >> >> error in add_executable(..) > > > what kind of error? > Please give us more information like the exact error spitted out by cmake. > > > -- > Eric > L'?lection n'est pas la d?mocratie -- http://www.le-message.org > > -- > > 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 From dankolle at mail.de Thu Jan 22 06:00:07 2015 From: dankolle at mail.de (Daniel Kollmann) Date: Thu, 22 Jan 2015 12:00:07 +0100 Subject: [CMake] Visual Studio 2013 No CXX flags applied Message-ID: <003901d03632$96458eb0$c2d0ac10$@mail.de> Hello everybody, I have the big problem that my flags are not forwarded to VS. I am not sure why, I suspect that maybe it does not realise that the CXX flags are supposed to be used. Here is what my cache looks like: CMAKE_CXX_FLAGS:STRING= /DWIN32 /D_WINDOWS /W3 /GR /EHsc CMAKE_CXX_FLAGS_DEBUG:STRING=/D_DEBUG /MDd /Zi /Ob0 /Od /RTC1 /MTd When VS calls the compiler I get basically this output: cl /c /IC:\Depot\Source /IC:\Depot\include /W1 /WX- /O2 /D CONFIG_64 /D _ALLOW_KEYWORD_MACROS /D BOOST_ALL_NO_LIB /D BOOST_FILESYSTEM_NO_DEPRECATED /D "CMAKE_INTDIR=\"Debug\"" /D _MBCS /Gm- /MD /GS /fp:precise /Zc:wchar_t /Zc:forScope /Fo"Creator.dir\Debug\\" /Fd"Creator.dir\Debug\vc120.pdb" /Gd /TP /errorReport:prompt Main.cpp As you can see none of the flags are listed. Strangely enough the combination of the first few flags can also not be found anywhere in the cache file so I guess it is some project defaults VS put in place. Any suggestion why CMAKE_CXX_FLAGS would not be applied to VS builds? I am using Cmake 3.1.0 and VS2013. My cmake call looks like this: cmake.exe -H. -B"../../../../Intermediate/Creator" -G "Visual Studio 12 2013 Win64" -DWIN64=1 --trace Thanks Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.hoffman at kitware.com Thu Jan 22 09:20:08 2015 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Thu, 22 Jan 2015 09:20:08 -0500 Subject: [CMake] Visual Studio 2013 No CXX flags applied In-Reply-To: <003901d03632$96458eb0$c2d0ac10$@mail.de> References: <003901d03632$96458eb0$c2d0ac10$@mail.de> Message-ID: <54C10718.2010907@kitware.com> On 1/22/2015 6:00 AM, Daniel Kollmann wrote: > As you can see none of the flags are listed. Strangely enough the > combination of the first few flags can also not be found anywhere in the > cache file so I guess it is some project defaults VS put in place. > my guess is the project is clobbering the cache values with something like this: set(CMAKE_CXX_FLAGS ....) It would override the cache values. It should should up in your --trace output. -Bill From paul at mad-scientist.net Thu Jan 22 11:11:20 2015 From: paul at mad-scientist.net (Paul Smith) Date: Thu, 22 Jan 2015 11:11:20 -0500 Subject: [CMake] Are CMAKE_CXX_FLAGS supposed to go on the link line? In-Reply-To: <1420761121.3404.4.camel@mad-scientist.net> References: <1420761121.3404.4.camel@mad-scientist.net> Message-ID: <1421943080.5495.45.camel@mad-scientist.net> I didn't get a response to the question below. I've since reproduced this with a simple test case; maybe someone can let me know why this difference appears and how I should handle it? I'm using cmake 3.1.0: Sample CMakeLists.txt: $ cat >CMakeLists.txt < foo.cpp On MacOSX with Xcode installed, I see the following behavior: $ cmake -G Xcode . && cmake --build . 2>&1 | tee xc.out In the output I see that the "-pthread" flag DOES appear on the compile line for "foo.o", but DOES NOT appear in the link line for "foo": $ grep pthread xc.out /.../clang -x c++ ... -pthread ... -c /.../foo.cpp -o /.../foo.o This is correct for clang, which does not want -pthread on the link line (unlike GCC, which wants it in both places). Now, I clean that up and try with the Makefile generator, and I see the following behavior: $ cmake -G 'Unix Makefiles' . && cmake --build . -- VERBOSE=1 2>&1 | tee mk.out clang: warning: argument unused during compilation: '-pthread' Now in this case we can see that the -pthread flag was added to BOTH the compile and the link line: $ grep pthread mk.out /usr/bin/c++ -pthread -o .../foo.cpp.o -c .../foo.cpp /usr/bin/c++ -pthread .../foo.cpp.o -o foo clang: warning: argument unused during compilation: '-pthread' This warning is totally bogus: it really means "unused during LINKING", but anyway: I'm not sure what to do to get rid of this warning: I need to support both Xcode and Makefiles on MacOSX (and Makefiles on Linux as well as both GCC and Clang). Is the intent that CMAKE_CXX_FLAGS only ever appear on the compile line? Or should it appear on both the compile and link lines? Is there an equivalent flag to CMAKE_EXE_LINKER_FLAGS that always applies only to compile lines, in all generators? Do we just have to continue to bastardize add_definitions() for this, maybe? On Thu, 2015-01-08 at 18:52 -0500, Paul Smith wrote: > If I'm on OSX, then when I set CMAKE_CXX_FLAGS and do not set > CMAKE_EXE_LINKER_FLAGS, for example, and I use the Xcode generator, > then > I see: > * CMAKE_CXX_FLAGS show up on the compilation line > * CMAKE_CXX_FLAGS do NOT show up in the linker line > > On the other hand if I'm on OSX and I use the Unix Makefiles > generator, > then I see: > * CMAKE_CXX_FLAGS show up on the compilation line > * CMAKE_CXX_FLAGS ALSO show up in the linker line > > I assume the Xcode output is correct and the makefile output (with > CMAKE_CXX_FLAGS in both) is not correct... but there's nothing I can > find in the docs that says this explicitly. > > I've printed the contents of the CMAKE_CXX_FLAGS and > CMAKE_EXE_LINKER_FLAGS at the end of my CMakeLists.txt and they're > just > what I expect. It's just that the link line has extra flags, when > invoked from make. From dankolle at mail.de Thu Jan 22 13:04:38 2015 From: dankolle at mail.de (Daniel Kollmann) Date: Thu, 22 Jan 2015 19:04:38 +0100 Subject: [CMake] Visual Studio 2013 No CXX flags applied In-Reply-To: <54C10718.2010907@kitware.com> References: <003901d03632$96458eb0$c2d0ac10$@mail.de> <54C10718.2010907@kitware.com> Message-ID: <000601d0366d$e41aef50$ac50cdf0$@mail.de> I added a message before the executable is added. C:/Depot/Build/Cmake/CMakeLists.txt(45): message(QQQQQQQQ CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} ) QQQQQQQQCMAKE_CXX_FLAGS /DWIN32 /D_WINDOWS /W3 /GR /EHsc C:/Build/Cmake/CMakeLists.txt(46): message(QQQQQQQQ CMAKE_CXX_FLAGS_DEBUG ${CMAKE_CXX_FLAGS_DEBUG} ) QQQQQQQQCMAKE_CXX_FLAGS_DEBUG/D_DEBUG /MDd /Zi /Ob0 /Od /RTC1 /MTd C:/Build/Cmake/CMakeLists.txt(48): add_executable(Creator ${setup_source_files} ${pyconfigfile} ) That is basically the end of the log so I would not see how these flags are changed. Dan -----Urspr?ngliche Nachricht----- Von: CMake [mailto:cmake-bounces at cmake.org] Im Auftrag von Bill Hoffman Gesendet: Donnerstag, 22. Januar 2015 15:20 An: cmake at cmake.org Betreff: Re: [CMake] Visual Studio 2013 No CXX flags applied On 1/22/2015 6:00 AM, Daniel Kollmann wrote: > As you can see none of the flags are listed. Strangely enough the > combination of the first few flags can also not be found anywhere in > the cache file so I guess it is some project defaults VS put in place. > my guess is the project is clobbering the cache values with something like this: set(CMAKE_CXX_FLAGS ....) It would override the cache values. It should should up in your --trace output. -Bill -- 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 From remirampin at gmail.com Thu Jan 22 14:29:21 2015 From: remirampin at gmail.com (=?UTF-8?B?UsOpbWkgUmFtcGlu?=) Date: Thu, 22 Jan 2015 14:29:21 -0500 Subject: [CMake] Escaping/quoting special option keywords Message-ID: Hi everyone, I'm trying to figure out a way to escape the special keywords that are used to introduce named options in function arguments (see CMakeParseArguments [1]), for example to pass the string RESULT_VARIABLE as argument to a command executed via execute_process(): set(what "RESULT_VARIABLE") execute_process(COMMAND echo ${what}) Example result: CMake Error at CMakeLists.txt:2 (execute_process): execute_process called with no value for RESULT_VARIABLE. The documentation doesn't seem to mention anything, nor did I see a solution for this in CMakeParseArguments.cmake. Is there a way to do that, or do I have to just accept that some argument values will crash CMake? That would be a bummer. I'd appreciate any pointers, -- R?mi Rampin [1] http://www.cmake.org/cmake/help/v3.0/module/CMakeParseArguments.html From bill.hoffman at kitware.com Thu Jan 22 15:31:13 2015 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Thu, 22 Jan 2015 15:31:13 -0500 Subject: [CMake] Visual Studio 2013 No CXX flags applied In-Reply-To: <000601d0366d$e41aef50$ac50cdf0$@mail.de> References: <003901d03632$96458eb0$c2d0ac10$@mail.de> <54C10718.2010907@kitware.com> <000601d0366d$e41aef50$ac50cdf0$@mail.de> Message-ID: <54C15E11.7060401@kitware.com> On 1/22/2015 1:04 PM, Daniel Kollmann wrote: > I added a message before the executable is added. What happens when you grep your --trace output for CMAKE_CXX_FLAGS, do you ever see the flags being set as they look on the command line? -Bill From dankolle at mail.de Thu Jan 22 16:05:56 2015 From: dankolle at mail.de (Daniel Kollmann) Date: Thu, 22 Jan 2015 22:05:56 +0100 Subject: [CMake] Visual Studio 2013 No CXX flags applied In-Reply-To: <54C15E11.7060401@kitware.com> References: <003901d03632$96458eb0$c2d0ac10$@mail.de> <54C10718.2010907@kitware.com> <000601d0366d$e41aef50$ac50cdf0$@mail.de> <54C15E11.7060401@kitware.com> Message-ID: <001201d03687$3797e250$a6c7a6f0$@mail.de> Okay I found the problem. At the end I had the command: set_target_properties(MyTarget PROPERTIES LINKER_LANGUAGE C++) Which is wrong. I changed "C++" to "CXX" and then everything works as expected. Thanks again for the help. Dan -----Urspr?ngliche Nachricht----- Von: CMake [mailto:cmake-bounces at cmake.org] Im Auftrag von Bill Hoffman Gesendet: Donnerstag, 22. Januar 2015 21:31 An: cmake at cmake.org Betreff: Re: [CMake] Visual Studio 2013 No CXX flags applied On 1/22/2015 1:04 PM, Daniel Kollmann wrote: > I added a message before the executable is added. What happens when you grep your --trace output for CMAKE_CXX_FLAGS, do you ever see the flags being set as they look on the command line? -Bill -- 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 From dankolle at mail.de Thu Jan 22 16:52:14 2015 From: dankolle at mail.de (Daniel Kollmann) Date: Thu, 22 Jan 2015 22:52:14 +0100 Subject: [CMake] Set Xcode sources language to "Default" Message-ID: Hello, I have some files in Xcode that have mixed Objective-C and C++ code which is no problem if the files type is set to ?Default?. My problem is that Cmake sets it to ?C++ Source?. Here is how it should be, from another project: Here is how it is for files added by Cmake: Is there a way to tell Cmake to leave the files language property to ?Default?? Thanks Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0519BDC2-1C72-4D66-937C-17CFD01AC24A.png Type: image/png Size: 17256 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 01698D63-4E41-4339-8319-38DCD6FDAFF8.png Type: image/png Size: 18320 bytes Desc: not available URL: From robert.maynard at kitware.com Thu Jan 22 16:54:37 2015 From: robert.maynard at kitware.com (Robert Maynard) Date: Thu, 22 Jan 2015 16:54:37 -0500 Subject: [CMake] [ANNOUNCE] CMake 3.1.1 Released Message-ID: We are pleased to announce that CMake 3.1.1 is now available for download. Please use the latest release from our download page: http://www.cmake.org/download/ Thanks for your support! ------------------------------------------------------------------------- Changes in 3.1.1 since 3.1.0: Andr? Klitzing (1): Eclipse: Add org.eclipse.cdt.core.cnature to CXX projects (#15068) Ben Boeckel (4): get_test_property: clarify the documentation set_tests_properties: fix documentation tests: add tests for querying properties Xcode: Sort targets deterministically and with ALL_BUILD first (#15346) Brad King (14): bootstrap: Fix syntax for Solaris 10 shell (#15317) Help: Clarify MinGW v. MSYS Makefiles generators (#15319) Ninja: Do not crash when CMAKE__COMPILE_OBJECT is empty (#15325) Ninja: Generate rules only for languages compiled in a target (#15325) Tests: Test using objects from a language enabled in a subdirectory (#15325) Help: Add 3.1 release note about '#' escaping in Makefiles (#15322) Help: Clarify if() documentation (#15335) Help: Document CMAKE_FIND_PACKAGE_NAME variable Xcode: Do not require code signing for compiler id (#15214) Copyright.txt: Update year range to end in 2015 XL: Fix link flags for executables on Linux with XL compilers QNX: Fix detection of QCC compiler id (#15349) Xcode: Fix early termination on per-config source file error CMake 3.1.1 Calin Cascaval (1): CPack: Fix PackageMaker internal versioning for OS X 10.10 Chuck Atkins (1): Fix compilation with the Oracle / Sun compiler (#15318) Daniele E. Domenichelli (1): Help: Small fixes in CPackComponent documentation David Coppa (1): FindRuby: fix selection of version x.0 (#15345) Domen Vrankar (1): CPack: Avoid crash on invalid CMake generator name (#15308) Evangelos Foutras (1): FindRuby: Fix output check in _RUBY_CONFIG_VAR Gregor Jasny (1): find_package: Document CMAKE_FIND_PACKAGE_NAME variable Justin Borodinsky (1): QtAutoUic: Restore source file AUTOUIC_OPTIONS settings Mark Abraham (1): FindCUDA: Do not assume CMAKE_SYSTEM_PROCESSOR is set Peter Vasil (2): cmake-mode.el: Fix extracting keyword at point in cmake-help cmake-mode.el: Re-add explicit call to require thingatpt Rolf Eike Beer (5): FindIce: Port to work with CMP0054 NEW behavior FindSDL: Allow if() to dereference SDL_INCLUDE_DIR for matching FindQt: fix setting DESIRED_QT_VERSION if "find_package(Qt VVV)" was called FindQt: fix variable name in error message FindQt: explicitely mention that it cannot Qt5 or later Sergey Nikulov (1): FindBoost: Add latest Boost version 1.57.0 and next milestone 1.58.0 Simon Gomizelj (1): KWSys Terminal: Add xterm-termite to VT100 color support whitelist Stephen Kelly (7): Help: Document valid 14 value for CXX_STANDARD. (#15339) get_target_property: discern empty from undefined properties (#15333) QtAutoUic: Add a test for the regression in the parent commit. cmMakefile: Rename a method to what it really does. Features: Fix the COMPILE_FEATURES genex for unavailable features. cmTarget: Compute link language of TARGET_OBJECTS with CMP0026 OLD (#15338) Help: Link relevant documents for virtual override features (#15311) Tim Blechmann (1): Help: Add INTERFACE_LIBRARY to TYPE target property documentation William Lynch (1): Help: Update cmake.org links to avoid redirects From norulez at me.com Fri Jan 23 03:15:59 2015 From: norulez at me.com (NoRulez) Date: Fri, 23 Jan 2015 09:15:59 +0100 Subject: [CMake] CPack in CMake 3.1.0 doesn't install files In-Reply-To: <3D148401-325C-4F20-BD97-82C8EF3F216B@me.com> References: <52A2C443-8D57-4723-996E-CFBD9AAFC931@me.com> <3D148401-325C-4F20-BD97-82C8EF3F216B@me.com> Message-ID: <067991DF-9B20-4A01-B0DF-7E68D603B25B@me.com> Hi, i've tested it also with 3.1.1 and the failure behaves the same. Best Regards > Am 21.01.2015 um 10:00 schrieb NoRulez : > > Hi, > > it should also not work when you build a test project in release mode and then in the build directory type "cpack -G ZIP" for example. (Without the -C option) > > In the CTestScript is also added the -C option to ensure it uses the release mode, but it doesn't work either. > > When you then open the cmake_install.cmake files, you will see that the CMAKE_INSTALL_CONFIG_NAME variable is empty on line 15. > > In CMake 3.0.2 the variable is set with the value "Release". > > Best Regards > > >> Am 20.01.2015 um 18:40 schrieb Robert Maynard : >> >> Hi, >> >> I haven't seen this issue but if you have a self-contained and reduced >> (preferably plain CMake ) test case, I would be happy to run it and >> verify if this is a regression. >> >>> On Tue, Jan 20, 2015 at 2:37 AM, NoRulez wrote: >>> No one? >>> >>> Has something changed between 3.0.2 to 3.1.0 which prevents cpack to copy the generated *.exe file to the _CPack_Packages directory? Or did i need an additional variable to be set in 3.1.0? >>> >>> Thanks in advance >>> >>> Best Regards >>> >>> >>>> Am 16.01.2015 um 12:09 schrieb NoRulez : >>>> >>>> If I switch back to 3.0.2 everything is working like a charm >>>> >>>> Best Regards >>>> >>>>> Am 15.01.2015 um 17:49 schrieb NoRulez : >>>>> >>>>> Hello, >>>>> >>>>> we have only upgraded to the last release 3.1.0 from 3.0.2 and get the following when cpack is executed in a CTestScript: >>>>> >>>>> error: fixup_bundle: not a valid bundle >>>>> >>>>> The files are ceated, but they are not copied to the _CPack_Packages folder >>>>> >>>>> Then I found out that the variable "CMAKE_INSTALL_CONFIG_NAME" is empty in the cmake_install.cmake files >>>>> >>>>> Any hints? >>>>> >>>>> Best Regards >>>>> >>>>> -- >>>>> >>>>> Powered by www.kitware.com >>>>> >>>>> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ >>>>> >>>>> Kitware offers various services to support the CMake community. For more information on each offering, please visit: >>>>> >>>>> CMake Support: http://cmake.org/cmake/help/support.html >>>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>>>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>>>> >>>>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html >>>>> >>>>> Follow this link to subscribe/unsubscribe: >>>>> http://public.kitware.com/mailman/listinfo/cmake >>>> -- >>>> >>>> Powered by www.kitware.com >>>> >>>> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ >>>> >>>> Kitware offers various services to support the CMake community. For more information on each offering, please visit: >>>> >>>> CMake Support: http://cmake.org/cmake/help/support.html >>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>>> >>>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html >>>> >>>> Follow this link to subscribe/unsubscribe: >>>> http://public.kitware.com/mailman/listinfo/cmake >>> -- >>> >>> Powered by www.kitware.com >>> >>> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ >>> >>> Kitware offers various services to support the CMake community. For more information on each offering, please visit: >>> >>> CMake Support: http://cmake.org/cmake/help/support.html >>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>> >>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html >>> >>> Follow this link to subscribe/unsubscribe: >>> http://public.kitware.com/mailman/listinfo/cmake > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake From gerhard.gappmeier at ascolab.com Fri Jan 23 08:51:12 2015 From: gerhard.gappmeier at ascolab.com (Gerhard Gappmeier) Date: Fri, 23 Jan 2015 14:51:12 +0100 Subject: [CMake] E-Mail Notification of CDash is not working anymore Message-ID: <1749826.6TBhyAybWD@manjaro> Hi I'm actually not sure since when this is broken, but I'm pretty sure that it worked already. Actually I'm using CDash 2.2.3. When I configure the project susbcription to send emails on "when my checkins are causing problems in any sections of the dashboard " and notification in the user settings to "email checkins" I don't get any email when a new commit breaks the build. If I change "email checkins" to "all emails" then I get emails. So email sending works in general. However, most developers want to get emails only for the commits which they have broken, and not for all emails. The git commits contains correct author information with email, so that's not the problem. Any ideas what could be missing in the configuration? or is this maybe a known bug? -- mit freundlichen Gr??en / best regards Gerhard Gappmeier ascolab GmbH - automation systems communication laboratory Tel.: +49 9131 691 123 Fax: +49 9131 691 128 Web: http://www.ascolab.com GPG-KeyId: 5AAC50C4 GPG-Fingerprint: 967A 15F1 2788 164D CCA3 6C46 07CD 6F82 5AAC 50C4 -- ascolab GmbH Gesch?ftsf?hrer: Gerhard Gappmeier, Matthias Damm, Uwe Steinkrau? Sitz der Gesellschaft: Am Weichselgarten 7 ? 91058 Erlangen ? Germany Registernummer: HRB 9360 Registergericht: Amtsgericht F?rth -------------- next part -------------- An HTML attachment was scrubbed... URL: From julien.jomier at kitware.com Fri Jan 23 09:03:08 2015 From: julien.jomier at kitware.com (Julien Jomier) Date: Fri, 23 Jan 2015 15:03:08 +0100 Subject: [CMake] E-Mail Notification of CDash is not working anymore In-Reply-To: <1749826.6TBhyAybWD@manjaro> References: <1749826.6TBhyAybWD@manjaro> Message-ID: <54C2549C.2080209@kitware.com> Hi Gerhard, Can you check that the "Repository Credentials" associated with the user for a given project is matching the git commits information (email I suppose)? http:///manageProjectRoles.php?projectid= Julien On 23/01/2015 14:51, Gerhard Gappmeier wrote: > Hi > > I'm actually not sure since when this is broken, but I'm pretty sure > that it worked already. > > Actually I'm using CDash 2.2.3. > > When I configure the project susbcription to send emails on > > "when my checkins are causing problems in any sections of the dashboard " > > and notification in the user settings to "email checkins" I don't get > any email when a new commit breaks the build. > > If I change "email checkins" to "all emails" then I get emails. So email > sending works in general. > > However, most developers want to get emails only for the commits which > they have broken, and not for all emails. > > The git commits contains correct author information with email, so > that's not the problem. > > Any ideas what could be missing in the configuration? > > or is this maybe a known bug? > > -- > > mit freundlichen Gr??en / best regards > > Gerhard Gappmeier > > ascolab GmbH - automation systems communication laboratory > > Tel.: +49 9131 691 123 > > Fax: +49 9131 691 128 > > Web: http://www.ascolab.com > > GPG-KeyId: 5AAC50C4 > > GPG-Fingerprint: 967A 15F1 2788 164D CCA3 6C46 07CD 6F82 5AAC 50C4 > > -- > > ascolab GmbH > > Gesch?ftsf?hrer: Gerhard Gappmeier, Matthias Damm, Uwe Steinkrau? > > Sitz der Gesellschaft: Am Weichselgarten 7 ? 91058 Erlangen ? Germany > > Registernummer: HRB 9360 > > Registergericht: Amtsgericht F?rth > > > From wonder.mice at gmail.com Fri Jan 23 20:50:05 2015 From: wonder.mice at gmail.com (Andrey Pokrovskiy) Date: Fri, 23 Jan 2015 17:50:05 -0800 Subject: [CMake] add_jar OUTPUT_DIR contains intermediate files Message-ID: Hi, I noticed that when I explicitly specify OUTPUT_DIR for add_jar, like this: add_jar(demo SOURCES Main.java OUTPUT_DIR ${EXECUTABLE_OUTPUT_PATH}) All intermediate files for that target also go to specified output dir. So I end up with ./CMakeFiles/demo.dir directory in my ${EXECUTABLE_OUTPUT_PATH}. Is there any way to avoid that? From adam707blue at gmail.com Fri Jan 23 22:41:40 2015 From: adam707blue at gmail.com (Adam) Date: Sat, 24 Jan 2015 13:41:40 +1000 Subject: [CMake] whole archive linkage Message-ID: Hi All, I have a library that must be linked with -Wl,--whole-archive -lyourlib The library contains a static which registers itself in its constructor. This problem is described here http://stackoverflow.com/a/842770 Is there a target property I can set on this library so consumers of the library automatically get whole archive linkage when including this library. Regards, Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From d3ck0r at gmail.com Sat Jan 24 00:34:57 2015 From: d3ck0r at gmail.com (J Decker) Date: Fri, 23 Jan 2015 21:34:57 -0800 Subject: [CMake] whole archive linkage In-Reply-To: References: Message-ID: can just include it in the list of target_link_libraries() directive On Fri, Jan 23, 2015 at 7:41 PM, Adam wrote: > Hi All, > > I have a library that must be linked with -Wl,--whole-archive -lyourlib > > The library contains a static which registers itself in its constructor. > This problem is described here http://stackoverflow.com/a/842770 > > Is there a target property I can set on this library so consumers of the > library automatically get whole archive linkage when including this library. > > > Regards, > Adam > > > > -- > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From braden at endoframe.com Sat Jan 24 01:43:51 2015 From: braden at endoframe.com (Braden McDaniel) Date: Sat, 24 Jan 2015 01:43:51 -0500 Subject: [CMake] whole archive linkage In-Reply-To: References: Message-ID: <1422081831.6331.70.camel@endoframe.com> On Sat, 2015-01-24 at 13:41 +1000, Adam wrote: > The library contains a static which registers itself in its > constructor. This problem is described here > http://stackoverflow.com/a/842770 As something of an aside to your question, I don't know that I accept that as a sane use case. C++ doesn't guarantee that (in that example) m will be constructed before h. If m is not constructed first, construction of h calls operator[] on an uninitialized object. -- Braden McDaniel From dankolle at mail.de Sat Jan 24 06:25:25 2015 From: dankolle at mail.de (Daniel Kollmann) Date: Sat, 24 Jan 2015 12:25:25 +0100 Subject: [CMake] Xcode does not link against frameworks Message-ID: Hello, I add my required frameworks through this function of mine: function(add_framework target framework) if(APPLE) find_library(found ${framework}) if(${found} STREQUAL "${framework}-NOTFOUND?) message(FATAL_ERROR "ERROR: ${framework} not found (${CMAKE_OSX_SYSROOT})") endif() #message("Found framework ${found}") target_link_libraries(${target} ${found}) endif() endfunction() The framework is correctly found and added but still Xcode does neither list the frameworks as a build phase nor link against them. All symbols appear as missing. Maybe there is another step required to include the framework for Xcode. I am using Cmake 3.1.1 Thanks for the help Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam707blue at gmail.com Sat Jan 24 07:21:48 2015 From: adam707blue at gmail.com (Adam) Date: Sat, 24 Jan 2015 22:21:48 +1000 Subject: [CMake] whole archive linkage In-Reply-To: <1422081831.6331.70.camel@endoframe.com> References: <1422081831.6331.70.camel@endoframe.com> Message-ID: <1422102108.4199.5.camel@gmail.com> On Sat, 2015-01-24 at 01:43 -0500, Braden McDaniel wrote: > On Sat, 2015-01-24 at 13:41 +1000, Adam wrote: > > > The library contains a static which registers itself in its > > constructor. This problem is described here > > http://stackoverflow.com/a/842770 > > As something of an aside to your question, I don't know that I accept > that as a sane use case. C++ doesn't guarantee that (in that example) m > will be constructed before h. If m is not constructed first, > construction of h calls operator[] on an uninitialized object. > I agree. The actually legacy library I'm using has wrapped the global map 'm' inside a singleton which I believe resolves the static ordering issue. I currently have to specify something like the following for every application that wants to use this library target_link_libraries( Application -Wl,--whole-archive -llegacyLib -Wl,--no-whole-archive libA libB ) I was hoping there might have been a better way to do this with target properties of legacyLib. ~Adam From steveire at gmail.com Sat Jan 24 09:56:09 2015 From: steveire at gmail.com (Stephen Kelly) Date: Sat, 24 Jan 2015 15:56:09 +0100 Subject: [CMake] whole archive linkage References: <1422081831.6331.70.camel@endoframe.com> <1422102108.4199.5.camel@gmail.com> Message-ID: Adam wrote: > I was hoping there might have been a better way to do this with target > properties of legacyLib. > There is with cmake 3.1: set(isExe $,EXECUTABLE>) target_sources(legacyLib INTERFACE "$<${isExe}:${CMAKE_CURRENT_SOURCE_DIR}/use_symbol.cpp>") LegacyLib provides a simple source file which gets compiled into executables linking to it, and the source file invokes the singleton or whatever. This kind of use-case was the primary motivation for target_sources. http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/7082 Thanks, Steve. From ggarra13 at gmail.com Sat Jan 24 15:29:20 2015 From: ggarra13 at gmail.com (Gonzalo Garramuno) Date: Sat, 24 Jan 2015 17:29:20 -0300 Subject: [CMake] Setting environment variables on windows on install Message-ID: <54C400A0.4090803@gmail.com> I would like to set an environment variable in the NSIS installer, other than PATH during the install. Can someone show me how? From post at hendrik-sattler.de Sat Jan 24 16:36:56 2015 From: post at hendrik-sattler.de (Hendrik Sattler) Date: Sat, 24 Jan 2015 22:36:56 +0100 Subject: [CMake] Setting environment variables on windows on install In-Reply-To: <54C400A0.4090803@gmail.com> References: <54C400A0.4090803@gmail.com> Message-ID: <013FFC08-8A52-4FAC-A73A-F91FFFE41F46@hendrik-sattler.de> Hi, setting global environment variables in windows is just adding/editing some registry keys. As an alternative, you can run setx command in a cmd.exe instance. HS Am 24. Januar 2015 21:29:20 MEZ, schrieb Gonzalo Garramuno : >I would like to set an environment variable in the NSIS installer, >other >than PATH during the install. Can someone show me how? From zalmstra.bas at gmail.com Sat Jan 24 16:41:41 2015 From: zalmstra.bas at gmail.com (baszalmstra) Date: Sat, 24 Jan 2015 14:41:41 -0700 (MST) Subject: [CMake] Is anyone working on a FASTBuild Generator? In-Reply-To: References: Message-ID: <1422135701920-7589570.post@n2.nabble.com> Anybody has more news on this? FASTBuild looks absolutly amazing! -- View this message in context: http://cmake.3232098.n2.nabble.com/Is-anyone-working-on-a-FASTBuild-Generator-tp7588853p7589570.html Sent from the CMake mailing list archive at Nabble.com. From rcdailey.lists at gmail.com Sat Jan 24 18:43:59 2015 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Sat, 24 Jan 2015 17:43:59 -0600 Subject: [CMake] Specify 32-bit compilation to Clang In-Reply-To: <54BD5F9B.7010106@googlemail.com> References: <54BD5F9B.7010106@googlemail.com> Message-ID: Where are these variables documented? I haven't seen them anywhere. Also is this required? I'd rather the CMake script itself specify that 32-bit compilation is needed, since the code itself does not compile properly in 64-bit environment. On Mon, Jan 19, 2015 at 1:48 PM, Gregor Jasny wrote: > Hello Robert, > > On 19/01/15 20:42, Robert Dailey wrote: >> I'm running CMake 3.1 on Mint 64-bit OS. I need to generate an Eclipse >> project using Ninja that uses Clang to build a 32-bit application. >> >> When I do this: >> >> add_definitions("-m32") >> >> For some reason my code is not able to include STL headers (files not >> found). Any reason for this? Is there a more proper way to specify >> 32-bit compilation so STL include paths are set? > > You could try setting this two variables at configure time: > -DCMAKE_C_COMPILER_ARG1=-m32 -DCMAKE_CXX_COMPILER_ARG1=-m32 > > Hope this helps, > Gregpor From norbert.pfeiler+cmake at gmail.com Sat Jan 24 19:17:18 2015 From: norbert.pfeiler+cmake at gmail.com (Norbert Pfeiler) Date: Sun, 25 Jan 2015 01:17:18 +0100 Subject: [CMake] automoc autorcc Message-ID: Hello, i?m curious about 2 things and therefore wanted to ask: When i use qt5_add_resources and some of my resources change they get recompiled during the next invocation of my build tool. Whereas when i use cmakes autorcc this is not the case. Secondly, with qt5_wrap_cpp every file gets processed in parallel ? well, because they don?t depend on each other. In contrast, automoc mocs everything in sequence (for one target) which is a noticeable bottleneck on an 8 core machine. As i?ve found, the reasoning for the automoc case seems to be, that unconstrained parallelization will flood the machine and setting up logic to constrain that is not the goal. Shouldn?t cmake just generate independent build targets and let the build system handle the parallelization? I couldn?t find anything about the autorcc case though. automoc and autorcc are supposed to replace their corresponding macros and potentially be better than them. Is there something i?m missing? Regards, Norbert Pfeiler. -------------- next part -------------- An HTML attachment was scrubbed... URL: From j.fisher at digipen.edu Sat Jan 24 21:46:27 2015 From: j.fisher at digipen.edu (Joshua T. Fisher) Date: Sat, 24 Jan 2015 18:46:27 -0800 Subject: [CMake] Is anyone working on a FASTBuild Generator? In-Reply-To: <1422135701920-7589570.post@n2.nabble.com> References: <1422135701920-7589570.post@n2.nabble.com> Message-ID: You can contact the guy behind FASTBuild to let him know you're interested right here: fastbuild at fastbuild.org I know he knows there's interest but right now I don't really know how to get people who are actually familiar with CMake's generator code to be interested or link to documentation for those of us who want to look into writing it ourselves. And to be honest I'm not sure if that exists. Most of the generators were probably written by folks who just sat down and studied the code. On Sat, Jan 24, 2015 at 1:41 PM, baszalmstra wrote: > Anybody has more news on this? FASTBuild looks absolutly amazing! > > > > -- > View this message in context: > http://cmake.3232098.n2.nabble.com/Is-anyone-working-on-a-FASTBuild-Generator-tp7588853p7589570.html > Sent from the CMake mailing list archive at Nabble.com. > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dankolle at mail.de Sun Jan 25 07:43:13 2015 From: dankolle at mail.de (Daniel Kollmann) Date: Sun, 25 Jan 2015 13:43:13 +0100 Subject: [CMake] Xcode does not link against frameworks In-Reply-To: References: Message-ID: I took a closer look at the problem and while as I said the libraries are correctly found, when I look at the project file, I see this: OTHER_LDFLAGS = " -Wl,-search_paths_first -Wl,-headerpad_max_install_names -framework Accelerate -framework Accelerate -framework Accelerate -framework Accelerate -framework Accelerate -framework Accelerate -framework Accelerate -framework Accelerate -framework Accelerate -framework Accelerate -framework Accelerate -framework Accelerate -framework Accelerate -framework Accelerate My calls to the function look like this: add_framework(${target} Accelerate) add_framework(${target} AudioToolbox) add_framework(${target} Carbon) add_framework(${target} Cocoa) add_framework(${target} CoreAudio) add_framework(${target} CoreFoundation) add_framework(${target} CoreMIDI) add_framework(${target} DiscRecording) add_framework(${target} IOKit) add_framework(${target} OpenGL) add_framework(${target} QTKit) add_framework(${target} QuartzCore) add_framework(${target} QuickTime) add_framework(${target} WebKit) Shouldn?t ${found} be locally inside the function and is it not safe to call target_link_libraries several times? Thanks for any advice Dan Von: Daniel Kollmann Datum: Samstag, 24. Januar 2015 12:25 An: "cmake at cmake.org" Betreff: Xcode does not link against frameworks Hello, I add my required frameworks through this function of mine: function(add_framework target framework) if(APPLE) find_library(found ${framework}) if(${found} STREQUAL "${framework}-NOTFOUND?) message(FATAL_ERROR "ERROR: ${framework} not found (${CMAKE_OSX_SYSROOT})") endif() #message("Found framework ${found}") target_link_libraries(${target} ${found}) endif() endfunction() The framework is correctly found and added but still Xcode does neither list the frameworks as a build phase nor link against them. All symbols appear as missing. Maybe there is another step required to include the framework for Xcode. I am using Cmake 3.1.1 Thanks for the help Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcdailey.lists at gmail.com Sun Jan 25 17:24:20 2015 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Sun, 25 Jan 2015 16:24:20 -0600 Subject: [CMake] Eclipse build project does nothing Message-ID: I'm generating for Eclipse CDT4 - Ninja. When a build fails because of compiler errors or whatnot, "Build project" does absolutely nothing unless I change a CPP file and save it, then the build works. Is this a CMake issue or Eclipse setting? Help is appreciated. From rcdailey.lists at gmail.com Mon Jan 26 00:30:49 2015 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Sun, 25 Jan 2015 23:30:49 -0600 Subject: [CMake] CTest + Catch Framework Message-ID: Hi, I'm using Catch as my unit test framework: https://github.com/philsquared/Catch Is it possible for CTest to report each TEST_CASE block as an individual test? My understanding is that CTest will only treat each executable as a test. However, my test structure is as follows: 1 library 1 test project Each test project has 1 test CPP file per each class in the library. This way I implement tests for classes in a corresponding CPP file. Each CPP file contains multiple test cases (defined by TEST_CASE macro). The resulting output of `ctest -T Test` shows only 1 test, even though that may be around 50 test cases. I'd like CMake to show the pass/fail status of each one. Is this possible? From jamil.appa at zenotech.com Mon Jan 26 10:17:28 2015 From: jamil.appa at zenotech.com (Jamil Appa) Date: Mon, 26 Jan 2015 15:17:28 +0000 Subject: [CMake] cmake 3.1- ubuntu 14.10 - IBM Power 8 - xl Message-ID: Hi I am trying to use the IBM xl compilers with cmake 3.1 on a little endian Power 8 The find_library function fails as the architecture is not recognised. If I manually set the architecture using -DCMAKE_LIBRARY_ARCHITECTURE=powerpc64le-linux-gnu cmake works correctly. The IBM xl compiler is identified as Clang 3.4.2 as it uses the clang front end. I happy to provide a patch if this has not been fixed yet but I will need some guidance on which files need fixing. Thanks Jamil -- Jamil Appa | Co-Founder and Director | Zenotech +447747606788 | [image: View Jamil Appa's LinkedIn profile] jamil.appa at zenotech.com[image: Zenotech] Zenotech Ltd | Bristol & Bath Science Park | Emmersons Green | Bristol | BS16 7FR ------------------------------ Registered Address: 1 Larkfield Grove | Chepstow | Monmouthshire | NP16 5UF | UK Registered in England & Wales No: 7926926 VAT No: 128198591 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.j.abraham at gmail.com Mon Jan 26 10:56:26 2015 From: mark.j.abraham at gmail.com (Mark Abraham) Date: Mon, 26 Jan 2015 16:56:26 +0100 Subject: [CMake] cmake 3.1- ubuntu 14.10 - IBM Power 8 - xl In-Reply-To: References: Message-ID: Hi, I would start by playing with Modules/CMake*CompilerId* and if needed Modules/CMakeDetermine*Compiler.cmake in master branch of the CMake git repo. Presumably part of the problem is that the check for __clang__ is very early. You would need to take care that the older XL compilers still work in the intended way. I may be able to help with testing some things - just not sure I have access to a Power8 with recent XL. Cheers, Mark On Mon, Jan 26, 2015 at 4:17 PM, Jamil Appa wrote: > Hi > > I am trying to use the IBM xl compilers with cmake 3.1 on a little > endian Power 8 > > The find_library function fails as the architecture is not > recognised. If I manually set the architecture > using -DCMAKE_LIBRARY_ARCHITECTURE=powerpc64le-linux-gnu cmake works > correctly. > > The IBM xl compiler is identified as Clang 3.4.2 as it uses the clang > front end. > > I happy to provide a patch if this has not been fixed yet but I will > need some guidance on which files need fixing. > > Thanks > > Jamil > > -- > Jamil Appa | Co-Founder and Director | Zenotech > +447747606788 | [image: View Jamil Appa's LinkedIn profile] > > jamil.appa at zenotech.com[image: Zenotech] Zenotech > Ltd | Bristol & Bath Science Park | Emmersons Green | Bristol | BS16 7FR > ------------------------------ > Registered Address: 1 Larkfield Grove | Chepstow | Monmouthshire | NP16 > 5UF | UK > Registered in England & Wales No: 7926926 VAT No: 128198591 > > -- > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From DLRdave at aol.com Mon Jan 26 11:05:48 2015 From: DLRdave at aol.com (David Cole) Date: Mon, 26 Jan 2015 11:05:48 -0500 Subject: [CMake] CTest + Catch Framework In-Reply-To: References: Message-ID: Can you run a command that executes one test case at a time, or do you have to run all 50 when you execute the tests for a library? ctest just runs whatever you give it with add_test -- if you want to filter a collection of unit tests to run only a single unit test, then the unit test framework you're using would have to support that. Does Catch allow you to run the tests individually? On Mon, Jan 26, 2015 at 12:30 AM, Robert Dailey wrote: > Hi, > > I'm using Catch as my unit test framework: > https://github.com/philsquared/Catch > > Is it possible for CTest to report each TEST_CASE block as an > individual test? My understanding is that CTest will only treat each > executable as a test. However, my test structure is as follows: > > 1 library > 1 test project > > Each test project has 1 test CPP file per each class in the library. > This way I implement tests for classes in a corresponding CPP file. > > Each CPP file contains multiple test cases (defined by TEST_CASE macro). > > The resulting output of `ctest -T Test` shows only 1 test, even though > that may be around 50 test cases. I'd like CMake to show the pass/fail > status of each one. Is this possible? > -- > > 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 From brad.king at kitware.com Mon Jan 26 11:46:45 2015 From: brad.king at kitware.com (Brad King) Date: Mon, 26 Jan 2015 11:46:45 -0500 Subject: [CMake] cmake 3.1- ubuntu 14.10 - IBM Power 8 - xl In-Reply-To: References: Message-ID: <54C66F75.7050007@kitware.com> On 01/26/2015 10:56 AM, Mark Abraham wrote: >> The IBM xl compiler is identified as Clang 3.4.2 as it uses the clang front end. > I would start by playing with > > Modules/CMake*CompilerId* > > in master branch of the CMake git repo. Presumably part of the > problem is that the check for __clang__ is very early. You would > need to take care that the older XL compilers still work in the > intended way. Yes. > On Mon, Jan 26, 2015 at 4:17 PM, Jamil Appa wrote: >> The find_library function fails as the architecture is not recognised. >> If I manually set the architecture using >> -DCMAKE_LIBRARY_ARCHITECTURE=powerpc64le-linux-gnu cmake works correctly. Look at definition and use of CMAKE_LIBRARY_ARCHITECTURE_REGEX in the Modules directory. Modules/CMakeDetermineCompilerABI.cmake uses it to extract the library architecture from the list of implicit linker search paths used by the front-end. This may be detected better when the proper compiler id is found as above. Thanks, -Brad From parag at ionicsecurity.com Mon Jan 26 13:12:02 2015 From: parag at ionicsecurity.com (Parag Chandra) Date: Mon, 26 Jan 2015 18:12:02 +0000 Subject: [CMake] Xcode does not link against frameworks Message-ID: Hi Daniel, I've just been using: target_link_libraries (TargetName "-framework IOKit") Which has been working perfectly for me. Then again, I am only trying to add frameworks that are part of the OS. I haven't yet tried building my own frameworks and linking those in. Parag Chandra Software Engineer, Mobile Team Mobile: +1.919.824.1410 [https://www.ionicsecurity.com/IonicSigHz.png] Ionic Security Inc. 1170 Peachtree St. NE STE 400, Atlanta, GA 30309 From: Daniel Kollmann > Date: Sunday, January 25, 2015 at 7:43 AM To: "cmake at cmake.org" > Subject: Re: [CMake] Xcode does not link against frameworks I took a closer look at the problem and while as I said the libraries are correctly found, when I look at the project file, I see this: OTHER_LDFLAGS = " -Wl,-search_paths_first -Wl,-headerpad_max_install_names -framework Accelerate -framework Accelerate -framework Accelerate -framework Accelerate -framework Accelerate -framework Accelerate -framework Accelerate -framework Accelerate -framework Accelerate -framework Accelerate -framework Accelerate -framework Accelerate -framework Accelerate -framework Accelerate My calls to the function look like this: add_framework(${target} Accelerate) add_framework(${target} AudioToolbox) add_framework(${target} Carbon) add_framework(${target} Cocoa) add_framework(${target} CoreAudio) add_framework(${target} CoreFoundation) add_framework(${target} CoreMIDI) add_framework(${target} DiscRecording) add_framework(${target} IOKit) add_framework(${target} OpenGL) add_framework(${target} QTKit) add_framework(${target} QuartzCore) add_framework(${target} QuickTime) add_framework(${target} WebKit) Shouldn't ${found} be locally inside the function and is it not safe to call target_link_libraries several times? Thanks for any advice Dan Von: Daniel Kollmann > Datum: Samstag, 24. Januar 2015 12:25 An: "cmake at cmake.org" > Betreff: Xcode does not link against frameworks Hello, I add my required frameworks through this function of mine: function(add_framework target framework) if(APPLE) find_library(found ${framework}) if(${found} STREQUAL "${framework}-NOTFOUND") message(FATAL_ERROR "ERROR: ${framework} not found (${CMAKE_OSX_SYSROOT})") endif() #message("Found framework ${found}") target_link_libraries(${target} ${found}) endif() endfunction() The framework is correctly found and added but still Xcode does neither list the frameworks as a build phase nor link against them. All symbols appear as missing. Maybe there is another step required to include the framework for Xcode. I am using Cmake 3.1.1 Thanks for the help Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcdailey.lists at gmail.com Mon Jan 26 16:05:30 2015 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Mon, 26 Jan 2015 15:05:30 -0600 Subject: [CMake] CTest + Catch Framework In-Reply-To: References: Message-ID: I believe so, but then you run into the chicken and egg problem: I need to fully build all unit tests in order to know all the test cases, but I need to define the tests at the generation phase (before build). I'm just not sure how to handle this. The best i can think of is to generate 1 test executable per CPP file that we write in our unit tests (generally 1 CPP file per class that is unit tested). Any ideas? On Mon, Jan 26, 2015 at 10:05 AM, David Cole wrote: > Can you run a command that executes one test case at a time, or do you > have to run all 50 when you execute the tests for a library? > > ctest just runs whatever you give it with add_test -- if you want to > filter a collection of unit tests to run only a single unit test, then > the unit test framework you're using would have to support that. Does > Catch allow you to run the tests individually? > > > > On Mon, Jan 26, 2015 at 12:30 AM, Robert Dailey > wrote: >> Hi, >> >> I'm using Catch as my unit test framework: >> https://github.com/philsquared/Catch >> >> Is it possible for CTest to report each TEST_CASE block as an >> individual test? My understanding is that CTest will only treat each >> executable as a test. However, my test structure is as follows: >> >> 1 library >> 1 test project >> >> Each test project has 1 test CPP file per each class in the library. >> This way I implement tests for classes in a corresponding CPP file. >> >> Each CPP file contains multiple test cases (defined by TEST_CASE macro). >> >> The resulting output of `ctest -T Test` shows only 1 test, even though >> that may be around 50 test cases. I'd like CMake to show the pass/fail >> status of each one. Is this possible? >> -- >> >> 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 From DLRdave at aol.com Tue Jan 27 08:18:32 2015 From: DLRdave at aol.com (David Cole) Date: Tue, 27 Jan 2015 08:18:32 -0500 Subject: [CMake] CTest + Catch Framework In-Reply-To: References: Message-ID: It's only a chicken and egg problem if you constrain yourself artificially. When you define a new unit test source file, there are two things you need to do: (1) add it to its executable (2) write an add_test line that invokes that specific unit test You could possibly encapsulate those actions into an add_unit_test macro so that it only seems like you have one thing to do, but certainly, it's possible. You must be doing #1 already, so you just have to make sure #2 always happens whenever #1 happens. Both eggs. D On Mon, Jan 26, 2015 at 4:05 PM, Robert Dailey wrote: > I believe so, but then you run into the chicken and egg problem: > > I need to fully build all unit tests in order to know all the test > cases, but I need to define the tests at the generation phase (before > build). > > I'm just not sure how to handle this. The best i can think of is to > generate 1 test executable per CPP file that we write in our unit > tests (generally 1 CPP file per class that is unit tested). Any ideas? > > On Mon, Jan 26, 2015 at 10:05 AM, David Cole wrote: >> Can you run a command that executes one test case at a time, or do you >> have to run all 50 when you execute the tests for a library? >> >> ctest just runs whatever you give it with add_test -- if you want to >> filter a collection of unit tests to run only a single unit test, then >> the unit test framework you're using would have to support that. Does >> Catch allow you to run the tests individually? >> >> >> >> On Mon, Jan 26, 2015 at 12:30 AM, Robert Dailey >> wrote: >>> Hi, >>> >>> I'm using Catch as my unit test framework: >>> https://github.com/philsquared/Catch >>> >>> Is it possible for CTest to report each TEST_CASE block as an >>> individual test? My understanding is that CTest will only treat each >>> executable as a test. However, my test structure is as follows: >>> >>> 1 library >>> 1 test project >>> >>> Each test project has 1 test CPP file per each class in the library. >>> This way I implement tests for classes in a corresponding CPP file. >>> >>> Each CPP file contains multiple test cases (defined by TEST_CASE macro). >>> >>> The resulting output of `ctest -T Test` shows only 1 test, even though >>> that may be around 50 test cases. I'd like CMake to show the pass/fail >>> status of each one. Is this possible? >>> -- >>> >>> 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 From blowekamp at mail.nih.gov Tue Jan 27 09:49:21 2015 From: blowekamp at mail.nih.gov (Bradley Lowekamp) Date: Tue, 27 Jan 2015 09:49:21 -0500 Subject: [CMake] CTest + Catch Framework In-Reply-To: References: Message-ID: <76E11ADE-5CAC-4B22-AA2B-3C83124962C0@mail.nih.gov> Hello, This looks a little like google test. For a project I just created a CMake macro which grepped through the test files for the test cases and adds them one by one. Certainly features could be added to better support text fixtures. Hope this gives you some inspiration: https://github.com/SimpleITK/SimpleITK/blob/7aeb952d25c0142e66087edce89e708db2d59a1a/Testing/Unit/CMakeLists.txt#L270-L310 Brad On Jan 27, 2015, at 8:18 AM, David Cole via CMake wrote: > It's only a chicken and egg problem if you constrain yourself artificially. > > When you define a new unit test source file, there are two things you > need to do: > (1) add it to its executable > (2) write an add_test line that invokes that specific unit test > > You could possibly encapsulate those actions into an add_unit_test > macro so that it only seems like you have one thing to do, but > certainly, it's possible. > > You must be doing #1 already, so you just have to make sure #2 always > happens whenever #1 happens. > > Both eggs. > > > D > > > > > On Mon, Jan 26, 2015 at 4:05 PM, Robert Dailey wrote: >> I believe so, but then you run into the chicken and egg problem: >> >> I need to fully build all unit tests in order to know all the test >> cases, but I need to define the tests at the generation phase (before >> build). >> >> I'm just not sure how to handle this. The best i can think of is to >> generate 1 test executable per CPP file that we write in our unit >> tests (generally 1 CPP file per class that is unit tested). Any ideas? >> >> On Mon, Jan 26, 2015 at 10:05 AM, David Cole wrote: >>> Can you run a command that executes one test case at a time, or do you >>> have to run all 50 when you execute the tests for a library? >>> >>> ctest just runs whatever you give it with add_test -- if you want to >>> filter a collection of unit tests to run only a single unit test, then >>> the unit test framework you're using would have to support that. Does >>> Catch allow you to run the tests individually? >>> >>> >>> >>> On Mon, Jan 26, 2015 at 12:30 AM, Robert Dailey >>> wrote: >>>> Hi, >>>> >>>> I'm using Catch as my unit test framework: >>>> https://github.com/philsquared/Catch >>>> >>>> Is it possible for CTest to report each TEST_CASE block as an >>>> individual test? My understanding is that CTest will only treat each >>>> executable as a test. However, my test structure is as follows: >>>> >>>> 1 library >>>> 1 test project >>>> >>>> Each test project has 1 test CPP file per each class in the library. >>>> This way I implement tests for classes in a corresponding CPP file. >>>> >>>> Each CPP file contains multiple test cases (defined by TEST_CASE macro). >>>> >>>> The resulting output of `ctest -T Test` shows only 1 test, even though >>>> that may be around 50 test cases. I'd like CMake to show the pass/fail >>>> status of each one. Is this possible? >>>> -- >>>> >>>> Powered by www.kitware.com >>>> >>>> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ >>>> >>>> Kitware offers various services to support the CMake community. For more information on each offering, please visit: >>>> >>>> CMake Support: http://cmake.org/cmake/help/support.html >>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>>> >>>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html >>>> >>>> Follow this link to subscribe/unsubscribe: >>>> http://public.kitware.com/mailman/listinfo/cmake > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake From rcdailey.lists at gmail.com Tue Jan 27 11:18:48 2015 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Tue, 27 Jan 2015 10:18:48 -0600 Subject: [CMake] CTest + Catch Framework In-Reply-To: References: Message-ID: I wouldn't say this is an artificial problem. let me go into more detail. A single test can define any number of test cases. These are unknown to CMake scripts, as they are written and defined in code. The ideal solution is to have the test program output a list of all test cases and based on that list, automatically generate the add_test commands. That way I don't have to worry about hard-coding test case names in the build scripts. When a new test case is added to the test code (no new files would be added), "magically" a new unit test appears to CMake. But none of this can be done unless the unit test executables are built. Thus the chicken and egg problem. To do it as you suggest would require me to hard-code the test cases. Example: In MyTest.cpp: #include TEST_CASE("test1") {} TEST_CASE("test2") {} In CMakeLists.txt: add_executable( MyTest MyTest.cpp ) add_test( NAME MyTest_test1 COMMAND test1 ) add_test( NAME MyTest_test2 COMMAND test2 ) Am I correctly understanding what you have in mind? If so, can you think of a way to automate this a little better? On Tue, Jan 27, 2015 at 7:18 AM, David Cole wrote: > It's only a chicken and egg problem if you constrain yourself artificially. > > When you define a new unit test source file, there are two things you > need to do: > (1) add it to its executable > (2) write an add_test line that invokes that specific unit test > > You could possibly encapsulate those actions into an add_unit_test > macro so that it only seems like you have one thing to do, but > certainly, it's possible. > > You must be doing #1 already, so you just have to make sure #2 always > happens whenever #1 happens. > > Both eggs. > > > D > > > > > On Mon, Jan 26, 2015 at 4:05 PM, Robert Dailey wrote: >> I believe so, but then you run into the chicken and egg problem: >> >> I need to fully build all unit tests in order to know all the test >> cases, but I need to define the tests at the generation phase (before >> build). >> >> I'm just not sure how to handle this. The best i can think of is to >> generate 1 test executable per CPP file that we write in our unit >> tests (generally 1 CPP file per class that is unit tested). Any ideas? >> >> On Mon, Jan 26, 2015 at 10:05 AM, David Cole wrote: >>> Can you run a command that executes one test case at a time, or do you >>> have to run all 50 when you execute the tests for a library? >>> >>> ctest just runs whatever you give it with add_test -- if you want to >>> filter a collection of unit tests to run only a single unit test, then >>> the unit test framework you're using would have to support that. Does >>> Catch allow you to run the tests individually? >>> >>> >>> >>> On Mon, Jan 26, 2015 at 12:30 AM, Robert Dailey >>> wrote: >>>> Hi, >>>> >>>> I'm using Catch as my unit test framework: >>>> https://github.com/philsquared/Catch >>>> >>>> Is it possible for CTest to report each TEST_CASE block as an >>>> individual test? My understanding is that CTest will only treat each >>>> executable as a test. However, my test structure is as follows: >>>> >>>> 1 library >>>> 1 test project >>>> >>>> Each test project has 1 test CPP file per each class in the library. >>>> This way I implement tests for classes in a corresponding CPP file. >>>> >>>> Each CPP file contains multiple test cases (defined by TEST_CASE macro). >>>> >>>> The resulting output of `ctest -T Test` shows only 1 test, even though >>>> that may be around 50 test cases. I'd like CMake to show the pass/fail >>>> status of each one. Is this possible? >>>> -- >>>> >>>> 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 From rob.harris at gmail.com Tue Jan 27 11:33:45 2015 From: rob.harris at gmail.com (Rob Harris) Date: Tue, 27 Jan 2015 11:33:45 -0500 Subject: [CMake] Setting CPACK_PACKAGE_FILE_NAME per COMPONENT Message-ID: <54C7BDE9.2020906@gmail.com> All, I'm trying to have CPack create filenames in the debian-conformant format using my component definitions. It looks like there was an issue in place to resolve this (0012997) by exposing a CPACK_COMPONENT_NAME variable, but it doesn't look like it was ever resolved/committed. Is there another way to solve this problem? R'ing TFM and Googling proved fruitless. Thanks. -Rob Harris From DLRdave at aol.com Tue Jan 27 12:14:33 2015 From: DLRdave at aol.com (David Cole) Date: Tue, 27 Jan 2015 12:14:33 -0500 Subject: [CMake] CTest + Catch Framework In-Reply-To: References: Message-ID: The best thing to do would be to make CTest aware of unit test frameworks like this, and have it be automatic. Support for cppunit, gtest and Catch (and any other popular ones) would all be appreciated by many, I'm sure. Got time to dig into ctest a little bit? D On Tue, Jan 27, 2015 at 11:18 AM, Robert Dailey wrote: > I wouldn't say this is an artificial problem. let me go into more detail. > > A single test can define any number of test cases. These are unknown > to CMake scripts, as they are written and defined in code. The ideal > solution is to have the test program output a list of all test cases > and based on that list, automatically generate the add_test commands. > That way I don't have to worry about hard-coding test case names in > the build scripts. When a new test case is added to the test code (no > new files would be added), "magically" a new unit test appears to > CMake. > > But none of this can be done unless the unit test executables are > built. Thus the chicken and egg problem. To do it as you suggest would > require me to hard-code the test cases. Example: > > In MyTest.cpp: > > #include > TEST_CASE("test1") {} > TEST_CASE("test2") {} > > In CMakeLists.txt: > > add_executable( MyTest MyTest.cpp ) > add_test( NAME MyTest_test1 COMMAND test1 ) > add_test( NAME MyTest_test2 COMMAND test2 ) > > Am I correctly understanding what you have in mind? If so, can you > think of a way to automate this a little better? > > On Tue, Jan 27, 2015 at 7:18 AM, David Cole wrote: >> It's only a chicken and egg problem if you constrain yourself artificially. >> >> When you define a new unit test source file, there are two things you >> need to do: >> (1) add it to its executable >> (2) write an add_test line that invokes that specific unit test >> >> You could possibly encapsulate those actions into an add_unit_test >> macro so that it only seems like you have one thing to do, but >> certainly, it's possible. >> >> You must be doing #1 already, so you just have to make sure #2 always >> happens whenever #1 happens. >> >> Both eggs. >> >> >> D >> >> >> >> >> On Mon, Jan 26, 2015 at 4:05 PM, Robert Dailey wrote: >>> I believe so, but then you run into the chicken and egg problem: >>> >>> I need to fully build all unit tests in order to know all the test >>> cases, but I need to define the tests at the generation phase (before >>> build). >>> >>> I'm just not sure how to handle this. The best i can think of is to >>> generate 1 test executable per CPP file that we write in our unit >>> tests (generally 1 CPP file per class that is unit tested). Any ideas? >>> >>> On Mon, Jan 26, 2015 at 10:05 AM, David Cole wrote: >>>> Can you run a command that executes one test case at a time, or do you >>>> have to run all 50 when you execute the tests for a library? >>>> >>>> ctest just runs whatever you give it with add_test -- if you want to >>>> filter a collection of unit tests to run only a single unit test, then >>>> the unit test framework you're using would have to support that. Does >>>> Catch allow you to run the tests individually? >>>> >>>> >>>> >>>> On Mon, Jan 26, 2015 at 12:30 AM, Robert Dailey >>>> wrote: >>>>> Hi, >>>>> >>>>> I'm using Catch as my unit test framework: >>>>> https://github.com/philsquared/Catch >>>>> >>>>> Is it possible for CTest to report each TEST_CASE block as an >>>>> individual test? My understanding is that CTest will only treat each >>>>> executable as a test. However, my test structure is as follows: >>>>> >>>>> 1 library >>>>> 1 test project >>>>> >>>>> Each test project has 1 test CPP file per each class in the library. >>>>> This way I implement tests for classes in a corresponding CPP file. >>>>> >>>>> Each CPP file contains multiple test cases (defined by TEST_CASE macro). >>>>> >>>>> The resulting output of `ctest -T Test` shows only 1 test, even though >>>>> that may be around 50 test cases. I'd like CMake to show the pass/fail >>>>> status of each one. Is this possible? >>>>> -- >>>>> >>>>> 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 From fraser.hutchison at gmail.com Tue Jan 27 18:08:21 2015 From: fraser.hutchison at gmail.com (Fraser Hutchison) Date: Tue, 27 Jan 2015 23:08:21 +0000 Subject: [CMake] CTest + Catch Framework In-Reply-To: References: Message-ID: <54C81A65.5000104@gmail.com> We've run into this exact chicken and egg problem with both gtest and Catch at my work too. In both cases, we've worked round the problem by writing fairly fragile CMake code which parses the C++ files comprising a test executable and ultimately calling add_test for each discovered test case. gtest is harder to handle than Catch in that it provides macros for handling value-parameterised and type-parameterised tests. It would be great if CTest were able to handle these popular test libraries automatically. I'm really short of time of the moment, but if there are any pointers from experts on how this might be best handled by CTest, I could perhaps start to have a poke about if there are no other takers? In the meantime, here's a link to our Catch-handling code: https://github.com/Fraser999/MaidSafe/blob/846ce37c23bd86ee261e439919dfd7000a8f9372/cmake_modules/add_catch_tests.cmake The file's commented at the top. It probably doesn't cover all Catch macros, and I'd be amazed if it handled all C++ coding styles properly, but it worked fairly reliably for us. We don't use Catch any more, so I'm not even sure if it works with the current version of Catch. For comparison (of the complexity) here's our gtest equivalent: https://github.com/Fraser999/MaidSafe/blob/72af3a0def2f03af7320696f5ea3d241c5af9bdc/cmake_modules/add_gtests.cmake (it's old code and could be made more efficient I'm sure - but again it works fine for us). Cheers, Fraser. On 27/01/2015 17:14, David Cole via CMake wrote: > The best thing to do would be to make CTest aware of unit test > frameworks like this, and have it be automatic. > > Support for cppunit, gtest and Catch (and any other popular ones) > would all be appreciated by many, I'm sure. > > Got time to dig into ctest a little bit? > > > D > > > > On Tue, Jan 27, 2015 at 11:18 AM, Robert Dailey > wrote: >> I wouldn't say this is an artificial problem. let me go into more detail. >> >> A single test can define any number of test cases. These are unknown >> to CMake scripts, as they are written and defined in code. The ideal >> solution is to have the test program output a list of all test cases >> and based on that list, automatically generate the add_test commands. >> That way I don't have to worry about hard-coding test case names in >> the build scripts. When a new test case is added to the test code (no >> new files would be added), "magically" a new unit test appears to >> CMake. >> >> But none of this can be done unless the unit test executables are >> built. Thus the chicken and egg problem. To do it as you suggest would >> require me to hard-code the test cases. Example: >> >> In MyTest.cpp: >> >> #include >> TEST_CASE("test1") {} >> TEST_CASE("test2") {} >> >> In CMakeLists.txt: >> >> add_executable( MyTest MyTest.cpp ) >> add_test( NAME MyTest_test1 COMMAND test1 ) >> add_test( NAME MyTest_test2 COMMAND test2 ) >> >> Am I correctly understanding what you have in mind? If so, can you >> think of a way to automate this a little better? >> >> On Tue, Jan 27, 2015 at 7:18 AM, David Cole wrote: >>> It's only a chicken and egg problem if you constrain yourself artificially. >>> >>> When you define a new unit test source file, there are two things you >>> need to do: >>> (1) add it to its executable >>> (2) write an add_test line that invokes that specific unit test >>> >>> You could possibly encapsulate those actions into an add_unit_test >>> macro so that it only seems like you have one thing to do, but >>> certainly, it's possible. >>> >>> You must be doing #1 already, so you just have to make sure #2 always >>> happens whenever #1 happens. >>> >>> Both eggs. >>> >>> >>> D >>> >>> >>> >>> >>> On Mon, Jan 26, 2015 at 4:05 PM, Robert Dailey wrote: >>>> I believe so, but then you run into the chicken and egg problem: >>>> >>>> I need to fully build all unit tests in order to know all the test >>>> cases, but I need to define the tests at the generation phase (before >>>> build). >>>> >>>> I'm just not sure how to handle this. The best i can think of is to >>>> generate 1 test executable per CPP file that we write in our unit >>>> tests (generally 1 CPP file per class that is unit tested). Any ideas? >>>> >>>> On Mon, Jan 26, 2015 at 10:05 AM, David Cole wrote: >>>>> Can you run a command that executes one test case at a time, or do you >>>>> have to run all 50 when you execute the tests for a library? >>>>> >>>>> ctest just runs whatever you give it with add_test -- if you want to >>>>> filter a collection of unit tests to run only a single unit test, then >>>>> the unit test framework you're using would have to support that. Does >>>>> Catch allow you to run the tests individually? >>>>> >>>>> >>>>> >>>>> On Mon, Jan 26, 2015 at 12:30 AM, Robert Dailey >>>>> wrote: >>>>>> Hi, >>>>>> >>>>>> I'm using Catch as my unit test framework: >>>>>> https://github.com/philsquared/Catch >>>>>> >>>>>> Is it possible for CTest to report each TEST_CASE block as an >>>>>> individual test? My understanding is that CTest will only treat each >>>>>> executable as a test. However, my test structure is as follows: >>>>>> >>>>>> 1 library >>>>>> 1 test project >>>>>> >>>>>> Each test project has 1 test CPP file per each class in the library. >>>>>> This way I implement tests for classes in a corresponding CPP file. >>>>>> >>>>>> Each CPP file contains multiple test cases (defined by TEST_CASE macro). >>>>>> >>>>>> The resulting output of `ctest -T Test` shows only 1 test, even though >>>>>> that may be around 50 test cases. I'd like CMake to show the pass/fail >>>>>> status of each one. Is this possible? >>>>>> -- >>>>>> >>>>>> 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 From rcdailey.lists at gmail.com Tue Jan 27 19:38:25 2015 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Tue, 27 Jan 2015 18:38:25 -0600 Subject: [CMake] CTest + Catch Framework In-Reply-To: <54C81A65.5000104@gmail.com> References: <54C81A65.5000104@gmail.com> Message-ID: I suspect that per David's suggestion, CTest would essentially do what you're doing but in a more thorough manner (based on the test framework used). So essentially CTest will need: - A new command line parameter that specifies the test framework - Functionality to parse the contents of source files provided to the target the test is assigned to I'll try to look into this when I can. David, if you have more specific requirements or pointers please do share them here. Thanks for the input everyone. On Tue, Jan 27, 2015 at 5:08 PM, Fraser Hutchison wrote: > We've run into this exact chicken and egg problem with both gtest and Catch > at my work too. In both cases, we've worked round the problem by writing > fairly fragile CMake code which parses the C++ files comprising a test > executable and ultimately calling add_test for each discovered test case. > > gtest is harder to handle than Catch in that it provides macros for handling > value-parameterised and type-parameterised tests. It would be great if > CTest were able to handle these popular test libraries automatically. I'm > really short of time of the moment, but if there are any pointers from > experts on how this might be best handled by CTest, I could perhaps start to > have a poke about if there are no other takers? > > In the meantime, here's a link to our Catch-handling code: > https://github.com/Fraser999/MaidSafe/blob/846ce37c23bd86ee261e439919dfd7000a8f9372/cmake_modules/add_catch_tests.cmake > > The file's commented at the top. It probably doesn't cover all Catch > macros, and I'd be amazed if it handled all C++ coding styles properly, but > it worked fairly reliably for us. We don't use Catch any more, so I'm not > even sure if it works with the current version of Catch. For comparison (of > the complexity) here's our gtest equivalent: > https://github.com/Fraser999/MaidSafe/blob/72af3a0def2f03af7320696f5ea3d241c5af9bdc/cmake_modules/add_gtests.cmake > (it's old code and could be made more efficient I'm sure - but again it > works fine for us). > > Cheers, > Fraser. > > > > On 27/01/2015 17:14, David Cole via CMake wrote: >> >> The best thing to do would be to make CTest aware of unit test >> frameworks like this, and have it be automatic. >> >> Support for cppunit, gtest and Catch (and any other popular ones) >> would all be appreciated by many, I'm sure. >> >> Got time to dig into ctest a little bit? >> >> >> D >> >> >> >> On Tue, Jan 27, 2015 at 11:18 AM, Robert Dailey >> wrote: >>> >>> I wouldn't say this is an artificial problem. let me go into more detail. >>> >>> A single test can define any number of test cases. These are unknown >>> to CMake scripts, as they are written and defined in code. The ideal >>> solution is to have the test program output a list of all test cases >>> and based on that list, automatically generate the add_test commands. >>> That way I don't have to worry about hard-coding test case names in >>> the build scripts. When a new test case is added to the test code (no >>> new files would be added), "magically" a new unit test appears to >>> CMake. >>> >>> But none of this can be done unless the unit test executables are >>> built. Thus the chicken and egg problem. To do it as you suggest would >>> require me to hard-code the test cases. Example: >>> >>> In MyTest.cpp: >>> >>> #include >>> TEST_CASE("test1") {} >>> TEST_CASE("test2") {} >>> >>> In CMakeLists.txt: >>> >>> add_executable( MyTest MyTest.cpp ) >>> add_test( NAME MyTest_test1 COMMAND test1 ) >>> add_test( NAME MyTest_test2 COMMAND test2 ) >>> >>> Am I correctly understanding what you have in mind? If so, can you >>> think of a way to automate this a little better? >>> >>> On Tue, Jan 27, 2015 at 7:18 AM, David Cole wrote: >>>> >>>> It's only a chicken and egg problem if you constrain yourself >>>> artificially. >>>> >>>> When you define a new unit test source file, there are two things you >>>> need to do: >>>> (1) add it to its executable >>>> (2) write an add_test line that invokes that specific unit test >>>> >>>> You could possibly encapsulate those actions into an add_unit_test >>>> macro so that it only seems like you have one thing to do, but >>>> certainly, it's possible. >>>> >>>> You must be doing #1 already, so you just have to make sure #2 always >>>> happens whenever #1 happens. >>>> >>>> Both eggs. >>>> >>>> >>>> D >>>> >>>> >>>> >>>> >>>> On Mon, Jan 26, 2015 at 4:05 PM, Robert Dailey >>>> wrote: >>>>> >>>>> I believe so, but then you run into the chicken and egg problem: >>>>> >>>>> I need to fully build all unit tests in order to know all the test >>>>> cases, but I need to define the tests at the generation phase (before >>>>> build). >>>>> >>>>> I'm just not sure how to handle this. The best i can think of is to >>>>> generate 1 test executable per CPP file that we write in our unit >>>>> tests (generally 1 CPP file per class that is unit tested). Any ideas? >>>>> >>>>> On Mon, Jan 26, 2015 at 10:05 AM, David Cole wrote: >>>>>> >>>>>> Can you run a command that executes one test case at a time, or do you >>>>>> have to run all 50 when you execute the tests for a library? >>>>>> >>>>>> ctest just runs whatever you give it with add_test -- if you want to >>>>>> filter a collection of unit tests to run only a single unit test, then >>>>>> the unit test framework you're using would have to support that. Does >>>>>> Catch allow you to run the tests individually? >>>>>> >>>>>> >>>>>> >>>>>> On Mon, Jan 26, 2015 at 12:30 AM, Robert Dailey >>>>>> wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I'm using Catch as my unit test framework: >>>>>>> https://github.com/philsquared/Catch >>>>>>> >>>>>>> Is it possible for CTest to report each TEST_CASE block as an >>>>>>> individual test? My understanding is that CTest will only treat each >>>>>>> executable as a test. However, my test structure is as follows: >>>>>>> >>>>>>> 1 library >>>>>>> 1 test project >>>>>>> >>>>>>> Each test project has 1 test CPP file per each class in the library. >>>>>>> This way I implement tests for classes in a corresponding CPP file. >>>>>>> >>>>>>> Each CPP file contains multiple test cases (defined by TEST_CASE >>>>>>> macro). >>>>>>> >>>>>>> The resulting output of `ctest -T Test` shows only 1 test, even >>>>>>> though >>>>>>> that may be around 50 test cases. I'd like CMake to show the >>>>>>> pass/fail >>>>>>> status of each one. Is this possible? >>>>>>> -- >>>>>>> >>>>>>> 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 > > From petr.kmoch at gmail.com Wed Jan 28 02:29:41 2015 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Wed, 28 Jan 2015 08:29:41 +0100 Subject: [CMake] CTest + Catch Framework In-Reply-To: References: <54C81A65.5000104@gmail.com> Message-ID: Hi all. I've run into this problem as well - I think first-class support for this in CTest would be a most useful feature. And I would like to nominate Boost.Test into the list of frameworks considered for support, if possible. Petr On Wed, Jan 28, 2015 at 1:38 AM, Robert Dailey wrote: > I suspect that per David's suggestion, CTest would essentially do what > you're doing but in a more thorough manner (based on the test > framework used). So essentially CTest will need: > > - A new command line parameter that specifies the test framework > - Functionality to parse the contents of source files provided to the > target the test is assigned to > > I'll try to look into this when I can. David, if you have more > specific requirements or pointers please do share them here. Thanks > for the input everyone. > > On Tue, Jan 27, 2015 at 5:08 PM, Fraser Hutchison > wrote: > > We've run into this exact chicken and egg problem with both gtest and > Catch > > at my work too. In both cases, we've worked round the problem by writing > > fairly fragile CMake code which parses the C++ files comprising a test > > executable and ultimately calling add_test for each discovered test case. > > > > gtest is harder to handle than Catch in that it provides macros for > handling > > value-parameterised and type-parameterised tests. It would be great if > > CTest were able to handle these popular test libraries automatically. > I'm > > really short of time of the moment, but if there are any pointers from > > experts on how this might be best handled by CTest, I could perhaps > start to > > have a poke about if there are no other takers? > > > > In the meantime, here's a link to our Catch-handling code: > > > https://github.com/Fraser999/MaidSafe/blob/846ce37c23bd86ee261e439919dfd7000a8f9372/cmake_modules/add_catch_tests.cmake > > > > The file's commented at the top. It probably doesn't cover all Catch > > macros, and I'd be amazed if it handled all C++ coding styles properly, > but > > it worked fairly reliably for us. We don't use Catch any more, so I'm > not > > even sure if it works with the current version of Catch. For comparison > (of > > the complexity) here's our gtest equivalent: > > > https://github.com/Fraser999/MaidSafe/blob/72af3a0def2f03af7320696f5ea3d241c5af9bdc/cmake_modules/add_gtests.cmake > > (it's old code and could be made more efficient I'm sure - but again it > > works fine for us). > > > > Cheers, > > Fraser. > > > > > > > > On 27/01/2015 17:14, David Cole via CMake wrote: > >> > >> The best thing to do would be to make CTest aware of unit test > >> frameworks like this, and have it be automatic. > >> > >> Support for cppunit, gtest and Catch (and any other popular ones) > >> would all be appreciated by many, I'm sure. > >> > >> Got time to dig into ctest a little bit? > >> > >> > >> D > >> > >> > >> > >> On Tue, Jan 27, 2015 at 11:18 AM, Robert Dailey > >> wrote: > >>> > >>> I wouldn't say this is an artificial problem. let me go into more > detail. > >>> > >>> A single test can define any number of test cases. These are unknown > >>> to CMake scripts, as they are written and defined in code. The ideal > >>> solution is to have the test program output a list of all test cases > >>> and based on that list, automatically generate the add_test commands. > >>> That way I don't have to worry about hard-coding test case names in > >>> the build scripts. When a new test case is added to the test code (no > >>> new files would be added), "magically" a new unit test appears to > >>> CMake. > >>> > >>> But none of this can be done unless the unit test executables are > >>> built. Thus the chicken and egg problem. To do it as you suggest would > >>> require me to hard-code the test cases. Example: > >>> > >>> In MyTest.cpp: > >>> > >>> #include > >>> TEST_CASE("test1") {} > >>> TEST_CASE("test2") {} > >>> > >>> In CMakeLists.txt: > >>> > >>> add_executable( MyTest MyTest.cpp ) > >>> add_test( NAME MyTest_test1 COMMAND test1 ) > >>> add_test( NAME MyTest_test2 COMMAND test2 ) > >>> > >>> Am I correctly understanding what you have in mind? If so, can you > >>> think of a way to automate this a little better? > >>> > >>> On Tue, Jan 27, 2015 at 7:18 AM, David Cole wrote: > >>>> > >>>> It's only a chicken and egg problem if you constrain yourself > >>>> artificially. > >>>> > >>>> When you define a new unit test source file, there are two things you > >>>> need to do: > >>>> (1) add it to its executable > >>>> (2) write an add_test line that invokes that specific unit test > >>>> > >>>> You could possibly encapsulate those actions into an add_unit_test > >>>> macro so that it only seems like you have one thing to do, but > >>>> certainly, it's possible. > >>>> > >>>> You must be doing #1 already, so you just have to make sure #2 always > >>>> happens whenever #1 happens. > >>>> > >>>> Both eggs. > >>>> > >>>> > >>>> D > >>>> > >>>> > >>>> > >>>> > >>>> On Mon, Jan 26, 2015 at 4:05 PM, Robert Dailey > >>>> wrote: > >>>>> > >>>>> I believe so, but then you run into the chicken and egg problem: > >>>>> > >>>>> I need to fully build all unit tests in order to know all the test > >>>>> cases, but I need to define the tests at the generation phase (before > >>>>> build). > >>>>> > >>>>> I'm just not sure how to handle this. The best i can think of is to > >>>>> generate 1 test executable per CPP file that we write in our unit > >>>>> tests (generally 1 CPP file per class that is unit tested). Any > ideas? > >>>>> > >>>>> On Mon, Jan 26, 2015 at 10:05 AM, David Cole > wrote: > >>>>>> > >>>>>> Can you run a command that executes one test case at a time, or do > you > >>>>>> have to run all 50 when you execute the tests for a library? > >>>>>> > >>>>>> ctest just runs whatever you give it with add_test -- if you want to > >>>>>> filter a collection of unit tests to run only a single unit test, > then > >>>>>> the unit test framework you're using would have to support that. > Does > >>>>>> Catch allow you to run the tests individually? > >>>>>> > >>>>>> > >>>>>> > >>>>>> On Mon, Jan 26, 2015 at 12:30 AM, Robert Dailey > >>>>>> wrote: > >>>>>>> > >>>>>>> Hi, > >>>>>>> > >>>>>>> I'm using Catch as my unit test framework: > >>>>>>> https://github.com/philsquared/Catch > >>>>>>> > >>>>>>> Is it possible for CTest to report each TEST_CASE block as an > >>>>>>> individual test? My understanding is that CTest will only treat > each > >>>>>>> executable as a test. However, my test structure is as follows: > >>>>>>> > >>>>>>> 1 library > >>>>>>> 1 test project > >>>>>>> > >>>>>>> Each test project has 1 test CPP file per each class in the > library. > >>>>>>> This way I implement tests for classes in a corresponding CPP file. > >>>>>>> > >>>>>>> Each CPP file contains multiple test cases (defined by TEST_CASE > >>>>>>> macro). > >>>>>>> > >>>>>>> The resulting output of `ctest -T Test` shows only 1 test, even > >>>>>>> though > >>>>>>> that may be around 50 test cases. I'd like CMake to show the > >>>>>>> pass/fail > >>>>>>> status of each one. Is this possible? > >>>>>>> -- > >>>>>>> > >>>>>>> Powered by www.kitware.com > >>>>>>> > >>>>>>> Please keep messages on-topic and check the CMake FAQ at: > >>>>>>> http://www.cmake.org/Wiki/CMake_FAQ > >>>>>>> > >>>>>>> Kitware offers various services to support the CMake community. For > >>>>>>> more information on each offering, please visit: > >>>>>>> > >>>>>>> CMake Support: http://cmake.org/cmake/help/support.html > >>>>>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html > >>>>>>> CMake Training Courses: http://cmake.org/cmake/help/training.html > >>>>>>> > >>>>>>> Visit other Kitware open-source projects at > >>>>>>> http://www.kitware.com/opensource/opensource.html > >>>>>>> > >>>>>>> Follow this link to subscribe/unsubscribe: > >>>>>>> http://public.kitware.com/mailman/listinfo/cmake > > > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Wed Jan 28 04:19:31 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Wed, 28 Jan 2015 10:19:31 +0100 Subject: [CMake] CTest + Catch Framework In-Reply-To: References: <54C81A65.5000104@gmail.com> Message-ID: <54C8A9A3.4090802@gmail.com> On 28.01.2015 01:38, Robert Dailey wrote: > I suspect that per David's suggestion, CTest would essentially do what > you're doing but in a more thorough manner (based on the test > framework used). So essentially CTest will need: > > - A new command line parameter that specifies the test framework > - Functionality to parse the contents of source files provided to the > target the test is assigned to > > I'll try to look into this when I can. David, if you have more > specific requirements or pointers please do share them here. Thanks > for the input everyone. > CMake generates "CTestTestfile.cmake" files which contain the code that defines tests during execution of ctest itself. Those "CTestTestfile.cmake" files could use execute_process() to query test binaries for their contained tests and then add tests appropriately. With that approach there would be no need to parse source files. This can already be done in a hackish way by using the TEST_INCLUDE_FILE[1] directory property. file(GENERATE) can be used to create per-test-binary/per-configuration snippets with executable locations ($) which then can be globbed for and included by CTestTestfile.cmake. I would still opt for implementing support for this in cmake itself though since the entire logic could be contained in the generated "CTestTestfile.cmake"s. Perhaps with a couple of properties that would define how to e.g. query the list of tests and the required parameter to run a specific test; that way it could be made to work irregardless of which test framework is being used. Nils [1] http://www.cmake.org/cmake/help/v3.1/prop_dir/TEST_INCLUDE_FILE.html From DLRdave at aol.com Wed Jan 28 07:43:43 2015 From: DLRdave at aol.com (David Cole) Date: Wed, 28 Jan 2015 07:43:43 -0500 Subject: [CMake] CTest + Catch Framework In-Reply-To: <54C8A9A3.4090802@gmail.com> References: <54C81A65.5000104@gmail.com> <54C8A9A3.4090802@gmail.com> Message-ID: I have two more suggestions for whoever takes on this work. One: add a new CMake command add_unit_test_container (or add_unit_tester or a better name ... ?) which names the DLL or executable file containing the unit tests. Give it properties to indicate how to extract a list of tests from it (perhaps just a "type" that maps to internal code that knows how to do this for each type...), and how to run *all* the tests, and how to run an individual test by name. Two: consider performance, both of running all the unit tests and of submitting/processing results on CDash, ... frequently, some unit test containers involve "expensive" setup and teardown, and that's why it's a good thing to have many tests in one container -- so the slow stuff only has to run once for 100 tests... (or more!) Unless you really really need this functionality, you might want to test out CDash first to make sure it can handle the number of tests you want to send it. Done properly, unit tests will test every single C++ method in your code... If VTK were to do that, there would be **tens of thousands** of test results being sent to CDash for each row on the dashboard. OK, and [Three:], make it a goal to add support for all of the following (and make it easily extensible for more): - gtest - cppunit - Catch - Boost.Test - Microsoft::VisualStudio::CppUnitTestFramework I am currently involved with a project where we're using Microsoft::VisualStudio::CppUnitTestFramework for unit tests, and we run vstest.console.exe to run all the unit tests at once for each library we test. Then we submit to a CDash dashboard as "Release.UnitTests.LibraryName" and "Debug.UnitTests.LibraryName" -- if a single test fails, you just have to inspect the output and read which test failed. Unit tests, in general, should run nearly instantaneously, and ALL your developers should run them and verify passing unit tests before every push to the repo. If they're not doing that already, then new ctest features ain't gonna help you... Cheers, David C. On Wed, Jan 28, 2015 at 4:19 AM, Nils Gladitz wrote: > On 28.01.2015 01:38, Robert Dailey wrote: >> >> I suspect that per David's suggestion, CTest would essentially do what >> you're doing but in a more thorough manner (based on the test >> framework used). So essentially CTest will need: >> >> - A new command line parameter that specifies the test framework >> - Functionality to parse the contents of source files provided to the >> target the test is assigned to >> >> I'll try to look into this when I can. David, if you have more >> specific requirements or pointers please do share them here. Thanks >> for the input everyone. >> > > CMake generates "CTestTestfile.cmake" files which contain the code that > defines tests during execution of ctest itself. > > Those "CTestTestfile.cmake" files could use execute_process() to query test > binaries for their contained tests and then add tests appropriately. > With that approach there would be no need to parse source files. > > This can already be done in a hackish way by using the TEST_INCLUDE_FILE[1] > directory property. > file(GENERATE) can be used to create per-test-binary/per-configuration > snippets with executable locations ($) which then can be > globbed for and included by CTestTestfile.cmake. > > I would still opt for implementing support for this in cmake itself though > since the entire logic could be contained in the generated > "CTestTestfile.cmake"s. > Perhaps with a couple of properties that would define how to e.g. query the > list of tests and the required parameter to run a specific test; that way it > could be made to work irregardless of which test framework is being used. > > Nils > > [1] http://www.cmake.org/cmake/help/v3.1/prop_dir/TEST_INCLUDE_FILE.html > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake From rcdailey.lists at gmail.com Wed Jan 28 11:57:05 2015 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Wed, 28 Jan 2015 10:57:05 -0600 Subject: [CMake] CTest + Catch Framework In-Reply-To: References: <54C81A65.5000104@gmail.com> <54C8A9A3.4090802@gmail.com> Message-ID: @David I agree with your point about unit test initialization. Perhaps instead of running a test multiple times, we can inspect the output of a test that is run 1 time and assuming it spits out success/failure details for individual test cases, we can simply parse that output into appropriate CText XML so that it appears as if it was instead run once for each test case? I'm being fairly abstract here as I'm not sure of the implementation details of CTest or if this is even possible. But it's a thought. Let me know what you think. On Wed, Jan 28, 2015 at 6:43 AM, David Cole wrote: > I have two more suggestions for whoever takes on this work. > > One: add a new CMake command add_unit_test_container (or > add_unit_tester or a better name ... ?) which names the DLL or > executable file containing the unit tests. Give it properties to > indicate how to extract a list of tests from it (perhaps just a "type" > that maps to internal code that knows how to do this for each > type...), and how to run *all* the tests, and how to run an individual > test by name. > > Two: consider performance, both of running all the unit tests and of > submitting/processing results on CDash, ... frequently, some unit test > containers involve "expensive" setup and teardown, and that's why it's > a good thing to have many tests in one container -- so the slow stuff > only has to run once for 100 tests... (or more!) > > Unless you really really need this functionality, you might want to > test out CDash first to make sure it can handle the number of tests > you want to send it. Done properly, unit tests will test every single > C++ method in your code... If VTK were to do that, there would be > **tens of thousands** of test results being sent to CDash for each row > on the dashboard. > > OK, and [Three:], make it a goal to add support for all of the > following (and make it easily extensible for more): > > - gtest > - cppunit > - Catch > - Boost.Test > - Microsoft::VisualStudio::CppUnitTestFramework > > I am currently involved with a project where we're using > Microsoft::VisualStudio::CppUnitTestFramework for unit tests, and we > run vstest.console.exe to run all the unit tests at once for each > library we test. Then we submit to a CDash dashboard as > "Release.UnitTests.LibraryName" and "Debug.UnitTests.LibraryName" -- > if a single test fails, you just have to inspect the output and read > which test failed. > > Unit tests, in general, should run nearly instantaneously, and ALL > your developers should run them and verify passing unit tests before > every push to the repo. If they're not doing that already, then new > ctest features ain't gonna help you... > > > Cheers, > David C. > > On Wed, Jan 28, 2015 at 4:19 AM, Nils Gladitz wrote: >> On 28.01.2015 01:38, Robert Dailey wrote: >>> >>> I suspect that per David's suggestion, CTest would essentially do what >>> you're doing but in a more thorough manner (based on the test >>> framework used). So essentially CTest will need: >>> >>> - A new command line parameter that specifies the test framework >>> - Functionality to parse the contents of source files provided to the >>> target the test is assigned to >>> >>> I'll try to look into this when I can. David, if you have more >>> specific requirements or pointers please do share them here. Thanks >>> for the input everyone. >>> >> >> CMake generates "CTestTestfile.cmake" files which contain the code that >> defines tests during execution of ctest itself. >> >> Those "CTestTestfile.cmake" files could use execute_process() to query test >> binaries for their contained tests and then add tests appropriately. >> With that approach there would be no need to parse source files. >> >> This can already be done in a hackish way by using the TEST_INCLUDE_FILE[1] >> directory property. >> file(GENERATE) can be used to create per-test-binary/per-configuration >> snippets with executable locations ($) which then can be >> globbed for and included by CTestTestfile.cmake. >> >> I would still opt for implementing support for this in cmake itself though >> since the entire logic could be contained in the generated >> "CTestTestfile.cmake"s. >> Perhaps with a couple of properties that would define how to e.g. query the >> list of tests and the required parameter to run a specific test; that way it >> could be made to work irregardless of which test framework is being used. >> >> Nils >> >> [1] http://www.cmake.org/cmake/help/v3.1/prop_dir/TEST_INCLUDE_FILE.html >> >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake From gunjan.gemini29 at gmail.com Wed Jan 28 12:00:34 2015 From: gunjan.gemini29 at gmail.com (Gunjan Gautam) Date: Wed, 28 Jan 2015 22:30:34 +0530 Subject: [CMake] Unable to install cmake Message-ID: Hi All, I am trying to install Cmake (v2.8.x) in my system which is 64bit Ubuntu but unable to get it. Probably I'm not getting the steps properly. I'll be thankful if anyone can help to resolve this problem. Gunjan -------------- next part -------------- An HTML attachment was scrubbed... URL: From DLRdave at aol.com Wed Jan 28 13:33:46 2015 From: DLRdave at aol.com (David Cole) Date: Wed, 28 Jan 2015 13:33:46 -0500 Subject: [CMake] CTest + Catch Framework In-Reply-To: References: <54C81A65.5000104@gmail.com> <54C8A9A3.4090802@gmail.com> Message-ID: I'm sure it's possible, as long as CDash can handle the flood of test results. CTest is responsible for taking add_test (or whatever the new CMake command will be called) calls and transforming them into Test.xml files for sending to CDash. As long as you can read the output of running the unit tests, and decide how to split it up into test results, you can map it however you like. The beauty of unwritten code is that it always does exactly what you want it to do. Until you write it. :-) On Wed, Jan 28, 2015 at 11:57 AM, Robert Dailey wrote: > @David > > I agree with your point about unit test initialization. Perhaps > instead of running a test multiple times, we can inspect the output of > a test that is run 1 time and assuming it spits out success/failure > details for individual test cases, we can simply parse that output > into appropriate CText XML so that it appears as if it was instead run > once for each test case? > > I'm being fairly abstract here as I'm not sure of the implementation > details of CTest or if this is even possible. But it's a thought. Let > me know what you think. > > On Wed, Jan 28, 2015 at 6:43 AM, David Cole wrote: >> I have two more suggestions for whoever takes on this work. >> >> One: add a new CMake command add_unit_test_container (or >> add_unit_tester or a better name ... ?) which names the DLL or >> executable file containing the unit tests. Give it properties to >> indicate how to extract a list of tests from it (perhaps just a "type" >> that maps to internal code that knows how to do this for each >> type...), and how to run *all* the tests, and how to run an individual >> test by name. >> >> Two: consider performance, both of running all the unit tests and of >> submitting/processing results on CDash, ... frequently, some unit test >> containers involve "expensive" setup and teardown, and that's why it's >> a good thing to have many tests in one container -- so the slow stuff >> only has to run once for 100 tests... (or more!) >> >> Unless you really really need this functionality, you might want to >> test out CDash first to make sure it can handle the number of tests >> you want to send it. Done properly, unit tests will test every single >> C++ method in your code... If VTK were to do that, there would be >> **tens of thousands** of test results being sent to CDash for each row >> on the dashboard. >> >> OK, and [Three:], make it a goal to add support for all of the >> following (and make it easily extensible for more): >> >> - gtest >> - cppunit >> - Catch >> - Boost.Test >> - Microsoft::VisualStudio::CppUnitTestFramework >> >> I am currently involved with a project where we're using >> Microsoft::VisualStudio::CppUnitTestFramework for unit tests, and we >> run vstest.console.exe to run all the unit tests at once for each >> library we test. Then we submit to a CDash dashboard as >> "Release.UnitTests.LibraryName" and "Debug.UnitTests.LibraryName" -- >> if a single test fails, you just have to inspect the output and read >> which test failed. >> >> Unit tests, in general, should run nearly instantaneously, and ALL >> your developers should run them and verify passing unit tests before >> every push to the repo. If they're not doing that already, then new >> ctest features ain't gonna help you... >> >> >> Cheers, >> David C. >> >> On Wed, Jan 28, 2015 at 4:19 AM, Nils Gladitz wrote: >>> On 28.01.2015 01:38, Robert Dailey wrote: >>>> >>>> I suspect that per David's suggestion, CTest would essentially do what >>>> you're doing but in a more thorough manner (based on the test >>>> framework used). So essentially CTest will need: >>>> >>>> - A new command line parameter that specifies the test framework >>>> - Functionality to parse the contents of source files provided to the >>>> target the test is assigned to >>>> >>>> I'll try to look into this when I can. David, if you have more >>>> specific requirements or pointers please do share them here. Thanks >>>> for the input everyone. >>>> >>> >>> CMake generates "CTestTestfile.cmake" files which contain the code that >>> defines tests during execution of ctest itself. >>> >>> Those "CTestTestfile.cmake" files could use execute_process() to query test >>> binaries for their contained tests and then add tests appropriately. >>> With that approach there would be no need to parse source files. >>> >>> This can already be done in a hackish way by using the TEST_INCLUDE_FILE[1] >>> directory property. >>> file(GENERATE) can be used to create per-test-binary/per-configuration >>> snippets with executable locations ($) which then can be >>> globbed for and included by CTestTestfile.cmake. >>> >>> I would still opt for implementing support for this in cmake itself though >>> since the entire logic could be contained in the generated >>> "CTestTestfile.cmake"s. >>> Perhaps with a couple of properties that would define how to e.g. query the >>> list of tests and the required parameter to run a specific test; that way it >>> could be made to work irregardless of which test framework is being used. >>> >>> Nils >>> >>> [1] http://www.cmake.org/cmake/help/v3.1/prop_dir/TEST_INCLUDE_FILE.html >>> >>> -- >>> >>> Powered by www.kitware.com >>> >>> Please keep messages on-topic and check the CMake FAQ at: >>> http://www.cmake.org/Wiki/CMake_FAQ >>> >>> Kitware offers various services to support the CMake community. For more >>> information on each offering, please visit: >>> >>> CMake Support: http://cmake.org/cmake/help/support.html >>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>> >>> Visit other Kitware open-source projects at >>> http://www.kitware.com/opensource/opensource.html >>> >>> Follow this link to subscribe/unsubscribe: >>> http://public.kitware.com/mailman/listinfo/cmake From rcdailey.lists at gmail.com Wed Jan 28 13:56:24 2015 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Wed, 28 Jan 2015 12:56:24 -0600 Subject: [CMake] CMake Eclipse & Resource Filters Message-ID: Hello, I generate my project using Eclipse CDT4 - Ninja. I have a subdirectory called "Third Party" under my source directory that contains boost, QT, and a number of other very large libraries. I notice that the C++ indexer in Eclipse processes files in these directories and frequently locks up my machine or crashes. Indexing takes up to 30 minutes if it decides to complete. Is there a way I can specify resource filters in CMake scripts? If I can do this, I can tell Eclipse to ignore the directories I don't want it to scan or care about. Thanks in advance. Using CMake v3.1 From greenc at fnal.gov Wed Jan 28 15:12:03 2015 From: greenc at fnal.gov (Chris Green) Date: Wed, 28 Jan 2015 14:12:03 -0600 Subject: [CMake] target_link_libraries replacing fully-qualified library with -l Message-ID: <54C94293.6050100@fnal.gov> Hi, I've been trying to run down a problem with our cmake-based build system that appears to be a result of a target_link_libraries(...) invocation taking a fully qualified shared library location and replacing it with -l. Since we're trying very hard to avoid picking up unwanted, older copies of this library from system areas, this is causing us quite some angst. The command: target_link_libraries( /X/Y/libtbb.so) results in link.txt files containing -ltbb. I wasn't able to find anywhere in documentation that mentioned this was a possible behavior of target_link_libraries, which is why it took us so long to trace it down to this in particular. So, my questions: 1. Is this a bug? 2. If not a bug, what is the rationale for this behavior, and under what circumstances does this behavior get triggered? 3. Is it possible to deactivate this behavior? 4. If not, can it be made possible to deactivate this behavior? Thanks for your help, Chris. -- Chris Green , FNAL CS/SCD/ADSS/SSI/SSD; 'phone (630) 840-2167; Skype: chris.h.green; IM: greenc at jabber.fnal.gov, chissgreen (AIM, Yahoo), chissg at hotmail.com (MSNM), chris.h.green (Google Talk). -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.neundorf-work at gmx.net Wed Jan 28 16:58:57 2015 From: a.neundorf-work at gmx.net (Alexander Neundorf) Date: Wed, 28 Jan 2015 22:58:57 +0100 Subject: [CMake] target_link_libraries replacing fully-qualified library with -l In-Reply-To: <54C94293.6050100@fnal.gov> References: <54C94293.6050100@fnal.gov> Message-ID: <4311413.X9T9R8zGoH@tuxedo.neundorf.net> On Wednesday, January 28, 2015 14:12:03 Chris Green wrote: > Hi, > > I've been trying to run down a problem with our cmake-based build system > that appears to be a result of a target_link_libraries(...) invocation > taking a fully qualified shared library location and replacing it with > -l. Since we're trying very hard to avoid picking up unwanted, > older copies of this library from system areas, this is causing us quite > some angst. > > The command: > > target_link_libraries( /X/Y/libtbb.so) > > results in link.txt files containing -ltbb. > > I wasn't able to find anywhere in documentation that mentioned this was > a possible behavior of target_link_libraries, which is why it took us so > long to trace it down to this in particular. > > So, my questions: > > 1. Is this a bug? > 2. If not a bug, what is the rationale for this behavior, and under > what circumstances does this behavior get triggered? > 3. Is it possible to deactivate this behavior? > 4. If not, can it be made possible to deactivate this behavior? IIRC, this is done if the directory /X/Y/ is part of some environment variable, I think it was LIBRARY_PATH. Alex From a.neundorf-work at gmx.net Wed Jan 28 16:55:21 2015 From: a.neundorf-work at gmx.net (Alexander Neundorf) Date: Wed, 28 Jan 2015 22:55:21 +0100 Subject: [CMake] CMake Eclipse & Resource Filters In-Reply-To: References: Message-ID: <8753712.XZ7TzcIeoO@tuxedo.neundorf.net> On Wednesday, January 28, 2015 12:56:24 Robert Dailey wrote: > Hello, > > I generate my project using Eclipse CDT4 - Ninja. I have a > subdirectory called "Third Party" under my source directory that > contains boost, QT, and a number of other very large libraries. I > notice that the C++ indexer in Eclipse processes files in these > directories and frequently locks up my machine or crashes. Indexing > takes up to 30 minutes if it decides to complete. > > Is there a way I can specify resource filters in CMake scripts? If I > can do this, I can tell Eclipse to ignore the directories I don't want > it to scan or care about. no, there's currently not. Please enter a ticket on http://public.kitware.com/Bug Thanks Alex From brad.king at kitware.com Thu Jan 29 08:41:56 2015 From: brad.king at kitware.com (Brad King) Date: Thu, 29 Jan 2015 08:41:56 -0500 Subject: [CMake] target_link_libraries replacing fully-qualified library with -l In-Reply-To: <54C94293.6050100@fnal.gov> References: <54C94293.6050100@fnal.gov> Message-ID: <54CA38A4.5090908@kitware.com> On 01/28/2015 03:12 PM, Chris Green wrote: > target_link_libraries( /X/Y/libtbb.so) > > results in link.txt files containing -ltbb. This happens when the library is in an implicit link directory, or possibly when the library does not have an SONAME field set. For the former case, use an imported target: http://www.cmake.org/cmake/help/v3.1/command/add_library.html#imported-libraries http://www.cmake.org/cmake/help/v3.1/manual/cmake-buildsystem.7.html#imported-targets -Brad From greenc at fnal.gov Thu Jan 29 09:39:33 2015 From: greenc at fnal.gov (Chris Green) Date: Thu, 29 Jan 2015 08:39:33 -0600 Subject: [CMake] target_link_libraries replacing fully-qualified library with -l In-Reply-To: <54CA38A4.5090908@kitware.com> References: <54C94293.6050100@fnal.gov> <54CA38A4.5090908@kitware.com> Message-ID: <54CA4625.8080404@fnal.gov> On 1/29/15 7:41 AM, Brad King wrote: > On 01/28/2015 03:12 PM, Chris Green wrote: >> target_link_libraries( /X/Y/libtbb.so) >> >> results in link.txt files containing -ltbb. > This happens when the library is in an implicit link directory, > or possibly when the library does not have an SONAME field set. Thanks for this, Brad. Assuming that the list of implicit link directories is internal to CMake and nobody has added to it by mistake, then I'm guessing there's no SONAME: *$ ls -l $TBB_LIB** *total 3144 -rw-r--r--. 1 greenc g163 20 Aug 19 07:15 libtbb.so -rwxr-xr-x. 1 greenc g163 2493406 Aug 19 07:15 libtbb.so.2 -rw-r--r--. 1 greenc g163 26 Aug 19 07:15 libtbbmalloc.so -rwxr-xr-x. 1 greenc g163 675732 Aug 19 07:15 libtbbmalloc.so.2 -rw-r--r--. 1 greenc g163 32 Aug 19 07:15 libtbbmalloc_proxy.so -rwxr-xr-x. 1 greenc g163 28976 Aug 19 07:15 libtbbmalloc_proxy.so.2 drwxr-xr-x. 3 greenc g163 4096 Jul 23 2013 tbb *$ cat $TBB_LIB/libtbb.so** *INPUT (libtbb.so.2) *$ objdump -p $TBB_LIB/libtbb.so | grep SONAME** *objdump: /home/greenc/work/cet-is/products/tbb/v4_2_5/Linux64bit+2.6-2.12-e6-prof/lib/libtbb.so: File format not recognized *$ objdump -p $TBB_LIB/libtbb.so.2 | grep SONAME** * SONAME libtbb.so.2 I would hazard a guess that the linker instruction in libtbb.so is not sufficient currently for CMake to deduce the SONAME as libtbb.so.2. I can test a workaround when I get to work of replacing the libtbb.so and friends with the more usual symbolic link, but it would be nice if a future version of CMake were able to understand this particular system. Is this analysis correct and reasonable, or is there something I'm missing? Thanks, Chris. > > For the former case, use an imported target: > > http://www.cmake.org/cmake/help/v3.1/command/add_library.html#imported-libraries > http://www.cmake.org/cmake/help/v3.1/manual/cmake-buildsystem.7.html#imported-targets > > -Brad > -- Chris Green , FNAL CS/SCD/ADSS/SSI/SSD; 'phone (630) 840-2167; Skype: chris.h.green; IM: greenc at jabber.fnal.gov, chissgreen (AIM, Yahoo), chissg at hotmail.com (MSNM), chris.h.green (Google Talk). -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Thu Jan 29 10:06:59 2015 From: brad.king at kitware.com (Brad King) Date: Thu, 29 Jan 2015 10:06:59 -0500 Subject: [CMake] target_link_libraries replacing fully-qualified library with -l In-Reply-To: <54CA4625.8080404@fnal.gov> References: <54C94293.6050100@fnal.gov> <54CA38A4.5090908@kitware.com> <54CA4625.8080404@fnal.gov> Message-ID: <54CA4C93.4000805@kitware.com> On 01/29/2015 09:39 AM, Chris Green wrote: > Assuming that the list of implicit link directories is internal to CMake > and nobody has added to it by mistake CMake detects it from the compiler. Run grep IMPLICIT_LINK_DIRECTORIES CMakeFiles/*/CMake*Compiler.cmake in the top of the build tree to see the detected directories. > then I'm guessing there's no SONAME: It can only be this if something tells CMake that it has no SONAME. That can only happen when it is an imported target with an appropriate property set. CMake doesn't try to read the binary IIRC. -Brad From cxjohnson at gmail.com Thu Jan 29 10:09:26 2015 From: cxjohnson at gmail.com (Chris Johnson) Date: Thu, 29 Jan 2015 09:09:26 -0600 Subject: [CMake] Generated files? Message-ID: ?I am looking for suggestions on how to solve the following problem. I need a solution which is easy to understand and safe from future maintenance errors. There is a project directory with one C++ program and a large number of "input" data files. The C++ program needs to be compiled, and then run against each of the input files to generate an output file of the same base name but with a different output suffix. E.g. from the command line it might be: % myprog file001.in file001.out Finally, the output files need to be installed in the proper location. For one input file, it might look like this: add_executable(myprog myprog.cpp) add_custom_command(OUTPUT file001.out COMMAND /bin/cp ${CMAKE_CURRENT_SOURCE_DIR}/file001.in . COMMAND myprog file001.in file001.out DEPENDS files001.in myprog.cpp ) install(FILES ${CMAKE_CURRENT_BINARY_DIR}/file001.out DESTINATION share/docs) Listing all of the input files in my CMakeLists.txt file is not a problem, but it would be nice to avoid having to list the corresponding output files. How can I build a CMakeLists.txt file which will succinctly handle this situation? -- Thanks, ..chris? -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Thu Jan 29 10:25:41 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Thu, 29 Jan 2015 16:25:41 +0100 Subject: [CMake] target_link_libraries replacing fully-qualified library with -l In-Reply-To: <54CA4C93.4000805@kitware.com> References: <54C94293.6050100@fnal.gov> <54CA38A4.5090908@kitware.com> <54CA4625.8080404@fnal.gov> <54CA4C93.4000805@kitware.com> Message-ID: <54CA50F5.1060300@gmail.com> On 01/29/2015 04:06 PM, Brad King wrote: >CMake doesn't try to read the binary IIRC. I think cmComputeLinkInformation uses "cmSystemTools::GuessLibrarySOName" which uses the elf parser to check for a SONAME. Nils From greenc at fnal.gov Thu Jan 29 10:32:15 2015 From: greenc at fnal.gov (Chris Green) Date: Thu, 29 Jan 2015 09:32:15 -0600 Subject: [CMake] target_link_libraries replacing fully-qualified library with -l In-Reply-To: <54CA4C93.4000805@kitware.com> References: <54C94293.6050100@fnal.gov> <54CA38A4.5090908@kitware.com> <54CA4625.8080404@fnal.gov> <54CA4C93.4000805@kitware.com> Message-ID: <54CA527F.2070200@fnal.gov> Hi, On 1/29/15 9:06 AM, Brad King wrote: > then I'm guessing there's no SONAME: > It can only be this if something tells CMake that it has no SONAME. > That can only happen when it is an imported target with an appropriate > property set. CMake doesn't try to read the binary IIRC. I can confirm that replacing the text libtbb.so file containing the INPUT instruction with a link to the library with the SONAME is sufficient to solve the problem, at least as a short term workaround. There is no importing of targets: this library is found with find_library as part of a config.cmake file invoked as part of find_package(). I don't know whether CMake is using readelf, objdump or readlink, but it appears that something of that nature is being tried (a quick search with ack revealed cmELF.{h,cxx}). If interpreting the INPUT directive were to be added to that procedure, I think we would be very happy. Should I put an entry in Mantis? Thanks, Chris. -- Chris Green , FNAL CS/SCD/ADSS/SSI/SSD; 'phone (630) 840-2167; Skype: chris.h.green; IM: greenc at jabber.fnal.gov, chissgreen (AIM, Yahoo), chissg at hotmail.com (MSNM), chris.h.green (Google Talk). From brad.king at kitware.com Thu Jan 29 10:36:49 2015 From: brad.king at kitware.com (Brad King) Date: Thu, 29 Jan 2015 10:36:49 -0500 Subject: [CMake] target_link_libraries replacing fully-qualified library with -l In-Reply-To: <54CA527F.2070200@fnal.gov> References: <54C94293.6050100@fnal.gov> <54CA38A4.5090908@kitware.com> <54CA4625.8080404@fnal.gov> <54CA4C93.4000805@kitware.com> <54CA527F.2070200@fnal.gov> Message-ID: <54CA5391.3030408@kitware.com> On 01/29/2015 10:32 AM, Chris Green wrote: > I can confirm that replacing the text libtbb.so file containing the > INPUT instruction with a link to the library with the SONAME is > sufficient to solve the problem, at least as a short term workaround. > There is no importing of targets: this library is found with > find_library as part of a config.cmake file invoked as part of > find_package(). I don't know whether CMake is using readelf, objdump or > readlink, but it appears that something of that nature is being tried (a > quick search with ack revealed cmELF.{h,cxx}). If interpreting the INPUT > directive were to be added to that procedure, I think we would be very > happy. Should I put an entry in Mantis? Nils is correct that GuessLibrarySOName is used. I'd forgotten about that. If you link tothis library using a full path manually, what is recorded in the NEEDED field of the resulting binary? Without SONAME many linkers record the full path. Does INPUT avoid that? Thanks, -Brad From nilsgladitz at gmail.com Thu Jan 29 10:53:57 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Thu, 29 Jan 2015 16:53:57 +0100 Subject: [CMake] target_link_libraries replacing fully-qualified library with -l In-Reply-To: <54CA5391.3030408@kitware.com> References: <54C94293.6050100@fnal.gov> <54CA38A4.5090908@kitware.com> <54CA4625.8080404@fnal.gov> <54CA4C93.4000805@kitware.com> <54CA527F.2070200@fnal.gov> <54CA5391.3030408@kitware.com> Message-ID: <54CA5795.4060200@gmail.com> On 01/29/2015 04:36 PM, Brad King wrote: > > If you link tothis library using a full path manually, what is recorded > in the NEEDED field of the resulting binary? Without SONAME many linkers > record the full path. Does INPUT avoid that? > > Thanks, > -Brad > The actual library referenced by INPUT() [1] does have a SONAME so that is what should show up as a NEEDED entry. I am not entirely sure what would happen if the referenced library did not have a SONAME. I'd say that would be out of scope for cmake though since it is not responsible for the content of the linker script nor can it reasonably influence its interpretation. Perhaps failing to read a SONAME should imply that a SONAME is available (in context of cmComputeLinkInformation). Might be easier/more reliable than guessing if the given file is actually a linker script? Nils [1] https://sourceware.org/binutils/docs/ld/File-Commands.html From kgt at lanl.gov Thu Jan 29 10:51:10 2015 From: kgt at lanl.gov (Thompson, KT) Date: Thu, 29 Jan 2015 15:51:10 +0000 Subject: [CMake] Generated files? In-Reply-To: References: Message-ID: <0458DF31F610EF42BFC78C497E806C7B3B59FEBE@ECS-EXG-P-MB03.win.lanl.gov> Hi Chris, Why not use a foreach loop? Something like this? add_executable(myprog myprog.cpp) set( files file001 fiile002 ?) foreach( file in files) add_custom_command(OUTPUT ${file}.out COMMAND /bin/cp ${CMAKE_CURRENT_SOURCE_DIR}/${file}.in . COMMAND myprog ${file}.in ${file}.out DEPENDS ${file}.in myprog.cpp ) endforeach() For portability, you might want to use ?${CMAKE_COMMAND} ?E copy_if_different? in place of ?/bin/cp? and CMAKE_CURRENT_BINARY_DIR in place of ?.? -kt From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Chris Johnson Sent: Thursday, January 29, 2015 8:09 AM To: cmake at cmake.org Subject: [CMake] Generated files? ?I am looking for suggestions on how to solve the following problem. I need a solution which is easy to understand and safe from future maintenance errors. There is a project directory with one C++ program and a large number of "input" data files. The C++ program needs to be compiled, and then run against each of the input files to generate an output file of the same base name but with a different output suffix. E.g. from the command line it might be: % myprog file001.in file001.out Finally, the output files need to be installed in the proper location. For one input file, it might look like this: add_executable(myprog myprog.cpp) add_custom_command(OUTPUT file001.out COMMAND /bin/cp ${CMAKE_CURRENT_SOURCE_DIR}/file001.in . COMMAND myprog file001.in file001.out DEPENDS files001.in myprog.cpp ) install(FILES ${CMAKE_CURRENT_BINARY_DIR}/file001.out DESTINATION share/docs) Listing all of the input files in my CMakeLists.txt file is not a problem, but it would be nice to avoid having to list the corresponding output files. How can I build a CMakeLists.txt file which will succinctly handle this situation? -- Thanks, ..chris? -------------- next part -------------- An HTML attachment was scrubbed... URL: From petr.kmoch at gmail.com Thu Jan 29 11:15:42 2015 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Thu, 29 Jan 2015 17:15:42 +0100 Subject: [CMake] Generated files? In-Reply-To: References: Message-ID: Hi Chris. I believe a function should do the trick: function(ProcessFile inFile) get_filename_component(outFile ${inFile} NAME_WE) set(outFile ${outFile}.out) add_custom_command( OUTPUT ${outFile} COMMAND ${CMAKE_COMMAND} -E copy ${CMAKE_CURRENT_SOURCE_DIR}/${inFile} ${CMAKE_CURRENT_BINARY_DIR} COMMAND myprog ${inFile} ${outFile} DEPENDS ${inFile} myprog.cpp ) install(FILES ${CMAKE_CURRENT_BINARY_DIR}/${outFile} DESTINATION share/docs) endfunction() (Modulo syntax errors, untested) Petr On Thu, Jan 29, 2015 at 4:09 PM, Chris Johnson wrote: > ?I am looking for suggestions on how to solve the following problem. I > need a solution which is easy to understand and safe from future > maintenance errors. > > There is a project directory with one C++ program and a large number of > "input" data files. > > The C++ program needs to be compiled, and then run against each of the > input files to generate an output file of the same base name but with a > different output suffix. E.g. from the command line it might be: > > % myprog file001.in file001.out > > Finally, the output files need to be installed in the proper location. > > For one input file, it might look like this: > > add_executable(myprog myprog.cpp) > add_custom_command(OUTPUT file001.out > COMMAND /bin/cp ${CMAKE_CURRENT_SOURCE_DIR}/file001.in . > COMMAND myprog file001.in file001.out > DEPENDS files001.in myprog.cpp > ) > install(FILES ${CMAKE_CURRENT_BINARY_DIR}/file001.out DESTINATION > share/docs) > > > Listing all of the input files in my CMakeLists.txt file is not a problem, > but it would be nice to avoid having to list the corresponding output files. > > How can I build a CMakeLists.txt file which will succinctly handle this > situation? > > -- > Thanks, > ..chris? > > -- > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Thu Jan 29 11:31:33 2015 From: brad.king at kitware.com (Brad King) Date: Thu, 29 Jan 2015 11:31:33 -0500 Subject: [CMake] target_link_libraries replacing fully-qualified library with -l In-Reply-To: <54CA5795.4060200@gmail.com> References: <54C94293.6050100@fnal.gov> <54CA38A4.5090908@kitware.com> <54CA4625.8080404@fnal.gov> <54CA4C93.4000805@kitware.com> <54CA527F.2070200@fnal.gov> <54CA5391.3030408@kitware.com> <54CA5795.4060200@gmail.com> Message-ID: <54CA6065.5010402@kitware.com> On 01/29/2015 10:53 AM, Nils Gladitz wrote: > Perhaps failing to read a SONAME should imply that a SONAME is available > (in context of cmComputeLinkInformation). > > Might be easier/more reliable than guessing if the given file is > actually a linker script? We don't actually know anything about the binary format so failing to parse ELF cannot assume anything. That's why it falls back to the symlink checks and such. Ideally we should detect linker scripts and always use full paths to them to make sure the proper script is used, and then trust it to know what it is doing. -Brad From greenc at fnal.gov Thu Jan 29 11:34:49 2015 From: greenc at fnal.gov (Chris Green) Date: Thu, 29 Jan 2015 10:34:49 -0600 Subject: [CMake] target_link_libraries replacing fully-qualified library with -l In-Reply-To: <54CA5391.3030408@kitware.com> References: <54C94293.6050100@fnal.gov> <54CA38A4.5090908@kitware.com> <54CA4625.8080404@fnal.gov> <54CA4C93.4000805@kitware.com> <54CA527F.2070200@fnal.gov> <54CA5391.3030408@kitware.com> Message-ID: <54CA6129.2070806@fnal.gov> Hi, On 1/29/15 9:36 AM, Brad King wrote: > If you link tothis library using a full path manually, what is recorded > in the NEEDED field of the resulting binary? Without SONAME many linkers > record the full path. Does INPUT avoid that? With the caveat that a -L is necessary for the linker to find the sonam-ed library based on the linker script (and with uncertainties over whether the same-named library in (e.g.) /usr/lib might jump in, thereby recreating the original problem), the correct NEEDED entry does seem to be made in the linked program: $ objdump -p ../../bin/tbb_init_t-x | grep NEEDED NEEDED libtbb.so.2 NEEDED libstdc++.so.6 NEEDED libm.so.6 NEEDED libgcc_s.so.1 NEEDED libc.so.6 NEEDED librt.so.1 I am extremely uneasy about the possibility of finding the wrong library, though. Thanks, Chris. -- Chris Green , FNAL CS/SCD/ADSS/SSI/SSD; 'phone (630) 840-2167; Skype: chris.h.green; IM: greenc at jabber.fnal.gov, chissgreen (AIM, Yahoo), chissg at hotmail.com (MSNM), chris.h.green (Google Talk). From a.neundorf-work at gmx.net Thu Jan 29 12:11:44 2015 From: a.neundorf-work at gmx.net (Alexander Neundorf) Date: Thu, 29 Jan 2015 18:11:44 +0100 Subject: [CMake] target_link_libraries replacing fully-qualified library with -l In-Reply-To: <54CA4625.8080404@fnal.gov> References: <54C94293.6050100@fnal.gov> <54CA38A4.5090908@kitware.com> <54CA4625.8080404@fnal.gov> Message-ID: <1941432.UjOyNQja2Y@tuxedo.neundorf.net> On Thursday, January 29, 2015 08:39:33 Chris Green wrote: > On 1/29/15 7:41 AM, Brad King wrote: > > On 01/28/2015 03:12 PM, Chris Green wrote: > >> target_link_libraries( /X/Y/libtbb.so) > >> > >> results in link.txt files containing -ltbb. > > > > This happens when the library is in an implicit link directory, > > or possibly when the library does not have an SONAME field set. > > Thanks for this, Brad. > > Assuming that the list of implicit link directories is internal to CMake > and nobody has added to it by mistake, then I'm guessing there's no SONAME: just to make sure: you did check that the library directory is not part of LIBRARY_PATH ? Alex From greenc at fnal.gov Thu Jan 29 12:21:47 2015 From: greenc at fnal.gov (Chris Green) Date: Thu, 29 Jan 2015 11:21:47 -0600 Subject: [CMake] target_link_libraries replacing fully-qualified library with -l In-Reply-To: <1941432.UjOyNQja2Y@tuxedo.neundorf.net> References: <54C94293.6050100@fnal.gov> <54CA38A4.5090908@kitware.com> <54CA4625.8080404@fnal.gov> <1941432.UjOyNQja2Y@tuxedo.neundorf.net> Message-ID: <54CA6C2B.4040103@fnal.gov> Hi, On 1/29/15 11:11 AM, Alexander Neundorf wrote: > just to make sure: you did check that the library directory is not part of > LIBRARY_PATH ? > > Alex I have verified that the presence or absence of LIBRARY_PATH (or LD_LIBRARY_PATH) is irrelevant in the presence of a linker script. Best, Chris. -- Chris Green , FNAL CS/SCD/ADSS/SSI/SSD; 'phone (630) 840-2167; Skype: chris.h.green; IM: greenc at jabber.fnal.gov, chissgreen (AIM, Yahoo), chissg at hotmail.com (MSNM), chris.h.green (Google Talk). From rcdailey.lists at gmail.com Thu Jan 29 13:15:31 2015 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Thu, 29 Jan 2015 12:15:31 -0600 Subject: [CMake] CMake Eclipse & Resource Filters In-Reply-To: <8753712.XZ7TzcIeoO@tuxedo.neundorf.net> References: <8753712.XZ7TzcIeoO@tuxedo.neundorf.net> Message-ID: Submitted here: http://public.kitware.com/Bug/view.php?id=15382 Thanks. On Wed, Jan 28, 2015 at 3:55 PM, Alexander Neundorf wrote: > On Wednesday, January 28, 2015 12:56:24 Robert Dailey wrote: >> Hello, >> >> I generate my project using Eclipse CDT4 - Ninja. I have a >> subdirectory called "Third Party" under my source directory that >> contains boost, QT, and a number of other very large libraries. I >> notice that the C++ indexer in Eclipse processes files in these >> directories and frequently locks up my machine or crashes. Indexing >> takes up to 30 minutes if it decides to complete. >> >> Is there a way I can specify resource filters in CMake scripts? If I >> can do this, I can tell Eclipse to ignore the directories I don't want >> it to scan or care about. > > no, there's currently not. > Please enter a ticket on http://public.kitware.com/Bug > > Thanks > Alex > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake From steveire at gmail.com Thu Jan 29 14:34:52 2015 From: steveire at gmail.com (Stephen Kelly) Date: Thu, 29 Jan 2015 20:34:52 +0100 Subject: [CMake] target_link_libraries replacing fully-qualified library with -l References: <54C94293.6050100@fnal.gov> <54CA38A4.5090908@kitware.com> <54CA4625.8080404@fnal.gov> <54CA4C93.4000805@kitware.com> <54CA527F.2070200@fnal.gov> Message-ID: Chris Green wrote: > this library is found with > find_library as part of a config.cmake file invoked as part of > find_package() Consider reading http://www.cmake.org/cmake/help/v3.1/manual/cmake-packages.7.html at some point. find_library and config files don't go together. Thanks, Steve. From steveire at gmail.com Thu Jan 29 15:26:34 2015 From: steveire at gmail.com (Stephen Kelly) Date: Thu, 29 Jan 2015 21:26:34 +0100 Subject: [CMake] automoc autorcc References: Message-ID: Norbert Pfeiler wrote: > Hello, > i?m curious about 2 things and therefore wanted to ask: > > When i use qt5_add_resources and some of my resources change they get > recompiled during the next invocation of my build tool. Whereas when i use > cmakes autorcc this is not the case. This was fixed in CMake 3.1. > > Secondly, with qt5_wrap_cpp every file gets processed in parallel ? well, > because they don?t depend on each other. In contrast, automoc mocs > everything in sequence (for one target) which is a noticeable bottleneck > on an 8 core machine. This was part of the original design of the automoc feature. Maybe it could be done better, but as far as I know, no one is working on it. Thanks, Steve. From cxjohnson at gmail.com Thu Jan 29 15:36:05 2015 From: cxjohnson at gmail.com (Chris Johnson) Date: Thu, 29 Jan 2015 14:36:05 -0600 Subject: [CMake] Generated files? In-Reply-To: <0458DF31F610EF42BFC78C497E806C7B3B59FEBE@ECS-EXG-P-MB03.win.lanl.gov> References: <0458DF31F610EF42BFC78C497E806C7B3B59FEBE@ECS-EXG-P-MB03.win.lanl.gov> Message-ID: Thanks; I appreciate the suggestions. One thing that jumped out is the thought that foreach() is executed at "configuration" time, not "run" time. To me, that was counter-intuitive, but makes more sense once more thoroughly considered. But I have to admit, I've never seen anything in the documentation which lists all of the commands which execute at configuration time, and which are executed at run time. Is there such documentation? A link to it would be great. On Thu, Jan 29, 2015 at 9:51 AM, Thompson, KT wrote: > Hi Chris, > > > > Why not use a foreach loop? Something like this? > > > > add_executable(myprog myprog.cpp) > > set( files file001 fiile002 ?) > > foreach( file in files) > > add_custom_command(OUTPUT ${file}.out > > COMMAND /bin/cp ${CMAKE_CURRENT_SOURCE_DIR}/${file}.in . > > COMMAND myprog ${file}.in ${file}.out > > DEPENDS ${file}.in myprog.cpp > > ) > > endforeach() > > > > For portability, you might want to use ?${CMAKE_COMMAND} ?E > copy_if_different? in place of ?/bin/cp? and CMAKE_CURRENT_BINARY_DIR in > place of ?.? > > > > -kt > > > > *From:* CMake [mailto:cmake-bounces at cmake.org] *On Behalf Of *Chris > Johnson > *Sent:* Thursday, January 29, 2015 8:09 AM > *To:* cmake at cmake.org > *Subject:* [CMake] Generated files? > > > > ?I am looking for suggestions on how to solve the following problem. I > need a solution which is easy to understand and safe from future > maintenance errors. > > > > There is a project directory with one C++ program and a large number of > "input" data files. > > > > The C++ program needs to be compiled, and then run against each of the > input files to generate an output file of the same base name but with a > different output suffix. E.g. from the command line it might be: > > > > % myprog file001.in file001.out > > > > Finally, the output files need to be installed in the proper location. > > > > For one input file, it might look like this: > > > > add_executable(myprog myprog.cpp) > > add_custom_command(OUTPUT file001.out > > COMMAND /bin/cp ${CMAKE_CURRENT_SOURCE_DIR}/file001.in . > > COMMAND myprog file001.in file001.out > > DEPENDS files001.in myprog.cpp > > ) > > install(FILES ${CMAKE_CURRENT_BINARY_DIR}/file001.out DESTINATION > share/docs) > > > > > > Listing all of the input files in my CMakeLists.txt file is not a problem, > but it would be nice to avoid having to list the corresponding output files. > > > > How can I build a CMakeLists.txt file which will succinctly handle this > situation? > > > > -- > > Thanks, > > ..chris? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicolasbock at gmail.com Thu Jan 29 18:15:47 2015 From: nicolasbock at gmail.com (Nicolas Bock) Date: Thu, 29 Jan 2015 16:15:47 -0700 Subject: [CMake] Adding module CheckFortranCompilerFlag.cmake Message-ID: Hi, please find attached for potential inclusion into CMake a new Module that tests Fortran compiler flags. It is a modified copy of the existing CheckCCompilerFlag.cmake module. Thanks, nick -------------- next part -------------- A non-text attachment was scrubbed... Name: CheckFortranCompilerFlag.cmake Type: text/x-cmake Size: 3099 bytes Desc: not available URL: From norbert.pfeiler+cmake at gmail.com Thu Jan 29 20:41:28 2015 From: norbert.pfeiler+cmake at gmail.com (Norbert Pfeiler) Date: Fri, 30 Jan 2015 02:41:28 +0100 Subject: [CMake] automoc autorcc In-Reply-To: References: Message-ID: > > > When i use qt5_add_resources and some of my resources change they get > > recompiled during the next invocation of my build tool. Whereas when i > use > > cmakes autorcc this is not the case. > This was fixed in CMake 3.1. Well, I?m using CMake 3.1.1, so apparently it?s not. > Secondly, with qt5_wrap_cpp every file gets processed in parallel ? well, > > because they don?t depend on each other. In contrast, automoc mocs > > everything in sequence (for one target) which is a noticeable bottleneck > > on an 8 core machine. > This was part of the original design of the automoc feature. Maybe it could > be done better, but as far as I know, no one is working on it. Ok, sad to hear. Best, Norbert. 2015-01-29 21:26 GMT+01:00 Stephen Kelly : > Norbert Pfeiler wrote: > > > Hello, > > i?m curious about 2 things and therefore wanted to ask: > > > > When i use qt5_add_resources and some of my resources change they get > > recompiled during the next invocation of my build tool. Whereas when i > use > > cmakes autorcc this is not the case. > > This was fixed in CMake 3.1. > > > > > Secondly, with qt5_wrap_cpp every file gets processed in parallel ? well, > > because they don?t depend on each other. In contrast, automoc mocs > > everything in sequence (for one target) which is a noticeable bottleneck > > on an 8 core machine. > > This was part of the original design of the automoc feature. Maybe it could > be done better, but as far as I know, no one is working on it. > > Thanks, > > Steve. > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake -------------- next part -------------- An HTML attachment was scrubbed... URL: From iosif.neitzke+cmake at gmail.com Thu Jan 29 23:24:45 2015 From: iosif.neitzke+cmake at gmail.com (Iosif Neitzke) Date: Thu, 29 Jan 2015 22:24:45 -0600 Subject: [CMake] Setting CPACK_PACKAGE_FILE_NAME per COMPONENT In-Reply-To: <54C7BDE9.2020906@gmail.com> References: <54C7BDE9.2020906@gmail.com> Message-ID: Where for a single run of CPack, each component name produces a corresponding named .deb file or ...? Have you tried using CPACK_PROJECT_CONFIG_FILE [0]? This allows you to set a few options at packaging time which can change the final output package file name. [0] http://www.cmake.org/cmake/help/v3.1/module/CPack.html On Tue, Jan 27, 2015 at 10:33 AM, Rob Harris wrote: > All, > > I'm trying to have CPack create filenames in the debian-conformant format > using my component definitions. > > It looks like there was an issue in place to resolve this (0012997) by > exposing a CPACK_COMPONENT_NAME variable, but it doesn't look like it was > ever resolved/committed. > > Is there another way to solve this problem? R'ing TFM and Googling proved > fruitless. > > Thanks. > -Rob Harris > > > -- > > 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 From petr.kmoch at gmail.com Fri Jan 30 05:32:35 2015 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Fri, 30 Jan 2015 11:32:35 +0100 Subject: [CMake] Generated files? In-Reply-To: References: <0458DF31F610EF42BFC78C497E806C7B3B59FEBE@ECS-EXG-P-MB03.win.lanl.gov> Message-ID: It's not clear to me what you mean with "run" time. There are the following "times" involved in a CMake-based project: * Configure time: CMake is parsing CMakeLists.txt files and files included from those and executing ALL CMake commands found in them. Variables expansion takes place. Data structures in CMake's memory are filled. * Generate time: CMake processes the data structures in its memory to write buildsystem files (Makefiles, solutions etc.) to disk. Generator expressions are expanded. Files are generated from data specified in file(GENERATE ...) commands. cmake_install.cmake file is written based on the contents of data structures filled by install() commands. * Build time: CMake is not running (except for driving the build if you do that with `cmake --build`). The build tool (make, ninja, devenv, msbuild, ...) is running, processing the buildsystem files and generating compiled binaries. At this time, commands which were set up by add_custom_command() and add_custom_target() are executed as driven by the build tool. * Install time (optional): Running `make install` or similarly triggering the install process causes CMake to run in installation mode. This CMake reads the cmake_install.cmake file and executes the commands there. These are mainly file() commands which copy files to the desired location. CMake commands in CMakeLists.txt and included files are all executed during configure time, as the files are parsed and processed by CMake. Some of these commands have immediate effects on the outside environment (e.g. file(WRITE), execute_process(), try_compile()), some affect the CMake processing control flow (e.g. include(), foreach()), some fill in or modify CMake's data structures (e.g. set(), add_executable(), install(), add_custom_command()). So there are no CMake commands executed after configure time. The value specified in a COMMAND argument of add_custom_command() executes at build time (driven by the build system), but the add_custom_command() itself executes at CMake time. I hope I've clarified it a little bit. Petr On Thu, Jan 29, 2015 at 9:36 PM, Chris Johnson wrote: > Thanks; I appreciate the suggestions. > > One thing that jumped out is the thought that foreach() is executed at > "configuration" time, not "run" time. To me, that was counter-intuitive, > but makes more sense once more thoroughly considered. > > But I have to admit, I've never seen anything in the documentation which > lists all of the commands which execute at configuration time, and which > are executed at run time. Is there such documentation? A link to it would > be great. > > On Thu, Jan 29, 2015 at 9:51 AM, Thompson, KT wrote: > >> Hi Chris, >> >> >> >> Why not use a foreach loop? Something like this? >> >> >> >> add_executable(myprog myprog.cpp) >> >> set( files file001 fiile002 ?) >> >> foreach( file in files) >> >> add_custom_command(OUTPUT ${file}.out >> >> COMMAND /bin/cp ${CMAKE_CURRENT_SOURCE_DIR}/${file}.in . >> >> COMMAND myprog ${file}.in ${file}.out >> >> DEPENDS ${file}.in myprog.cpp >> >> ) >> >> endforeach() >> >> >> >> For portability, you might want to use ?${CMAKE_COMMAND} ?E >> copy_if_different? in place of ?/bin/cp? and CMAKE_CURRENT_BINARY_DIR in >> place of ?.? >> >> >> >> -kt >> >> >> >> *From:* CMake [mailto:cmake-bounces at cmake.org] *On Behalf Of *Chris >> Johnson >> *Sent:* Thursday, January 29, 2015 8:09 AM >> *To:* cmake at cmake.org >> *Subject:* [CMake] Generated files? >> >> >> >> ?I am looking for suggestions on how to solve the following problem. I >> need a solution which is easy to understand and safe from future >> maintenance errors. >> >> >> >> There is a project directory with one C++ program and a large number of >> "input" data files. >> >> >> >> The C++ program needs to be compiled, and then run against each of the >> input files to generate an output file of the same base name but with a >> different output suffix. E.g. from the command line it might be: >> >> >> >> % myprog file001.in file001.out >> >> >> >> Finally, the output files need to be installed in the proper location. >> >> >> >> For one input file, it might look like this: >> >> >> >> add_executable(myprog myprog.cpp) >> >> add_custom_command(OUTPUT file001.out >> >> COMMAND /bin/cp ${CMAKE_CURRENT_SOURCE_DIR}/file001.in . >> >> COMMAND myprog file001.in file001.out >> >> DEPENDS files001.in myprog.cpp >> >> ) >> >> install(FILES ${CMAKE_CURRENT_BINARY_DIR}/file001.out DESTINATION >> share/docs) >> >> >> >> >> >> Listing all of the input files in my CMakeLists.txt file is not a >> problem, but it would be nice to avoid having to list the corresponding >> output files. >> >> >> >> How can I build a CMakeLists.txt file which will succinctly handle this >> situation? >> >> >> >> -- >> >> Thanks, >> >> ..chris? >> > > > -- > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rob.harris at gmail.com Fri Jan 30 07:05:06 2015 From: rob.harris at gmail.com (Rob Harris) Date: Fri, 30 Jan 2015 07:05:06 -0500 Subject: [CMake] Setting CPACK_PACKAGE_FILE_NAME per COMPONENT In-Reply-To: References: <54C7BDE9.2020906@gmail.com> Message-ID: <54CB7372.8090401@gmail.com> On 01/29/2015 11:24 PM, Iosif Neitzke wrote: > Where for a single run of CPack, each component name produces a > corresponding named .deb file or ...? Yes. Exactly. > Have you tried using CPACK_PROJECT_CONFIG_FILE [0]? This allows you > to set a few options at packaging time which can change the final > output package file name. > > [0] http://www.cmake.org/cmake/help/v3.1/module/CPack.html Maybe I'm missing something, but how does that help me if there isn't an accessible variable that contains the name of the component actively being packaged? -R From cxjohnson at gmail.com Fri Jan 30 09:27:21 2015 From: cxjohnson at gmail.com (Chris Johnson) Date: Fri, 30 Jan 2015 08:27:21 -0600 Subject: [CMake] Generated files? In-Reply-To: References: <0458DF31F610EF42BFC78C497E806C7B3B59FEBE@ECS-EXG-P-MB03.win.lanl.gov> Message-ID: That does clarify a few things yes. Thank you. By "configure" time I had meant the first two items you listed as Configure and Generate. By "run" time I had meant what you called Build. One place I am unclear on is exactly which commands in CMakeLists.txt get translated into Build time commands in buildsystem files (in my case, make). For example, make is fairly powerful at generating substitution file names, e.g. creating prog.o from prog.cpp, or file1.out from file1.in. Make is also capable of running full shell scripts within a makefile. But there's no obvious way to drive any kind of automation from CMake that make is capable of. As a programmer, my first thought when having to process a large list of files is to do it through some sort of automation, rather than generate a brute force solution. It appears that with CMake, the best one can hope for is to automate the creation of the brute-force solution. -- Cheers, ..chris On Fri, Jan 30, 2015 at 4:32 AM, Petr Kmoch wrote: > It's not clear to me what you mean with "run" time. There are the > following "times" involved in a CMake-based project: > > * Configure time: > CMake is parsing CMakeLists.txt files and files included from those and > executing ALL CMake commands found in them. Variables expansion takes > place. Data structures in CMake's memory are filled. > > * Generate time: > CMake processes the data structures in its memory to write buildsystem > files (Makefiles, solutions etc.) to disk. Generator expressions are > expanded. Files are generated from data specified in file(GENERATE ...) > commands. cmake_install.cmake file is written based on the contents of data > structures filled by install() commands. > > * Build time: > CMake is not running (except for driving the build if you do that with > `cmake --build`). The build tool (make, ninja, devenv, msbuild, ...) is > running, processing the buildsystem files and generating compiled binaries. > At this time, commands which were set up by add_custom_command() and > add_custom_target() are executed as driven by the build tool. > > * Install time (optional): > Running `make install` or similarly triggering the install process causes > CMake to run in installation mode. This CMake reads the cmake_install.cmake > file and executes the commands there. These are mainly file() commands > which copy files to the desired location. > > CMake commands in CMakeLists.txt and included files are all executed > during configure time, as the files are parsed and processed by CMake. Some > of these commands have immediate effects on the outside environment (e.g. > file(WRITE), execute_process(), try_compile()), some affect the CMake > processing control flow (e.g. include(), foreach()), some fill in or modify > CMake's data structures (e.g. set(), add_executable(), install(), > add_custom_command()). > > So there are no CMake commands executed after configure time. The value > specified in a COMMAND argument of add_custom_command() executes at build > time (driven by the build system), but the add_custom_command() itself > executes at CMake time. > > I hope I've clarified it a little bit. > > Petr > > > > On Thu, Jan 29, 2015 at 9:36 PM, Chris Johnson > wrote: > >> Thanks; I appreciate the suggestions. >> >> One thing that jumped out is the thought that foreach() is executed at >> "configuration" time, not "run" time. To me, that was counter-intuitive, >> but makes more sense once more thoroughly considered. >> >> But I have to admit, I've never seen anything in the documentation which >> lists all of the commands which execute at configuration time, and which >> are executed at run time. Is there such documentation? A link to it would >> be great. >> >> On Thu, Jan 29, 2015 at 9:51 AM, Thompson, KT wrote: >> >>> Hi Chris, >>> >>> >>> >>> Why not use a foreach loop? Something like this? >>> >>> >>> >>> add_executable(myprog myprog.cpp) >>> >>> set( files file001 fiile002 ?) >>> >>> foreach( file in files) >>> >>> add_custom_command(OUTPUT ${file}.out >>> >>> COMMAND /bin/cp ${CMAKE_CURRENT_SOURCE_DIR}/${file}.in . >>> >>> COMMAND myprog ${file}.in ${file}.out >>> >>> DEPENDS ${file}.in myprog.cpp >>> >>> ) >>> >>> endforeach() >>> >>> >>> >>> For portability, you might want to use ?${CMAKE_COMMAND} ?E >>> copy_if_different? in place of ?/bin/cp? and CMAKE_CURRENT_BINARY_DIR in >>> place of ?.? >>> >>> >>> >>> -kt >>> >>> >>> >>> *From:* CMake [mailto:cmake-bounces at cmake.org] *On Behalf Of *Chris >>> Johnson >>> *Sent:* Thursday, January 29, 2015 8:09 AM >>> *To:* cmake at cmake.org >>> *Subject:* [CMake] Generated files? >>> >>> >>> >>> ?I am looking for suggestions on how to solve the following problem. I >>> need a solution which is easy to understand and safe from future >>> maintenance errors. >>> >>> >>> >>> There is a project directory with one C++ program and a large number of >>> "input" data files. >>> >>> >>> >>> The C++ program needs to be compiled, and then run against each of the >>> input files to generate an output file of the same base name but with a >>> different output suffix. E.g. from the command line it might be: >>> >>> >>> >>> % myprog file001.in file001.out >>> >>> >>> >>> Finally, the output files need to be installed in the proper location. >>> >>> >>> >>> For one input file, it might look like this: >>> >>> >>> >>> add_executable(myprog myprog.cpp) >>> >>> add_custom_command(OUTPUT file001.out >>> >>> COMMAND /bin/cp ${CMAKE_CURRENT_SOURCE_DIR}/file001.in . >>> >>> COMMAND myprog file001.in file001.out >>> >>> DEPENDS files001.in myprog.cpp >>> >>> ) >>> >>> install(FILES ${CMAKE_CURRENT_BINARY_DIR}/file001.out DESTINATION >>> share/docs) >>> >>> >>> >>> >>> >>> Listing all of the input files in my CMakeLists.txt file is not a >>> problem, but it would be nice to avoid having to list the corresponding >>> output files. >>> >>> >>> >>> How can I build a CMakeLists.txt file which will succinctly handle this >>> situation? >>> >>> >>> >>> -- >>> >>> Thanks, >>> >>> ..chris? >>> >> >> >> -- >> >> 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 >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iosif.neitzke+cmake at gmail.com Fri Jan 30 09:48:02 2015 From: iosif.neitzke+cmake at gmail.com (Iosif Neitzke) Date: Fri, 30 Jan 2015 08:48:02 -0600 Subject: [CMake] Setting CPACK_PACKAGE_FILE_NAME per COMPONENT In-Reply-To: <54CB7372.8090401@gmail.com> References: <54C7BDE9.2020906@gmail.com> <54CB7372.8090401@gmail.com> Message-ID: Unfortunately it would take more than one run of CPack, but you may find useful something like: in CMakeLists.txt: set( CPACK_PROJECT_CONFIG_FILE "${CMAKE_CURRENT_SOURCE_DIR}/CMakeCPackOptions.cmake" ) in CMakeCPackOptions.cmake: set( CPACK_PACKAGE_FILE_NAME "${CPACK_PACKAGE_NAME}" ) which would let you run for each component: cpack -G DEB -D CPACK_COMPONENTS_ALL="ComponentX" -P PackageNameForComponentX to produce a PackageNameForComponentX.deb for each run of cpack https://github.com/Kitware/CMake/blob/master/CMakeCPackOptions.cmake.in On Fri, Jan 30, 2015 at 6:05 AM, Rob Harris wrote: > On 01/29/2015 11:24 PM, Iosif Neitzke wrote: >> >> Where for a single run of CPack, each component name produces a >> corresponding named .deb file or ...? > > Yes. Exactly. >> >> Have you tried using CPACK_PROJECT_CONFIG_FILE [0]? This allows you >> to set a few options at packaging time which can change the final >> output package file name. >> >> [0] http://www.cmake.org/cmake/help/v3.1/module/CPack.html > > Maybe I'm missing something, but how does that help me if there isn't an > accessible variable that contains the name of the component actively being > packaged? > > -R > From zbeekman at gmail.com Fri Jan 30 09:59:38 2015 From: zbeekman at gmail.com (Zaak Beekman) Date: Fri, 30 Jan 2015 14:59:38 +0000 Subject: [CMake] Adding module CheckFortranCompilerFlag.cmake (Nicolas Bock) Message-ID: Great! I would certainly like this functionality to be officially added to CMake and in the mean time will use your module... speaking of which, it seems that it was scrubbed from the digest email, or not originally attached. Can you please send it to me? On Thu, Jan 29, 2015 at 8:42 PM wrote: > Send CMake mailing list submissions to > cmake at cmake.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://public.kitware.com/mailman/listinfo/cmake > or, via email, send a message with subject or body 'help' to > cmake-request at cmake.org > > You can reach the person managing the list at > cmake-owner at cmake.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of CMake digest..." > > > Today's Topics: > > 1. Re: Generated files? (Chris Johnson) > 2. Adding module CheckFortranCompilerFlag.cmake (Nicolas Bock) > 3. Re: automoc autorcc (Norbert Pfeiler) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 29 Jan 2015 14:36:05 -0600 > From: Chris Johnson > Cc: "cmake at cmake.org" > Subject: Re: [CMake] Generated files? > Message-ID: > ail.com> > Content-Type: text/plain; charset="utf-8" > > Thanks; I appreciate the suggestions. > > One thing that jumped out is the thought that foreach() is executed at > "configuration" time, not "run" time. To me, that was counter-intuitive, > but makes more sense once more thoroughly considered. > > But I have to admit, I've never seen anything in the documentation which > lists all of the commands which execute at configuration time, and which > are executed at run time. Is there such documentation? A link to it would > be great. > > On Thu, Jan 29, 2015 at 9:51 AM, Thompson, KT wrote: > > > Hi Chris, > > > > > > > > Why not use a foreach loop? Something like this? > > > > > > > > add_executable(myprog myprog.cpp) > > > > set( files file001 fiile002 ?) > > > > foreach( file in files) > > > > add_custom_command(OUTPUT ${file}.out > > > > COMMAND /bin/cp ${CMAKE_CURRENT_SOURCE_DIR}/${file}.in . > > > > COMMAND myprog ${file}.in ${file}.out > > > > DEPENDS ${file}.in myprog.cpp > > > > ) > > > > endforeach() > > > > > > > > For portability, you might want to use ?${CMAKE_COMMAND} ?E > > copy_if_different? in place of ?/bin/cp? and CMAKE_CURRENT_BINARY_DIR in > > place of ?.? > > > > > > > > -kt > > > > > > > > *From:* CMake [mailto:cmake-bounces at cmake.org] *On Behalf Of *Chris > > Johnson > > *Sent:* Thursday, January 29, 2015 8:09 AM > > *To:* cmake at cmake.org > > *Subject:* [CMake] Generated files? > > > > > > > > ?I am looking for suggestions on how to solve the following problem. I > > need a solution which is easy to understand and safe from future > > maintenance errors. > > > > > > > > There is a project directory with one C++ program and a large number of > > "input" data files. > > > > > > > > The C++ program needs to be compiled, and then run against each of the > > input files to generate an output file of the same base name but with a > > different output suffix. E.g. from the command line it might be: > > > > > > > > % myprog file001.in file001.out > > > > > > > > Finally, the output files need to be installed in the proper location. > > > > > > > > For one input file, it might look like this: > > > > > > > > add_executable(myprog myprog.cpp) > > > > add_custom_command(OUTPUT file001.out > > > > COMMAND /bin/cp ${CMAKE_CURRENT_SOURCE_DIR}/file001.in . > > > > COMMAND myprog file001.in file001.out > > > > DEPENDS files001.in myprog.cpp > > > > ) > > > > install(FILES ${CMAKE_CURRENT_BINARY_DIR}/file001.out DESTINATION > > share/docs) > > > > > > > > > > > > Listing all of the input files in my CMakeLists.txt file is not a > problem, > > but it would be nice to avoid having to list the corresponding output > files. > > > > > > > > How can I build a CMakeLists.txt file which will succinctly handle this > > situation? > > > > > > > > -- > > > > Thanks, > > > > ..chris? > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: 129/e171c6df/attachment-0001.html> > > ------------------------------ > > Message: 2 > Date: Thu, 29 Jan 2015 16:15:47 -0700 > From: Nicolas Bock > To: "cmake at cmake.org" > Subject: [CMake] Adding module CheckFortranCompilerFlag.cmake > Message-ID: > gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hi, > > please find attached for potential inclusion into CMake a new Module > that tests Fortran compiler flags. It is a modified copy of the > existing CheckCCompilerFlag.cmake module. > > Thanks, > > nick > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: CheckFortranCompilerFlag.cmake > Type: text/x-cmake > Size: 3099 bytes > Desc: not available > URL: 129/2c91681a/attachment-0001.bin> > > ------------------------------ > > Message: 3 > Date: Fri, 30 Jan 2015 02:41:28 +0100 > From: Norbert Pfeiler > To: Stephen Kelly > Cc: cmake at cmake.org > Subject: Re: [CMake] automoc autorcc > Message-ID: > gmail.com> > Content-Type: text/plain; charset="utf-8" > > > > > > When i use qt5_add_resources and some of my resources change they get > > > recompiled during the next invocation of my build tool. Whereas when i > > use > > > cmakes autorcc this is not the case. > > This was fixed in CMake 3.1. > > > Well, I?m using CMake 3.1.1, so apparently it?s not. > > > Secondly, with qt5_wrap_cpp every file gets processed in parallel ? well, > > > because they don?t depend on each other. In contrast, automoc mocs > > > everything in sequence (for one target) which is a noticeable > bottleneck > > > on an 8 core machine. > > This was part of the original design of the automoc feature. Maybe it > could > > be done better, but as far as I know, no one is working on it. > > > Ok, sad to hear. > > Best, Norbert. > > 2015-01-29 21:26 GMT+01:00 Stephen Kelly : > > > Norbert Pfeiler wrote: > > > > > Hello, > > > i?m curious about 2 things and therefore wanted to ask: > > > > > > When i use qt5_add_resources and some of my resources change they get > > > recompiled during the next invocation of my build tool. Whereas when i > > use > > > cmakes autorcc this is not the case. > > > > This was fixed in CMake 3.1. > > > > > > > > Secondly, with qt5_wrap_cpp every file gets processed in parallel ? > well, > > > because they don?t depend on each other. In contrast, automoc mocs > > > everything in sequence (for one target) which is a noticeable > bottleneck > > > on an 8 core machine. > > > > This was part of the original design of the automoc feature. Maybe it > could > > be done better, but as far as I know, no one is working on it. > > > > Thanks, > > > > Steve. > > > > > > -- > > > > Powered by www.kitware.com > > > > Please keep messages on-topic and check the CMake FAQ at: > > http://www.cmake.org/Wiki/CMake_FAQ > > > > Kitware offers various services to support the CMake community. For more > > information on each offering, please visit: > > > > CMake Support: http://cmake.org/cmake/help/support.html > > CMake Consulting: http://cmake.org/cmake/help/consulting.html > > CMake Training Courses: http://cmake.org/cmake/help/training.html > > > > Visit other Kitware open-source projects at > > http://www.kitware.com/opensource/opensource.html > > > > Follow this link to subscribe/unsubscribe: > > http://public.kitware.com/mailman/listinfo/cmake > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: 130/54f2085c/attachment.html> > > ------------------------------ > > Subject: Digest Footer > > -- > > 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/opensou > rce/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > > ------------------------------ > > End of CMake Digest, Vol 129, Issue 46 > ************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: From petr.kmoch at gmail.com Fri Jan 30 10:11:04 2015 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Fri, 30 Jan 2015 16:11:04 +0100 Subject: [CMake] Generated files? In-Reply-To: References: <0458DF31F610EF42BFC78C497E806C7B3B59FEBE@ECS-EXG-P-MB03.win.lanl.gov> Message-ID: As you say, **make** is fairly powerful at this. Other build tools may not be, it might even be an alien concept to them. AFAIK, Ninja requires an explicit list of files & dependencies, for example. Visual Studio solutions can only contain explicitly listed files too. CMake projects are supposed to work with all generators which CMake supports (within reason). There are some generator-specific features in CMake, but the intent is to keep the set of these to a minimum. The list of CMake commands which directly create build-time "commands" (such as Makefile rules) is rather short: add_custom_command() add_custom_target() add_executable() add_library() Other commands modify the buildsystem (e.g. add_definitions(), target_link_libraries(), or setting properties such as COMPILE_OPTIONS), but they don't really add "commands" to it. Petr On Fri, Jan 30, 2015 at 3:27 PM, Chris Johnson wrote: > That does clarify a few things yes. Thank you. > > By "configure" time I had meant the first two items you listed as > Configure and Generate. By "run" time I had meant what you called Build. > > One place I am unclear on is exactly which commands in CMakeLists.txt get > translated into Build time commands in buildsystem files (in my case, > make). For example, make is fairly powerful at generating substitution > file names, e.g. creating prog.o from prog.cpp, or file1.out from file1.in. > Make is also capable of running full shell scripts within a makefile. But > there's no obvious way to drive any kind of automation from CMake that make > is capable of. > > As a programmer, my first thought when having to process a large list of > files is to do it through some sort of automation, rather than generate a > brute force solution. It appears that with CMake, the best one can hope > for is to automate the creation of the brute-force solution. > > -- > Cheers, > ..chris > > On Fri, Jan 30, 2015 at 4:32 AM, Petr Kmoch wrote: > >> It's not clear to me what you mean with "run" time. There are the >> following "times" involved in a CMake-based project: >> >> * Configure time: >> CMake is parsing CMakeLists.txt files and files included from those and >> executing ALL CMake commands found in them. Variables expansion takes >> place. Data structures in CMake's memory are filled. >> >> * Generate time: >> CMake processes the data structures in its memory to write buildsystem >> files (Makefiles, solutions etc.) to disk. Generator expressions are >> expanded. Files are generated from data specified in file(GENERATE ...) >> commands. cmake_install.cmake file is written based on the contents of data >> structures filled by install() commands. >> >> * Build time: >> CMake is not running (except for driving the build if you do that with >> `cmake --build`). The build tool (make, ninja, devenv, msbuild, ...) is >> running, processing the buildsystem files and generating compiled binaries. >> At this time, commands which were set up by add_custom_command() and >> add_custom_target() are executed as driven by the build tool. >> >> * Install time (optional): >> Running `make install` or similarly triggering the install process causes >> CMake to run in installation mode. This CMake reads the cmake_install.cmake >> file and executes the commands there. These are mainly file() commands >> which copy files to the desired location. >> >> CMake commands in CMakeLists.txt and included files are all executed >> during configure time, as the files are parsed and processed by CMake. Some >> of these commands have immediate effects on the outside environment (e.g. >> file(WRITE), execute_process(), try_compile()), some affect the CMake >> processing control flow (e.g. include(), foreach()), some fill in or modify >> CMake's data structures (e.g. set(), add_executable(), install(), >> add_custom_command()). >> >> So there are no CMake commands executed after configure time. The value >> specified in a COMMAND argument of add_custom_command() executes at build >> time (driven by the build system), but the add_custom_command() itself >> executes at CMake time. >> >> I hope I've clarified it a little bit. >> >> Petr >> >> >> >> On Thu, Jan 29, 2015 at 9:36 PM, Chris Johnson >> wrote: >> >>> Thanks; I appreciate the suggestions. >>> >>> One thing that jumped out is the thought that foreach() is executed at >>> "configuration" time, not "run" time. To me, that was counter-intuitive, >>> but makes more sense once more thoroughly considered. >>> >>> But I have to admit, I've never seen anything in the documentation which >>> lists all of the commands which execute at configuration time, and which >>> are executed at run time. Is there such documentation? A link to it would >>> be great. >>> >>> On Thu, Jan 29, 2015 at 9:51 AM, Thompson, KT wrote: >>> >>>> Hi Chris, >>>> >>>> >>>> >>>> Why not use a foreach loop? Something like this? >>>> >>>> >>>> >>>> add_executable(myprog myprog.cpp) >>>> >>>> set( files file001 fiile002 ?) >>>> >>>> foreach( file in files) >>>> >>>> add_custom_command(OUTPUT ${file}.out >>>> >>>> COMMAND /bin/cp ${CMAKE_CURRENT_SOURCE_DIR}/${file}.in . >>>> >>>> COMMAND myprog ${file}.in ${file}.out >>>> >>>> DEPENDS ${file}.in myprog.cpp >>>> >>>> ) >>>> >>>> endforeach() >>>> >>>> >>>> >>>> For portability, you might want to use ?${CMAKE_COMMAND} ?E >>>> copy_if_different? in place of ?/bin/cp? and CMAKE_CURRENT_BINARY_DIR in >>>> place of ?.? >>>> >>>> >>>> >>>> -kt >>>> >>>> >>>> >>>> *From:* CMake [mailto:cmake-bounces at cmake.org] *On Behalf Of *Chris >>>> Johnson >>>> *Sent:* Thursday, January 29, 2015 8:09 AM >>>> *To:* cmake at cmake.org >>>> *Subject:* [CMake] Generated files? >>>> >>>> >>>> >>>> ?I am looking for suggestions on how to solve the following problem. >>>> I need a solution which is easy to understand and safe from future >>>> maintenance errors. >>>> >>>> >>>> >>>> There is a project directory with one C++ program and a large number of >>>> "input" data files. >>>> >>>> >>>> >>>> The C++ program needs to be compiled, and then run against each of the >>>> input files to generate an output file of the same base name but with a >>>> different output suffix. E.g. from the command line it might be: >>>> >>>> >>>> >>>> % myprog file001.in file001.out >>>> >>>> >>>> >>>> Finally, the output files need to be installed in the proper location. >>>> >>>> >>>> >>>> For one input file, it might look like this: >>>> >>>> >>>> >>>> add_executable(myprog myprog.cpp) >>>> >>>> add_custom_command(OUTPUT file001.out >>>> >>>> COMMAND /bin/cp ${CMAKE_CURRENT_SOURCE_DIR}/file001.in . >>>> >>>> COMMAND myprog file001.in file001.out >>>> >>>> DEPENDS files001.in myprog.cpp >>>> >>>> ) >>>> >>>> install(FILES ${CMAKE_CURRENT_BINARY_DIR}/file001.out DESTINATION >>>> share/docs) >>>> >>>> >>>> >>>> >>>> >>>> Listing all of the input files in my CMakeLists.txt file is not a >>>> problem, but it would be nice to avoid having to list the corresponding >>>> output files. >>>> >>>> >>>> >>>> How can I build a CMakeLists.txt file which will succinctly handle this >>>> situation? >>>> >>>> >>>> >>>> -- >>>> >>>> Thanks, >>>> >>>> ..chris? >>>> >>> >>> >>> -- >>> >>> 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 >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From d3ck0r at gmail.com Fri Jan 30 10:18:05 2015 From: d3ck0r at gmail.com (J Decker) Date: Fri, 30 Jan 2015 07:18:05 -0800 Subject: [CMake] Generated files? In-Reply-To: References: <0458DF31F610EF42BFC78C497E806C7B3B59FEBE@ECS-EXG-P-MB03.win.lanl.gov> Message-ID: file(GLOB ... ) might be of interest to get the list of files -------------- next part -------------- An HTML attachment was scrubbed... URL: From cxjohnson at gmail.com Fri Jan 30 10:40:58 2015 From: cxjohnson at gmail.com (Chris Johnson) Date: Fri, 30 Jan 2015 09:40:58 -0600 Subject: [CMake] Generated files? In-Reply-To: References: <0458DF31F610EF42BFC78C497E806C7B3B59FEBE@ECS-EXG-P-MB03.win.lanl.gov> Message-ID: Petr, thanks. That makes a lot of sense. Now I am struggling with causing all of these files to be generated when I do the default build target, e.g. just "make" in the build directory. That is, I want myprog to be compiled, and then all of the files processed by it with just one build command. I assume that's possible, but have not quite yet been able to make it happen. On Fri, Jan 30, 2015 at 9:11 AM, Petr Kmoch wrote: > As you say, **make** is fairly powerful at this. Other build tools may not > be, it might even be an alien concept to them. AFAIK, Ninja requires an > explicit list of files & dependencies, for example. Visual Studio solutions > can only contain explicitly listed files too. > > CMake projects are supposed to work with all generators which CMake > supports (within reason). There are some generator-specific features in > CMake, but the intent is to keep the set of these to a minimum. > > The list of CMake commands which directly create build-time "commands" > (such as Makefile rules) is rather short: > > add_custom_command() > add_custom_target() > add_executable() > add_library() > > Other commands modify the buildsystem (e.g. add_definitions(), > target_link_libraries(), or setting properties such as COMPILE_OPTIONS), > but they don't really add "commands" to it. > > Petr > > > On Fri, Jan 30, 2015 at 3:27 PM, Chris Johnson > wrote: > >> That does clarify a few things yes. Thank you. >> >> By "configure" time I had meant the first two items you listed as >> Configure and Generate. By "run" time I had meant what you called Build. >> >> One place I am unclear on is exactly which commands in CMakeLists.txt get >> translated into Build time commands in buildsystem files (in my case, >> make). For example, make is fairly powerful at generating substitution >> file names, e.g. creating prog.o from prog.cpp, or file1.out from >> file1.in. Make is also capable of running full shell scripts within a >> makefile. But there's no obvious way to drive any kind of automation from >> CMake that make is capable of. >> >> As a programmer, my first thought when having to process a large list of >> files is to do it through some sort of automation, rather than generate a >> brute force solution. It appears that with CMake, the best one can hope >> for is to automate the creation of the brute-force solution. >> >> -- >> Cheers, >> ..chris >> >> On Fri, Jan 30, 2015 at 4:32 AM, Petr Kmoch wrote: >> >>> It's not clear to me what you mean with "run" time. There are the >>> following "times" involved in a CMake-based project: >>> >>> * Configure time: >>> CMake is parsing CMakeLists.txt files and files included from those and >>> executing ALL CMake commands found in them. Variables expansion takes >>> place. Data structures in CMake's memory are filled. >>> >>> * Generate time: >>> CMake processes the data structures in its memory to write buildsystem >>> files (Makefiles, solutions etc.) to disk. Generator expressions are >>> expanded. Files are generated from data specified in file(GENERATE ...) >>> commands. cmake_install.cmake file is written based on the contents of data >>> structures filled by install() commands. >>> >>> * Build time: >>> CMake is not running (except for driving the build if you do that with >>> `cmake --build`). The build tool (make, ninja, devenv, msbuild, ...) is >>> running, processing the buildsystem files and generating compiled binaries. >>> At this time, commands which were set up by add_custom_command() and >>> add_custom_target() are executed as driven by the build tool. >>> >>> * Install time (optional): >>> Running `make install` or similarly triggering the install process >>> causes CMake to run in installation mode. This CMake reads the >>> cmake_install.cmake file and executes the commands there. These are mainly >>> file() commands which copy files to the desired location. >>> >>> CMake commands in CMakeLists.txt and included files are all executed >>> during configure time, as the files are parsed and processed by CMake. Some >>> of these commands have immediate effects on the outside environment (e.g. >>> file(WRITE), execute_process(), try_compile()), some affect the CMake >>> processing control flow (e.g. include(), foreach()), some fill in or modify >>> CMake's data structures (e.g. set(), add_executable(), install(), >>> add_custom_command()). >>> >>> So there are no CMake commands executed after configure time. The value >>> specified in a COMMAND argument of add_custom_command() executes at build >>> time (driven by the build system), but the add_custom_command() itself >>> executes at CMake time. >>> >>> I hope I've clarified it a little bit. >>> >>> Petr >>> >>> >>> >>> On Thu, Jan 29, 2015 at 9:36 PM, Chris Johnson >>> wrote: >>> >>>> Thanks; I appreciate the suggestions. >>>> >>>> One thing that jumped out is the thought that foreach() is executed at >>>> "configuration" time, not "run" time. To me, that was counter-intuitive, >>>> but makes more sense once more thoroughly considered. >>>> >>>> But I have to admit, I've never seen anything in the documentation >>>> which lists all of the commands which execute at configuration time, and >>>> which are executed at run time. Is there such documentation? A link to it >>>> would be great. >>>> >>>> On Thu, Jan 29, 2015 at 9:51 AM, Thompson, KT wrote: >>>> >>>>> Hi Chris, >>>>> >>>>> >>>>> >>>>> Why not use a foreach loop? Something like this? >>>>> >>>>> >>>>> >>>>> add_executable(myprog myprog.cpp) >>>>> >>>>> set( files file001 fiile002 ?) >>>>> >>>>> foreach( file in files) >>>>> >>>>> add_custom_command(OUTPUT ${file}.out >>>>> >>>>> COMMAND /bin/cp ${CMAKE_CURRENT_SOURCE_DIR}/${file}.in . >>>>> >>>>> COMMAND myprog ${file}.in ${file}.out >>>>> >>>>> DEPENDS ${file}.in myprog.cpp >>>>> >>>>> ) >>>>> >>>>> endforeach() >>>>> >>>>> >>>>> >>>>> For portability, you might want to use ?${CMAKE_COMMAND} ?E >>>>> copy_if_different? in place of ?/bin/cp? and CMAKE_CURRENT_BINARY_DIR in >>>>> place of ?.? >>>>> >>>>> >>>>> >>>>> -kt >>>>> >>>>> >>>>> >>>>> *From:* CMake [mailto:cmake-bounces at cmake.org] *On Behalf Of *Chris >>>>> Johnson >>>>> *Sent:* Thursday, January 29, 2015 8:09 AM >>>>> *To:* cmake at cmake.org >>>>> *Subject:* [CMake] Generated files? >>>>> >>>>> >>>>> >>>>> ?I am looking for suggestions on how to solve the following problem. >>>>> I need a solution which is easy to understand and safe from future >>>>> maintenance errors. >>>>> >>>>> >>>>> >>>>> There is a project directory with one C++ program and a large number >>>>> of "input" data files. >>>>> >>>>> >>>>> >>>>> The C++ program needs to be compiled, and then run against each of the >>>>> input files to generate an output file of the same base name but with a >>>>> different output suffix. E.g. from the command line it might be: >>>>> >>>>> >>>>> >>>>> % myprog file001.in file001.out >>>>> >>>>> >>>>> >>>>> Finally, the output files need to be installed in the proper location. >>>>> >>>>> >>>>> >>>>> For one input file, it might look like this: >>>>> >>>>> >>>>> >>>>> add_executable(myprog myprog.cpp) >>>>> >>>>> add_custom_command(OUTPUT file001.out >>>>> >>>>> COMMAND /bin/cp ${CMAKE_CURRENT_SOURCE_DIR}/file001.in . >>>>> >>>>> COMMAND myprog file001.in file001.out >>>>> >>>>> DEPENDS files001.in myprog.cpp >>>>> >>>>> ) >>>>> >>>>> install(FILES ${CMAKE_CURRENT_BINARY_DIR}/file001.out DESTINATION >>>>> share/docs) >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Listing all of the input files in my CMakeLists.txt file is not a >>>>> problem, but it would be nice to avoid having to list the corresponding >>>>> output files. >>>>> >>>>> >>>>> >>>>> How can I build a CMakeLists.txt file which will succinctly handle >>>>> this situation? >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> Thanks, >>>>> >>>>> ..chris? >>>>> >>>> >>>> >>>> -- >>>> >>>> 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 >>>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.hoffman at kitware.com Fri Jan 30 11:24:06 2015 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Fri, 30 Jan 2015 11:24:06 -0500 Subject: [CMake] Generated files? In-Reply-To: References: <0458DF31F610EF42BFC78C497E806C7B3B59FEBE@ECS-EXG-P-MB03.win.lanl.gov> Message-ID: <54CBB026.2040200@kitware.com> On 1/30/2015 10:40 AM, Chris Johnson wrote: > Petr, thanks. That makes a lot of sense. > > Now I am struggling with causing all of these files to be generated when > I do the default build target, e.g. just "make" in the build directory. > That is, I want myprog to be compiled, and then all of the files > processed by it with just one build command. I assume that's possible, > but have not quite yet been able to make it happen. Something has to consume the output files. If you have a custom command that produces files, those files have to be part of a target or the commands will never get used. -Bill From petr.kmoch at gmail.com Fri Jan 30 11:28:55 2015 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Fri, 30 Jan 2015 17:28:55 +0100 Subject: [CMake] Generated files? In-Reply-To: References: <0458DF31F610EF42BFC78C497E806C7B3B59FEBE@ECS-EXG-P-MB03.win.lanl.gov> Message-ID: I believe the classic "driving target" approach could be used here. Add a custom target which will drive the custom commands by depending on their outputs: add_custom_target( RunMyProg ALL DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/file001.out ${CMAKE_CURRENT_BINARY_DIR}/file002.out #... COMMENT "Processing files with MyProg" ) Notice the ALL after the target name - this makes the target part of 'make all' or equivalent. Custom targets are always considered out of date (always rebuilt), but this one has no COMMAND and so building it does nothing. It does make sure all its dependencies (the .out files) are up to date, though, and if they are not, it will run the rules to build them. These rules are the custom commands you've created earlier. This "custom target driving custom commands" is a very idiomatic pattern in CMake. Of course, you don't want to list the files by hand. You could modify my earlier function in one of two ways: 1. Have each invocation append to a list: set(OutputFileList "") function(ProcessFile inFile) get_filename_component(outFile ${inFile} NAME_WE) set(outFile ${inFile}.out) add_custom_command( OUTPUT ${outFile} COMMAND ${CMAKE_COMMAND} -E copy ${CMAKE_CURRENT_SOURCE_DIR}/${inFile} ${CMAKE_CURRENT_BINARY_DIR} COMMAND myprog ${inFile} ${outFile} DEPENDS ${inFile} myprog.cpp ) install(FILES ${CMAKE_CURRENT_BINARY_DIR}/${outFile} DESTINATION share/docs) set(OutputFileList ${OutputFileList} ${CMAKE_CURRENT_BINARY_DIR}/${outFile} PARENT_SCOPE) # This line is new endfunction() # process files ProcessFile(file001.in) ProcessFile(file002.in) ProcessFile(file003.in) # now use the list in the custom target: add_custom_target( RunMyProg ALL DEPENDS ${OutputFileList} COMMENT "Processing files with MyProg" ) Or, 2., refactor the function to take a list of files and do everything itself: function(ProcessFiles) set(OutputFileList "") foreach(inFile IN LISTS ARGN) get_filename_component(outFile ${inFile} NAME_WE) set(outFile ${inFile}.out) add_custom_command( OUTPUT ${outFile} COMMAND ${CMAKE_COMMAND} -E copy ${CMAKE_CURRENT_SOURCE_DIR}/${inFile} ${CMAKE_CURRENT_BINARY_DIR} COMMAND myprog ${inFile} ${outFile} DEPENDS ${inFile} myprog.cpp ) list(APPEND OutputFileList ${CMAKE_CURRENT_BINARY_DIR}/${outFile}) endforeach() install(FILES ${OutputFileList} DESTINATION share/docs) add_custom_target( RunMyProg ALL DEPENDS ${OutputFileList} COMMENT "Processing files with MyProg" ) endfunction() # now just call it once with the list of files: ProcessFiles( file001.in file002.in file003.in ) You can naturally enlist file(GLOB) to grab the list of files, as J Decker suggests. The downside, as with any list of source files, is that CMake will not know that it needs to re-run when you simply add a new file which matches the glob. If you list the files explicitly, you have to edit the CMakeList to add the file, and CMake will know to re-run at next build. Petr On Fri, Jan 30, 2015 at 4:40 PM, Chris Johnson wrote: > Petr, thanks. That makes a lot of sense. > > Now I am struggling with causing all of these files to be generated when I > do the default build target, e.g. just "make" in the build directory. That > is, I want myprog to be compiled, and then all of the files processed by it > with just one build command. I assume that's possible, but have not quite > yet been able to make it happen. > > On Fri, Jan 30, 2015 at 9:11 AM, Petr Kmoch wrote: > >> As you say, **make** is fairly powerful at this. Other build tools may >> not be, it might even be an alien concept to them. AFAIK, Ninja requires an >> explicit list of files & dependencies, for example. Visual Studio solutions >> can only contain explicitly listed files too. >> >> CMake projects are supposed to work with all generators which CMake >> supports (within reason). There are some generator-specific features in >> CMake, but the intent is to keep the set of these to a minimum. >> >> The list of CMake commands which directly create build-time "commands" >> (such as Makefile rules) is rather short: >> >> add_custom_command() >> add_custom_target() >> add_executable() >> add_library() >> >> Other commands modify the buildsystem (e.g. add_definitions(), >> target_link_libraries(), or setting properties such as COMPILE_OPTIONS), >> but they don't really add "commands" to it. >> >> Petr >> >> >> On Fri, Jan 30, 2015 at 3:27 PM, Chris Johnson >> wrote: >> >>> That does clarify a few things yes. Thank you. >>> >>> By "configure" time I had meant the first two items you listed as >>> Configure and Generate. By "run" time I had meant what you called Build. >>> >>> One place I am unclear on is exactly which commands in CMakeLists.txt >>> get translated into Build time commands in buildsystem files (in my case, >>> make). For example, make is fairly powerful at generating substitution >>> file names, e.g. creating prog.o from prog.cpp, or file1.out from >>> file1.in. Make is also capable of running full shell scripts within a >>> makefile. But there's no obvious way to drive any kind of automation from >>> CMake that make is capable of. >>> >>> As a programmer, my first thought when having to process a large list of >>> files is to do it through some sort of automation, rather than generate a >>> brute force solution. It appears that with CMake, the best one can hope >>> for is to automate the creation of the brute-force solution. >>> >>> -- >>> Cheers, >>> ..chris >>> >>> On Fri, Jan 30, 2015 at 4:32 AM, Petr Kmoch >>> wrote: >>> >>>> It's not clear to me what you mean with "run" time. There are the >>>> following "times" involved in a CMake-based project: >>>> >>>> * Configure time: >>>> CMake is parsing CMakeLists.txt files and files included from those and >>>> executing ALL CMake commands found in them. Variables expansion takes >>>> place. Data structures in CMake's memory are filled. >>>> >>>> * Generate time: >>>> CMake processes the data structures in its memory to write buildsystem >>>> files (Makefiles, solutions etc.) to disk. Generator expressions are >>>> expanded. Files are generated from data specified in file(GENERATE ...) >>>> commands. cmake_install.cmake file is written based on the contents of data >>>> structures filled by install() commands. >>>> >>>> * Build time: >>>> CMake is not running (except for driving the build if you do that with >>>> `cmake --build`). The build tool (make, ninja, devenv, msbuild, ...) is >>>> running, processing the buildsystem files and generating compiled binaries. >>>> At this time, commands which were set up by add_custom_command() and >>>> add_custom_target() are executed as driven by the build tool. >>>> >>>> * Install time (optional): >>>> Running `make install` or similarly triggering the install process >>>> causes CMake to run in installation mode. This CMake reads the >>>> cmake_install.cmake file and executes the commands there. These are mainly >>>> file() commands which copy files to the desired location. >>>> >>>> CMake commands in CMakeLists.txt and included files are all executed >>>> during configure time, as the files are parsed and processed by CMake. Some >>>> of these commands have immediate effects on the outside environment (e.g. >>>> file(WRITE), execute_process(), try_compile()), some affect the CMake >>>> processing control flow (e.g. include(), foreach()), some fill in or modify >>>> CMake's data structures (e.g. set(), add_executable(), install(), >>>> add_custom_command()). >>>> >>>> So there are no CMake commands executed after configure time. The value >>>> specified in a COMMAND argument of add_custom_command() executes at build >>>> time (driven by the build system), but the add_custom_command() itself >>>> executes at CMake time. >>>> >>>> I hope I've clarified it a little bit. >>>> >>>> Petr >>>> >>>> >>>> >>>> On Thu, Jan 29, 2015 at 9:36 PM, Chris Johnson >>>> wrote: >>>> >>>>> Thanks; I appreciate the suggestions. >>>>> >>>>> One thing that jumped out is the thought that foreach() is executed at >>>>> "configuration" time, not "run" time. To me, that was counter-intuitive, >>>>> but makes more sense once more thoroughly considered. >>>>> >>>>> But I have to admit, I've never seen anything in the documentation >>>>> which lists all of the commands which execute at configuration time, and >>>>> which are executed at run time. Is there such documentation? A link to it >>>>> would be great. >>>>> >>>>> On Thu, Jan 29, 2015 at 9:51 AM, Thompson, KT wrote: >>>>> >>>>>> Hi Chris, >>>>>> >>>>>> >>>>>> >>>>>> Why not use a foreach loop? Something like this? >>>>>> >>>>>> >>>>>> >>>>>> add_executable(myprog myprog.cpp) >>>>>> >>>>>> set( files file001 fiile002 ?) >>>>>> >>>>>> foreach( file in files) >>>>>> >>>>>> add_custom_command(OUTPUT ${file}.out >>>>>> >>>>>> COMMAND /bin/cp ${CMAKE_CURRENT_SOURCE_DIR}/${file}.in . >>>>>> >>>>>> COMMAND myprog ${file}.in ${file}.out >>>>>> >>>>>> DEPENDS ${file}.in myprog.cpp >>>>>> >>>>>> ) >>>>>> >>>>>> endforeach() >>>>>> >>>>>> >>>>>> >>>>>> For portability, you might want to use ?${CMAKE_COMMAND} ?E >>>>>> copy_if_different? in place of ?/bin/cp? and CMAKE_CURRENT_BINARY_DIR in >>>>>> place of ?.? >>>>>> >>>>>> >>>>>> >>>>>> -kt >>>>>> >>>>>> >>>>>> >>>>>> *From:* CMake [mailto:cmake-bounces at cmake.org] *On Behalf Of *Chris >>>>>> Johnson >>>>>> *Sent:* Thursday, January 29, 2015 8:09 AM >>>>>> *To:* cmake at cmake.org >>>>>> *Subject:* [CMake] Generated files? >>>>>> >>>>>> >>>>>> >>>>>> ?I am looking for suggestions on how to solve the following >>>>>> problem. I need a solution which is easy to understand and safe from >>>>>> future maintenance errors. >>>>>> >>>>>> >>>>>> >>>>>> There is a project directory with one C++ program and a large number >>>>>> of "input" data files. >>>>>> >>>>>> >>>>>> >>>>>> The C++ program needs to be compiled, and then run against each of >>>>>> the input files to generate an output file of the same base name but with a >>>>>> different output suffix. E.g. from the command line it might be: >>>>>> >>>>>> >>>>>> >>>>>> % myprog file001.in file001.out >>>>>> >>>>>> >>>>>> >>>>>> Finally, the output files need to be installed in the proper location. >>>>>> >>>>>> >>>>>> >>>>>> For one input file, it might look like this: >>>>>> >>>>>> >>>>>> >>>>>> add_executable(myprog myprog.cpp) >>>>>> >>>>>> add_custom_command(OUTPUT file001.out >>>>>> >>>>>> COMMAND /bin/cp ${CMAKE_CURRENT_SOURCE_DIR}/file001.in . >>>>>> >>>>>> COMMAND myprog file001.in file001.out >>>>>> >>>>>> DEPENDS files001.in myprog.cpp >>>>>> >>>>>> ) >>>>>> >>>>>> install(FILES ${CMAKE_CURRENT_BINARY_DIR}/file001.out DESTINATION >>>>>> share/docs) >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Listing all of the input files in my CMakeLists.txt file is not a >>>>>> problem, but it would be nice to avoid having to list the corresponding >>>>>> output files. >>>>>> >>>>>> >>>>>> >>>>>> How can I build a CMakeLists.txt file which will succinctly handle >>>>>> this situation? >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> Thanks, >>>>>> >>>>>> ..chris? >>>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> 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 >>>>> >>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cxjohnson at gmail.com Fri Jan 30 12:07:29 2015 From: cxjohnson at gmail.com (Chris Johnson) Date: Fri, 30 Jan 2015 11:07:29 -0600 Subject: [CMake] Generated files? In-Reply-To: References: <0458DF31F610EF42BFC78C497E806C7B3B59FEBE@ECS-EXG-P-MB03.win.lanl.gov> Message-ID: I'm trying to use the method outlined in your #2, with the list of files. But I get circular dependency errors, with messages like this one (for each file): make[2]: Circular validate/X12_Standards/997_5010.x12 <- validate/X12_Standards/997_5010.x12 dependency dropped. On Fri, Jan 30, 2015 at 10:28 AM, Petr Kmoch wrote: > I believe the classic "driving target" approach could be used here. Add a > custom target which will drive the custom commands by depending on their > outputs: > > add_custom_target( > RunMyProg ALL > DEPENDS > ${CMAKE_CURRENT_BINARY_DIR}/file001.out > ${CMAKE_CURRENT_BINARY_DIR}/file002.out > #... > COMMENT "Processing files with MyProg" > ) > > Notice the ALL after the target name - this makes the target part of 'make > all' or equivalent. > > Custom targets are always considered out of date (always rebuilt), but > this one has no COMMAND and so building it does nothing. It does make sure > all its dependencies (the .out files) are up to date, though, and if they > are not, it will run the rules to build them. These rules are the custom > commands you've created earlier. > > This "custom target driving custom commands" is a very idiomatic pattern > in CMake. > > Of course, you don't want to list the files by hand. You could modify my > earlier function in one of two ways: > > 1. Have each invocation append to a list: > > set(OutputFileList "") > > function(ProcessFile inFile) > get_filename_component(outFile ${inFile} NAME_WE) > set(outFile ${inFile}.out) > add_custom_command( > OUTPUT ${outFile} > COMMAND ${CMAKE_COMMAND} -E copy ${CMAKE_CURRENT_SOURCE_DIR}/${inFile} > ${CMAKE_CURRENT_BINARY_DIR} > COMMAND myprog ${inFile} ${outFile} > DEPENDS ${inFile} myprog.cpp > ) > install(FILES ${CMAKE_CURRENT_BINARY_DIR}/${outFile} DESTINATION > share/docs) > set(OutputFileList ${OutputFileList} > ${CMAKE_CURRENT_BINARY_DIR}/${outFile} PARENT_SCOPE) # This line is new > endfunction() > > # process files > ProcessFile(file001.in) > ProcessFile(file002.in) > ProcessFile(file003.in) > > > # now use the list in the custom target: > add_custom_target( > RunMyProg ALL > DEPENDS ${OutputFileList} > COMMENT "Processing files with MyProg" > ) > > > Or, 2., refactor the function to take a list of files and do everything > itself: > > function(ProcessFiles) > set(OutputFileList "") > foreach(inFile IN LISTS ARGN) > get_filename_component(outFile ${inFile} NAME_WE) > set(outFile ${inFile}.out) > add_custom_command( > OUTPUT ${outFile} > COMMAND ${CMAKE_COMMAND} -E copy > ${CMAKE_CURRENT_SOURCE_DIR}/${inFile} ${CMAKE_CURRENT_BINARY_DIR} > COMMAND myprog ${inFile} ${outFile} > DEPENDS ${inFile} myprog.cpp > ) > list(APPEND OutputFileList ${CMAKE_CURRENT_BINARY_DIR}/${outFile}) > endforeach() > install(FILES ${OutputFileList} DESTINATION share/docs) > add_custom_target( > RunMyProg ALL > DEPENDS ${OutputFileList} > COMMENT "Processing files with MyProg" > ) > endfunction() > > # now just call it once with the list of files: > ProcessFiles( > file001.in > file002.in > file003.in > ) > > > You can naturally enlist file(GLOB) to grab the list of files, as J Decker > suggests. The downside, as with any list of source files, is that CMake > will not know that it needs to re-run when you simply add a new file which > matches the glob. If you list the files explicitly, you have to edit the > CMakeList to add the file, and CMake will know to re-run at next build. > > Petr > > > > > > On Fri, Jan 30, 2015 at 4:40 PM, Chris Johnson > wrote: > >> Petr, thanks. That makes a lot of sense. >> >> Now I am struggling with causing all of these files to be generated when >> I do the default build target, e.g. just "make" in the build directory. >> That is, I want myprog to be compiled, and then all of the files processed >> by it with just one build command. I assume that's possible, but have not >> quite yet been able to make it happen. >> >> On Fri, Jan 30, 2015 at 9:11 AM, Petr Kmoch wrote: >> >>> As you say, **make** is fairly powerful at this. Other build tools may >>> not be, it might even be an alien concept to them. AFAIK, Ninja requires an >>> explicit list of files & dependencies, for example. Visual Studio solutions >>> can only contain explicitly listed files too. >>> >>> CMake projects are supposed to work with all generators which CMake >>> supports (within reason). There are some generator-specific features in >>> CMake, but the intent is to keep the set of these to a minimum. >>> >>> The list of CMake commands which directly create build-time "commands" >>> (such as Makefile rules) is rather short: >>> >>> add_custom_command() >>> add_custom_target() >>> add_executable() >>> add_library() >>> >>> Other commands modify the buildsystem (e.g. add_definitions(), >>> target_link_libraries(), or setting properties such as COMPILE_OPTIONS), >>> but they don't really add "commands" to it. >>> >>> Petr >>> >>> >>> On Fri, Jan 30, 2015 at 3:27 PM, Chris Johnson >>> wrote: >>> >>>> That does clarify a few things yes. Thank you. >>>> >>>> By "configure" time I had meant the first two items you listed as >>>> Configure and Generate. By "run" time I had meant what you called Build. >>>> >>>> One place I am unclear on is exactly which commands in CMakeLists.txt >>>> get translated into Build time commands in buildsystem files (in my case, >>>> make). For example, make is fairly powerful at generating substitution >>>> file names, e.g. creating prog.o from prog.cpp, or file1.out from >>>> file1.in. Make is also capable of running full shell scripts within a >>>> makefile. But there's no obvious way to drive any kind of automation from >>>> CMake that make is capable of. >>>> >>>> As a programmer, my first thought when having to process a large list >>>> of files is to do it through some sort of automation, rather than generate >>>> a brute force solution. It appears that with CMake, the best one can hope >>>> for is to automate the creation of the brute-force solution. >>>> >>>> -- >>>> Cheers, >>>> ..chris >>>> >>>> On Fri, Jan 30, 2015 at 4:32 AM, Petr Kmoch >>>> wrote: >>>> >>>>> It's not clear to me what you mean with "run" time. There are the >>>>> following "times" involved in a CMake-based project: >>>>> >>>>> * Configure time: >>>>> CMake is parsing CMakeLists.txt files and files included from those >>>>> and executing ALL CMake commands found in them. Variables expansion takes >>>>> place. Data structures in CMake's memory are filled. >>>>> >>>>> * Generate time: >>>>> CMake processes the data structures in its memory to write buildsystem >>>>> files (Makefiles, solutions etc.) to disk. Generator expressions are >>>>> expanded. Files are generated from data specified in file(GENERATE ...) >>>>> commands. cmake_install.cmake file is written based on the contents of data >>>>> structures filled by install() commands. >>>>> >>>>> * Build time: >>>>> CMake is not running (except for driving the build if you do that with >>>>> `cmake --build`). The build tool (make, ninja, devenv, msbuild, ...) is >>>>> running, processing the buildsystem files and generating compiled binaries. >>>>> At this time, commands which were set up by add_custom_command() and >>>>> add_custom_target() are executed as driven by the build tool. >>>>> >>>>> * Install time (optional): >>>>> Running `make install` or similarly triggering the install process >>>>> causes CMake to run in installation mode. This CMake reads the >>>>> cmake_install.cmake file and executes the commands there. These are mainly >>>>> file() commands which copy files to the desired location. >>>>> >>>>> CMake commands in CMakeLists.txt and included files are all executed >>>>> during configure time, as the files are parsed and processed by CMake. Some >>>>> of these commands have immediate effects on the outside environment (e.g. >>>>> file(WRITE), execute_process(), try_compile()), some affect the CMake >>>>> processing control flow (e.g. include(), foreach()), some fill in or modify >>>>> CMake's data structures (e.g. set(), add_executable(), install(), >>>>> add_custom_command()). >>>>> >>>>> So there are no CMake commands executed after configure time. The >>>>> value specified in a COMMAND argument of add_custom_command() executes at >>>>> build time (driven by the build system), but the add_custom_command() >>>>> itself executes at CMake time. >>>>> >>>>> I hope I've clarified it a little bit. >>>>> >>>>> Petr >>>>> >>>>> >>>>> >>>>> On Thu, Jan 29, 2015 at 9:36 PM, Chris Johnson >>>>> wrote: >>>>> >>>>>> Thanks; I appreciate the suggestions. >>>>>> >>>>>> One thing that jumped out is the thought that foreach() is executed >>>>>> at "configuration" time, not "run" time. To me, that was >>>>>> counter-intuitive, but makes more sense once more thoroughly considered. >>>>>> >>>>>> But I have to admit, I've never seen anything in the documentation >>>>>> which lists all of the commands which execute at configuration time, and >>>>>> which are executed at run time. Is there such documentation? A link to it >>>>>> would be great. >>>>>> >>>>>> On Thu, Jan 29, 2015 at 9:51 AM, Thompson, KT wrote: >>>>>> >>>>>>> Hi Chris, >>>>>>> >>>>>>> >>>>>>> >>>>>>> Why not use a foreach loop? Something like this? >>>>>>> >>>>>>> >>>>>>> >>>>>>> add_executable(myprog myprog.cpp) >>>>>>> >>>>>>> set( files file001 fiile002 ?) >>>>>>> >>>>>>> foreach( file in files) >>>>>>> >>>>>>> add_custom_command(OUTPUT ${file}.out >>>>>>> >>>>>>> COMMAND /bin/cp ${CMAKE_CURRENT_SOURCE_DIR}/${file}.in . >>>>>>> >>>>>>> COMMAND myprog ${file}.in ${file}.out >>>>>>> >>>>>>> DEPENDS ${file}.in myprog.cpp >>>>>>> >>>>>>> ) >>>>>>> >>>>>>> endforeach() >>>>>>> >>>>>>> >>>>>>> >>>>>>> For portability, you might want to use ?${CMAKE_COMMAND} ?E >>>>>>> copy_if_different? in place of ?/bin/cp? and CMAKE_CURRENT_BINARY_DIR in >>>>>>> place of ?.? >>>>>>> >>>>>>> >>>>>>> >>>>>>> -kt >>>>>>> >>>>>>> >>>>>>> >>>>>>> *From:* CMake [mailto:cmake-bounces at cmake.org] *On Behalf Of *Chris >>>>>>> Johnson >>>>>>> *Sent:* Thursday, January 29, 2015 8:09 AM >>>>>>> *To:* cmake at cmake.org >>>>>>> *Subject:* [CMake] Generated files? >>>>>>> >>>>>>> >>>>>>> >>>>>>> ?I am looking for suggestions on how to solve the following >>>>>>> problem. I need a solution which is easy to understand and safe from >>>>>>> future maintenance errors. >>>>>>> >>>>>>> >>>>>>> >>>>>>> There is a project directory with one C++ program and a large number >>>>>>> of "input" data files. >>>>>>> >>>>>>> >>>>>>> >>>>>>> The C++ program needs to be compiled, and then run against each of >>>>>>> the input files to generate an output file of the same base name but with a >>>>>>> different output suffix. E.g. from the command line it might be: >>>>>>> >>>>>>> >>>>>>> >>>>>>> % myprog file001.in file001.out >>>>>>> >>>>>>> >>>>>>> >>>>>>> Finally, the output files need to be installed in the proper >>>>>>> location. >>>>>>> >>>>>>> >>>>>>> >>>>>>> For one input file, it might look like this: >>>>>>> >>>>>>> >>>>>>> >>>>>>> add_executable(myprog myprog.cpp) >>>>>>> >>>>>>> add_custom_command(OUTPUT file001.out >>>>>>> >>>>>>> COMMAND /bin/cp ${CMAKE_CURRENT_SOURCE_DIR}/file001.in . >>>>>>> >>>>>>> COMMAND myprog file001.in file001.out >>>>>>> >>>>>>> DEPENDS files001.in myprog.cpp >>>>>>> >>>>>>> ) >>>>>>> >>>>>>> install(FILES ${CMAKE_CURRENT_BINARY_DIR}/file001.out >>>>>>> DESTINATION share/docs) >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Listing all of the input files in my CMakeLists.txt file is not a >>>>>>> problem, but it would be nice to avoid having to list the corresponding >>>>>>> output files. >>>>>>> >>>>>>> >>>>>>> >>>>>>> How can I build a CMakeLists.txt file which will succinctly handle >>>>>>> this situation? >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> ..chris? >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> 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 >>>>>> >>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cxjohnson at gmail.com Fri Jan 30 12:09:54 2015 From: cxjohnson at gmail.com (Chris Johnson) Date: Fri, 30 Jan 2015 11:09:54 -0600 Subject: [CMake] Generated files? In-Reply-To: References: <0458DF31F610EF42BFC78C497E806C7B3B59FEBE@ECS-EXG-P-MB03.win.lanl.gov> Message-ID: Ah, I found the problem. I had the output file listed in the custom command's DEPEND clause. Thank you very much for all the help! On Fri, Jan 30, 2015 at 11:07 AM, Chris Johnson wrote: > I'm trying to use the method outlined in your #2, with the list of files. > But I get circular dependency errors, with messages like this one (for each > file): > > make[2]: Circular validate/X12_Standards/997_5010.x12 <- > validate/X12_Standards/997_5010.x12 dependency dropped. > > On Fri, Jan 30, 2015 at 10:28 AM, Petr Kmoch wrote: > >> I believe the classic "driving target" approach could be used here. Add a >> custom target which will drive the custom commands by depending on their >> outputs: >> >> add_custom_target( >> RunMyProg ALL >> DEPENDS >> ${CMAKE_CURRENT_BINARY_DIR}/file001.out >> ${CMAKE_CURRENT_BINARY_DIR}/file002.out >> #... >> COMMENT "Processing files with MyProg" >> ) >> >> Notice the ALL after the target name - this makes the target part of >> 'make all' or equivalent. >> >> Custom targets are always considered out of date (always rebuilt), but >> this one has no COMMAND and so building it does nothing. It does make sure >> all its dependencies (the .out files) are up to date, though, and if they >> are not, it will run the rules to build them. These rules are the custom >> commands you've created earlier. >> >> This "custom target driving custom commands" is a very idiomatic pattern >> in CMake. >> >> Of course, you don't want to list the files by hand. You could modify my >> earlier function in one of two ways: >> >> 1. Have each invocation append to a list: >> >> set(OutputFileList "") >> >> function(ProcessFile inFile) >> get_filename_component(outFile ${inFile} NAME_WE) >> set(outFile ${inFile}.out) >> add_custom_command( >> OUTPUT ${outFile} >> COMMAND ${CMAKE_COMMAND} -E copy >> ${CMAKE_CURRENT_SOURCE_DIR}/${inFile} ${CMAKE_CURRENT_BINARY_DIR} >> COMMAND myprog ${inFile} ${outFile} >> DEPENDS ${inFile} myprog.cpp >> ) >> install(FILES ${CMAKE_CURRENT_BINARY_DIR}/${outFile} DESTINATION >> share/docs) >> set(OutputFileList ${OutputFileList} >> ${CMAKE_CURRENT_BINARY_DIR}/${outFile} PARENT_SCOPE) # This line is new >> endfunction() >> >> # process files >> ProcessFile(file001.in) >> ProcessFile(file002.in) >> ProcessFile(file003.in) >> >> >> # now use the list in the custom target: >> add_custom_target( >> RunMyProg ALL >> DEPENDS ${OutputFileList} >> COMMENT "Processing files with MyProg" >> ) >> >> >> Or, 2., refactor the function to take a list of files and do everything >> itself: >> >> function(ProcessFiles) >> set(OutputFileList "") >> foreach(inFile IN LISTS ARGN) >> get_filename_component(outFile ${inFile} NAME_WE) >> set(outFile ${inFile}.out) >> add_custom_command( >> OUTPUT ${outFile} >> COMMAND ${CMAKE_COMMAND} -E copy >> ${CMAKE_CURRENT_SOURCE_DIR}/${inFile} ${CMAKE_CURRENT_BINARY_DIR} >> COMMAND myprog ${inFile} ${outFile} >> DEPENDS ${inFile} myprog.cpp >> ) >> list(APPEND OutputFileList ${CMAKE_CURRENT_BINARY_DIR}/${outFile}) >> endforeach() >> install(FILES ${OutputFileList} DESTINATION share/docs) >> add_custom_target( >> RunMyProg ALL >> DEPENDS ${OutputFileList} >> COMMENT "Processing files with MyProg" >> ) >> endfunction() >> >> # now just call it once with the list of files: >> ProcessFiles( >> file001.in >> file002.in >> file003.in >> ) >> >> >> You can naturally enlist file(GLOB) to grab the list of files, as J >> Decker suggests. The downside, as with any list of source files, is that >> CMake will not know that it needs to re-run when you simply add a new file >> which matches the glob. If you list the files explicitly, you have to edit >> the CMakeList to add the file, and CMake will know to re-run at next build. >> >> Petr >> >> >> >> >> >> On Fri, Jan 30, 2015 at 4:40 PM, Chris Johnson >> wrote: >> >>> Petr, thanks. That makes a lot of sense. >>> >>> Now I am struggling with causing all of these files to be generated when >>> I do the default build target, e.g. just "make" in the build directory. >>> That is, I want myprog to be compiled, and then all of the files processed >>> by it with just one build command. I assume that's possible, but have not >>> quite yet been able to make it happen. >>> >>> On Fri, Jan 30, 2015 at 9:11 AM, Petr Kmoch >>> wrote: >>> >>>> As you say, **make** is fairly powerful at this. Other build tools may >>>> not be, it might even be an alien concept to them. AFAIK, Ninja requires an >>>> explicit list of files & dependencies, for example. Visual Studio solutions >>>> can only contain explicitly listed files too. >>>> >>>> CMake projects are supposed to work with all generators which CMake >>>> supports (within reason). There are some generator-specific features in >>>> CMake, but the intent is to keep the set of these to a minimum. >>>> >>>> The list of CMake commands which directly create build-time "commands" >>>> (such as Makefile rules) is rather short: >>>> >>>> add_custom_command() >>>> add_custom_target() >>>> add_executable() >>>> add_library() >>>> >>>> Other commands modify the buildsystem (e.g. add_definitions(), >>>> target_link_libraries(), or setting properties such as COMPILE_OPTIONS), >>>> but they don't really add "commands" to it. >>>> >>>> Petr >>>> >>>> >>>> On Fri, Jan 30, 2015 at 3:27 PM, Chris Johnson >>>> wrote: >>>> >>>>> That does clarify a few things yes. Thank you. >>>>> >>>>> By "configure" time I had meant the first two items you listed as >>>>> Configure and Generate. By "run" time I had meant what you called Build. >>>>> >>>>> One place I am unclear on is exactly which commands in CMakeLists.txt >>>>> get translated into Build time commands in buildsystem files (in my case, >>>>> make). For example, make is fairly powerful at generating substitution >>>>> file names, e.g. creating prog.o from prog.cpp, or file1.out from >>>>> file1.in. Make is also capable of running full shell scripts within >>>>> a makefile. But there's no obvious way to drive any kind of automation >>>>> from CMake that make is capable of. >>>>> >>>>> As a programmer, my first thought when having to process a large list >>>>> of files is to do it through some sort of automation, rather than generate >>>>> a brute force solution. It appears that with CMake, the best one can hope >>>>> for is to automate the creation of the brute-force solution. >>>>> >>>>> -- >>>>> Cheers, >>>>> ..chris >>>>> >>>>> On Fri, Jan 30, 2015 at 4:32 AM, Petr Kmoch >>>>> wrote: >>>>> >>>>>> It's not clear to me what you mean with "run" time. There are the >>>>>> following "times" involved in a CMake-based project: >>>>>> >>>>>> * Configure time: >>>>>> CMake is parsing CMakeLists.txt files and files included from those >>>>>> and executing ALL CMake commands found in them. Variables expansion takes >>>>>> place. Data structures in CMake's memory are filled. >>>>>> >>>>>> * Generate time: >>>>>> CMake processes the data structures in its memory to write >>>>>> buildsystem files (Makefiles, solutions etc.) to disk. Generator >>>>>> expressions are expanded. Files are generated from data specified in >>>>>> file(GENERATE ...) commands. cmake_install.cmake file is written based on >>>>>> the contents of data structures filled by install() commands. >>>>>> >>>>>> * Build time: >>>>>> CMake is not running (except for driving the build if you do that >>>>>> with `cmake --build`). The build tool (make, ninja, devenv, msbuild, ...) >>>>>> is running, processing the buildsystem files and generating compiled >>>>>> binaries. At this time, commands which were set up by add_custom_command() >>>>>> and add_custom_target() are executed as driven by the build tool. >>>>>> >>>>>> * Install time (optional): >>>>>> Running `make install` or similarly triggering the install process >>>>>> causes CMake to run in installation mode. This CMake reads the >>>>>> cmake_install.cmake file and executes the commands there. These are mainly >>>>>> file() commands which copy files to the desired location. >>>>>> >>>>>> CMake commands in CMakeLists.txt and included files are all executed >>>>>> during configure time, as the files are parsed and processed by CMake. Some >>>>>> of these commands have immediate effects on the outside environment (e.g. >>>>>> file(WRITE), execute_process(), try_compile()), some affect the CMake >>>>>> processing control flow (e.g. include(), foreach()), some fill in or modify >>>>>> CMake's data structures (e.g. set(), add_executable(), install(), >>>>>> add_custom_command()). >>>>>> >>>>>> So there are no CMake commands executed after configure time. The >>>>>> value specified in a COMMAND argument of add_custom_command() executes at >>>>>> build time (driven by the build system), but the add_custom_command() >>>>>> itself executes at CMake time. >>>>>> >>>>>> I hope I've clarified it a little bit. >>>>>> >>>>>> Petr >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Jan 29, 2015 at 9:36 PM, Chris Johnson >>>>>> wrote: >>>>>> >>>>>>> Thanks; I appreciate the suggestions. >>>>>>> >>>>>>> One thing that jumped out is the thought that foreach() is executed >>>>>>> at "configuration" time, not "run" time. To me, that was >>>>>>> counter-intuitive, but makes more sense once more thoroughly considered. >>>>>>> >>>>>>> But I have to admit, I've never seen anything in the documentation >>>>>>> which lists all of the commands which execute at configuration time, and >>>>>>> which are executed at run time. Is there such documentation? A link to it >>>>>>> would be great. >>>>>>> >>>>>>> On Thu, Jan 29, 2015 at 9:51 AM, Thompson, KT wrote: >>>>>>> >>>>>>>> Hi Chris, >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Why not use a foreach loop? Something like this? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> add_executable(myprog myprog.cpp) >>>>>>>> >>>>>>>> set( files file001 fiile002 ?) >>>>>>>> >>>>>>>> foreach( file in files) >>>>>>>> >>>>>>>> add_custom_command(OUTPUT ${file}.out >>>>>>>> >>>>>>>> COMMAND /bin/cp ${CMAKE_CURRENT_SOURCE_DIR}/${file}.in . >>>>>>>> >>>>>>>> COMMAND myprog ${file}.in ${file}.out >>>>>>>> >>>>>>>> DEPENDS ${file}.in myprog.cpp >>>>>>>> >>>>>>>> ) >>>>>>>> >>>>>>>> endforeach() >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> For portability, you might want to use ?${CMAKE_COMMAND} ?E >>>>>>>> copy_if_different? in place of ?/bin/cp? and CMAKE_CURRENT_BINARY_DIR in >>>>>>>> place of ?.? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -kt >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> *From:* CMake [mailto:cmake-bounces at cmake.org] *On Behalf Of *Chris >>>>>>>> Johnson >>>>>>>> *Sent:* Thursday, January 29, 2015 8:09 AM >>>>>>>> *To:* cmake at cmake.org >>>>>>>> *Subject:* [CMake] Generated files? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ?I am looking for suggestions on how to solve the following >>>>>>>> problem. I need a solution which is easy to understand and safe from >>>>>>>> future maintenance errors. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> There is a project directory with one C++ program and a large >>>>>>>> number of "input" data files. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> The C++ program needs to be compiled, and then run against each of >>>>>>>> the input files to generate an output file of the same base name but with a >>>>>>>> different output suffix. E.g. from the command line it might be: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> % myprog file001.in file001.out >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Finally, the output files need to be installed in the proper >>>>>>>> location. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> For one input file, it might look like this: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> add_executable(myprog myprog.cpp) >>>>>>>> >>>>>>>> add_custom_command(OUTPUT file001.out >>>>>>>> >>>>>>>> COMMAND /bin/cp ${CMAKE_CURRENT_SOURCE_DIR}/file001.in . >>>>>>>> >>>>>>>> COMMAND myprog file001.in file001.out >>>>>>>> >>>>>>>> DEPENDS files001.in myprog.cpp >>>>>>>> >>>>>>>> ) >>>>>>>> >>>>>>>> install(FILES ${CMAKE_CURRENT_BINARY_DIR}/file001.out >>>>>>>> DESTINATION share/docs) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Listing all of the input files in my CMakeLists.txt file is not a >>>>>>>> problem, but it would be nice to avoid having to list the corresponding >>>>>>>> output files. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> How can I build a CMakeLists.txt file which will succinctly handle >>>>>>>> this situation? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> ..chris? >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> 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 >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcdailey.lists at gmail.com Fri Jan 30 13:07:43 2015 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Fri, 30 Jan 2015 12:07:43 -0600 Subject: [CMake] How can I make CTest not do dart-related stuff? Message-ID: I run ctest on my build server *just* to run the test executables and get result XML. I use a separate tool to parse the XML and upload it to an unrelated server (not CDash) I get errors like below: Cannot find file: /sourcerepo/build/DartConfiguration.tcl Can someone explain what CTest is doing and if there is a way to turn it off? From greenc at fnal.gov Fri Jan 30 13:07:46 2015 From: greenc at fnal.gov (Chris Green) Date: Fri, 30 Jan 2015 12:07:46 -0600 Subject: [CMake] target_link_libraries replacing fully-qualified library with -l In-Reply-To: References: <54C94293.6050100@fnal.gov> <54CA38A4.5090908@kitware.com> <54CA4625.8080404@fnal.gov> <54CA4C93.4000805@kitware.com> <54CA527F.2070200@fnal.gov> Message-ID: <54CBC872.9030807@fnal.gov> On 1/29/15 1:34 PM, Stephen Kelly wrote: > Chris Green wrote: > >> this library is found with >> find_library as part of a config.cmake file invoked as part of >> find_package() > Consider reading > > http://www.cmake.org/cmake/help/v3.1/manual/cmake-packages.7.html > > at some point. > > find_library and config files don't go together. Thanks for the advice; I'll take a look, Chris. > > Thanks, > > Steve. > > > -- Chris Green , FNAL CS/SCD/ADSS/SSI/SSD; 'phone (630) 840-2167; Skype: chris.h.green; IM: greenc at jabber.fnal.gov, chissgreen (AIM, Yahoo), chissg at hotmail.com (MSNM), chris.h.green (Google Talk). From steveire at gmail.com Fri Jan 30 13:08:32 2015 From: steveire at gmail.com (Stephen Kelly) Date: Fri, 30 Jan 2015 19:08:32 +0100 Subject: [CMake] automoc autorcc References: Message-ID: Norbert Pfeiler wrote: >> >> > When i use qt5_add_resources and some of my resources change they get >> > recompiled during the next invocation of my build tool. Whereas when i >> use >> > cmakes autorcc this is not the case. >> This was fixed in CMake 3.1. > > > Well, I?m using CMake 3.1.1, so apparently it?s not. Ok. In that case you must be doing something different to the testcase: http://www.cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6e1c359fe9 If you have a http://sscce.org/ please add it to http://public.kitware.com/Bug/view.php?id=15074 Thanks, Steve. From dschepler at scalable-networks.com Fri Jan 30 13:13:18 2015 From: dschepler at scalable-networks.com (Daniel Schepler) Date: Fri, 30 Jan 2015 18:13:18 +0000 Subject: [CMake] How can I make CTest not do dart-related stuff? In-Reply-To: References: Message-ID: Here, to generate XML for Jenkins' xUnit plugin, we run "ctest -T Test -j2" which has never complained about missing DartConfiguration.tcl. -- Daniel Schepler ________________________________________ From: CMake [cmake-bounces at cmake.org] on behalf of Robert Dailey [rcdailey.lists at gmail.com] Sent: Friday, January 30, 2015 10:07 AM To: CMake Subject: [CMake] How can I make CTest not do dart-related stuff? I run ctest on my build server *just* to run the test executables and get result XML. I use a separate tool to parse the XML and upload it to an unrelated server (not CDash) I get errors like below: Cannot find file: /sourcerepo/build/DartConfiguration.tcl Can someone explain what CTest is doing and if there is a way to turn it off? -- 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 From DLRdave at aol.com Fri Jan 30 14:47:51 2015 From: DLRdave at aol.com (David Cole) Date: Fri, 30 Jan 2015 14:47:51 -0500 Subject: [CMake] How can I make CTest not do dart-related stuff? In-Reply-To: References: Message-ID: Do you have a CTestConfig.cmake file in your source tree? If you do, then ctest will load that instead of looking for the DartConfiguration.tcl file in your build tree... Even if it's empty because you don't submit to a CDash server, the presence of CTestConfig.cmake in your top level source tree should suppress this error message. HTH, David C. On Fri, Jan 30, 2015 at 1:07 PM, Robert Dailey wrote: > I run ctest on my build server *just* to run the test executables and > get result XML. I use a separate tool to parse the XML and upload it > to an unrelated server (not CDash) > > I get errors like below: > > Cannot find file: /sourcerepo/build/DartConfiguration.tcl > > Can someone explain what CTest is doing and if there is a way to turn it off? > -- > > 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 From norbert.pfeiler+cmake at gmail.com Fri Jan 30 15:07:08 2015 From: norbert.pfeiler+cmake at gmail.com (Norbert Pfeiler) Date: Fri, 30 Jan 2015 21:07:08 +0100 Subject: [CMake] automoc autorcc In-Reply-To: References: Message-ID: > > Ok. In that case you must be doing something different to the testcase: > http://www.cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6e1c359fe9 > If you have a http://sscce.org/ please add it to > http://public.kitware.com/Bug/view.php?id=15074 The issue report you linked indicates that the fix is effective in CMake 3.2 not 3.1, coincidentally I also cannot find the changes from the commit in the official 3.1 sources. Waiting for the 3.2 release then. Best, Norbert. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcdailey.lists at gmail.com Fri Jan 30 15:26:08 2015 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Fri, 30 Jan 2015 14:26:08 -0600 Subject: [CMake] How can I make CTest not do dart-related stuff? In-Reply-To: References: Message-ID: David, I added a CTestConfig.cmake right next to the root CMakeLists.txt and it's empty except for a comment. I get the following output: =============================================================================== [189/189] Linking CXX executable output/bin/Test_UI_String Cannot find file: /home/fe/atlassian/bamboo_builds/131076/FE-MP88-UT/build/DartConfiguration.tcl Site: Build name: (empty) Create new tag: 20150130-2000 - Experimental Cannot find file: /home/fe/atlassian/bamboo_builds/131076/FE-MP88-UT/build/DartConfiguration.tcl Test project /home/fe/atlassian/bamboo_builds/131076/FE-MP88-UT/build Start 1: Test_UI_List Start 2: Test_UI_String 1/2 Test #1: Test_UI_List ..................... Passed 0.03 sec 2/2 Test #2: Test_UI_String ................... Passed 0.03 sec 100% tests passed, 0 tests failed out of 2 Total Test time (real) = 0.04 sec =============================================================================== It still says it can't find the dart files. Do I need to include the CTestConfig.cmake file somewhere? here is the build script my Bamboo server is using: =============================================================================== set -e export CC=clang export CXX=clang++ NINJA=${bamboo.capability.system.builder.command.Ninja} TRUE_COMMAND=${bamboo.capability.system.builder.command.true} cmake ../frontend -G"Ninja" \ -DCMAKE_BUILD_TYPE=Release \ -DCMAKE_MAKE_PROGRAM=$NINJA \ # This builds all tests + dependencies $NINJA all_tests || { echo "Build Failure"; exit 1; } # Test against /usr/bin/true so that test failures don't # cause build failures. ctest -T Test -j 16 --output-on-failure || eval $TRUE_COMMAND =============================================================================== On Fri, Jan 30, 2015 at 1:47 PM, David Cole wrote: > Do you have a CTestConfig.cmake file in your source tree? > > If you do, then ctest will load that instead of looking for the > DartConfiguration.tcl file in your build tree... Even if it's empty > because you don't submit to a CDash server, the presence of > CTestConfig.cmake in your top level source tree should suppress this > error message. > > > HTH, > David C. > > > > On Fri, Jan 30, 2015 at 1:07 PM, Robert Dailey wrote: >> I run ctest on my build server *just* to run the test executables and >> get result XML. I use a separate tool to parse the XML and upload it >> to an unrelated server (not CDash) >> >> I get errors like below: >> >> Cannot find file: /sourcerepo/build/DartConfiguration.tcl >> >> Can someone explain what CTest is doing and if there is a way to turn it off? >> -- >> >> 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 From rcdailey.lists at gmail.com Fri Jan 30 16:27:07 2015 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Fri, 30 Jan 2015 15:27:07 -0600 Subject: [CMake] How can I make CTest not do dart-related stuff? In-Reply-To: References: Message-ID: Apparently I have to: include( CTest ) I wasn't doing that. Now it works as you have explained. Thanks! On Fri, Jan 30, 2015 at 2:26 PM, Robert Dailey wrote: > David, > > I added a CTestConfig.cmake right next to the root CMakeLists.txt and > it's empty except for a comment. I get the following output: > > =============================================================================== > [189/189] Linking CXX executable output/bin/Test_UI_String > Cannot find file: > /home/fe/atlassian/bamboo_builds/131076/FE-MP88-UT/build/DartConfiguration.tcl > Site: > Build name: (empty) > Create new tag: 20150130-2000 - Experimental > Cannot find file: > /home/fe/atlassian/bamboo_builds/131076/FE-MP88-UT/build/DartConfiguration.tcl > Test project /home/fe/atlassian/bamboo_builds/131076/FE-MP88-UT/build > Start 1: Test_UI_List > Start 2: Test_UI_String > 1/2 Test #1: Test_UI_List ..................... Passed 0.03 sec > 2/2 Test #2: Test_UI_String ................... Passed 0.03 sec > > 100% tests passed, 0 tests failed out of 2 > > Total Test time (real) = 0.04 sec > =============================================================================== > > It still says it can't find the dart files. Do I need to include the > CTestConfig.cmake file somewhere? > > here is the build script my Bamboo server is using: > > =============================================================================== > set -e > > export CC=clang > export CXX=clang++ > NINJA=${bamboo.capability.system.builder.command.Ninja} > TRUE_COMMAND=${bamboo.capability.system.builder.command.true} > > cmake ../frontend -G"Ninja" \ > -DCMAKE_BUILD_TYPE=Release \ > -DCMAKE_MAKE_PROGRAM=$NINJA \ > > # This builds all tests + dependencies > $NINJA all_tests || { echo "Build Failure"; exit 1; } > > # Test against /usr/bin/true so that test failures don't > # cause build failures. > ctest -T Test -j 16 --output-on-failure || eval $TRUE_COMMAND > =============================================================================== > > On Fri, Jan 30, 2015 at 1:47 PM, David Cole wrote: >> Do you have a CTestConfig.cmake file in your source tree? >> >> If you do, then ctest will load that instead of looking for the >> DartConfiguration.tcl file in your build tree... Even if it's empty >> because you don't submit to a CDash server, the presence of >> CTestConfig.cmake in your top level source tree should suppress this >> error message. >> >> >> HTH, >> David C. >> >> >> >> On Fri, Jan 30, 2015 at 1:07 PM, Robert Dailey wrote: >>> I run ctest on my build server *just* to run the test executables and >>> get result XML. I use a separate tool to parse the XML and upload it >>> to an unrelated server (not CDash) >>> >>> I get errors like below: >>> >>> Cannot find file: /sourcerepo/build/DartConfiguration.tcl >>> >>> Can someone explain what CTest is doing and if there is a way to turn it off? >>> -- >>> >>> 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 From eike at sf-mail.de Sat Jan 31 06:22:44 2015 From: eike at sf-mail.de (Rolf Eike Beer) Date: Sat, 31 Jan 2015 12:22:44 +0100 Subject: [CMake] [cmake-developers] CFLAGS merged during CMake process In-Reply-To: <084da137ebbae5c19d7c0cfd0e64c812@cloudmailn6.netcore.co.in> References: <084da137ebbae5c19d7c0cfd0e64c812@cloudmailn6.netcore.co.in> Message-ID: <10322155.2JZqMyXX9r@caliban.sf-tec.de> Sriram Rajan wrote: > I observed that Cflags were corrupted during the cmake > I am working on a simple libxml example code from > http://www.xmlsoft.org/examples/xpath2.c > (http://www.xmlsoft.org/examples/xpath2.c). For some reason, my current > working directory is prepended without a space ' '. > CMakeFiles/nmapWrapper.dir/flags.make:C_FLAGS = > -I/Users/sriram/xmlparse/-I/Appl... Removing this from the flags results in > a successfull compilation: $ cc > -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Deve > loper/SDKs/MacOSX10.10.sdk/usr/include/libxml2 `xml2-config --libs` xpath2.c > -o xpath2 Thanks, Try removing the quotes in include_directories(). Also, this has nothing to do with CMake development, so I'll redirect this to the users list. 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 steveire at gmail.com Sat Jan 31 09:14:12 2015 From: steveire at gmail.com (Stephen Kelly) Date: Sat, 31 Jan 2015 15:14:12 +0100 Subject: [CMake] automoc autorcc References: Message-ID: Norbert Pfeiler wrote: >> >> Ok. In that case you must be doing something different to the testcase: >> http://www.cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6e1c359fe9 >> If you have a http://sscce.org/ please add it to >> http://public.kitware.com/Bug/view.php?id=15074 > > > The issue report you linked indicates that the fix is effective in CMake > 3.2 not 3.1, > coincidentally I also cannot find the changes from the commit in the > official 3.1 sources. > > Waiting for the 3.2 release then. Oops, you're right. I misinterpreted the git output. Thanks, Steve. From ramey at rrsd.com Sat Jan 31 10:15:43 2015 From: ramey at rrsd.com (Robert Ramey) Date: Sat, 31 Jan 2015 08:15:43 -0700 (MST) Subject: [CMake] problem with my.cdash.org Message-ID: <1422717343256-7589643.post@n2.nabble.com> I'm trying to gather tests results in http://my.cdash.org/index.php?project=Safe+Numerics and they aren't show ing up. Here's what happens when I run the test target "Experimental" $make Exprerimental make: *** No rule to make target `Exprerimental'. Stop. $make Experimental Scanning dependencies of target Experimental Site: Roberts-Mac-mini.local Build name: Darwin-g++ Create new tag: 20150131-1511 - Experimental Configure project Each . represents 1024 bytes of output . Size of output: 0K Build project Each symbol represents 1024 bytes of output. '!' represents an error and '*' a warning. . Size of output: 0K 0 Compiler errors 0 Compiler warnings Test project /Users/robertramey/WorkingProjects/safe_numerics_gcc-4.8.1 Start 1: test0 1/9 Test #1: test0 ............................ Passed 0.00 sec Start 2: test_add 2/9 Test #2: test_add ......................... Passed 0.02 sec Start 3: test_cast 3/9 Test #3: test_cast ........................ Passed 0.00 sec Start 4: test_compare 4/9 Test #4: test_compare ..................... Passed 0.01 sec Start 5: test_conversion 5/9 Test #5: test_conversion .................. Passed 0.02 sec Start 6: test_divide 6/9 Test #6: test_divide ...................... Passed 0.01 sec Start 7: test_modulus 7/9 Test #7: test_modulus ..................... Passed 0.01 sec Start 8: test_multiply 8/9 Test #8: test_multiply .................... Passed 0.02 sec Start 9: test_subtract 9/9 Test #9: test_subtract .................... Passed 0.02 sec 100% tests passed, 0 tests failed out of 9 Total Test time (real) = 0.11 sec Performing coverage Cannot find any coverage files. Ignoring Coverage request. Submit files (using http) Using HTTP submit method Drop site:http://my.cdash.org/submit.php?project=Safe+Numerics Uploaded: /Users/robertramey/WorkingProjects/safe_numerics_gcc-4.8.1/Testing/20150131-1511/Build.xml Uploaded: /Users/robertramey/WorkingProjects/safe_numerics_gcc-4.8.1/Testing/20150131-1511/Configure.xml Uploaded: /Users/robertramey/WorkingProjects/safe_numerics_gcc-4.8.1/Testing/20150131-1511/Test.xml Submission successful Built target Experimental which look OK to me. What do I have to do to make this work? Robert Ramey -- View this message in context: http://cmake.3232098.n2.nabble.com/problem-with-my-cdash-org-tp7589643.html Sent from the CMake mailing list archive at Nabble.com. From julien.jomier at kitware.com Sat Jan 31 10:24:08 2015 From: julien.jomier at kitware.com (Julien Jomier) Date: Sat, 31 Jan 2015 16:24:08 +0100 Subject: [CMake] problem with my.cdash.org In-Reply-To: <1422717343256-7589643.post@n2.nabble.com> References: <1422717343256-7589643.post@n2.nabble.com> Message-ID: <54CCF398.5040303@kitware.com> Looks like your build is showing up: http://my.cdash.org/index.php?project=Safe+Numerics Julien On 31/01/2015 16:15, Robert Ramey wrote: > I'm trying to gather tests results in > http://my.cdash.org/index.php?project=Safe+Numerics and they aren't show ing > up. > > Here's what happens when I run the test target "Experimental" > > $make Exprerimental > make: *** No rule to make target `Exprerimental'. Stop. > $make Experimental > Scanning dependencies of target Experimental > Site: Roberts-Mac-mini.local > Build name: Darwin-g++ > Create new tag: 20150131-1511 - Experimental > Configure project > Each . represents 1024 bytes of output > . Size of output: 0K > Build project > Each symbol represents 1024 bytes of output. > '!' represents an error and '*' a warning. > . Size of output: 0K > 0 Compiler errors > 0 Compiler warnings > Test project /Users/robertramey/WorkingProjects/safe_numerics_gcc-4.8.1 > Start 1: test0 > 1/9 Test #1: test0 ............................ Passed 0.00 sec > Start 2: test_add > 2/9 Test #2: test_add ......................... Passed 0.02 sec > Start 3: test_cast > 3/9 Test #3: test_cast ........................ Passed 0.00 sec > Start 4: test_compare > 4/9 Test #4: test_compare ..................... Passed 0.01 sec > Start 5: test_conversion > 5/9 Test #5: test_conversion .................. Passed 0.02 sec > Start 6: test_divide > 6/9 Test #6: test_divide ...................... Passed 0.01 sec > Start 7: test_modulus > 7/9 Test #7: test_modulus ..................... Passed 0.01 sec > Start 8: test_multiply > 8/9 Test #8: test_multiply .................... Passed 0.02 sec > Start 9: test_subtract > 9/9 Test #9: test_subtract .................... Passed 0.02 sec > > 100% tests passed, 0 tests failed out of 9 > > Total Test time (real) = 0.11 sec > Performing coverage > Cannot find any coverage files. Ignoring Coverage request. > Submit files (using http) > Using HTTP submit method > Drop site:http://my.cdash.org/submit.php?project=Safe+Numerics > Uploaded: > /Users/robertramey/WorkingProjects/safe_numerics_gcc-4.8.1/Testing/20150131-1511/Build.xml > Uploaded: > /Users/robertramey/WorkingProjects/safe_numerics_gcc-4.8.1/Testing/20150131-1511/Configure.xml > Uploaded: > /Users/robertramey/WorkingProjects/safe_numerics_gcc-4.8.1/Testing/20150131-1511/Test.xml > Submission successful > Built target Experimental > > which look OK to me. What do I have to do to make this work? > > Robert Ramey > > > > -- > View this message in context: http://cmake.3232098.n2.nabble.com/problem-with-my-cdash-org-tp7589643.html > Sent from the CMake mailing list archive at Nabble.com. > From sriram.r at vit.in Sat Jan 31 13:39:03 2015 From: sriram.r at vit.in (Sriram Rajan) Date: Sat, 31 Jan 2015 18:39:03 +0000 Subject: [CMake] [cmake-developers] CFLAGS merged during CMake process In-Reply-To: <10322155.2JZqMyXX9r@caliban.sf-tec.de> References: <084da137ebbae5c19d7c0cfd0e64c812@cloudmailn6.netcore.co.in> <10322155.2JZqMyXX9r@caliban.sf-tec.de> Message-ID: <2de5f74a73fb4ecfc82217c9c6108694@cloudmailn6.netcore.co.in> Hi Rolf, Thanks for forwarding this e-mail on my behalf. I figured out the solution.. I was using `xml2-config --cflags` for the include files. The result was pre-pended with a "-I", follwed by include-path. Using sed to remove this "-I" worked. Thanks, Sriram On Sat, Jan 31, 2015 at 04:52 PM, Rolf Eike Beer wrote:Sriram Rajan wrote: I observed that Cflags were corrupted during the cmake I am working on a simple libxml example code from http://www.xmlsoft.org/examples/xpath2.c (http://www.xmlsoft.org/examples/xpath2.c) (http://www.xmlsoft.org/examples/xpath2.c (http://www.xmlsoft.org/examples/xpath2.c)). For some reason, my current working directory is prepended without a space ' '. CMakeFiles/nmapWrapper.dir/flags.make:C_FLAGS = -I/Users/sriram/xmlparse/-I/Appl... Removing this from the flags results in a successfull compilation: $ cc -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Deve loper/SDKs/MacOSX10.10.sdk/usr/include/libxml2 `xml2-config --libs` xpath2.c -o xpath2 Thanks, Try removing the quotes in include_directories(). Also, this has nothing to do with CMake development, so I'll redirect this to the users list. Eike -------------- next part -------------- An HTML attachment was scrubbed... URL: From eike at sf-mail.de Sat Jan 31 15:02:37 2015 From: eike at sf-mail.de (Rolf Eike Beer) Date: Sat, 31 Jan 2015 21:02:37 +0100 Subject: [CMake] [cmake-developers] CFLAGS merged during CMake process In-Reply-To: <2de5f74a73fb4ecfc82217c9c6108694@cloudmailn6.netcore.co.in> References: <10322155.2JZqMyXX9r@caliban.sf-tec.de> <2de5f74a73fb4ecfc82217c9c6108694@cloudmailn6.netcore.co.in> Message-ID: <5658483.i5uApGZ6Rd@caliban.sf-tec.de> Am Samstag, 31. Januar 2015, 18:39:03 schrieb Sriram Rajan: > Hi Rolf, > Thanks for forwarding this e-mail on my behalf. I figured out the > solution.. I was using `xml2-config --cflags` for the include files. The > result was pre-pended with a "-I", follwed by include-path. Using sed to > remove this "-I" worked. Why don't use simply use find_package(LibXml2) include_directories(${LIBXML2_INCLUDE_DIR}) 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 ramey at rrsd.com Sat Jan 31 21:21:35 2015 From: ramey at rrsd.com (Robert Ramey) Date: Sat, 31 Jan 2015 19:21:35 -0700 (MST) Subject: [CMake] problem with my.cdash.org In-Reply-To: <54CCF398.5040303@kitware.com> References: <1422717343256-7589643.post@n2.nabble.com> <54CCF398.5040303@kitware.com> Message-ID: <1422757295931-7589647.post@n2.nabble.com> Thank for a very fast response!!! Indeed I do find it there - I'm not sure why I didn't before. In any case I have the the (non) problem again with my Xcode version. Here is the log from the build/test/experimental: Build target ZERO_CHECK Write auxiliary files /bin/mkdir -p /Users/robertramey/WorkingProjects/safe_numerics_xcode/SafeIntegers.build/Debug/ZERO_CHECK.build write-file /Users/robertramey/WorkingProjects/safe_numerics_xcode/SafeIntegers.build/Debug/ZERO_CHECK.build/Script-F1CBCB8546DA4D6A95E16443.sh chmod 0755 /Users/robertramey/WorkingProjects/safe_numerics_xcode/SafeIntegers.build/Debug/ZERO_CHECK.build/Script-F1CBCB8546DA4D6A95E16443.sh PhaseScriptExecution CMake\ Rules /Users/robertramey/WorkingProjects/safe_numerics_xcode/SafeIntegers.build/Debug/ZERO_CHECK.build/Script-F1CBCB8546DA4D6A95E16443.sh cd /Users/robertramey/WorkingProjects/safe_numerics/CMake /bin/sh -c /Users/robertramey/WorkingProjects/safe_numerics_xcode/SafeIntegers.build/Debug/ZERO_CHECK.build/Script-F1CBCB8546DA4D6A95E16443.sh echo "" make -f /Users/robertramey/WorkingProjects/safe_numerics_xcode/CMakeScripts/ReRunCMake.make make[1]: `/Users/robertramey/WorkingProjects/safe_numerics_xcode/CMakeFiles/cmake.check_cache' is up to date. Build target Experimental Write auxiliary files /bin/mkdir -p /Users/robertramey/WorkingProjects/safe_numerics_xcode/SafeIntegers.build/Debug/Experimental.build write-file /Users/robertramey/WorkingProjects/safe_numerics_xcode/SafeIntegers.build/Debug/Experimental.build/Script-056A663D5FF740F4ABCEA422.sh chmod 0755 /Users/robertramey/WorkingProjects/safe_numerics_xcode/SafeIntegers.build/Debug/Experimental.build/Script-056A663D5FF740F4ABCEA422.sh PhaseScriptExecution CMake\ Rules /Users/robertramey/WorkingProjects/safe_numerics_xcode/SafeIntegers.build/Debug/Experimental.build/Script-056A663D5FF740F4ABCEA422.sh cd /Users/robertramey/WorkingProjects/safe_numerics/CMake /bin/sh -c /Users/robertramey/WorkingProjects/safe_numerics_xcode/SafeIntegers.build/Debug/Experimental.build/Script-056A663D5FF740F4ABCEA422.sh echo "" /Applications/CMake.app/Contents/bin/ctest -C Debug -D Experimental Site: Robert Ramey OSX clang-600.0.56 Build name: Darwin-clang++ Create new tag: 20150201-0209 - Experimental Configure project Each . represents 1024 bytes of output . Size of output: 0K Build project Each symbol represents 1024 bytes of output. '!' represents an error and '*' a warning. .............. Size of output: 14K 0 Compiler errors 0 Compiler warnings Test project /Users/robertramey/WorkingProjects/safe_numerics_xcode Start 1: test0 1/15 Test #1: test0 ............................ Passed 0.00 sec Start 2: test_add 2/15 Test #2: test_add ......................... Passed 0.01 sec Start 3: test_cast 3/15 Test #3: test_cast ........................ Passed 0.00 sec Start 4: test_compare 4/15 Test #4: test_compare ..................... Passed 0.01 sec Start 5: test_conversion 5/15 Test #5: test_conversion .................. Passed 0.00 sec Start 6: test_divide 6/15 Test #6: test_divide ...................... Passed 0.02 sec Start 7: test_modulus 7/15 Test #7: test_modulus ..................... Passed 0.02 sec Start 8: test_multiply 8/15 Test #8: test_multiply .................... Passed 0.01 sec Start 9: test_subtract 9/15 Test #9: test_subtract .................... Passed 0.01 sec Start 10: example1 10/15 Test #10: example1 ......................... Passed 0.00 sec Start 11: example2 11/15 Test #11: example2 ......................... Passed 0.00 sec Start 12: example3 12/15 Test #12: example3 ......................... Passed 0.00 sec Start 13: example4 13/15 Test #13: example4 ......................... Passed 0.00 sec Start 14: example5 14/15 Test #14: example5 ......................... Passed 0.00 sec Start 15: example6 15/15 Test #15: example6 ......................... Passed 0.00 sec 100% tests passed, 0 tests failed out of 15 Total Test time (real) = 0.12 sec Performing coverage Cannot find any coverage files. Ignoring Coverage request. Submit files (using http) Using HTTP submit method Drop site:http://my.cdash.org/submit.php?project=Safe+Numerics Uploaded: /Users/robertramey/WorkingProjects/safe_numerics_xcode/Testing/20150201-0209/Build.xml make: *** [/Users/robertramey/WorkingProjects/safe_numerics_xcode/CMakeFiles/Experimental] Interrupt: 2 And here is the window on my test results. Notice the most recent Xcode one is not complete -- View this message in context: http://cmake.3232098.n2.nabble.com/problem-with-my-cdash-org-tp7589643p7589647.html Sent from the CMake mailing list archive at Nabble.com. From sriram.r at vit.in Sat Jan 31 23:15:58 2015 From: sriram.r at vit.in (sriram.r at vit.in) Date: Sun, 01 Feb 2015 09:45:58 +0530 Subject: [CMake] [cmake-developers] CFLAGS merged during CMake process In-Reply-To: <5658483.i5uApGZ6Rd@caliban.sf-tec.de> Message-ID: <8b43a8523ad4f37bda6cb3f0718acde49ee85207@mail.vit.in> Thanks Elke. Find_package works perfectly. I also used find_library successfully on my linux at work. However, find_library fails for OS X? -- Found LibXml2: /usr/lib/libxml2.dylib (found version "2.9.0")? -- Found include: /usr/include/libxml2 -- LIBXML2:? find_library(LIBXML2 libxml2 /usr/lib) MESSAGE (STATUS "LIBXML2: " ${LIBML2}) if (${LIBXML2} STREQUAL "") ? ? MESSAGE(FATAL_ERROR "Couldn't find libxml2n. Please install") endif() Thanks, Sriram----- Original Message ----- From: "Rolf Eike Beer" To:"Sriram Rajan" Cc: Sent:Sat, 31 Jan 2015 21:02:37 +0100 Subject:Re: [cmake-developers] CFLAGS merged during CMake process Am Samstag, 31. Januar 2015, 18:39:03 schrieb Sriram Rajan: > Hi Rolf, > Thanks for forwarding this e-mail on my behalf. I figured out the > solution.. I was using `xml2-config --cflags` for the include files. The > result was pre-pended with a "-I", follwed by include-path. Using sed to > remove this "-I" worked. Why don't use simply use find_package(LibXml2) include_directories(${LIBXML2_INCLUDE_DIR}) Greetings, Eike -------------- next part -------------- An HTML attachment was scrubbed... URL: