From julien.jomier at kitware.com Sun Feb 1 01:52:59 2015 From: julien.jomier at kitware.com (Julien Jomier) Date: Sun, 01 Feb 2015 07:52:59 +0100 Subject: [CMake] problem with my.cdash.org In-Reply-To: <1422757295931-7589647.post@n2.nabble.com> References: <1422717343256-7589643.post@n2.nabble.com> <54CCF398.5040303@kitware.com> <1422757295931-7589647.post@n2.nabble.com> Message-ID: <54CDCD4B.405@kitware.com> It seems to be here: http://my.cdash.org/index.php?project=Safe+Numerics&date=2015-01-31 Note that CDash is processing the XML files asynchronously therefore it might take some time for the results to show up. Julien On 01/02/2015 03:21, Robert Ramey wrote: > 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 eike at sf-mail.de Sun Feb 1 04:21:23 2015 From: eike at sf-mail.de (Rolf Eike Beer) Date: Sun, 01 Feb 2015 10:21:23 +0100 Subject: [CMake] [cmake-developers] CFLAGS merged during CMake process In-Reply-To: <8b43a8523ad4f37bda6cb3f0718acde49ee85207@mail.vit.in> References: <8b43a8523ad4f37bda6cb3f0718acde49ee85207@mail.vit.in> Message-ID: <2003181.fAdn00UlPg@eto> sriram.r at vit.in wrote: > 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 Look, find_package() already found your library. No need to use find_library() for Xml2 again. cmake --help-module FindLibXml2 will tel you which variables to use. 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 Sun Feb 1 10:25:17 2015 From: ramey at rrsd.com (Robert Ramey) Date: Sun, 1 Feb 2015 08:25:17 -0700 (MST) Subject: [CMake] problem with my.cdash.org In-Reply-To: <54CDCD4B.405@kitware.com> References: <1422717343256-7589643.post@n2.nabble.com> <54CCF398.5040303@kitware.com> <1422757295931-7589647.post@n2.nabble.com> <54CDCD4B.405@kitware.com> Message-ID: <1422804317379-7589651.post@n2.nabble.com> Julien Jomier wrote > It seems to be here: > > http://my.cdash.org/index.php?project=Safe+Numerics&date=2015-01-31 > > Note that CDash is processing the XML files asynchronously therefore it > might take some time for the results to show up. > > Julien Hmmm - it hasn't shown up yet Robert Ramey -- View this message in context: http://cmake.3232098.n2.nabble.com/problem-with-my-cdash-org-tp7589643p7589651.html Sent from the CMake mailing list archive at Nabble.com. From DLRdave at aol.com Sun Feb 1 12:33:03 2015 From: DLRdave at aol.com (David Cole) Date: Sun, 1 Feb 2015 12:33:03 -0500 Subject: [CMake] problem with my.cdash.org In-Reply-To: <1422804317379-7589651.post@n2.nabble.com> References: <1422717343256-7589643.post@n2.nabble.com> <54CCF398.5040303@kitware.com> <1422757295931-7589647.post@n2.nabble.com> <54CDCD4B.405@kitware.com> <1422804317379-7589651.post@n2.nabble.com> Message-ID: This output: On Sun, Feb 1, 2015 at 10:25 AM, Robert Ramey wrote: > Julien Jomier wrote >> It seems to be here: >> >> http://my.cdash.org/index.php?project=Safe+Numerics&date=2015-01-31 >> >> Note that CDash is processing the XML files asynchronously therefore it >> might take some time for the results to show up. >> >> Julien > > Hmmm - it hasn't shown up yet > > Robert Ramey > > > > -- > View this message in context: http://cmake.3232098.n2.nabble.com/problem-with-my-cdash-org-tp7589643p7589651.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 From DLRdave at aol.com Sun Feb 1 12:35:56 2015 From: DLRdave at aol.com (David Cole) Date: Sun, 1 Feb 2015 12:35:56 -0500 Subject: [CMake] problem with my.cdash.org In-Reply-To: <1422804317379-7589651.post@n2.nabble.com> References: <1422717343256-7589643.post@n2.nabble.com> <54CCF398.5040303@kitware.com> <1422757295931-7589647.post@n2.nabble.com> <54CDCD4B.405@kitware.com> <1422804317379-7589651.post@n2.nabble.com> Message-ID: This output: 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 makes it seem like you interrupted the build (with a Ctrl+C perhaps?) or something before the submission was done. The Build.xml file for the stamp 20150201-0209 is indeed there now: http://my.cdash.org/buildSummary.php?buildid=720331 It shows the configure output and the build output, but since transmitting the test data was interrupted for some reason, it's not there. Does "Interrupt: 2" always occur here, or can you try to run another one and let it go all the way until it's done submitting? D On Sun, Feb 1, 2015 at 10:25 AM, Robert Ramey wrote: > Julien Jomier wrote >> It seems to be here: >> >> http://my.cdash.org/index.php?project=Safe+Numerics&date=2015-01-31 >> >> Note that CDash is processing the XML files asynchronously therefore it >> might take some time for the results to show up. >> >> Julien > > Hmmm - it hasn't shown up yet > > Robert Ramey > > > > -- > View this message in context: http://cmake.3232098.n2.nabble.com/problem-with-my-cdash-org-tp7589643p7589651.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 From ramey at rrsd.com Sun Feb 1 15:00:18 2015 From: ramey at rrsd.com (Robert Ramey) Date: Sun, 1 Feb 2015 13:00:18 -0700 (MST) Subject: [CMake] problem with my.cdash.org In-Reply-To: References: <1422717343256-7589643.post@n2.nabble.com> <54CCF398.5040303@kitware.com> <1422757295931-7589647.post@n2.nabble.com> <54CDCD4B.405@kitware.com> <1422804317379-7589651.post@n2.nabble.com> Message-ID: <1422820818839-7589654.post@n2.nabble.com> CMake mailing list wrote > This output: > > 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 > > makes it seem like you interrupted the build (with a Ctrl+C perhaps?) > or something before the submission was done. The Build.xml file for > the stamp 20150201-0209 is indeed there now: > > http://my.cdash.org/buildSummary.php?buildid=720331 > > It shows the configure output and the build output, but since > transmitting the test data was interrupted for some reason, it's not > there. > > Does "Interrupt: 2" always occur here, or can you try to run another > one and let it go all the way until it's done submitting? It always occurs when I build the "Experimental" project with Xcode. I've been unable to discover what the return value of 2 Looks like I'm not the first to have this problem! http://www.cmake.org/pipermail/cmake/2014-September/058686.html Robert Ramey -- View this message in context: http://cmake.3232098.n2.nabble.com/problem-with-my-cdash-org-tp7589643p7589654.html Sent from the CMake mailing list archive at Nabble.com. From ramey at rrsd.com Sun Feb 1 15:16:36 2015 From: ramey at rrsd.com (Robert Ramey) Date: Sun, 1 Feb 2015 13:16:36 -0700 (MST) Subject: [CMake] problem with my.cdash.org In-Reply-To: <1422820818839-7589654.post@n2.nabble.com> References: <1422717343256-7589643.post@n2.nabble.com> <54CCF398.5040303@kitware.com> <1422757295931-7589647.post@n2.nabble.com> <54CDCD4B.405@kitware.com> <1422804317379-7589651.post@n2.nabble.com> <1422820818839-7589654.post@n2.nabble.com> Message-ID: <1422821796480-7589655.post@n2.nabble.com> I did managed to make this work with the following command line $/Applications/CMake*/Contents/bin/ctest -C Debug -D Experimental Of course this only means that there's something about the CMake generated file for Xcode which some sort of issue. It would be helpful to see this addressed! Robert Ramey -- View this message in context: http://cmake.3232098.n2.nabble.com/problem-with-my-cdash-org-tp7589643p7589655.html Sent from the CMake mailing list archive at Nabble.com. From norulez at me.com Sun Feb 1 16:56:38 2015 From: norulez at me.com (NoRulez) Date: Sun, 01 Feb 2015 22:56:38 +0100 Subject: [CMake] CMake 3.0.2 check_include_files can't find include files in Mac OS X Message-ID: <62D841D4-C12F-45AC-A1E4-B2C7DF26444A@me.com> Hello, I've my SDK under /Developer/SDKs/MacOSX10.7.sdk. I've tried to set several CMake and environment variables, but check_include_files doesn't find anything. (e.g. sys/types.h, sys/stat.h, memory.h, ...) What did I need to define, so that check_include_files find my include files? The directory which i need to use: /Developer/SDKs/MacOSX10.7.sdk/usr/include Already tried CMake variables: CMAKE_REQUIRED_INCLUDES CNAKE_INCLUDE_PATH Already tried environment variables: USER_HEADER_SEARCH_PATH HEADER_SEARCH_PATH INCLUDEPATH DYLD_LIBRARY_PATH PATH CPLUS_INCLUDE_PATH C_INCLUDE_PATH Could someone help? Thanks in advance From braden at endoframe.com Mon Feb 2 00:58:11 2015 From: braden at endoframe.com (Braden McDaniel) Date: Mon, 02 Feb 2015 00:58:11 -0500 Subject: [CMake] CMake 3.0.2 check_include_files can't find include files in Mac OS X In-Reply-To: <62D841D4-C12F-45AC-A1E4-B2C7DF26444A@me.com> References: <62D841D4-C12F-45AC-A1E4-B2C7DF26444A@me.com> Message-ID: <1422856691.6331.77.camel@endoframe.com> On Sun, 2015-02-01 at 22:56 +0100, NoRulez wrote: > I've my SDK under /Developer/SDKs/MacOSX10.7.sdk. You need to set CMAKE_OSX_SYSROOT to that path. It's surprising you were able to get very far at all without that; perhpas CMAKE_OSX_SYSROOT got set to something else (you definitely don't want that). -- Braden McDaniel From norulez at me.com Mon Feb 2 02:48:19 2015 From: norulez at me.com (NoRulez) Date: Mon, 02 Feb 2015 08:48:19 +0100 Subject: [CMake] CMake 3.0.2 check_include_files can't find include files in Mac OS X In-Reply-To: <1422856691.6331.77.camel@endoframe.com> References: <62D841D4-C12F-45AC-A1E4-B2C7DF26444A@me.com> <1422856691.6331.77.camel@endoframe.com> Message-ID: Hi, I've already set CMAKE_OSX_SYSROOT to /Developer/SDKs/MacOSX10.7.sdk And CMAKE_OSX_DEPLOYMENT_TARGET to 10.7 Thanks in advance Best regards > Am 02.02.2015 um 06:58 schrieb Braden McDaniel : > >> On Sun, 2015-02-01 at 22:56 +0100, NoRulez wrote: >> I've my SDK under /Developer/SDKs/MacOSX10.7.sdk. > > You need to set CMAKE_OSX_SYSROOT to that path. > > It's surprising you were able to get very far at all without that; > perhpas CMAKE_OSX_SYSROOT got set to something else (you definitely > don't want that). > > -- > Braden McDaniel > > -- > > 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 norulez at me.com Mon Feb 2 09:54:56 2015 From: norulez at me.com (NoRulez) Date: Mon, 02 Feb 2015 15:54:56 +0100 Subject: [CMake] CPack in CMake 3.1.0 doesn't install files In-Reply-To: <067991DF-9B20-4A01-B0DF-7E68D603B25B@me.com> References: <52A2C443-8D57-4723-996E-CFBD9AAFC931@me.com> <3D148401-325C-4F20-BD97-82C8EF3F216B@me.com> <067991DF-9B20-4A01-B0DF-7E68D603B25B@me.com> Message-ID: Hi, I think I found the problem: In the file cmLocalGenerator.cxx the pointer is always true since 3.1.0, which was a const char* in 3.0.2. and now it could point to an empty const std::string, but the pointer is still valid The if statement is: if(!default_config) And should be (line 411): if(!default_config || (default_config && strlen(default_config) == 0)) Best Regards > Am 23.01.2015 um 09:15 schrieb NoRulez : > > 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 > -- > > 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 cubicool at gmail.com Mon Feb 2 19:23:41 2015 From: cubicool at gmail.com (Jeremy Moles) Date: Mon, 02 Feb 2015 19:23:41 -0500 Subject: [CMake] Announcing a (potential) new CMake project! Message-ID: <54D0150D.9080503@gmail.com> Hello everyone! My name is Jeremy, and I've been working with AlphaPixel (http://www.alphapixel.com) for the last 3 years. Similar to other companies of the type, Chris (our CEO), gives the employees the opportunity to frequently work on projects that don't always directly relate to the contract work at hand. Lately we've been tossing around the idea of working on a project related to CMake, and before I set out to begin hacking, I wanted to ping the lists and make sure I'm not duplicating existing work or putting effort into something that won't ever see any use. Our idea is to create a website (and corresponding frontends) that acts as a kind of universal, well-known CMake module repository. This would be a central place where all (or as many as people are willing to commit!) CMake files are hosted, version-controlled, reviewed, and easily accessible with a number of different API's and frontends. Of course, CMake itself includes a large number of modules with each release, but our service--which we are calling CMakeSys internally--would serve as a kind of "stomping grounds" before the modules are formally integrated with CMake proper. My idea is to build the core of CMakeSys as a web service that responds to specially formatted (and sometimes necessarily long) GET requests. Further, in addition to specifying the language of choice for your project, the modules you need, etc., the service will also be able to package up a skeleton directory layout for your project as a zip archive! I envision this service acting not only as a central repository for CMake modules, but also as a place where, going foward--and in parallel with CMake's recent widespread adoption--many different CMake usage paradigms are established and developed. At this point, we're soliciting any input the community might have on our idea. I am aware of the project biicode (http://web.biicode.com) which is somewhat similar to what we're trying to create, although CMakeSys could potentially be a (or THE) repository this project uses as well. From jiri.hoogland at gmail.com Mon Feb 2 23:34:16 2015 From: jiri.hoogland at gmail.com (Jiri Hoogland) Date: Mon, 2 Feb 2015 23:34:16 -0500 Subject: [CMake] Cmake 3.1.1 generates CodeBlocks project file with full paths instead of relative ... bug ? Message-ID: Hi I have a project for which I would like to generate a CodeBlocks, There are a bunch of libraries I build under project_root/src/lib{1,2,3} The CMakeLists.txt file in the lib{1,2,3} directories use the following function to set up the relevant bits function( add_cxx_library lib_name ) set( dependencies ${ARGN} ) project( ${lib_name} ) file( GLOB_RECURSE lib_sources "*.cpp" ) file( GLOB_RECURSE lib_headers "*.h" ) add_library( ${lib_name} SHARED ${lib_sources} ${lib_headers} ) install( DIRECTORY ${PROJECT_SOURCE_DIR} DESTINATION include/{lib_name} FILES_MATCHING PATTERN "*.h" ) endfunction() I added the header files because appearantly that makes the headers show up in the IDE... When running (OSX Maverick, CMake 3.1.1) cmake -G "CodeBlocks - Unix Makefiles" from project_root/build the cbp file is generated, and on opening in CodeBlocks the files in the project show up under an absolute path from / instead of relative to project_root/src /Users/Jiri/dev/cpp/project/src/Lib1/file{1,2,3}.{h,cpp} instead of Lib1/file{1,2,3}.{h,cpp} Switching to file( GLOB_RECURSE lib_sources RELATIVE ${PROJECT_SOURCE_DIR} "*.cpp" ) file( GLOB_RECURSE lib_headers RELATIVE ${PROJECT_SOURCE_DIR} "*.h" ) doesnt help... If I would generate the cbp file directly in CodeBlocks it would do exactly what I want. Could it be there is some bug in cmake ? Googling around there is some mention of this type of behaviour in CMake 2.8.4, which was fixed in 2.8.6... http://www.cmake.org/Bug/view.php?id=12110 I am a bit at loss what is going on here.. Is the bug still there ? There is no documentation found anywhere Could someone shed some light, and possible a solution ? Many thanks Jiri -------------- next part -------------- An HTML attachment was scrubbed... URL: From surryhill at gmail.com Tue Feb 3 04:40:55 2015 From: surryhill at gmail.com (Alexis) Date: Tue, 3 Feb 2015 10:40:55 +0100 Subject: [CMake] Announcing a (potential) new CMake project! In-Reply-To: <54D0150D.9080503@gmail.com> Message-ID: <20150203094055.GA69979@kei.fritz.box> Hi Jeremy, I personally would like to see a central place on the web for CMake modules given that http://www.cmake.org/Wiki/CMake:Module_Maintainers misses several modules that I need, e.g. FindGMP, FindMPFR, FindLibIntl, and that there are various versions of those which greatly vary in quality floating on the internet. I'd be even willing to help out on writing and possibly maintaining some CMake modules. Are there official conventions and best practices for writing CMake modules? Cheers, Alexis From nilsgladitz at gmail.com Tue Feb 3 04:46:31 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Tue, 03 Feb 2015 10:46:31 +0100 Subject: [CMake] Announcing a (potential) new CMake project! In-Reply-To: <20150203094055.GA69979@kei.fritz.box> References: <20150203094055.GA69979@kei.fritz.box> Message-ID: <54D098F7.80600@gmail.com> On 02/03/2015 10:40 AM, Alexis wrote: > I'd be even willing to help out on writing and possibly maintaining some > CMake modules. > > Are there official conventions and best practices for writing CMake > modules? Yes, see http://www.cmake.org/cmake/help/git-master/manual/cmake-developer.7.html#modules Nils From rcdailey.lists at gmail.com Tue Feb 3 12:47:06 2015 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Tue, 3 Feb 2015 11:47:06 -0600 Subject: [CMake] CMake & Android with debugging Message-ID: So the way I've seen JAVA integration with NDK suggested is to use a custom target to launch ant to build the APK. However, if I do it this way, how would I launch debugging from Eclipse with ADT installed? From robert.maynard at kitware.com Tue Feb 3 14:34:06 2015 From: robert.maynard at kitware.com (Robert Maynard) Date: Tue, 3 Feb 2015 14:34:06 -0500 Subject: [CMake] CPack in CMake 3.1.0 doesn't install files In-Reply-To: References: <52A2C443-8D57-4723-996E-CFBD9AAFC931@me.com> <3D148401-325C-4F20-BD97-82C8EF3F216B@me.com> <067991DF-9B20-4A01-B0DF-7E68D603B25B@me.com> Message-ID: This is a regression and will be fixed in the next release. install: Fix regression in default configuration selection http://www.cmake.org/gitweb?p=cmake.git;a=commitdiff;h=dea42d92 On Mon, Feb 2, 2015 at 9:54 AM, NoRulez wrote: > Hi, > > I think I found the problem: > In the file cmLocalGenerator.cxx the pointer is always true since 3.1.0, which was a const char* in 3.0.2. and now it could point to an empty const std::string, but the pointer is still valid > > The if statement is: > if(!default_config) > > And should be (line 411): > if(!default_config || (default_config && strlen(default_config) == 0)) > > Best Regards > > >> Am 23.01.2015 um 09:15 schrieb NoRulez : >> >> 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 >> -- >> >> 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 a.neundorf-work at gmx.net Tue Feb 3 14:57:26 2015 From: a.neundorf-work at gmx.net (Alexander Neundorf) Date: Tue, 03 Feb 2015 20:57:26 +0100 Subject: [CMake] Announcing a (potential) new CMake project! In-Reply-To: <54D0150D.9080503@gmail.com> References: <54D0150D.9080503@gmail.com> Message-ID: <4199806.0c9lABsvmD@tuxedo.neundorf.net> On Monday, February 02, 2015 19:23:41 Jeremy Moles wrote: > Hello everyone! My name is Jeremy, and I've been working with AlphaPixel > (http://www.alphapixel.com) for the last 3 years. Similar to other > companies of the type, Chris (our CEO), gives the employees the > opportunity to frequently work on projects that don't always directly > relate to the contract work at hand. Lately we've been tossing around > the idea of working on a project related to CMake, and before I set out > to begin hacking, I wanted to ping the lists and make sure I'm not > duplicating existing work or putting effort into something that won't > ever see any use. It's a good idea, and you're not the first one with that idea. There were several before (http://www.cmake.org/Wiki/CMake:Module_Maintainers#Third-Party_Modules) , one of them extra-cmake-modules, which I started: https://projects.kde.org/projects/kdesupport/extra-cmake-modules/repository/revisions/master/show/modules I intended this to be a central place for additional cmake modules, with contributors also from outside KDE, and not really bound to KDE, but this didn't work out, and until today there are no contributors outside KDE and I have the feeling that it is now basically a "KDE library". Aynway, you may check on the kde-buildsystem mailing list (https://mail.kde.org/mailman/listinfo/kde-buildsystem) whether the maintainers want to cooperate. Alex From jmerkow at gmail.com Tue Feb 3 16:50:34 2015 From: jmerkow at gmail.com (jmerkow) Date: Tue, 3 Feb 2015 14:50:34 -0700 (MST) Subject: [CMake] Announcing a (potential) new CMake project! In-Reply-To: <4199806.0c9lABsvmD@tuxedo.neundorf.net> References: <54D0150D.9080503@gmail.com> <4199806.0c9lABsvmD@tuxedo.neundorf.net> Message-ID: <1423000234074-7589667.post@n2.nabble.com> I would love a place to learn more about CMake design patterns and paradigms. The CMake documentation is very good, and the Cmake website has a good tutorial to get people started with a simple project. However, there are a lot of commonly used design patterns out there that aren't explained anywhere. As I learned CMake (and continue to), and convert existing projects to CMake, I studied the big CMake projects' code such as VTK, ITK, Slicer, CITK, Parview etc to look at what they did. Having a knowledge base that covers best practices and design patterns would be fantastic. And incredibly benefical. -- View this message in context: http://cmake.3232098.n2.nabble.com/Announcing-a-potential-new-CMake-project-tp7589660p7589667.html Sent from the CMake mailing list archive at Nabble.com. From norulez at me.com Wed Feb 4 05:37:29 2015 From: norulez at me.com (NoRulez) Date: Wed, 04 Feb 2015 11:37:29 +0100 Subject: [CMake] CPack in CMake 3.1.0 doesn't install files In-Reply-To: References: <52A2C443-8D57-4723-996E-CFBD9AAFC931@me.com> <3D148401-325C-4F20-BD97-82C8EF3F216B@me.com> <067991DF-9B20-4A01-B0DF-7E68D603B25B@me.com> Message-ID: Thank you for the information. > Am 03.02.2015 um 20:34 schrieb Robert Maynard : > > This is a regression and will be fixed in the next release. > > install: Fix regression in default configuration selection > http://www.cmake.org/gitweb?p=cmake.git;a=commitdiff;h=dea42d92 > >> On Mon, Feb 2, 2015 at 9:54 AM, NoRulez wrote: >> Hi, >> >> I think I found the problem: >> In the file cmLocalGenerator.cxx the pointer is always true since 3.1.0, which was a const char* in 3.0.2. and now it could point to an empty const std::string, but the pointer is still valid >> >> The if statement is: >> if(!default_config) >> >> And should be (line 411): >> if(!default_config || (default_config && strlen(default_config) == 0)) >> >> Best Regards >> >> >>> Am 23.01.2015 um 09:15 schrieb NoRulez : >>> >>> 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 >>> -- >>> >>> 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 norulez at me.com Wed Feb 4 07:47:09 2015 From: norulez at me.com (NoRulez) Date: Wed, 04 Feb 2015 13:47:09 +0100 Subject: [CMake] Workaround for CMP0026 Message-ID: <95975260-EF68-4514-88B4-BD7DC5723810@me.com> Hello, currently I'm updating my CMake scripts to use newer features and/or to solve some old workarounds. I have the following code: get_target_property(${PROJECT_NAME}OutputDirectory ${PROJECT_NAME} LOCATION_RELEASE) get_filename_component(${PROJECT_NAME}OutputDirectory ${${PROJECT_NAME}OutputDirectory} PATH) install(DIRECTORY "${${PROJECT_NAME}OutputDirectory}/MyDir" DESTINATION share/myproj) In the description for porting such code is to use "file(GENERATE...)" If I use this, how can I then read the value? The following gives me the error that the file doesn't exist (in release build): file(GENERATE OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/MyPath$.txt CONTENT "$") file(READ ${CMAKE_CURRENT_BINARY_DIR}/MyPathRelease.txt MYCONTENT) install(DIRECTORY ${MYCONTENT}/MyDir DESTINATION share/myproj) Without the "file(read" and install, the files are created. So, how can i use such information for the install stuff? I already tried "set_source_file_properties(${CMAKE_CURRENT_BINARY_DIR}/MyPath$.txt PROPERTIES GENERATED TRUE)" but that doesn't work either. Thanks in advance Best Regards From Cosmin.CREMARENCO at murex.com Wed Feb 4 09:14:55 2015 From: Cosmin.CREMARENCO at murex.com (CREMARENCO Cosmin) Date: Wed, 4 Feb 2015 14:14:55 +0000 Subject: [CMake] command in add_custom_command launched even if output not stale Message-ID: <71F64EA53CF7EA488875E561C7BE0C1004DB8D87@FR-FRDC2-MB-P2.fr.murex.com> Hello, We use CMake and among other things CMake is used for generating code at compilation time. We have a custom command like so: add_custom_command(OUTPUT O0, O1, O2...On launch-generation-command DEPENDS I0, I1, I2, ....In VERBATIM) So there are multiple inputs and multiple outputs (why not launch the command for each input and have only one output? - it would take too much time combined, a jvm is launched every time and there are a lot of generated files). The command that is launched is intelligent enough to not touch output if its corresponding input has not changed. Now I'm coming to the problem: when I touch an input Ix, I expect that output Ox is regenerated. That works great, make will launch the custom command and Ox will be generated and compiled afterwards. But, subsequent runs of make will still launch the custom command which is not ok. By digging in the generated Makefiles I see that cmake will hang the custom command under one of the outputs (arbitrarily?). If that output is not exactly the input that I touch, given that the generator will only output code for what has really changed, the target will always be invalid and make will always launch the custom command. Is there a solution for this? It seems obvious to me that if the oldest output is more recent than the newest input then the custom command shouldn't be called. Visual Studio is even worse. Besides launching the custom command every time, it will recompile all outputs because, my guess is that after the custom command has run it won't even bother to check that the .obj is more recent than the corresponding .cpp. Sorry for the somewhat terse mail and thanks in advance! Cosmin ******************************* This e-mail contains information for the intended recipient only. It may contain proprietary material or confidential information. If you are not the intended recipient you are not authorised to distribute, copy or use this e-mail or any attachment to it. Murex cannot guarantee that it is virus free and accepts no responsibility for any loss or damage arising from its use. If you have received this e-mail in error please notify immediately the sender and delete the original email received, any attachments and all copies from your system. -------------- next part -------------- An HTML attachment was scrubbed... URL: From surryhill at gmail.com Wed Feb 4 10:49:41 2015 From: surryhill at gmail.com (Alexis) Date: Wed, 4 Feb 2015 16:49:41 +0100 Subject: [CMake] Announcing a (potential) new CMake project! In-Reply-To: <54D098F7.80600@gmail.com> References: <20150203094055.GA69979@kei.fritz.box> <54D098F7.80600@gmail.com> Message-ID: <20150204154941.GB69979@kei.fritz.box> Hello Nils Gladitz on Tue, Feb 03, 2015 at 10:46:31AM CET, you wrote: > >Are there official conventions and best practices for writing CMake > >modules? > > Yes, see http://www.cmake.org/cmake/help/git-master/manual/cmake-developer.7.html#modules Great! Just what I was looking for how did I not find this? :) Cheers, Alexis From ruslan_baratov at yahoo.com Wed Feb 4 13:16:15 2015 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Wed, 04 Feb 2015 21:16:15 +0300 Subject: [CMake] command in add_custom_command launched even if output not stale In-Reply-To: <71F64EA53CF7EA488875E561C7BE0C1004DB8D87@FR-FRDC2-MB-P2.fr.murex.com> References: <71F64EA53CF7EA488875E561C7BE0C1004DB8D87@FR-FRDC2-MB-P2.fr.murex.com> Message-ID: <54D261EF.8050802@yahoo.com> All OUTPUT files O0, O1, O2,... depends on all DEPENDS files I0, I1, I2,... See this discussion: http://www.cmake.org/pipermail/cmake/2014-October/058824.html On 04-Feb-15 17:14, CREMARENCO Cosmin wrote: > > Hello, > > We use CMake and among other things CMake is used for generating code > at compilation time. > > We have a custom command like so: > > add_custom_command(OUTPUT O0, O1, O2?On > > launch-generation-command > > DEPENDS I0, I1, I2, ?.In > > VERBATIM) > > So there are multiple inputs and multiple outputs (why not launch the > command for each input and have only one output? ? it would take too > much time combined, a jvm is launched every time and there are a lot > of generated files). > > The command that is launched is intelligent enough to not touch output > if its corresponding input has not changed. > > Now I?m coming to the problem: when I touch an input Ix, I expect that > output Ox is regenerated. That works great, make will launch the > custom command and Ox will be generated and compiled afterwards. But, > subsequent runs of make will still launch the custom command which is > not ok. By digging in the generated Makefiles I see that cmake will > hang the custom command under one of the outputs (arbitrarily?). If > that output is not exactly the input that I touch, given that the > generator will only output code for what has really changed, the > target will always be invalid and make will always launch the custom > command. Is there a solution for this? > > It seems obvious to me that if the oldest output is more recent than > the newest input then the custom command shouldn?t be called. > > Visual Studio is even worse. Besides launching the custom command > every time, it will recompile all outputs because, my guess is that > after the custom command has run it won?t even bother to check that > the .obj is more recent than the corresponding .cpp. > > Sorry for the somewhat terse mail and thanks in advance! > > Cosmin > > ******************************* > > This e-mail contains information for the intended recipient only. It > may contain proprietary material or confidential information. If you > are not the intended recipient you are not authorised to distribute, > copy or use this e-mail or any attachment to it. Murex cannot > guarantee that it is virus free and accepts no responsibility for any > loss or damage arising from its use. If you have received this e-mail > in error please notify immediately the sender and delete the original > email received, any attachments and all copies from your system. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ruslan_baratov at yahoo.com Wed Feb 4 13:35:46 2015 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Wed, 04 Feb 2015 21:35:46 +0300 Subject: [CMake] Set Xcode sources language to "Default" In-Reply-To: References: Message-ID: <54D26682.4000207@yahoo.com> Update cmake to version 3.1 and try: set_source_files_properties(juce_audio_devices.cpp PROPERTIES XCODE_LAST_KNOWN_FILE_TYPE YES) On 23-Jan-15 00:52, Daniel Kollmann wrote: > 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: From parag at ionicsecurity.com Wed Feb 4 13:55:31 2015 From: parag at ionicsecurity.com (Parag Chandra) Date: Wed, 4 Feb 2015 18:55:31 +0000 Subject: [CMake] Any way to set the "productType" in a CMake-generated Xcode project? Message-ID: Hi, I'm trying to generate a unit-test project for iOS via CMake using the following commands: add_library (${TargetName} MODULE ${SourceFiles} ${HeaderFiles}) set_property(TARGET ${TargetName} PROPERTY BUNDLE True) I've been able to adjust all the required settings save the most important one, which is the "productType" entry inside the PBXNativeTarget section of the generated Xcode project. This needs to be "com.apple.product-type.bundle.unit-test", but CMake sets it to "com.apple.product-type.bundle". Is there any way to alter this value? Thanks, 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From steveire at gmail.com Wed Feb 4 14:24:00 2015 From: steveire at gmail.com (Stephen Kelly) Date: Wed, 04 Feb 2015 20:24 +0100 Subject: [CMake] Workaround for CMP0026 References: <95975260-EF68-4514-88B4-BD7DC5723810@me.com> Message-ID: NoRulez wrote: > Hello, > > currently I'm updating my CMake scripts to use newer features and/or to > solve some old workarounds. I think you're looking for file(GENERATE OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/dirInstallScript.cmake" CONTENT " if (CMAKE_INSTALL_CONFIG_NAME STREQUAL RELEASE) file(INSTALL DESTINATION \"\${CMAKE_INSTALL_PREFIX}/share/myproj\" TYPE DIRECTORY FILES \"$/MyDir\") endif()") install(SCRIPT "${CMAKE_CURRENT_BINARY_DIR}/dirInstallScript.cmake") Thanks, Steve. From scott.bloom at onshorecs.com Wed Feb 4 14:28:07 2015 From: scott.bloom at onshorecs.com (Scott Aron Bloom) Date: Wed, 4 Feb 2015 19:28:07 +0000 Subject: [CMake] Building for 64 bit with Visual Studio 2013 Message-ID: <6FD2E165340D9A429CF831C7A2D4F42E4E5DE8B3@WIN-R92V03RFJ85.onshorecs.local> We have been building for 32 bits on windows, and 64 bit on linux and OSX for a while. In order to enable this, we have a simple function that uses CMAKE_SIZEOF_VOID_P to add a define via add_defintions However, we are now going to build for windows 64, I calling vsvarsall.bat with x64 as a parameter, however, the CMAKE_SIZEOF_VOID_P still is equal to 4. Any idea on what Im missing? Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Wed Feb 4 14:33:53 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Wed, 04 Feb 2015 20:33:53 +0100 Subject: [CMake] Building for 64 bit with Visual Studio 2013 In-Reply-To: <6FD2E165340D9A429CF831C7A2D4F42E4E5DE8B3@WIN-R92V03RFJ85.onshorecs.local> References: <6FD2E165340D9A429CF831C7A2D4F42E4E5DE8B3@WIN-R92V03RFJ85.onshorecs.local> Message-ID: <54D27421.7070805@gmail.com> On 04.02.2015 20:28, Scott Aron Bloom wrote: > > We have been building for 32 bits on windows, and 64 bit on linux and > OSX for a while. > > In order to enable this, we have a simple function that uses > CMAKE_SIZEOF_VOID_P to add a define via add_defintions > > However, we are now going to build for windows 64, I calling > vsvarsall.bat with x64 as a parameter, however, the > CMAKE_SIZEOF_VOID_P still is equal to 4. > > Any idea on what Im missing? > Are you using a "Visual Studio" generator or a "Makefile" or "Ninja" generator? The visual studio command line environment is only relevant for the later. For the Visual Studio generators you can append e.g. "Win64" to the generator name to get the 64-bit compilers. e.g. "Visual Studio 12 2013 Win64". Nils -------------- next part -------------- An HTML attachment was scrubbed... URL: From scott.bloom at onshorecs.com Wed Feb 4 14:44:02 2015 From: scott.bloom at onshorecs.com (Scott Aron Bloom) Date: Wed, 4 Feb 2015 19:44:02 +0000 Subject: [CMake] Building for 64 bit with Visual Studio 2013 In-Reply-To: <54D27421.7070805@gmail.com> References: <6FD2E165340D9A429CF831C7A2D4F42E4E5DE8B3@WIN-R92V03RFJ85.onshorecs.local> <54D27421.7070805@gmail.com> Message-ID: <6FD2E165340D9A429CF831C7A2D4F42E4E5DE938@WIN-R92V03RFJ85.onshorecs.local> That was it! Is there any way to set that as the default? Ie, is there an environmental variable that sets the default generator? Scott From: Nils Gladitz [mailto:nilsgladitz at gmail.com] Sent: Wednesday, February 04, 2015 11:34 AM To: Scott Aron Bloom; cmake at cmake.org Subject: Re: [CMake] Building for 64 bit with Visual Studio 2013 On 04.02.2015 20:28, Scott Aron Bloom wrote: We have been building for 32 bits on windows, and 64 bit on linux and OSX for a while. In order to enable this, we have a simple function that uses CMAKE_SIZEOF_VOID_P to add a define via add_defintions However, we are now going to build for windows 64, I calling vsvarsall.bat with x64 as a parameter, however, the CMAKE_SIZEOF_VOID_P still is equal to 4. Any idea on what Im missing? Are you using a "Visual Studio" generator or a "Makefile" or "Ninja" generator? The visual studio command line environment is only relevant for the later. For the Visual Studio generators you can append e.g. "Win64" to the generator name to get the 64-bit compilers. e.g. "Visual Studio 12 2013 Win64". Nils -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Wed Feb 4 14:53:17 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Wed, 04 Feb 2015 20:53:17 +0100 Subject: [CMake] Building for 64 bit with Visual Studio 2013 In-Reply-To: <6FD2E165340D9A429CF831C7A2D4F42E4E5DE938@WIN-R92V03RFJ85.onshorecs.local> References: <6FD2E165340D9A429CF831C7A2D4F42E4E5DE8B3@WIN-R92V03RFJ85.onshorecs.local> <54D27421.7070805@gmail.com> <6FD2E165340D9A429CF831C7A2D4F42E4E5DE938@WIN-R92V03RFJ85.onshorecs.local> Message-ID: <54D278AD.6040303@gmail.com> On 04.02.2015 20:44, Scott Aron Bloom wrote: > > That was it! Is there any way to set that as the default? Ie, is > there an environmental variable that sets the default generator? > Not as far as I know. Maybe you could set up a batch script that invokes cmake with your preferred generator and forwards all arguments for local use. Alternatively the CMake GUI afair remembers the last used generator. Nils -------------- next part -------------- An HTML attachment was scrubbed... URL: From scott.bloom at onshorecs.com Wed Feb 4 14:53:18 2015 From: scott.bloom at onshorecs.com (Scott Aron Bloom) Date: Wed, 4 Feb 2015 19:53:18 +0000 Subject: [CMake] Building for 64 bit with Visual Studio 2013 In-Reply-To: <54D278AD.6040303@gmail.com> References: <6FD2E165340D9A429CF831C7A2D4F42E4E5DE8B3@WIN-R92V03RFJ85.onshorecs.local> <54D27421.7070805@gmail.com> <6FD2E165340D9A429CF831C7A2D4F42E4E5DE938@WIN-R92V03RFJ85.onshorecs.local> <54D278AD.6040303@gmail.com> Message-ID: <6FD2E165340D9A429CF831C7A2D4F42E4E5DE95C@WIN-R92V03RFJ85.onshorecs.local> Thanks. :( From: Nils Gladitz [mailto:nilsgladitz at gmail.com] Sent: Wednesday, February 04, 2015 11:53 AM To: Scott Aron Bloom; cmake at cmake.org Subject: Re: [CMake] Building for 64 bit with Visual Studio 2013 On 04.02.2015 20:44, Scott Aron Bloom wrote: That was it! Is there any way to set that as the default? Ie, is there an environmental variable that sets the default generator? Not as far as I know. Maybe you could set up a batch script that invokes cmake with your preferred generator and forwards all arguments for local use. Alternatively the CMake GUI afair remembers the last used generator. Nils -------------- next part -------------- An HTML attachment was scrubbed... URL: From parag at ionicsecurity.com Wed Feb 4 15:40:01 2015 From: parag at ionicsecurity.com (Parag Chandra) Date: Wed, 4 Feb 2015 20:40:01 +0000 Subject: [CMake] Any way to set the "productType" in a CMake-generated Xcode project? In-Reply-To: References: Message-ID: One of the guys I work with figured out the following: set_property(TARGET ${TargetName} PROPERTY XCODE_ATTRIBUTE_WRAPPER_EXTENSION "xctest") Which will indeed cause the generated project to have the correct productType. Things seem to be working now, but the info.plist file that is generated needs to be modified to more closely align with what Xcode spits out for a unit test project. We've been playing with the MACOSX_BUNDLE_INFO_PLIST property to specify a template: set (MACOSX_BUNDLE_INFO_PLIST "/Users/blah/Desktop/MacOSXBundleInfo.plist.in") However, renaming that plist.in file so that it no longer exists results in no errors from CMake, so it seems that our template is being completely ignored. Is this a bug? 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: Parag Chandra > Date: Wednesday, February 4, 2015 at 1:55 PM To: "cmake at cmake.org" > Subject: [CMake] Any way to set the "productType" in a CMake-generated Xcode project? Hi, I'm trying to generate a unit-test project for iOS via CMake using the following commands: add_library (${TargetName} MODULE ${SourceFiles} ${HeaderFiles}) set_property(TARGET ${TargetName} PROPERTY BUNDLE True) I've been able to adjust all the required settings save the most important one, which is the "productType" entry inside the PBXNativeTarget section of the generated Xcode project. This needs to be "com.apple.product-type.bundle.unit-test", but CMake sets it to "com.apple.product-type.bundle". Is there any way to alter this value? Thanks, 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bnewcomb at nvidia.com Wed Feb 4 16:36:50 2015 From: bnewcomb at nvidia.com (Bill Newcomb) Date: Wed, 4 Feb 2015 13:36:50 -0800 Subject: [CMake] custom target like add_executable Message-ID: <54D290F2.7070903@nvidia.com> When I specify add_executable(foo foo.c), I get both a top-level target (which defaults to ALL but can be set not to be) and an actual file that gets built that are named the same (Unix Makefiles). add_custom_target can get me the first of those for non-executable things, and add_custom_command can do the second. However, I can't use the same thing for the first arg to add_custom_target and the OUTPUT of add_custom_command. Ideally what I'd like is a way to specify that a particular add_custom_command is also a top-level target (with ALL being settable on it). Are there technical reasons this wouldn't be possible? Thanks, B. ----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ----------------------------------------------------------------------------------- From bnewcomb at nvidia.com Wed Feb 4 16:45:25 2015 From: bnewcomb at nvidia.com (Bill Newcomb) Date: Wed, 4 Feb 2015 13:45:25 -0800 Subject: [CMake] custom target like add_executable In-Reply-To: <54D290F2.7070903@nvidia.com> References: <54D290F2.7070903@nvidia.com> Message-ID: <54D292F5.8030105@nvidia.com> Oops, so I guess it's not that it doesn't work at all, but that the add_custom_command gets run every time I 'make all', and that gnu make emits some warnings about circular dependencies. The first is more of a problem, but both are kind of annoying. Thanks, B. On 02/04/2015 01:36 PM, Bill Newcomb wrote: > When I specify add_executable(foo foo.c), I get both a top-level target > (which defaults to ALL but can be set not to be) and an actual file that > gets built that are named the same (Unix Makefiles). > > add_custom_target can get me the first of those for non-executable > things, and add_custom_command can do the second. However, I can't use > the same thing for the first arg to add_custom_target and the OUTPUT of > add_custom_command. > > Ideally what I'd like is a way to specify that a particular > add_custom_command is also a top-level target (with ALL being settable > on it). Are there technical reasons this wouldn't be possible? > > Thanks, > B. > > ----------------------------------------------------------------------------------- > > This email message is for the sole use of the intended recipient(s) and > may contain > confidential information. Any unauthorized review, use, disclosure or > distribution > is prohibited. If you are not the intended recipient, please contact > the sender by > reply email and destroy all copies of the original message. > ----------------------------------------------------------------------------------- > From irwin at beluga.phys.uvic.ca Wed Feb 4 21:59:07 2015 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Wed, 4 Feb 2015 18:59:07 -0800 (PST) Subject: [CMake] custom target like add_executable In-Reply-To: <54D292F5.8030105@nvidia.com> References: <54D290F2.7070903@nvidia.com> <54D292F5.8030105@nvidia.com> Message-ID: On 2015-02-04 13:45-0800 Bill Newcomb wrote: > Oops, so I guess it's not that it doesn't work at all, but that the > add_custom_command gets run every time I 'make all', and that gnu make emits > some warnings about circular dependencies. The first is more of a problem, > but both are kind of annoying. Neither of those "issues" occurs if you have set up add_custom_command and the corresponding add_custom_target with the appropriate dependencies between them. If re-reading the CMake documentation for add_custom_command and add_custom_target doesn't help, then I suggest you give a simple example that is not working for you. I assume you have some dependency issue, but until you give an example, it is hard to anticipate what that might be. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From gerhard.gappmeier at ascolab.com Thu Feb 5 04:10:23 2015 From: gerhard.gappmeier at ascolab.com (Gerhard Gappmeier) Date: Thu, 05 Feb 2015 10:10:23 +0100 Subject: [CMake] E-Mail Notification of CDash is not working anymore In-Reply-To: <54C2549C.2080209@kitware.com> References: <1749826.6TBhyAybWD@manjaro> <54C2549C.2080209@kitware.com> Message-ID: <1606498.iXFAWUQ4hD@manjaro> thx for the reply and sorry for the late response. I've checked this, and except for one I believe the settings are correct. What I don't understand is what this is for? The CDash server has a local git clone and can access all commits, so I don't understand what this credential is for when using git. I've the E-Mail address configured for the credential which is used also for git author info. Is this correct? What is CDash doing with this credential info? On Friday, January 23, 2015 03:03:08 PM Julien Jomier wrote: > 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 -- 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 norulez at me.com Thu Feb 5 04:22:43 2015 From: norulez at me.com (NoRulez) Date: Thu, 05 Feb 2015 10:22:43 +0100 Subject: [CMake] Workaround for CMP0026 In-Reply-To: References: <95975260-EF68-4514-88B4-BD7DC5723810@me.com> Message-ID: <7D7195D7-148A-47B4-AB50-8CACE5462C25@me.com> Thank you for your help. I think that for the replacement there is some missing documentation outstanding, because i didn't find the "TYPE" attribute in the "file" function for example. Or examples for the CMP0026 policy like in the CMP0043 documentation. Nevertheless, I also need to change the filename from "dirInstallScript.cmake" to "dirInstallScript$.cmake" in the "file(GENERATE" statement and use the hard coded filename "dirInstallScriptRelease.cmake" in the "install(SCRIPT" statement, because if i didn't so, I get several warnings/errors when generating with Visual Studio generator. Is this really the right way? Best Regards > Am 04.02.2015 um 20:24 schrieb Stephen Kelly : > > NoRulez wrote: > >> Hello, >> >> currently I'm updating my CMake scripts to use newer features and/or to >> solve some old workarounds. > > I think you're looking for > > > file(GENERATE > OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/dirInstallScript.cmake" > CONTENT " > if (CMAKE_INSTALL_CONFIG_NAME STREQUAL RELEASE) > file(INSTALL DESTINATION > \"\${CMAKE_INSTALL_PREFIX}/share/myproj\" TYPE DIRECTORY > FILES \"$/MyDir\") > endif()") > > install(SCRIPT "${CMAKE_CURRENT_BINARY_DIR}/dirInstallScript.cmake") > > > 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 From mjklaim at gmail.com Thu Feb 5 09:45:48 2015 From: mjklaim at gmail.com (=?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?=) Date: Thu, 5 Feb 2015 15:45:48 +0100 Subject: [CMake] Building for 64 bit with Visual Studio 2013 In-Reply-To: <6FD2E165340D9A429CF831C7A2D4F42E4E5DE95C@WIN-R92V03RFJ85.onshorecs.local> References: <6FD2E165340D9A429CF831C7A2D4F42E4E5DE8B3@WIN-R92V03RFJ85.onshorecs.local> <54D27421.7070805@gmail.com> <6FD2E165340D9A429CF831C7A2D4F42E4E5DE938@WIN-R92V03RFJ85.onshorecs.local> <54D278AD.6040303@gmail.com> <6FD2E165340D9A429CF831C7A2D4F42E4E5DE95C@WIN-R92V03RFJ85.onshorecs.local> Message-ID: I think adding a simple check (fatal-error) on the value of CMAKE_SIZEOF_VOID_P in your cmake files would help the user realise that they are not using the right generator? -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Thu Feb 5 10:34:50 2015 From: robert.maynard at kitware.com (Robert Maynard) Date: Thu, 5 Feb 2015 10:34:50 -0500 Subject: [CMake] [ANNOUNCE] CMake 3.1.2 Released Message-ID: We are pleased to announce that CMake 3.1.2 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.2 since 3.1.1: Ben Boeckel (1): install: Fix regression in default configuration selection Bill Hoffman (1): CPack: Fix packaging of source tarballs with symbolic links Brad King (5): KWSys Directory: Check opendir return value before using it (#15367) Help: Clarify status of link_libraries command Normalize OBJECT_DEPENDS paths to match custom commands (#15366) MSVC: Fix initialization of RelWithDebInfo shared library link flags (#15385) CMake 3.1.2 Christoph Gr?ninger (1): FeatureSummary: Fix bracket in documentation. Guillaume Belz (1): FindOpenSSL: fix detection of OpenSSL 1.0.2 Marco Nolden (1): ctest_build: Update GNU make error message matching (#15379) From franz.engel at apworks.de Thu Feb 5 11:32:06 2015 From: franz.engel at apworks.de (Franz Engel) Date: Thu, 5 Feb 2015 16:32:06 +0000 Subject: [CMake] ExternalProject_add and add_subdirectory in one step Message-ID: Hi, I try to clone an repository from my bare-repository and to build my project tree. Therefore I use the following commands: ExternalProject_Add ( demoA PREFIX ${MAIN_PATH}/demoA GIT_REPOSITORY ${REPOSITORY_PATH}/demoA GIT_TAG origin/master UPDATE_COMMAND "" INSTALL_COMMAND "" ) add_subdirectory(${CMAKE_CURRENT_SOURCE_DIR}/../demoA/src/DemoA ${CMAKE_CURRENT_SOURCE_DIR}/demoA) Know I have the following problem. I load the Cmake-file with QtCreator. If I run CMake I get the error message "does not contain a CMakeLists.txt file". That message is clear for me, because the repository only get loaded when I compile the code. The question is, if it is possible to clone the repo in the step of CMake. Does somebody has an idea? Or is there another method to build the project tree? Br, Franz _______________________________________ Franz Engel AIRBUS APWORKS GmbH 81663 Munich - Germany T: +49 (0) 89 607 29103 M: +49 (0) 170 44 59 006 franz.engel at apworks.de AIRBUS APWORKS GmbH Registered Office: Ottobrunn District Court of Munich: HRB 141734 Managing Director: Joachim Zettler Internet: www.apworks.de _______________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcdailey.lists at gmail.com Thu Feb 5 12:04:42 2015 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Thu, 5 Feb 2015 11:04:42 -0600 Subject: [CMake] CMake & Android with debugging In-Reply-To: References: Message-ID: Would love some feedback from those who have experience with this setup. On Tue, Feb 3, 2015 at 11:47 AM, Robert Dailey wrote: > So the way I've seen JAVA integration with NDK suggested is to use a > custom target to launch ant to build the APK. However, if I do it this > way, how would I launch debugging from Eclipse with ADT installed? From dominic.r.kempf at gmail.com Thu Feb 5 13:02:39 2015 From: dominic.r.kempf at gmail.com (Dominic Kempf) Date: Thu, 5 Feb 2015 19:02:39 +0100 Subject: [CMake] Correct dependencies in a code generation workflow Message-ID: Dear CMake list, I am trying to get a code generating tool chain to work in a cmake based build system with the Unix Makefiles generator and cmake 2.8.12. Look at the following MWE of what I am doing: add_custom_command(OUTPUT generated.hh COMMAND DEPENDS sourcefile) configure_file(StandardMain.cmake main.cc) add_executable(target main.cc generated.hh) generated.hh is generated by a complex command from sourcefile. main.cc is generated from a template to include the header generated.hh. I can run "make target" and everything works very nicely: both main.cc and generated.hh are generated and the target is built. However, when I touch sourcefile and run make again, generated.hh is refreshed but the target is not rebuilt although generated.hh has been specified a source. I am looking forward to all your helpful responses!! Thanks! Dominic Kempf -------------- next part -------------- An HTML attachment was scrubbed... URL: From bnewcomb at nvidia.com Thu Feb 5 13:14:18 2015 From: bnewcomb at nvidia.com (Bill Newcomb) Date: Thu, 5 Feb 2015 10:14:18 -0800 Subject: [CMake] custom target like add_executable In-Reply-To: References: <54D290F2.7070903@nvidia.com> <54D292F5.8030105@nvidia.com> Message-ID: <54D3B2FA.1090807@nvidia.com> A contrived example: $ ls .. b CMakeLists.txt foo $ cat ../CMakeLists.txt cmake_minimum_required(VERSION 3.1) add_custom_target(foo.sha1 ALL DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/foo.sha1) add_custom_command( OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/foo.sha1 COMMAND openssl sha1 -out ${CMAKE_CURRENT_BINARY_DIR}/foo.sha1 ${CMAKE_CURRENT_SOURCE_DIR}/foo ) $ cmake .. -- The C compiler identification is GNU 4.1.2 -- The CXX compiler identification is GNU 4.1.2 -- Check for working C compiler: /usr/bin/cc -- Check for working C compiler: /usr/bin/cc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Detecting C compile features -- Detecting C compile features - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done -- Configuring done -- Generating done -- Build files have been written to: /home/bnewcomb/tmp/cmake-tests/test-fail/b $ make Scanning dependencies of target foo.sha1 make[2]: Circular CMakeFiles/foo.sha1 <- foo.sha1 dependency dropped. make[2]: Circular foo.sha1 <- foo.sha1 dependency dropped. [100%] Generating foo.sha1 [100%] Built target foo.sha1 $ ls --full-time foo.sha1 -rw-rw-r-- 1 bnewcomb hardware 93 2015-02-05 10:10:48.984606000 -0800 foo.sha1 $ make make[2]: Circular CMakeFiles/foo.sha1 <- foo.sha1 dependency dropped. make[2]: Circular foo.sha1 <- foo.sha1 dependency dropped. [100%] Generating foo.sha1 [100%] Built target foo.sha1 $ ls --full-time foo.sha1 -rw-rw-r-- 1 bnewcomb hardware 93 2015-02-05 10:11:05.432925000 -0800 foo.sha1 $ I read in a years-old bug that I should always use absolute paths with add_custom_command, but I don't know if that's still necessary. Using relative paths doesn't seem to change the outcome. Thanks, B. On 02/04/2015 06:59 PM, Alan W. Irwin wrote: > On 2015-02-04 13:45-0800 Bill Newcomb wrote: > >> Oops, so I guess it's not that it doesn't work at all, but that the >> add_custom_command gets run every time I 'make all', and that gnu make >> emits some warnings about circular dependencies. The first is more of >> a problem, but both are kind of annoying. > > Neither of those "issues" occurs if you have set up add_custom_command > and the corresponding add_custom_target with the appropriate > dependencies between them. > > If re-reading the CMake documentation for add_custom_command and > add_custom_target doesn't help, then I suggest you give a simple example > that is not working for you. I assume you have some dependency > issue, but until you give an example, it is hard to anticipate what > that might be. > > Alan > __________________________ > Alan W. Irwin > > Astronomical research affiliation with Department of Physics and Astronomy, > University of Victoria (astrowww.phys.uvic.ca). > > Programming affiliations with the FreeEOS equation-of-state > implementation for stellar interiors (freeeos.sf.net); the Time > Ephemerides project (timeephem.sf.net); PLplot scientific plotting > software package (plplot.sf.net); the libLASi project > (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); > and the Linux Brochure Project (lbproject.sf.net). > __________________________ > > Linux-powered Science > __________________________ ----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ----------------------------------------------------------------------------------- From steveire at gmail.com Thu Feb 5 14:01:53 2015 From: steveire at gmail.com (Stephen Kelly) Date: Thu, 05 Feb 2015 20:01:53 +0100 Subject: [CMake] Workaround for CMP0026 References: <95975260-EF68-4514-88B4-BD7DC5723810@me.com> <7D7195D7-148A-47B4-AB50-8CACE5462C25@me.com> Message-ID: NoRulez wrote: > Thank you for your help. > > I think that for the replacement there is some missing documentation > outstanding, because i didn't find the "TYPE" attribute in the "file" > function for example. I copied and modifier the content from a generated cmake_install.cmake script. The install(SCRIPT) command doesn't specify what can go into such a script. That's a gap in the docs. > Or examples for the CMP0026 policy like in the CMP0043 documentation. > > Nevertheless, I also need to change the filename from > "dirInstallScript.cmake" to "dirInstallScript$.cmake" in the > "file(GENERATE" statement and use the hard coded filename > "dirInstallScriptRelease.cmake" in the "install(SCRIPT" statement, because > if i didn't so, I get several warnings/errors when generating with Visual > Studio generator. Yes, I didn't test with that generator, but I see why that was needed. I'm sure it's possible to avoid hardcoding 'release' in the script. You can generate conditions or anything. > Is this really the right way? Nope, this is a workaround for lack of generator expression support in the install(DIRECTORY) command, similar to http://www.cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6e89c8a5 I don't know if that's not possible for any reason, but it seems to be what you want. Thanks, Steve. From irwin at beluga.phys.uvic.ca Thu Feb 5 14:37:45 2015 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Thu, 5 Feb 2015 11:37:45 -0800 (PST) Subject: [CMake] custom target like add_executable In-Reply-To: <54D3B2FA.1090807@nvidia.com> References: <54D290F2.7070903@nvidia.com> <54D292F5.8030105@nvidia.com> <54D3B2FA.1090807@nvidia.com> Message-ID: On 2015-02-05 10:14-0800 Bill Newcomb wrote: > A contrived example: > > $ ls .. > b CMakeLists.txt foo > > $ cat ../CMakeLists.txt > cmake_minimum_required(VERSION 3.1) > > add_custom_target(foo.sha1 ALL DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/foo.sha1) > > add_custom_command( > OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/foo.sha1 > COMMAND openssl sha1 -out ${CMAKE_CURRENT_BINARY_DIR}/foo.sha1 ${CMAKE_CURRENT_SOURCE_DIR}/foo > ) > Hi Bill: I am virtually positive that target name = filename as in the above example will cause circular dependencies (as you have observed) since for at least the default "Unix Makefiles" generator target names are usually identified with the corresponding filename which name clashes in this case. Also, your add_custom_command has no DEPENDS so by definition it is always out of date and will keep being repeated. I am not familiar with command-line openssl, but I assume ${CMAKE_CURRENT_SOURCE_DIR}/foo is the dependency there. Therefore, I suggest the following modifications: add_custom_command( OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/foo.sha1 COMMAND openssl sha1 -out ${CMAKE_CURRENT_BINARY_DIR}/foo.sha1 ${CMAKE_CURRENT_SOURCE_DIR}/foo DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/foo ) add_custom_target(target_foo.sha1 ALL DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/foo.sha1) (Note, the target name "target_foo.sha1" which no longer corresponds to a real file name (i.e., it has the .PHONY attribute in the Makefile similar to the "all", "install", "help", etc., targets), and the DEPENDS line on the custom command.) After running cmake, then make VERBOSE=1 (or make VERBOSE=1 target_foo.sha1) should run the openssl command Subsequent make commands should not run that openssl command since the result foo.sha1 will have a later date than foo. Subsequently, if you touch foo, then any of the above make commands will run that openssl command (once) again. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From Kent.Knox at amd.com Thu Feb 5 14:29:24 2015 From: Kent.Knox at amd.com (Knox, Kent) Date: Thu, 5 Feb 2015 19:29:24 +0000 Subject: [CMake] Resolving CMP0026 warnings Message-ID: <19F649914E0E4A4C82F9972E886B16CA44BBAA26@satlexdag04.amd.com> Hi all~ I have a question similar to one recently asked by NoRulez about CMP0026. I've been working on updating my legacy cmake code to compile without warnings with the 3.x series. When I install my projects, I want to copy my 'non-system' target dependencies to help debug on non-development machines. A while back, I stumbled on the get_prerequisites( ) cmake function, which helps me enumerate target dependencies. http://www.cmake.org/cmake/help/v3.1/module/GetPrerequisites.html My code is based on the solution posted by a Timothy M. Shead here: http://www.cmake.org/pipermail/cmake/2009-June/029975.html The problem is that get_prerequisites( ) needs a path to the target. How do I now get this path without calling the LOCATION property? I don't know where I can use a generator expression. ===================================== CMakeLists.txt ==================================== get_target_property( libraryLocation myHumbleLibrary LOCATION ) configure_file( "${CMAKE_CURRENT_SOURCE_DIR}/copyLibraryDependencies.cmake.in" "${CMAKE_CURRENT_BINARY_DIR}/copyLibraryDependencies.cmake" @ONLY ) # Register script at run at install time to analyze the executable and copy dependencies into package install( SCRIPT "${CMAKE_CURRENT_BINARY_DIR}/copyLibraryDependencies.cmake" ) ===================================== copyLibraryDependencies.cmake.in ===================================== # The Microsoft IDE presents a challenge because the full configuration is not known at cmake time # This logic allows us to 'substitute' the proper configuration at install time if( "${CMAKE_INSTALL_CONFIG_NAME}" MATCHES "Debug" ) string( REPLACE "\$(Configuration)" "Debug" fixedLibraryLocation "@libraryLocation@" ) endif( ) ... # This retrieves a list of shared library dependencies from the target; they are not full path names # Skip system dependencies and skip recursion get_prerequisites( ${fixedLibraryLocation} libraryDependencies 1 0 "" "" ) # Loop on queried library dependencies and copy them into package foreach( dep ${libraryDependencies} ) ... endforeach( ) Thanks for any help, Kent -------------- next part -------------- An HTML attachment was scrubbed... URL: From ghleclerc at gmail.com Thu Feb 5 15:02:05 2015 From: ghleclerc at gmail.com (Ghyslain Leclerc) Date: Thu, 5 Feb 2015 15:02:05 -0500 Subject: [CMake] Mixed linking Message-ID: Hello, My apologies for the long post, but I think context helps a little. We have a set of applications (4 at the moment) which compile against ITK, VTK, DCMTK and Boost. ?All of those things are compiled statically. ?So is the application. ?We are developing on Windows, OS X and Linux boxes, but deploying almost only on Windows, so the cross-platform quality of the libraries is important to us and CMake makes it relatively easy to target all those platform. Without going into static vs dynamic territory, I?ll say that our choice is based on ease of deployment to the hospital network where IT has lots of control, but we do not. ?So far, because of our choice of static linking, deployment is basically renaming the old .exe to keep an archive of all software that has been run clinical, and then put the new executable in place. We?ve come to the stage where a GUI is something that would be practical. ?We have decided to go with Qt. ?We would like, if possible, to keep using static linking as a strategy, but as far as I can tell, trying to figure out how to use the new Qt5 macros, static linking of Qt is not exactly supported by CMake. Here are a few questions for the list (hoping someone more knowledgable than me will read this and help): 1) Am I right when I say CMake, Qt and static linking don?t mix ? I have tried on OS X. ? I have compiled a static version of Qt, making sure I explicitly enable every plugin I need. ?Then, I have used the following CMake code : ? ? find_package( Qt5Widgets ) ? ? find_package( Qt5Sql ) ? ? find_library( COREFOUNDATION_LIBRARY CoreFoundation ) ? ? find_library( COCOA_LIBRARY Cocoa ) ? ? find_library( CARBON_LIBRARY Carbon ) ? ? find_library( WEBKIT_LIBRARY WebKit ) ? ? find_library( IOKIT_LIBRARY IOKit ) ? ? find_library( OPENGL_LIBRARY OpenGL ) ? ? set( CMAKE_INCLUDE_CURRENT_DIR ON ) ? ? set( CMAKE_AUTOMOC ON ) ? ? add_executable( calculum ${SRCS_LIST} ${UIS_LIST} ${HDRS_LIST} ) ? ? target_link_libraries( calculum ${COREFOUNDATION_LIBRARY} ${COCOA_LIBRARY} ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ${OPENGL_LIBRARY} ${CARBON_LIBRARY} ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Qt5::Widgets Qt5::Sql "/sw/local/qt/plugins/platforms/libqcocoa.a"? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "/sw/local/qt/lib/libqtharfbuzzng.a" z ) ? ? qt5_use_modules( calculum Widgets Sql ) Even so, the executable won?t run. ?I have then tried using the BundleUtilities, but that still won?t work (although I am still figuring things out, so it might be misunderstanding on my part that?s the culprit) 2) If so, we will have to switch to dynamic linking for our GUI applications. ?In that case, is there a way to keep statically linking our other libraries (ITK, VTK, etc.) into our application and only dynamically link the Qt stuff ? ?If we can?t, it means we?ll have to create dynamic libraries of all our external libraries and link to them. ?Deployment will be much harder for us, given that we have zero experience with that. Can you point me towards some tutorials (or documentation, but sometimes, documentation only gets you so far without examples?) ? Thanks Ghyslain -------------- next part -------------- An HTML attachment was scrubbed... URL: From format_c at online.de Thu Feb 5 15:12:36 2015 From: format_c at online.de (Alexander Koeppe) Date: Thu, 05 Feb 2015 21:12:36 +0100 Subject: [CMake] Check symbol in header files with dependencies Message-ID: Hi Cmake user list, I have a problem that I need to check the presence of a certain symbol in a header file using CHECK_SYMBOL_EXISTS which has several dependencies. The check fails because the header file also contains data types that require an additional header file to be included by the test program. It looks like CHECK_SYMBOL_EXISTS is not capable doing that. To be more precise I want to check the presence if IP6T_SO_ORIGINAL_DST is defined in linux/netfilter_ipv6/ip6_tables.h. But the CMakeError.log shows why the check fails: --- Determining if the IP6T_SO_ORIGINAL_DST exist failed with the following output: [...] In file included from /usr/include/linux/netfilter.h:6:0, from /usr/include/linux/netfilter_ipv6.h:11, from /usr/include/linux/netfilter_ipv6/ip6_tables.h:20, from /build/CMakeFiles/CMakeTmp/CheckSymbolExists.c:2: /usr/include/linux/sysctl.h:40:2: error: unknown type name ?size_t? size_t *oldlenp; ^ /usr/include/linux/sysctl.h:42:2: error: unknown type name ?size_t? size_t newlen; ^ In file included from /usr/include/linux/netfilter_ipv6.h:11:0, from /usr/include/linux/netfilter_ipv6/ip6_tables.h:20, from /build/CMakeFiles/CMakeTmp/CheckSymbolExists.c:2: /usr/include/linux/netfilter.h:67:17: error: field ?in? has incomplete type struct in_addr in; ^ /usr/include/linux/netfilter.h:68:18: error: field ?in6? has incomplete type struct in6_addr in6; ^ [...] File /build/CMakeFiles/CMakeTmp/CheckSymbolExists.c: /* */ #include int main(int argc, char** argv) { (void)argv; #ifndef IP6T_SO_ORIGINAL_DST return ((int*)(&IP6T_SO_ORIGINAL_DST))[argc]; #else (void)argc; return 0; #endif } --- Does somebody have an advice how to overcome this issue? Maybe I have missed a function or macro that does the trick? Any help on that is much appreciated. Cheers Alex From steveire at gmail.com Thu Feb 5 15:36:04 2015 From: steveire at gmail.com (Stephen Kelly) Date: Thu, 05 Feb 2015 21:36:04 +0100 Subject: [CMake] Resolving CMP0026 warnings References: <19F649914E0E4A4C82F9972E886B16CA44BBAA26@satlexdag04.amd.com> Message-ID: Knox, Kent wrote: > The problem is that get_prerequisites( ) needs a path to the target. How > do I now get this path without calling the LOCATION property? I don't > know where I can use a generator expression. Replace your configure_file with something like file(GENERATE OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/copyLibraryDependencies$.cmake" CONTENT "if(CMAKE_INSTALL_CONFIG_NAME STREQUAL $) set(libraryLocation $) endif() " ) There's no need to 'fix' the library then. Of course, if there are multiple targets, you might want to generate a loop instead of one such file per target etc. I'll leave it to you to parametrize whatever you want :). Thanks, Steve. From steveire at gmail.com Thu Feb 5 15:41:40 2015 From: steveire at gmail.com (Stephen Kelly) Date: Thu, 05 Feb 2015 21:41:40 +0100 Subject: [CMake] Mixed linking References: Message-ID: Ghyslain Leclerc wrote: > Here are a few questions for the list (hoping someone more knowledgable > than me will read this and help): > > 1) Am I right when I say CMake, Qt and static linking don?t mix ? They should mix fine. > > I have tried on OS X. I have compiled a static version of Qt, making > sure I explicitly enable every plugin I need. Then, I have used the > following CMake code : I recommend starting with a minimal testcase, make sure it runs, and add things until it doesn't. Find the change that breaks. > qt5_use_modules( calculum Widgets Sql ) You probably don't need this line. I don't have experience on OSX to help. Thanks, Steve. From eike at sf-mail.de Thu Feb 5 15:58:38 2015 From: eike at sf-mail.de (Rolf Eike Beer) Date: Thu, 05 Feb 2015 21:58:38 +0100 Subject: [CMake] Check symbol in header files with dependencies In-Reply-To: References: Message-ID: <4705420.RVzLX5ejzZ@caliban.sf-tec.de> Am Donnerstag, 5. Februar 2015, 21:12:36 schrieb Alexander Koeppe: > Hi Cmake user list, > > I have a problem that I need to check the presence of a certain symbol > in a header file using CHECK_SYMBOL_EXISTS which has several dependencies. > > The check fails because the header file also contains data types that > require an additional header file to be included by the test program. It > looks like CHECK_SYMBOL_EXISTS is not capable doing that. set(CMAKE_REQUIRED_INCLUDES some_header.h other/header.h) check_symbol_exists(...) 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 marco.atzeri at gmail.com Thu Feb 5 16:08:47 2015 From: marco.atzeri at gmail.com (Marco Atzeri) Date: Thu, 05 Feb 2015 22:08:47 +0100 Subject: [CMake] Post test in build tree Message-ID: <54D3DBDF.2000902@gmail.com> on latest Lapack source there is on "CTestCustom.cmake.in" the following command SET(CTEST_CUSTOM_POST_TEST "./lapack_testing.py -s -d TESTING") but unfortunately as "./lapack_testing.py" is on the source tree it does not work if the build tree is a different one. Any suggestion how to modify it ? Thanks in advance Marco From bnewcomb at nvidia.com Thu Feb 5 16:12:57 2015 From: bnewcomb at nvidia.com (Bill Newcomb) Date: Thu, 5 Feb 2015 13:12:57 -0800 Subject: [CMake] custom target like add_executable In-Reply-To: References: <54D290F2.7070903@nvidia.com> <54D292F5.8030105@nvidia.com> <54D3B2FA.1090807@nvidia.com> Message-ID: <54D3DCD9.60309@nvidia.com> I was missing the dependency of foo.sha1 on foo, but adding it doesn't change the behavior in this example--it is still regenerated after every make. But now I think I see why. Commenting out first one, then the other of my add_custom_*, I start to see why this is the case--add_custom_output doesn't do anything at all if the OUTPUT isn't used by something else, and add_custom_target targets are ALWAYS out of date. If I delete the following lines from CMakeFiles/foo.sha1.dir/build.make, it works exactly like I'd want it to: --- b/CMakeFiles/foo.sha1.dir/build.make 2015-02-05 12:27:58.169468000 -0800 +++ b.good/CMakeFiles/foo.sha1.dir/build.make 2015-02-05 12:26:24.804643000 -0800 @@ -52,10 +52,7 @@ @$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) --blue --bold "Generating foo.sha1" openssl sha1 -out /home/bnewcomb/tmp/cmake-tests/test-fail/b/foo.sha1 /home/bnewcomb/tmp/cmake-tests/test-fail/foo -foo.sha1: CMakeFiles/foo.sha1 -foo.sha1: foo.sha1 foo.sha1: CMakeFiles/foo.sha1.dir/build.make -.PHONY : foo.sha1 # Rule to build all files generated by this target. CMakeFiles/foo.sha1.dir/build: foo.sha1 I have been using the workaround you suggested below as a stopgap, but it has the drawback of being non-obvious to users that in order to generate the file named foo.sha1 from the command line they need to type 'make target_foo.sha1' instead of 'make foo.sha1'. The following (anti-)pattern actually does what I want, although it's a gratuitous hack: add_custom_target(target_foo.sha1 DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/foo.sha1) add_custom_target(foo.sha1 ALL) add_dependencies(foo.sha1 target_foo.sha1) add_custom_command( OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/foo.sha1 COMMAND openssl sha1 -out ${CMAKE_CURRENT_BINARY_DIR}/foo.sha1 ${CMAKE_CURRENT_SOURCE_DIR}/foo DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/foo ) Mostly, I wanted to figure out if this were possible with existing cmake, and my curiosity is satisfied. Thanks, B. On 02/05/2015 11:37 AM, Alan W. Irwin wrote: > On 2015-02-05 10:14-0800 Bill Newcomb wrote: > >> A contrived example: >> >> $ ls .. >> b CMakeLists.txt foo >> >> $ cat ../CMakeLists.txt >> cmake_minimum_required(VERSION 3.1) >> >> add_custom_target(foo.sha1 ALL DEPENDS >> ${CMAKE_CURRENT_BINARY_DIR}/foo.sha1) >> >> add_custom_command( >> OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/foo.sha1 >> COMMAND openssl sha1 -out ${CMAKE_CURRENT_BINARY_DIR}/foo.sha1 >> ${CMAKE_CURRENT_SOURCE_DIR}/foo >> ) >> > > Hi Bill: > > I am virtually positive that target name = filename as in the above > example will cause circular dependencies (as you have observed) since > for at least the default "Unix Makefiles" generator target names are > usually identified with the > corresponding filename which name clashes in this case. Also, your > add_custom_command has no DEPENDS so by definition it is always out of > date and will keep being repeated. I am not familiar with > command-line openssl, but I assume ${CMAKE_CURRENT_SOURCE_DIR}/foo is > the dependency there. > > Therefore, I suggest the following modifications: > > add_custom_command( > OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/foo.sha1 > COMMAND openssl sha1 -out ${CMAKE_CURRENT_BINARY_DIR}/foo.sha1 > ${CMAKE_CURRENT_SOURCE_DIR}/foo > DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/foo > ) > > add_custom_target(target_foo.sha1 ALL DEPENDS > ${CMAKE_CURRENT_BINARY_DIR}/foo.sha1) > > (Note, the target name "target_foo.sha1" which no longer corresponds > to a real file name (i.e., it has the .PHONY attribute in the Makefile > similar to the > "all", "install", "help", etc., targets), and the DEPENDS line on the > custom command.) > > After running cmake, then > > make VERBOSE=1 (or make VERBOSE=1 target_foo.sha1) should run the > openssl command > > Subsequent make commands should not run that openssl command since the > result foo.sha1 will have a later date than foo. Subsequently, if you > touch foo, then any of the above make commands will run that openssl > command (once) again. > > Alan > __________________________ > Alan W. Irwin > > Astronomical research affiliation with Department of Physics and Astronomy, > University of Victoria (astrowww.phys.uvic.ca). > > Programming affiliations with the FreeEOS equation-of-state > implementation for stellar interiors (freeeos.sf.net); the Time > Ephemerides project (timeephem.sf.net); PLplot scientific plotting > software package (plplot.sf.net); the libLASi project > (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); > and the Linux Brochure Project (lbproject.sf.net). > __________________________ > > Linux-powered Science > __________________________ ----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ----------------------------------------------------------------------------------- From luc_j_bourhis at mac.com Thu Feb 5 18:20:39 2015 From: luc_j_bourhis at mac.com (Luc J. Bourhis) Date: Thu, 5 Feb 2015 16:20:39 -0700 (MST) Subject: [CMake] ExternalProject: download step progress prints too much Message-ID: <1423178439370-7589703.post@n2.nabble.com> Using "include(ExternalProject)" with CMake 2.8, the download step echoes its progress in my terminal as: I am pretty sure the intended effect was a single line with the percentage changing as the download progresses. But what is missing from my environment to achieve that? I am running a stock Fedora 20. Thanks in advance. ----- -- Luc J. Bourhis -- View this message in context: http://cmake.3232098.n2.nabble.com/ExternalProject-download-step-progress-prints-too-much-tp7589703.html Sent from the CMake mailing list archive at Nabble.com. From norbert.pfeiler+cmake at gmail.com Thu Feb 5 19:13:20 2015 From: norbert.pfeiler+cmake at gmail.com (Norbert Pfeiler) Date: Fri, 6 Feb 2015 01:13:20 +0100 Subject: [CMake] Mixed linking In-Reply-To: References: Message-ID: Hey, to build a static qt executable for windows you may be interested in using msys2. It offers a prepackaged static qt5 with patches for static linking with cmake (as the official files are a bit broken for mingw). Currently you have to define ?QT_STATIC? and explicitly include your required plugins in the code to get it working. In our case we only link statically on windows, on linux and mac we deploy the dynamic libraries. Best, Norbert. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jussi.lind at vincit.fi Fri Feb 6 02:42:33 2015 From: jussi.lind at vincit.fi (Jussi Lind) Date: Fri, 6 Feb 2015 09:42:33 +0200 Subject: [CMake] CMake: Error running link command: %1 is not a valid Win32 application Message-ID: I'm trying to build a NaCl extension for Google Chrome on 64-bit Windows 8.1 using CMake. It uses a custom toolchain that comes with the SDK. The same code works on Ubuntu without any problems. Everything goes well until CMake tries to link with this command: cmake -E cmake_link_script link.txt CMake: Error running link command: %1 is not a valid Win32 application The link.txt is as follows: C:/nacl_sdk/pepper_39/toolchain/win_pnacl/bin/pnacl-ar cr libfoo.a CMakeFiles/foo.dir/Foo.cc.o C:/nacl_sdk/pepper_39/toolchain/win_pnacl/bin/pnacl-ranlib libfoo.a This happens with both NMake and Unix makefile generators (the NaCl SDK contains make.exe for Windows). If I run those exactly same commands manually, they succeed. What could be wrong here? It's as if CMake somehow fails to parse the paths correctly for some reason. BR, Jussi -------------- next part -------------- An HTML attachment was scrubbed... URL: From petr.kmoch at gmail.com Fri Feb 6 08:01:30 2015 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Fri, 6 Feb 2015 14:01:30 +0100 Subject: [CMake] ExternalProject_add and add_subdirectory in one step In-Reply-To: References: Message-ID: Hi Franz. The "canonical" approach to ExternalProject is to use a "superbuild" setup. Design your top-level CMakeList so that it *only* contains ExternalProject_add() calls, treating your "original" project as just another external project. Build the superbuild once, getting all the dependencies downloaded, built, installed etc. as necessary. Then, switch to working with only your "original" project subcomponent of the superbuild. Petr On Thu, Feb 5, 2015 at 5:32 PM, Franz Engel wrote: > Hi, > > > > I try to clone an repository from my bare-repository and to build my > project tree. Therefore I use the following commands: > > > > ExternalProject_Add ( demoA > > PREFIX ${MAIN_PATH}/demoA > > GIT_REPOSITORY ${REPOSITORY_PATH}/demoA > > GIT_TAG origin/master > > UPDATE_COMMAND "" > > INSTALL_COMMAND "" ) > > > > add_subdirectory(${CMAKE_CURRENT_SOURCE_DIR}/../demoA/src/DemoA > ${CMAKE_CURRENT_SOURCE_DIR}/demoA) > > > > Know I have the following problem. I load the Cmake-file with QtCreator. > If I run CMake I get the error message ?does not contain a CMakeLists.txt > file?. That message is clear for me, because the repository only get loaded > when I compile the code. The question is, if it is possible to clone the > repo in the step of CMake. Does somebody has an idea? Or is there another > method to build the project tree? > > > > Br, > > Franz > > ------------------------------ > > > Franz Engel > > AIRBUS APWORKS GmbH > 81663 Munich - Germany > T: +49 (0) 89 607 29103 > M: +49 (0) 170 44 59 006 > franz.engel at apworks.de > > AIRBUS APWORKS GmbH > Registered Office: Ottobrunn > District Court of Munich: HRB 141734 > Managing Director: Joachim Zettler > Internet: www.apworks.de > > ------------------------------ > > > > -- > > 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 mike.jackson at bluequartz.net Fri Feb 6 09:00:31 2015 From: mike.jackson at bluequartz.net (Michael Jackson) Date: Fri, 6 Feb 2015 09:00:31 -0500 Subject: [CMake] "Modern" CMake with Qt5 and packaging on OS X Message-ID: <1CACA968-18E9-48EC-BF34-C4912767F309@bluequartz.net> We are migrating our application from Qt4 to Qt5. In the past we had a combination of a cmake script and shell script that would fix-up the application bundle on OS X. This does not seem to work any more in that we are missing the platform plugins and a few other items. Are there any examples of how people are creating app packages with Qt5 for OS X? Eventually we will need Windows and Linux also. We also have our own plugins which may complicate things but any help is appreciated. Thanks Mike Jackson From zjfroot at gmail.com Fri Feb 6 09:03:19 2015 From: zjfroot at gmail.com (Jifeng ZHANG) Date: Fri, 6 Feb 2015 15:03:19 +0100 Subject: [CMake] CMP0026 - Disallow use of the LOCATION target property Message-ID: Hi, I have a question of policy CMP0026. Our project currently is on CMake 2 and we are planning to move to CMake 3. When we run CMake3.1.1, we get get a few warnings due to the policy CMP0026, "Disallow use of the LOCATION target property". Even though with those warnings, our cmake scripts still work fine and we are getting the property correctly. One example is like this: get_target_property (TEST_PATH ${TESTS_PROJECT} LOCATION_${CMAKE_BUILD_TYPE}) So my question is, will the support of this kind of usage be dropped in the future releases? I understand the LOCATION property is not fully determined until geenrate-time, however, since it works in our case, can we rely on this behavior or we should consider it will change in the coming 3.x releases? If we migrate away from get_target_property, "$ generator expression" is suggested from CMake3.1.1's documentation. So to get the LOCATION of ${TEST_PROJECT}, I can use: set (TEST_PATH $) But if I want to get LOCATION_${CMAKE_BUILD_TYPE}, how can I do it? Thanks. -- V?nliga h?lsningar/Best regards, Jifeng Zhang From ghleclerc at gmail.com Fri Feb 6 10:04:33 2015 From: ghleclerc at gmail.com (Ghyslain Leclerc) Date: Fri, 6 Feb 2015 10:04:33 -0500 Subject: [CMake] Mixed linking Message-ID: Hello again. Thanks for the answers. To Stephen Kelly: >> Here are a few questions for the list (hoping someone more knowledgable >> than me will read this and help): >> >> 1) Am I right when I say CMake, Qt and static linking don?t mix ? >They should mix fine. Alright, I won't give up just yet. :-) >> I have tried on OS X. I have compiled a static version of Qt, making >> sure I explicitly enable every plugin I need. Then, I have used the >> following CMake code : >I recommend starting with a minimal testcase, make sure it runs, and add >things until it doesn't. Find the change that breaks. Thanks for the suggestion. Just did. Here is the code for CMake: # Some definitions to setup Qt set( CMAKE_INCLUDE_CURRENT_DIR ON ) set( CMAKE_AUTOMOC ON ) set( QT_STATIC TRUE ) add_definitions( -DQT_STATIC ) if( "${CMAKE_BUILD_TYPE}" MATCHES Release ) add_definitions(-DQT_NO_DEBUG_OUTPUT) endif() # Find Qt packages find_package( Qt5Widgets ) # Find Qt dependencies find_library( COREFOUNDATION_LIBRARY CoreFoundation ) find_library( COCOA_LIBRARY Cocoa ) find_library( CARBON_LIBRARY Carbon ) find_library( OPENGL_LIBRARY OpenGL ) include_directories( ${CMAKE_CURRENT_LIST_DIR} ) add_executable( helwrld main.cpp ) target_link_libraries( helwrld Qt5::Widgets ${COREFOUNDATION_LIBRARY} ${COCOA_LIBRARY} ${CARBON_LIBRARY} ${OPENGL_LIBRARY} "/sw/local/qt/lib/libqtharfbuzzng.a" z ) And here is the main.cpp file #include #include int main(int argc, char *argv[]) { QApplication a(argc, argv); QLabel *label = new QLabel("Hello Qt!"); label->show(); return a.exec(); } Don't know how to make it simpler. Using the code compiles and links, but still won't run. Maybe my Qt static compilation was missing something. I will try and look into that. To Norbert Pfeiler : > Currently you have to define ?QT_STATIC? and explicitly include your > required plugins in the code to get it working. Thanks for the tips. I looked up and now define QT_STATIC. But I just don't know how to include the plugins. Actually, I always get the error about the platform plugin (cocoa in my case). Any tips ? Thank you to all ! Ghyslain From norbert.pfeiler+cmake at gmail.com Fri Feb 6 10:24:09 2015 From: norbert.pfeiler+cmake at gmail.com (Norbert Pfeiler) Date: Fri, 6 Feb 2015 16:24:09 +0100 Subject: [CMake] Mixed linking In-Reply-To: References: Message-ID: > > But I just don't know how to include the plugins. Actually, I always get > the error about the platform plugin (cocoa in my case). Any tips ? For Windows it?s like this: #if defined(Q_OS_WIN) && defined(QT_STATIC) #include Q_IMPORT_PLUGIN(QWindowsIntegrationPlugin) #endif Best, Norbert. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at classdesign.com Fri Feb 6 13:03:25 2015 From: bill at classdesign.com (Bill Somerville) Date: Fri, 06 Feb 2015 18:03:25 +0000 Subject: [CMake] "Modern" CMake with Qt5 and packaging on OS X In-Reply-To: <1CACA968-18E9-48EC-BF34-C4912767F309@bluequartz.net> References: <1CACA968-18E9-48EC-BF34-C4912767F309@bluequartz.net> Message-ID: <54D501ED.7010405@classdesign.com> On 06/02/2015 14:00, Michael Jackson wrote: Hi Mike, > We are migrating our application from Qt4 to Qt5. In the past we had a combination of a cmake script and shell script that would fix-up the application bundle on OS X. This does not seem to work any more in that we are missing the platform plugins and a few other items. Are there any examples of how people are creating app packages with Qt5 for OS X? Eventually we will need Windows and Linux also. We also have our own plugins which may complicate things but any help is appreciated. Not offering this as a glowing example of CMake idiom and style as it is a learning process for me as well, but this project builds an application bundle on Mac as well as building on Windows, Linux etc.. The Mac and Windows packaging is done mainly with the CMake/CPack bundle utilities. We don't manage to directly produce Linux packages but we try and help the Linux packages as much as possible. svn checkout svn://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx Only the above branch, which a trunk in disguise :( , is "properly" CMake/CPack built. This is not commercial software but it does use Fortran/C/C++ Qt5 FFTW3 and most recently OpenMP so it is quite complex. > > Thanks > Mike Jackson > Regards Bill Somerville. From steveire at gmail.com Fri Feb 6 13:18:31 2015 From: steveire at gmail.com (Stephen Kelly) Date: Fri, 06 Feb 2015 19:18:31 +0100 Subject: [CMake] CMP0026 - Disallow use of the LOCATION target property References: Message-ID: Jifeng ZHANG wrote: > Hi, > > I have a question of policy CMP0026. Our project currently is on CMake > 2 and we are planning to move to CMake 3. Lot's of questions on that lately. Someone opened the floodgates it seems :). > When we run CMake3.1.1, we get get a few warnings due to the policy > CMP0026, "Disallow use of the LOCATION target property". Even though > with those warnings, our cmake scripts still work fine and we are > getting the property correctly. > So my question is, will the support of this kind of usage be dropped > in the future releases? Yes. That is the purpose of the policy. Attempting to read the LOCATION will eventually be an error. That is not going to happen before CMake 4.0 though. > If we migrate away from get_target_property, "$ generator > expression" is suggested from CMake3.1.1's documentation. So to get > the LOCATION of ${TEST_PROJECT}, I can use: > set (TEST_PATH $) This won't work. You need to use the generator expression instead of a cmake variable. You use the generator expression in place of ${TEST_PATH} in add_custom_command or wherever you use it. Thanks, Steve. From steveire at gmail.com Fri Feb 6 13:24:40 2015 From: steveire at gmail.com (Stephen Kelly) Date: Fri, 06 Feb 2015 19:24:40 +0100 Subject: [CMake] Mixed linking References: Message-ID: Norbert Pfeiler wrote: >> >> But I just don't know how to include the plugins. Actually, I always get >> the error about the platform plugin (cocoa in my case). Any tips ? > > > For Windows it?s like this: > > #if defined(Q_OS_WIN) && defined(QT_STATIC) > #include > Q_IMPORT_PLUGIN(QWindowsIntegrationPlugin) > #endif Ah, right the platform plugin issue. This is likely the reason for not running on OSX. CMake 3.1 learned a new feature specifically so that this would become easier in the future: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/7970 qmake generates a file like the above for you and compiles it and links it into your application for you in the static version. With http://www.cmake.org/cmake/help/v3.1/prop_tgt/INTERFACE_SOURCES.html Qt can do the same, but someone would have to patch Qt to do so. Something for the future... :) Thanks, Steve. From mingw.android at gmail.com Fri Feb 6 17:18:08 2015 From: mingw.android at gmail.com (Ray Donnelly) Date: Fri, 6 Feb 2015 22:18:08 +0000 Subject: [CMake] Mixed linking Message-ID: Hi, Apologies that this won't tread correctly (and for directly CC'ing the three participants); I only signed up to the mailing list after I saw this conversation. I'm an MSYS2 developer (and I occasionally hack on Qt build system issues). I've spent a lot of time working on our qt5 and qt5-static packages and a little time working on our cmake packages, so I'm quite familiar with the CMake and Qt5 static issues you are discussing, in fact it's the most recent thing I've hacked on for these packages. My patches can be found at: https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-qt5-static [patches 33 .. 41 are mostly cmake related] .. and: https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-cmake [qt5-static-plugin-support.patch] Stephen Kelly wrote: > Ghyslain Leclerc wrote: > > > Here are a few questions for the list (hoping someone more knowledgable > > than me will read this and help): > > > > 1) Am I right when I say CMake, Qt and static linking don?t mix ? > > They should mix fine. .. actually, you did submit a patch to Qt5 for this: https://codereview.qt-project.org/#/c/33193/ .. but then you reverted it: https://codereview.qt-project.org/#/c/37307/ I un-reverted it for MSYS2, with the logic given in my commit message. I'll not paste it here as you can read it there, but please correct me if I'm wrong regarding INTERFACE_LINK_LIBRARIES: https://github.com/Alexpux/MINGW-packages/commit/fe1c58d6baf5ca98cf6697a41e8e98349a7e81d8 Norbert Pfeiler wrote: > Currently you have to define ?QT_STATIC? You shouldn't need to do this. If you use MSYS2's mingw-w64-{i686,x86_64}-qt5-static then that will be defined for you. > and explicitly include your required plugins in the code to get it working More on this below. Norbert Pfeiler wrote: > For Windows it?s like this: > > #if defined(Q_OS_WIN) && defined(QT_STATIC) > #include > Q_IMPORT_PLUGIN(QWindowsIntegrationPlugin) > #endif Again, if you use MSYS2's mingw-w64-{i686,x86_64}-cmake then you should not need to do this either, because of https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-cmake/qt5-static-plugin-support.patch Stephen Kelly wrote: > CMake 3.1 learned a new feature specifically so that this would become > easier in the future: > > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/7970 > > qmake generates a file like the above for you and compiles it and links it > into your application for you in the static version. > > With > > http://www.cmake.org/cmake/help/v3.1/prop_tgt/INTERFACE_SOURCES.html > > Qt can do the same, but someone would have to patch Qt to do so. Something > for the future... :) .. so I guess that overall, my patches are far from ideal (still they achieve their goal for us!), in particular I didn't like adding code to cmQtAutoGenerators.cxx as that seems like something that shouldn't be hard-coded into a general purpose build system, but I'm pleased to read that the plan is to generalise this kind of thing going forward (I think that's the gist - clearly I'm no expert in CMake). As a side node, I actually tried to use a Digia-provided (I think) Qt static build for something work-related about a year ago, and because it requires a specific version of the msvc++ runtime I don't think it fits any useful definition of 'static'. Qt static built with MinGW-w64 does though as the msvcrt.dll we use is present on all Windows releases all the way back to Windows XP. Maybe I used the wrong one though, as the Qt SDK seems to be static enough. Best regards, Ray Donnelly. From norbert.pfeiler+cmake at gmail.com Fri Feb 6 18:24:54 2015 From: norbert.pfeiler+cmake at gmail.com (Norbert Pfeiler) Date: Sat, 7 Feb 2015 00:24:54 +0100 Subject: [CMake] Mixed linking In-Reply-To: References: Message-ID: > > Norbert Pfeiler wrote: > > Currently you have to define ?QT_STATIC? > You shouldn't need to do this. If you use MSYS2's > mingw-w64-{i686,x86_64}-qt5-static then that will be defined for you. I have both *-qt5 (for dev) and *-qt5-static (for deploy) installed and append the root of qt5-static to CMAKE_PREFIX_PATH for cmake to prefer the static to the shared version. QT_STATIC is not defined in this case. Norbert Pfeiler wrote: > > For Windows it?s like this: > > > > #if defined(Q_OS_WIN) && defined(QT_STATIC) > > #include > > Q_IMPORT_PLUGIN(QWindowsIntegrationPlugin) > > #endif > Again, if you use MSYS2's mingw-w64-{i686,x86_64}-cmake then you > should not need to do this either, because of This is also not the case in the configuration above. I don?t have to explicitly link the platform plugin though (after adding Q_IMPORT_PLUGIN). These 2 additions are way less of a hassle than having to rename *.lib to *.a in all the qt cmake files and explicitly specifying all transitive qt link deps, which was necessary before. So thanks for your work. Looking forward to: > > They should mix fine. Best, Norbert. -------------- next part -------------- An HTML attachment was scrubbed... URL: From format_c at online.de Sat Feb 7 06:17:00 2015 From: format_c at online.de (Alexander Koeppe) Date: Sat, 07 Feb 2015 12:17:00 +0100 Subject: [CMake] Check symbol in header files with dependencies In-Reply-To: <4705420.RVzLX5ejzZ@caliban.sf-tec.de> References: <4705420.RVzLX5ejzZ@caliban.sf-tec.de> Message-ID: Am 05.02.2015 um 21:58 schrieb Rolf Eike Beer: > > set(CMAKE_REQUIRED_INCLUDES some_header.h other/header.h) > check_symbol_exists(...) > > Eike > Thanks Eike, unfortunately it didn't bring the effect it should have. Setting the CMAKE_REQUIRED_INCLUDES variable made setting the -I parameter of the compiler. That ended up in a test compiler call of /usr/bin/cc -DHAVE_IP6T_SO_ORIGINAL_DST -I/build/CMakeFiles/CMakeTmp/stdio.h -I/build/CMakeFiles/CMakeTmp/netinet/in.h -o CMakeFiles/cmTryCompileExec2968261629.dir/src.c.o -c /build/CMakeFiles /CMakeTmp/src.c But the test source file still contains only the #include specified in CHECK_SYMBOL_EXISTS(). Hence the compilation fails with the same "unknown type" errors. Any more tips are welcome. Cheers Alex From norulez at me.com Sat Feb 7 15:39:44 2015 From: norulez at me.com (NoRulez) Date: Sat, 07 Feb 2015 21:39:44 +0100 Subject: [CMake] CMP0026 - Disallow use of the LOCATION target property In-Reply-To: References: Message-ID: <1D9B19F0-F52E-42E5-8666-5728ABDFB579@me.com> Hi, We had that problem too. Look at the great example from Stephen to my question. His example was great and helped us a lot. Best Regards > Am 06.02.2015 um 19:18 schrieb Stephen Kelly : > > Jifeng ZHANG wrote: > >> Hi, >> >> I have a question of policy CMP0026. Our project currently is on CMake >> 2 and we are planning to move to CMake 3. > > Lot's of questions on that lately. Someone opened the floodgates it seems > :). > >> When we run CMake3.1.1, we get get a few warnings due to the policy >> CMP0026, "Disallow use of the LOCATION target property". Even though >> with those warnings, our cmake scripts still work fine and we are >> getting the property correctly. > >> So my question is, will the support of this kind of usage be dropped >> in the future releases? > > Yes. That is the purpose of the policy. Attempting to read the LOCATION will > eventually be an error. That is not going to happen before CMake 4.0 though. > >> If we migrate away from get_target_property, "$ generator >> expression" is suggested from CMake3.1.1's documentation. So to get >> the LOCATION of ${TEST_PROJECT}, I can use: >> set (TEST_PATH $) > > This won't work. You need to use the generator expression instead of a cmake > variable. You use the generator expression in place of ${TEST_PATH} in > add_custom_command or wherever you use 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 From alexey.petruchik at gmail.com Sat Feb 7 16:34:28 2015 From: alexey.petruchik at gmail.com (Alexey Petruchik) Date: Sun, 8 Feb 2015 00:34:28 +0300 Subject: [CMake] Remove -D${target_name}_EXPORTS from shared library compilation flags Message-ID: I know it's a bit weird but I need it. I'm currently working on moving make-based project to cmake. I want to get absolutely the same flags as current makefiles have, so I need to remove autogenerated -D${target_name}_EXPORTS. set_property(TARGET a PROPERTY DEFINE_SYMBOL "") is not working for me. Can anyone help me with this issue? Regards, Alexey -------------- next part -------------- An HTML attachment was scrubbed... URL: From neil.n.carlson at gmail.com Sat Feb 7 23:14:47 2015 From: neil.n.carlson at gmail.com (Neil Carlson) Date: Sat, 7 Feb 2015 21:14:47 -0700 Subject: [CMake] ExternalProject_Add: directing cmake to a different Message-ID: I'm trying to get ExternalProject_Add to build a TPL that doesn't have a CMakeLists.txt file in the top-level directory. The TPL untars as foo/{A,B} where A and B each contain a CMakeLists.txt file and are independent of each other. I only want to build "A" and would like to have cmake run with "foo/A" as the . Unfortunately I can't seem to manage it. The tar file is unpacked with ${SOURCE_DIR} as its root, and that same directory is used as the for the cmake command -- I want ${SOURCE_DIR}/A. Any suggestions on how to make ExternalProject do what I want? Clearly I can just repackage the tar file, but I'd rather use the pristine tar file if I can. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From espakm at gmail.com Sun Feb 8 01:24:50 2015 From: espakm at gmail.com (Miklos Espak) Date: Sun, 08 Feb 2015 06:24:50 +0000 Subject: [CMake] ExternalProject_Add: directing cmake to a different References: Message-ID: Specify a patch command that creates a toplevel cmake list with one 'add_subdirectory(A)' line. On Sun, 8 Feb 2015 4:14 am Neil Carlson wrote: > I'm trying to get ExternalProject_Add to build a TPL that doesn't have a > CMakeLists.txt file in the top-level directory. The TPL untars as > foo/{A,B} where A and B each contain a CMakeLists.txt file and are > independent of each other. I only want to build "A" and would like to have > cmake run with "foo/A" as the . Unfortunately I can't seem > to manage it. The tar file is unpacked with ${SOURCE_DIR} as its root, and > that same directory is used as the for the cmake command > -- I want ${SOURCE_DIR}/A. Any suggestions on how to make ExternalProject > do what I want? Clearly I can just repackage the tar file, but I'd rather > use the pristine tar file if I can. > > Thanks > -- > > 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 dan.zadeh at pathcore.ca Sun Feb 8 02:32:05 2015 From: dan.zadeh at pathcore.ca (dannyboy) Date: Sun, 8 Feb 2015 00:32:05 -0700 (MST) Subject: [CMake] Access denied error with cmake 3.1.1 -E env option (MSVC 11) Message-ID: <1423380725656-7589722.post@n2.nabble.com> Hello, I recently discovered the "cmake -E env" option in the newly released 3.1 version of CMake. Fantastic contribution, thank you to all involved! This is a great feature that is very useful for ExternalProject_Add as other have pointed out. However, I have now spent the better part of a day trying to recover from a vague "Access is denied" error in Visual Studios while trying to use this new feature. Any advice or helpful hints would be greatly appreciated. Here is some code to demonstrate my issue. Everything goes smoothly until the build command executes. // // ... other decelerations excluded for brevity // FILE(TO_NATIVE_PATH "${CMAKE_SOURCE_DIR}/resources/windows" nasm_path ) SET( env_paths "$ENV{PATH};${nasm_path}" ) ExternalProject_Add( libjpeg PREFIX ${jpeg_prefix} URL ${jpeg_file} URL_MD5 ${jpeg_md5} PATCH_COMMAND "" BUILD_IN_SOURCE 1 CONFIGURE_COMMAND COMMAND ${CMAKE_COMMAND} -E chdir ${jpeg_source} ${CMAKE_COMMAND} -G "NMake Makefiles" -DCMAKE_BUILD_TYPE=Release ${jpeg_source} BUILD_COMMAND COMMAND ${CMAKE_COMMAND} -E chdir ${jpeg_source} ${CMAKE_COMMAND} -E env "PATH=${env_paths}" nmake /f Makefile INSTALL_COMMAND "" ) // // end of snippet // // // Build output - cleaned up for brevity // 2>------ Build started: Project: libjpeg (ExternalProjectTargets\libjpeg\libjpeg), Configuration: RelWithDebInfo Win32 ------ . . 2> Performing download step (download, verify and extract) for 'libjpeg' . . 2> Performing configure step for 'libjpeg' . . 2> Performing build step for 'libjpeg' 2> Access is denied 2> 2>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Microsoft.CppCommon.targets(172,5): error MSB6006: "cmd.exe" exited with code 1. ========== Build: 1 succeeded, 1 failed, 0 up-to-date, 0 skipped ========== // // Note 1: also tried this variant of the BUILD_COMMAND without success // BUILD_COMMAND COMMAND ${CMAKE_COMMAND} -E chdir ${jpeg_source} ${CMAKE_COMMAND} -E env "PATH=\"${env_paths}\"" nmake /f Makefile which produces a difference but more promising error: "The system cannot find the file specified", indicating there is a problem with escaping..... // // Note 2: Removing -E env option, the build command executes but ultimately fails because the required components are not found // // // Note 3: Tried running VS in administrator mode without success // -- View this message in context: http://cmake.3232098.n2.nabble.com/Access-denied-error-with-cmake-3-1-1-E-env-option-MSVC-11-tp7589722.html Sent from the CMake mailing list archive at Nabble.com. From chris530d at gmail.com Sun Feb 8 12:30:31 2015 From: chris530d at gmail.com (Chris Dembia) Date: Sun, 8 Feb 2015 09:30:31 -0800 Subject: [CMake] Not hardcoding install dir in Config.cmake. Message-ID: Hey all: I work on a project that is used heavily on Windows. Our project also creates a Config.cmake file. During build time, we do not know where the project will actually be installed on the user's system. However, the Config.file needs to know the installation directory of the package. Previously we were hardcoding this, and of course this doesn't let users choose their own install directory if they are only given our binary package. I see that the Targets.cmake file deals with this by computing the installation directory by using the knowledge of *where* the Targets.cmake file is within the project. This made me so happy to see! Anyway, this is how I'm thinking of doing the same thing: Given CONFIG_INSTALL_DIR (full path location of the Config.cmake file in the installation), and CMAKE_INSTALL_PREFIX: # within the project's CMakeLists.txt set(tmp "${CONFIG_INSTALL_DIR}") set(counter) while(NOT "${CMAKE_INSTALL_PREFIX}" STREQUAL "${tmp}") get_filename_component(tmp "${tmp}" PATH) math(EXPR counter "${counter} + 1") endwhile() # within the Config.cmake set(install_dir "${CMAKE_CURRENT_LIST_FILE}") foreach(i RANGE @counter@) get_filename_component(install_dir "${install_dir}" PATH) endforeach() I think this will work. My question is if anyone thinks they have suggestions for improvements on this. Is there a method to just "subtract" two paths or to count the number of directories in a relative path? Thank you! I also think it would be good if there were instructions in the documentation about Config.cmake files that showed people how they don't need to hard-code the install directory if they just know where the Config.cmake exists within the installation. -------------- next part -------------- An HTML attachment was scrubbed... URL: From felix.schwitzer at gmx.at Sun Feb 8 14:19:05 2015 From: felix.schwitzer at gmx.at (felix) Date: Sun, 8 Feb 2015 12:19:05 -0700 (MST) Subject: [CMake] Not hardcoding install dir in Config.cmake. In-Reply-To: References: Message-ID: <1423423145634-7589724.post@n2.nabble.com> have you tried CMakePackageConfigHelpers. Works great and if I understand your email right then it is exactly for that purpose. -- View this message in context: http://cmake.3232098.n2.nabble.com/Not-hardcoding-install-dir-in-Config-cmake-tp7589723p7589724.html Sent from the CMake mailing list archive at Nabble.com. From steveire at gmail.com Sun Feb 8 14:31:48 2015 From: steveire at gmail.com (Stephen Kelly) Date: Sun, 08 Feb 2015 20:31:48 +0100 Subject: [CMake] Not hardcoding install dir in Config.cmake. References: Message-ID: Chris Dembia wrote: > Hey all: > > I work on a project that is used heavily on Windows. Our project also > creates a Config.cmake file. During build time, we do not know where the > project will actually be installed on the user's system. However, the > Config.file needs to know the installation directory of the package. I'm curious why that's needed? I guess it's for things like include directories? You might consider creating IMPORTED targets instead and encoding the include directories into those instead. http://www.cmake.org/cmake/help/v3.0/manual/cmake-packages.7.html#creating-packages Thanks, Steve. From jcook at cray.com Mon Feb 9 10:24:10 2015 From: jcook at cray.com (Justin Cook) Date: Mon, 9 Feb 2015 15:24:10 +0000 Subject: [CMake] cmake option system-information interaction with other definition options Message-ID: Hello, I'm finding the cmake --system-information command option to be valuable in testing different things. However it appears that it does not appear to work with -D. For example: cmake -DCMAKE_C_COMPILER=/usr/bin/gcc --system-information system.txt The information in 'system.txt' will not contain the defined compiler from the -D option. I wonder if this is intended? Will it work with a toolchain file instead? Or do I need to do a real build in order to make use of toolchain files and the -D option? Thanks, Justin From 44ghnqv8rg at snkmail.com Mon Feb 9 13:23:41 2015 From: 44ghnqv8rg at snkmail.com (44ghnqv8rg at snkmail.com) Date: Mon, 09 Feb 2015 18:23:41 +0000 Subject: [CMake] lib/cmake vs share/cmake/Modules Message-ID: <2467-1423506221-813489@sneakemail.com> How does one who is making a package which installs .cmake files decide whether to put them in .../share/cmake/Modules or .../lib/cmake? Where are the docs about that? I've seen examples of 3rd party packages doing both (e.g., pulseaudio in lib/cmake/Foo & opencollada - in share/cmake/Modules). From format_c at online.de Mon Feb 9 14:02:03 2015 From: format_c at online.de (Alexander Koeppe) Date: Mon, 09 Feb 2015 20:02:03 +0100 Subject: [CMake] Check symbol in header files with dependencies In-Reply-To: References: Message-ID: Am 05.02.2015 um 21:12 schrieb Alexander Koeppe: > > Hi Cmake user list, > > I have a problem that I need to check the presence of a certain symbol > in a header file using CHECK_SYMBOL_EXISTS which has several dependencies. > > The check fails because the header file also contains data types that > require an additional header file to be included by the test program. It > looks like CHECK_SYMBOL_EXISTS is not capable doing that. Fortunately a friend of mine, Gianfranco Constamagna gave me a tip which led me to the solution to my problem. The link where to find the solution: http://stackoverflow.com/questions/13611847/how-to-check-for-a-symbol-that-requires-two-header-files-in-cmake Acutally the following code check_symbol_exists( IP6T_SO_ORIGINAL_DST "netinet/in.h;net/if.h;linux/netfilter_ipv6/ip6_tables.h" HAVE_IP6T_SO_ORIGINAL_DST ) did the trick and transformed the semicolon seperated list of header files to #include #include #include in the test C-file. With these headers the C testfile was compiled successfully and determined the availability of the #define variable. I answer to my own thread to document the solution to this problem on the place where I intentionly searched for in the 2nd instance. Maybe it helps somebody else who face the same problem. Greetings Alex From a.neundorf-work at gmx.net Mon Feb 9 15:34:11 2015 From: a.neundorf-work at gmx.net (Alexander Neundorf) Date: Mon, 09 Feb 2015 21:34:11 +0100 Subject: [CMake] lib/cmake vs share/cmake/Modules In-Reply-To: <2467-1423506221-813489@sneakemail.com> References: <2467-1423506221-813489@sneakemail.com> Message-ID: <1890872.JHAr8eeGGS@tuxedo.neundorf.net> On Monday, February 09, 2015 18:23:41 44ghnqv8rg at snkmail.com wrote: > How does one who is making a package which installs .cmake files decide > whether to put them in .../share/cmake/Modules or .../lib/cmake? Where are > the docs about that? I've seen examples of 3rd party packages doing both > (e.g., pulseaudio in lib/cmake/Foo & opencollada - in share/cmake/Modules). architecture-independent files, i.e. which could sit on a shared NFS drive and which could be mounted from hosts with any type of CPU architecture, go into share/, i.e. basically data or text files. Files which are architecture dependend, e.g. Config.cmake files for installed libraries, go into lib/. (in doubt, lib/ is the safe choice). Alex From scott.bloom at onshorecs.com Mon Feb 9 21:53:18 2015 From: scott.bloom at onshorecs.com (Scott Aron Bloom) Date: Tue, 10 Feb 2015 02:53:18 +0000 Subject: [CMake] NMake Makefiles JOM build Message-ID: <6FD2E165340D9A429CF831C7A2D4F42E4E5E6765@WIN-R92V03RFJ85.onshorecs.local> I am attempting to use the JOM makefile generator, Im using the latest (1.0.14 of jom) I get the following error: -- The C compiler identification is MSVC 15.0.30729.1 -- The CXX compiler identification is MSVC 15.0.30729.1 -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio 9.0/VC/bin/cl.exe CMake Error: Generator: execution of make failed. Make command was: "jom" "cmTryCompileExec3905947426\fast" -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio 9.0/VC/bin/cl.exe -- broken CMake Error at C:/Program Files (x86)/CMake/share/cmake-3.0/Modules/CMakeTestCCompiler.cmake:61 (message): The C compiler "C:/Program Files (x86)/Microsoft Visual Studio 9.0/VC/bin/cl.exe" is not able to compile a simple test program. It fails with the following output: Change Dir: C:/Users/scott.ONSHORE/Documents/Visual Studio 2008/Projects/bps/trunk/build.jom/CMakeFiles/CMakeTmp Run Build Command:"jom" "cmTryCompileExec3905947426\fast" The system cannot find the file specified Generator: execution of make failed. Make command was: "jom" "cmTryCompileExec3905947426\fast" CMake will not be able to correctly generate this project. Call Stack (most recent call first): CMakeLists.txt:17 (project) -- Configuring incomplete, errors occurred! See also "C:/Users/scott.ONSHORE/Documents/Visual Studio 2008/Projects/bps/trunk/build.jom/CMakeFiles/CMakeOutput.log". See also "C:/Users/scott.ONSHORE/Documents/Visual Studio 2008/Projects/bps/trunk/build.jom/CMakeFiles/CMakeError.log". I have disabled the virus protection, (found a pointer to that online) and it makes no difference. Note, if simply build the NMAke makefile generated system, but run jom instead, it seems to work just fine. Excep the color coding is god awful Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From lloydkl.tech at gmail.com Tue Feb 10 03:38:44 2015 From: lloydkl.tech at gmail.com (Lloyd) Date: Tue, 10 Feb 2015 14:08:44 +0530 Subject: [CMake] Qt5, find ICU and ANGLE libraries Message-ID: Hi, I am using Qt 5.3 (Angle on Windows) with CMake 2.8.12. Qt 5.3 has dependencies on ICU and ANGLE libs. I wish to copy these dlls to the build directory. Is there any CMake variable that holds name of ICU and ANGLE libs? To copy other Qt libraries I am using the following sample code fragment- GET_TARGET_PROPERTY(QT5_LIB_LOCATION Qt5::Core LOCATION_${BUILD_TYPE}) file(COPY ${QT5_LIB_LOCATION} DESTINATION {EXECUTABLE_OUTPUT_PATH}/${BUILD_TYPE}) Here BUILD_TYPE can be Debug or Release If it is not possible to get the lib names, I wish to get the Qt bin dir path. Is any variable holding this value? I could find Qt5_DIR, but not a variable pointing to the bin directory. Thanks, Lloyd -------------- next part -------------- An HTML attachment was scrubbed... URL: From steven.vancoillie at teokem.lu.se Tue Feb 10 03:52:22 2015 From: steven.vancoillie at teokem.lu.se (Steven Vancoillie) Date: Tue, 10 Feb 2015 09:52:22 +0100 Subject: [CMake] overriding initial Fortran flags with PGI compiler Message-ID: <20150210085222.GA1352@arch.teokem.lu.se> Hi, we use custom compiler flags for the default build types and our solution works fine. However, when using the PGI Fortran compiler, some initial flags are set in the module that are always there: (/usr/share/cmake-3.1/Modules/Compiler/PGI-Fortran.cmake) set(CMAKE_Fortran_FLAGS_INIT "${CMAKE_Fortran_FLAGS_INIT} -Mpreprocess -Kieee") What should I do if I don't want those flags? It seems to me that this should be tied to a certain build type? Because of those general initial flags, it is e.g. pointless to use an empty build type with custom flags, as the "-Mpreprocess -Kieee" will always be there. Steven From 44ghnqv8rg at snkmail.com Tue Feb 10 05:43:33 2015 From: 44ghnqv8rg at snkmail.com (44ghnqv8rg at snkmail.com) Date: Tue, 10 Feb 2015 03:43:33 -0700 Subject: [CMake] lib/cmake vs share/cmake/Modules In-Reply-To: <1890872.JHAr8eeGGS@tuxedo.neundorf.net> References: <2467-1423506221-813489@sneakemail.com> <1890872.JHAr8eeGGS@tuxedo.neundorf.net> Message-ID: <20865-1423565027-573418@sneakemail.com> Alexander Neundorf wrote at 21:34 +0100 on Feb 9, 2015: > On Monday, February 09, 2015 18:23:41 44ghnqv8rg at snkmail.com wrote: > > How does one who is making a package which installs .cmake files > > decide whether to put them in .../share/cmake/Modules or > > .../lib/cmake? Where are the docs about that? I've seen > > examples of 3rd party packages doing both (e.g., pulseaudio in > > lib/cmake/Foo & opencollada - in share/cmake/Modules). > > architecture-independent files, i.e. which could sit on a shared > NFS drive and which could be mounted from hosts with any type of > CPU architecture, go into share/, i.e. basically data or text > files. Files which are architecture dependend, e.g. Config.cmake > files for installed libraries, go into lib/. (in doubt, lib/ is > the safe choice). I'm looking for official cmake docs that explain the difference between the two locations from cmake's perspective (rather than just guidelines reiterated from hier(7)). Clearly .cmake files are architecture independent - there's no arch-dependent compiled binary version of a .cmake file (at least not yet). Based on the generic hints of hier(7), they should all be in share/cmake. But cmake supports (and encourages in cmake-packages(7)) package config files in lib/cmake. The docs for find_package in cmake-commands(7) describe the search hierarchy - it searches lib/cmake and share/cmake (at least on the unix-ish platforms) - but doesn't say why package files might be in either location. Note there exist now some config .cmake files in share/cmake and some in lib/cmake (as in the example cases I pointed out in the original post). The cmake project itself surely must have some policy written somewhere that describes what goes in each location. I just haven't found it yet. Or perhaps a lack of guidance has led to packagers picking either place without clear consensus and thus has led to some fragmentation. I'd also like to hear those opinions if people think that's the case. From gunjan.gemini29 at gmail.com Tue Feb 10 07:45:40 2015 From: gunjan.gemini29 at gmail.com (Gunjan Gautam) Date: Tue, 10 Feb 2015 18:15:40 +0530 Subject: [CMake] Error in Cmake Installation Message-ID: Hi All, While installing cmake using below option, I am facing the error in step 3. Step1: ./bootstarp Step2: make step: make install Error after step 3: *CMake Error at cmake_install.cmake:36 (file): file INSTALL cannot set permissions on "/usr/local/doc/cmake-3.1/Copyright.txt"* How to overcome this issue ? -- Best Regards, Gunjan -------------- next part -------------- An HTML attachment was scrubbed... URL: From parag at ionicsecurity.com Tue Feb 10 07:52:46 2015 From: parag at ionicsecurity.com (Parag Chandra) Date: Tue, 10 Feb 2015 12:52:46 +0000 Subject: [CMake] Error in Cmake Installation In-Reply-To: References: Message-ID: Try running: sudo make install Instead. On Feb 10, 2015, at 7:45 AM, Gunjan Gautam > wrote: Hi All, While installing cmake using below option, I am facing the error in step 3. Step1: ./bootstarp Step2: make step: make install Error after step 3: CMake Error at cmake_install.cmake:36 (file): file INSTALL cannot set permissions on "/usr/local/doc/cmake-3.1/Copyright.txt" How to overcome this issue ? -- Best Regards, Gunjan -- Powered by www.kitware.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 aai at purdue.edu Tue Feb 10 13:11:49 2015 From: aai at purdue.edu (P. A. Cheeseman) Date: Tue, 10 Feb 2015 13:11:49 -0500 Subject: [CMake] Problem writing on GPFS. Message-ID: <1d1301d0455d$0a574170$1f05c450$@purdue.edu> System: RHEL6 (2.6.32-504.8.1.el6.x86_64) Hardware: Various cluster nodes. We recently deployed GPFS storage and have discovered that Cmake fails when writing to files in the GPFS storage. The source of the problem, identified by using strace(1), appears to be a NULL pointer in the first entry of writev(2) iovec argument. The line below is representative of what we see in the strace output. -------- writev(3, [{NULL, 0}, {"\n#ifdef __cplusplus\n# error \"A C"..., 15135}], 2) = -1 EINVAL (Invalid argument) -------- On non-GPFS storage, the files are written w/o problem. The NULL pointer in the first iovec entry is silently ignored. The failures occur for Cmake installations made using Gcc 4.4.7, 4.7.2, 4.9.2, and all Intel compilers we've tried so far. We have worked around the problem by building Cmake 3.1.1 with PGI 11.8-0 which does not use the writev() system calls in its run-time. Has anyone else observed this symptom with GPFS? Is anyone familiar enough with the Cmake code to know why the g++ compiler run-time uses writev() in the first place? I have not been able to reproduce the writev() system calls with a short C++ program so far. The problem reproduces for us by attempting to build Cmake from source with the source tree on GPFS. For instance ... ./bootstrap --prefix=someinstallpoint with CWD at the top of the source tree, using g++. A C code with explicit writev() calls, with a NULL pointer in the first iovec entry, also reproduces the behavior. When the NULL is part of any entry other than the first, the code runs identically for all storage. Thanks, Phil P. A. Cheeseman aai at purdue.edu 765.496.8224 From eike at sf-mail.de Tue Feb 10 13:44:16 2015 From: eike at sf-mail.de (Rolf Eike Beer) Date: Tue, 10 Feb 2015 19:44:16 +0100 Subject: [CMake] Problem writing on GPFS. In-Reply-To: <1d1301d0455d$0a574170$1f05c450$@purdue.edu> References: <1d1301d0455d$0a574170$1f05c450$@purdue.edu> Message-ID: <3425404.FkQu6q1E5a@eto> P. A. Cheeseman wrote: > System: RHEL6 (2.6.32-504.8.1.el6.x86_64) > Hardware: Various cluster nodes. > A C code with explicit writev() calls, with a NULL pointer in > the first iovec entry, also reproduces the behavior. When the > NULL is part of any entry other than the first, the code runs > identically for all storage. I would suggest contacting Red Hat. This sounds for me like a bug in the GPFS code, especially since the call succeeds if the (NULL, 0) pair is in a later pair. Other than that, I don't see a reason why g++ should emit such a call. Should probably be reported to the gcc guys. Or maybe this is just something in your libc, so gcc isn't at fault at all. Probably time for the Red Hat guys to investigate, too ;) Eike -- -------------- 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 aai at purdue.edu Tue Feb 10 14:24:58 2015 From: aai at purdue.edu (P. A. Cheeseman) Date: Tue, 10 Feb 2015 14:24:58 -0500 Subject: [CMake] Problem writing on GPFS. In-Reply-To: <3425404.FkQu6q1E5a@eto> References: <1d1301d0455d$0a574170$1f05c450$@purdue.edu> <3425404.FkQu6q1E5a@eto> Message-ID: <1d5901d04567$425e9ff0$c71bdfd0$@purdue.edu> I want to thank Rolf here for his advice because I failed to do so in an off line reply. Shortly after I replied to Rolf's note, I received notification from IBM that the problem is related to our version of GPFS (4.1.0-2). Versions 4.1.0-3 and later apparently do not have the problem. Best regards, Phil P. A. Cheeseman aai at purdue.edu 765.496.8224 > -----Original Message----- > From: Rolf Eike Beer [mailto:eike at sf-mail.de] > Sent: Tuesday, February 10, 2015 13:44 > To: cmake at cmake.org; aai at purdue.edu > Subject: Re: [CMake] Problem writing on GPFS. > > P. A. Cheeseman wrote: > > System: RHEL6 (2.6.32-504.8.1.el6.x86_64) > > Hardware: Various cluster nodes. > > > A C code with explicit writev() calls, with a NULL pointer in the > > first iovec entry, also reproduces the behavior. When the NULL is > > part of any entry other than the first, the code runs identically for > > all storage. > > I would suggest contacting Red Hat. This sounds for me like a bug in the GPFS > code, especially since the call succeeds if the (NULL, 0) pair is in a later pair. > > Other than that, I don't see a reason why g++ should emit such a call. Should > probably be reported to the gcc guys. Or maybe this is just something in your > libc, so gcc isn't at fault at all. Probably time for the Red Hat guys to > investigate, too ;) > > Eike > -- From aai at purdue.edu Tue Feb 10 14:36:57 2015 From: aai at purdue.edu (P. A. Cheeseman) Date: Tue, 10 Feb 2015 14:36:57 -0500 Subject: [CMake] Problem writing on GPFS. In-Reply-To: <9493943.0GVxA6o2Ne@eto> References: <1d1301d0455d$0a574170$1f05c450$@purdue.edu> <3425404.FkQu6q1E5a@eto> <1d3901d04564$c7f9fe00$57edfa00$@purdue.edu> <9493943.0GVxA6o2Ne@eto> Message-ID: <1d7301d04568$eeb92210$cc2b6630$@purdue.edu> > Do you intentionally removed or just forgot to CC the list? I failed to 'reply-all'. One additional note. Turning off optimization didn't help, among the other things I tried. My own read of the issue is that there is room to trap the bad pointer at every layer in its handling. I suspect the run-time ignores them because that was easier than watching 'working' codes break wholesale if the existing convention were to throw an error (as write(2) does). Best regards, Phil P. A. Cheeseman aai at purdue.edu 765.496.8224 > -----Original Message----- > From: Rolf Eike Beer [mailto:eike at sf-mail.de] > Sent: Tuesday, February 10, 2015 14:18 > To: aai at purdue.edu > Subject: Re: [CMake] Problem writing on GPFS. > > P. A. Cheeseman wrote: > > RedHat and GNU support are on the todo list once I can identify > > what's in the Cmake source that tricks the run-time into using writev(). > > > > Several gdb(1) sessions led me to the top end source of the calls > > which is cmFileCommand::HandleWriteCommand(). I've not traced > through > > the multiple layers of run-time to see where the iovec array is > > created from the 'file << message' line. > > Ah, but that's a good clue. g++ may just optimize the message writing into > that, or libstdc++ may. You may try with CXXFLAGS=-O0 to see it it works > then. > > > The fact that the run-time from either GNU or Redhat generates > > the marginal call is bothersome. I suspect the fundamental problem > > has existed for some time. Have also not found any reference to what > > is 'correct' behavior for writev() when a pointer is NULL but I'm not > > a dedicated student of POSIX etc. > > I don't know, but given the fact that it works in a latter place and on all other > fs makes it look like a bug to me. > > Do you intentionally removed or just forgot to CC the list? > > Eike > -- From samuel.trahan at noaa.gov Tue Feb 10 14:43:30 2015 From: samuel.trahan at noaa.gov (Samuel Trahan - NOAA Affiliate) Date: Tue, 10 Feb 2015 14:43:30 -0500 Subject: [CMake] Problem writing on GPFS. In-Reply-To: <1d5901d04567$425e9ff0$c71bdfd0$@purdue.edu> References: <1d1301d0455d$0a574170$1f05c450$@purdue.edu> <3425404.FkQu6q1E5a@eto> <1d5901d04567$425e9ff0$c71bdfd0$@purdue.edu> Message-ID: Does anyone know of a workaround for this which does not require upgrading GPFS or changing compilers? On Tue, Feb 10, 2015 at 2:24 PM, P. A. Cheeseman wrote: > I want to thank Rolf here for his advice because I failed to > do so in an off line reply. > > Shortly after I replied to Rolf's note, I received notification from > IBM that the problem is related to our version of GPFS (4.1.0-2). > > Versions 4.1.0-3 and later apparently do not have the problem. > > Best regards, > Phil > > P. A. Cheeseman > aai at purdue.edu > 765.496.8224 > > > > -----Original Message----- > > From: Rolf Eike Beer [mailto:eike at sf-mail.de] > > Sent: Tuesday, February 10, 2015 13:44 > > To: cmake at cmake.org; aai at purdue.edu > > Subject: Re: [CMake] Problem writing on GPFS. > > > > P. A. Cheeseman wrote: > > > System: RHEL6 (2.6.32-504.8.1.el6.x86_64) > > > Hardware: Various cluster nodes. > > > > > A C code with explicit writev() calls, with a NULL pointer in the > > > first iovec entry, also reproduces the behavior. When the NULL is > > > part of any entry other than the first, the code runs identically for > > > all storage. > > > > I would suggest contacting Red Hat. This sounds for me like a bug in the > GPFS > > code, especially since the call succeeds if the (NULL, 0) pair is in a > later pair. > > > > Other than that, I don't see a reason why g++ should emit such a call. > Should > > probably be reported to the gcc guys. Or maybe this is just something in > your > > libc, so gcc isn't at fault at all. Probably time for the Red Hat guys to > > investigate, too ;) > > > > Eike > > -- > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From diltsman at gmail.com Tue Feb 10 14:52:47 2015 From: diltsman at gmail.com (Daniel Dilts) Date: Tue, 10 Feb 2015 11:52:47 -0800 Subject: [CMake] Pass GNU flags on Windows Message-ID: I am attempting to run CMake and use clang for the compiler. I am on Windows 8.1. It seems to me that if CMake used gcc flags instead of vc++ flags that this would work. Any ideas how I can make this work? I use the following command: cmake -DCMAKE_C_COMPILER=clang.exe DCMAKE_CXX_COMPILER=clang++.exe -DCMAKE_RC_COMPILER=rc.exe -G "Ninja" ../llvm When it attempts to test the compiler I get the following results: Run Build Command:"d:/llvm/ninja/ninja.exe" "cmTryCompileExec2377752233" [1/2] Building C object CMakeFiles\cmTryCompileExec2377752233.dir\testCCompiler.c.obj FAILED: d:\llvm\build\Release\bin\clang.exe /nologo /DWIN32 /D_WINDOWS /W3 /D_DEBUG /MDd /Zi /Ob0 /Od /RTC1 /showIncludes /FoCMakeFiles\cmTryCompileExec2377752233.dir\testCCompiler.c.obj /FdCMakeFiles\cmTryCompileExec2377752233.dir\ -c testCCompiler.c clang.exe: error: no such file or directory: '/nologo' clang.exe: error: no such file or directory: '/DWIN32' clang.exe: error: no such file or directory: '/D_WINDOWS' clang.exe: error: no such file or directory: '/W3' clang.exe: error: no such file or directory: '/D_DEBUG' clang.exe: error: no such file or directory: '/MDd' clang.exe: error: no such file or directory: '/Zi' clang.exe: error: no such file or directory: '/Ob0' clang.exe: error: no such file or directory: '/Od' clang.exe: error: no such file or directory: '/RTC1' clang.exe: error: no such file or directory: '/showIncludes' clang.exe: error: no such file or directory: '/FoCMakeFiles\cmTryCompileExec2377752233.dir\testCCompiler.c.obj' clang.exe: error: no such file or directory: '/FdCMakeFiles\cmTryCompileExec2377752233.dir\' ninja: build stopped: subcommand failed. -------------- next part -------------- An HTML attachment was scrubbed... URL: From aai at purdue.edu Tue Feb 10 16:09:12 2015 From: aai at purdue.edu (P. A. Cheeseman) Date: Tue, 10 Feb 2015 16:09:12 -0500 Subject: [CMake] Problem writing on GPFS. In-Reply-To: References: <1d1301d0455d$0a574170$1f05c450$@purdue.edu> <3425404.FkQu6q1E5a@eto> <1d5901d04567$425e9ff0$c71bdfd0$@purdue.edu> Message-ID: <1da601d04575$d1d769b0$75863d10$@purdue.edu> Reading into the final resolution of the IBM ticket tipped me to where the writev() calls originate in the C++ run-time. The amount of data has to be 1K or more before writev() is used. Then the NULL pointer in the iovec is assured with our versions of Gcc/G++. I've just compiled and run ... #include #include using namespace std; main() { ofstream file; std::string message; message += "Line 00\n"; message += "Line 01\n"; // Enough of these to create 1K ... // file.open("popeye",ios::binary); file << message; file.close(); return(0); } to mimic what happens in cmFileCommand::HandleWriteCommand(). The writev() calls appear in the strace after that. The workaround until GPFS catches up would be to disrupt the approach in HandleWriteCommand by pushing out the string(s) in parts less than 1K so the run-time will use write() instead of marginal calls to writev() (if you care to go that far :-)). Another workaround is to (sigh) build off of GPFS and rsync the installation to its final destination, patching any hard coded paths along the way (again, sigh). I'm not deep into the chain of handling under RedHat but I suspect the iovec is handed down through the system from the compiler run-time until it reaches a handler specific to the storage. I frankly wonder why the marginal calls make it out of the compiler run-time. In any case, the Cmake code really isn't at fault, if I'm following things correctly. If I pursue further, I'll be seeing if the compiler suite support and/or RedHat can explain the necessity of the NULLs :-). Thanks to all, Phil P. A. Cheeseman aai at purdue.edu 765.496.8224 From: Samuel Trahan - NOAA Affiliate [mailto:samuel.trahan at noaa.gov] Sent: Tuesday, February 10, 2015 14:44 To: aai at purdue.edu Cc: cmake at cmake.org Subject: Re: [CMake] Problem writing on GPFS. Does anyone know of a workaround for this which does not require upgrading GPFS or changing compilers? On Tue, Feb 10, 2015 at 2:24 PM, P. A. Cheeseman wrote: I want to thank Rolf here for his advice because I failed to do so in an off line reply. Shortly after I replied to Rolf's note, I received notification from IBM that the problem is related to our version of GPFS (4.1.0-2). Versions 4.1.0-3 and later apparently do not have the problem. Best regards, Phil P. A. Cheeseman aai at purdue.edu 765.496.8224 > -----Original Message----- > From: Rolf Eike Beer [mailto:eike at sf-mail.de] > Sent: Tuesday, February 10, 2015 13:44 > To: cmake at cmake.org; aai at purdue.edu > Subject: Re: [CMake] Problem writing on GPFS. > > P. A. Cheeseman wrote: > > System: RHEL6 (2.6.32-504.8.1.el6.x86_64) > > Hardware: Various cluster nodes. > > > A C code with explicit writev() calls, with a NULL pointer in the > > first iovec entry, also reproduces the behavior. When the NULL is > > part of any entry other than the first, the code runs identically for > > all storage. > > I would suggest contacting Red Hat. This sounds for me like a bug in the GPFS > code, especially since the call succeeds if the (NULL, 0) pair is in a later pair. > > Other than that, I don't see a reason why g++ should emit such a call. Should > probably be reported to the gcc guys. Or maybe this is just something in your > libc, so gcc isn't at fault at all. Probably time for the Red Hat guys to > investigate, too ;) > > Eike > -- -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.neundorf-work at gmx.net Tue Feb 10 16:19:20 2015 From: a.neundorf-work at gmx.net (Alexander Neundorf) Date: Tue, 10 Feb 2015 22:19:20 +0100 Subject: [CMake] lib/cmake vs share/cmake/Modules In-Reply-To: <20865-1423565027-573418@sneakemail.com> References: <2467-1423506221-813489@sneakemail.com> <1890872.JHAr8eeGGS@tuxedo.neundorf.net> <20865-1423565027-573418@sneakemail.com> Message-ID: <1741695.8NGGqlAlHP@tuxedo.neundorf.net> On Tuesday, February 10, 2015 03:43:33 44ghnqv8rg at snkmail.com wrote: > Alexander Neundorf wrote at 21:34 +0100 on Feb 9, 2015: > > On Monday, February 09, 2015 18:23:41 44ghnqv8rg at snkmail.com wrote: > > > How does one who is making a package which installs .cmake files > > > decide whether to put them in .../share/cmake/Modules or > > > .../lib/cmake? Where are the docs about that? I've seen > > > examples of 3rd party packages doing both (e.g., pulseaudio in > > > lib/cmake/Foo & opencollada - in share/cmake/Modules). > > > > architecture-independent files, i.e. which could sit on a shared > > NFS drive and which could be mounted from hosts with any type of > > CPU architecture, go into share/, i.e. basically data or text > > files. Files which are architecture dependend, e.g. Config.cmake > > files for installed libraries, go into lib/. (in doubt, lib/ is > > the safe choice). > > I'm looking for official cmake docs that explain the difference > between the two locations from cmake's perspective (rather than > just guidelines reiterated from hier(7)). I'm not aware for any more official docs, and if there are some, I doubt that they would contradict hier(7). So, Config.cmake files for libraries into lib/, for packages which are e.g. header only or similar share/ it is. If there are Config.cmake files for libraries which ar in shared I would consider this a bug. Alex From samuel.trahan at noaa.gov Tue Feb 10 16:35:15 2015 From: samuel.trahan at noaa.gov (Samuel Trahan - NOAA Affiliate) Date: Tue, 10 Feb 2015 16:35:15 -0500 Subject: [CMake] Problem writing on GPFS. In-Reply-To: <1da601d04575$d1d769b0$75863d10$@purdue.edu> References: <1d1301d0455d$0a574170$1f05c450$@purdue.edu> <3425404.FkQu6q1E5a@eto> <1d5901d04567$425e9ff0$c71bdfd0$@purdue.edu> <1da601d04575$d1d769b0$75863d10$@purdue.edu> Message-ID: Phil, Could you give me a ticket or bug number (however they track it) for GPFS that describes this as a known bug? I will need that when submitting a ticket to my organization's helpdesk. This problem is quite a lot larger than CMake: all C++ programs will break. Sincerely, Sam Trahan On Tue, Feb 10, 2015 at 4:09 PM, P. A. Cheeseman wrote: > Reading into the final resolution of the IBM ticket tipped me to > where the writev() calls originate in the C++ run-time. The amount of data > has to be 1K or more before writev() is used. Then the NULL pointer in the > iovec is assured with our versions of Gcc/G++. I've just compiled and run > ... > > > > #include > > #include > > using namespace std; > > main() > > { > > ofstream file; > > std::string message; > > > > message += "Line 00\n"; > > message += "Line 01\n"; > > // Enough of these to create 1K ... // > > > > file.open("popeye",ios::binary); > > file << message; > > file.close(); > > > > return(0); > > } > > > > to mimic what happens in cmFileCommand::HandleWriteCommand(). The > writev() calls appear in the strace after that. The workaround until GPFS > catches up would be to disrupt the approach in HandleWriteCommand by > pushing out the string(s) in parts less than 1K so the run-time will use > write() instead of marginal calls to writev() (if you care to go that far > :-)). > > > > Another workaround is to (sigh) build off of GPFS and rsync the > installation to its final destination, patching any hard coded paths along > the way (again, sigh). > > > > I'm not deep into the chain of handling under RedHat but I suspect > the iovec is handed down through the system from the compiler run-time > until it reaches a handler specific to the storage. I frankly wonder why > the marginal calls make it out of the compiler run-time. > > > > In any case, the Cmake code really isn't at fault, if I'm following > things correctly. If I pursue further, I'll be seeing if the compiler > suite support and/or RedHat can explain the necessity of the NULLs :-). > > > > Thanks to > all, > > Phil > > > > P. A. > Cheeseman > > aai at purdue.edu > > 765.496.8224 > > > > *From:* Samuel Trahan - NOAA Affiliate [mailto:samuel.trahan at noaa.gov] > *Sent:* Tuesday, February 10, 2015 14:44 > *To:* aai at purdue.edu > *Cc:* cmake at cmake.org > > *Subject:* Re: [CMake] Problem writing on GPFS. > > > > Does anyone know of a workaround for this which does not require upgrading > GPFS or changing compilers? > > > > On Tue, Feb 10, 2015 at 2:24 PM, P. A. Cheeseman wrote: > > I want to thank Rolf here for his advice because I failed to > do so in an off line reply. > > Shortly after I replied to Rolf's note, I received notification from > IBM that the problem is related to our version of GPFS (4.1.0-2). > > Versions 4.1.0-3 and later apparently do not have the problem. > > Best regards, > Phil > > P. A. Cheeseman > aai at purdue.edu > 765.496.8224 > > > -----Original Message----- > > From: Rolf Eike Beer [mailto:eike at sf-mail.de] > > Sent: Tuesday, February 10, 2015 13:44 > > To: cmake at cmake.org; aai at purdue.edu > > Subject: Re: [CMake] Problem writing on GPFS. > > > > P. A. Cheeseman wrote: > > > System: RHEL6 (2.6.32-504.8.1.el6.x86_64) > > > Hardware: Various cluster nodes. > > > > > A C code with explicit writev() calls, with a NULL pointer in the > > > first iovec entry, also reproduces the behavior. When the NULL is > > > part of any entry other than the first, the code runs identically for > > > all storage. > > > > I would suggest contacting Red Hat. This sounds for me like a bug in the > GPFS > > code, especially since the call succeeds if the (NULL, 0) pair is in a > later pair. > > > > Other than that, I don't see a reason why g++ should emit such a call. > Should > > probably be reported to the gcc guys. Or maybe this is just something in > your > > libc, so gcc isn't at fault at all. Probably time for the Red Hat guys to > > investigate, too ;) > > > > Eike > > -- > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aai at purdue.edu Tue Feb 10 17:09:39 2015 From: aai at purdue.edu (P. A. Cheeseman) Date: Tue, 10 Feb 2015 17:09:39 -0500 Subject: [CMake] Problem writing on GPFS. In-Reply-To: References: <1d1301d0455d$0a574170$1f05c450$@purdue.edu> <3425404.FkQu6q1E5a@eto> <1d5901d04567$425e9ff0$c71bdfd0$@purdue.edu> <1da601d04575$d1d769b0$75863d10$@purdue.edu> Message-ID: <1dd401d0457e$43ff3920$cbfdab60$@purdue.edu> Here's a start. If I post to GNU/RedHat, I'll pass that along too. http://www-01.ibm.com/support/docview.wss?uid=isg3T1021392 I understand the problem is bigger. It's helped me to understand why I'm having problems with C++ support for other packages. I'm still wondering how long the compiler/run-time has produced the risky writev() calls. Best regards, Phil P. A. Cheeseman aai at purdue.edu 765.496.8224 From: Samuel Trahan - NOAA Affiliate [mailto:samuel.trahan at noaa.gov] Sent: Tuesday, February 10, 2015 16:35 To: aai at purdue.edu Cc: cmake at cmake.org Subject: Re: [CMake] Problem writing on GPFS. Phil, Could you give me a ticket or bug number (however they track it) for GPFS that describes this as a known bug? I will need that when submitting a ticket to my organization's helpdesk. This problem is quite a lot larger than CMake: all C++ programs will break. Sincerely, Sam Trahan On Tue, Feb 10, 2015 at 4:09 PM, P. A. Cheeseman wrote: Reading into the final resolution of the IBM ticket tipped me to where the writev() calls originate in the C++ run-time. The amount of data has to be 1K or more before writev() is used. Then the NULL pointer in the iovec is assured with our versions of Gcc/G++. I've just compiled and run ... #include #include using namespace std; main() { ofstream file; std::string message; message += "Line 00\n"; message += "Line 01\n"; // Enough of these to create 1K ... // file.open("popeye",ios::binary); file << message; file.close(); return(0); } to mimic what happens in cmFileCommand::HandleWriteCommand(). The writev() calls appear in the strace after that. The workaround until GPFS catches up would be to disrupt the approach in HandleWriteCommand by pushing out the string(s) in parts less than 1K so the run-time will use write() instead of marginal calls to writev() (if you care to go that far :-)). Another workaround is to (sigh) build off of GPFS and rsync the installation to its final destination, patching any hard coded paths along the way (again, sigh). I'm not deep into the chain of handling under RedHat but I suspect the iovec is handed down through the system from the compiler run-time until it reaches a handler specific to the storage. I frankly wonder why the marginal calls make it out of the compiler run-time. In any case, the Cmake code really isn't at fault, if I'm following things correctly. If I pursue further, I'll be seeing if the compiler suite support and/or RedHat can explain the necessity of the NULLs :-). Thanks to all, Phil P. A. Cheeseman aai at purdue.edu 765.496.8224 From: Samuel Trahan - NOAA Affiliate [mailto:samuel.trahan at noaa.gov] Sent: Tuesday, February 10, 2015 14:44 To: aai at purdue.edu Cc: cmake at cmake.org Subject: Re: [CMake] Problem writing on GPFS. Does anyone know of a workaround for this which does not require upgrading GPFS or changing compilers? On Tue, Feb 10, 2015 at 2:24 PM, P. A. Cheeseman wrote: I want to thank Rolf here for his advice because I failed to do so in an off line reply. Shortly after I replied to Rolf's note, I received notification from IBM that the problem is related to our version of GPFS (4.1.0-2). Versions 4.1.0-3 and later apparently do not have the problem. Best regards, Phil P. A. Cheeseman aai at purdue.edu 765.496.8224 > -----Original Message----- > From: Rolf Eike Beer [mailto:eike at sf-mail.de] > Sent: Tuesday, February 10, 2015 13:44 > To: cmake at cmake.org; aai at purdue.edu > Subject: Re: [CMake] Problem writing on GPFS. > > P. A. Cheeseman wrote: > > System: RHEL6 (2.6.32-504.8.1.el6.x86_64) > > Hardware: Various cluster nodes. > > > A C code with explicit writev() calls, with a NULL pointer in the > > first iovec entry, also reproduces the behavior. When the NULL is > > part of any entry other than the first, the code runs identically for > > all storage. > > I would suggest contacting Red Hat. This sounds for me like a bug in the GPFS > code, especially since the call succeeds if the (NULL, 0) pair is in a later pair. > > Other than that, I don't see a reason why g++ should emit such a call. Should > probably be reported to the gcc guys. Or maybe this is just something in your > libc, so gcc isn't at fault at all. Probably time for the Red Hat guys to > investigate, too ;) > > Eike > -- -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake -------------- next part -------------- An HTML attachment was scrubbed... URL: From ghleclerc at gmail.com Tue Feb 10 23:01:35 2015 From: ghleclerc at gmail.com (Ghyslain Leclerc) Date: Tue, 10 Feb 2015 23:01:35 -0500 Subject: [CMake] Mixed linking In-Reply-To: References: Message-ID: Stephen Kelly wrote:? Ah, right the platform plugin issue. This is likely the reason for not? running on OSX.? CMake 3.1 learned a new feature specifically so that this would become? easier in the future:? http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/7970? qmake generates a file like the above for you and compiles it and links it? into your application for you in the static version.? With? http://www.cmake.org/cmake/help/v3.1/prop_tgt/INTERFACE_SOURCES.html? Qt can do the same, but someone would have to patch Qt to do so. Something? for the future... :)? Thanks for all the insight. ?I have been looking at this and quite a few posts (mostly from you !) to try and understand. ?I think I get most of it. That being said, I finally got a static executable for my application on my mac. What I did is build my application using qmake, get the linker command and manually find every library using cmake in order to recreate the linker command from qmake (I don?t think it makes a difference, but I?m not sure so I even kept the library order the same). ?For my application, this is what did it ended up with (some boiler plate removed). find_package( Qt5 COMPONENTS Widgets Sql PrintSupport REQUIRED ) find_library( DISKARBITRATION_LIBRARY DiskArbitration ) find_library( IOKIT_LIBRARY IOKit ) find_library( APPLICATIONSERVICES_LIBRARY ApplicationServices ) find_library( CORESERVICES_LIBRARY CoreServices ) find_library( COREFOUNDATION_LIBRARY CoreFoundation ) find_library( FOUNDATION_LIBRARY Foundation ) find_library( COCOA_LIBRARY Cocoa ) find_library( CARBON_LIBRARY Carbon ) find_library( OPENGL_LIBRARY OpenGL ) add_executable( calculum ${SRCS_LIST} ${UIS_LIST} ${HDRS_LIST} ) set( QT_INSTALL_DIR_GL "/sw/local/qt/" ) find_library( QCOCOA qcocoa ? ? PATHS "${QT_INSTALL_DIR_GL}/plugins/platforms" ) find_library( QDDS qdds ? ? PATHS "${QT_INSTALL_DIR_GL}/plugins/imageformats" ) find_library( QICNS qicns ? ? PATHS "${QT_INSTALL_DIR_GL}/plugins/imageformats" ) find_library( QICO qico ? ? PATHS "${QT_INSTALL_DIR_GL}/plugins/imageformats" ) find_library( QJP2 qjp2 ? ? PATHS "${QT_INSTALL_DIR_GL}/plugins/imageformats" ) find_library( QMNG qmng ? ? PATHS "${QT_INSTALL_DIR_GL}/plugins/imageformats" ) find_library( QTGA qtga ? ? PATHS "${QT_INSTALL_DIR_GL}/plugins/imageformats" ) find_library( QTIFF qtiff ? ? PATHS "${QT_INSTALL_DIR_GL}/plugins/imageformats" ) find_library( QWBMP qwbmp ? ? PATHS "${QT_INSTALL_DIR_GL}/plugins/imageformats" ) find_library( QWEBP qwebp ? ? PATHS "${QT_INSTALL_DIR_GL}/plugins/imageformats? ) # Note, GL are my initials. ?It was just to ensure no conflicts in names. ?Probably not necessary target_link_libraries( calculum ? ? ? ? ? ? ? ? ? ? ? ?${DISKARBITRATION_LIBRARY} ? ? ? ? ? ? ? ? ? ? ? ?${IOKIT_LIBRARY} ? ? ? ? ? ? ? ? ? ? ? ?${APPLICATIONSERVICES_LIBRARY} ? ? ? ? ? ? ? ? ? ? ? ?${CORESERVICES_LIBRARY} ? ? ? ? ? ? ? ? ? ? ? ?${COREFOUNDATION_LIBRARY} ? ? ? ? ? ? ? ? ? ? ? ?${FOUNDATION_LIBRARY} ? ? ? ? ? ? ? ? ? ? ? ?${COCOA_LIBRARY} ? ? ? ? ? ? ? ? ? ? ? ?${CARBON_LIBRARY} ? ? ? ? ? ? ? ? ? ? ? ?Qt5::Sql ? ? ? ? ? ? ? ? ? ? ? ?${QCOCOA} ? ? ? ? ? ? ? ? ? ? ? ?cups ? ? ? ? ? ? ? ? ? ? ? ?/sw/local/qt/lib/libQt5PlatformSupport.a ? ? ? ? ? ? ? ? ? ? ? ?${OPENGL_LIBRARY} ? ? ? ? ? ? ? ? ? ? ? ?Qt5::PrintSupport ? ? ? ? ? ? ? ? ? ? ? ?Qt5::Widgets ? ? ? ? ? ? ? ? ? ? ? ?${QDDS} ? ? ? ? ? ? ? ? ? ? ? ?${QICNS} ? ? ? ? ? ? ? ? ? ? ? ?${QICO} ? ? ? ? ? ? ? ? ? ? ? ?${QJP2} ? ? ? ? ? ? ? ? ? ? ? ?${QMNG} ? ? ? ? ? ? ? ? ? ? ? ?${QTGA} ? ? ? ? ? ? ? ? ? ? ? ?${QTIFF} ? ? ? ? ? ? ? ? ? ? ? ?${QWBMP} ? ? ? ? ? ? ? ? ? ? ? ?${QWEBP} ? ? ? ? ? ? ? ? ? ? ? ?Qt5::Gui ? ? ? ? ? ? ? ? ? ? ? ?Qt5::Core ? ? ? ? ? ? ? ? ? ? ? ?z ? ? ? ? ? ? ? ? ? ? ? ?m ) This seems like a lot of work to get what I want? ?But if it does the job. ?The fun part will be to see what I need on Windows and then put conditionals around that and all. If I misunderstood something and there is an easier way to get a static executable from using static qt from CMake, please let me know. ?I am posting this in case someone searches for information on how to link static Qt using CMake. ?The title of my mail said Mixed linking, but it should probably really say static linking Qt5 using CMake, but I don?t know how to change it (I have seen on the list the formerly was ?, but not sure if it?s appropriate or how to do it). Again, thanks for giving a bit of your time. ?Really appreciated. Ghyslain -------------- next part -------------- An HTML attachment was scrubbed... URL: From Arjen.Markus at deltares.nl Wed Feb 11 09:16:56 2015 From: Arjen.Markus at deltares.nl (Arjen Markus) Date: Wed, 11 Feb 2015 14:16:56 +0000 Subject: [CMake] Unexpected use of "ld" on Windows Message-ID: <8CF085736108634681FD03EC36E6A0723D98ED32@V-EXC-C02.DIRECTORY.INTRA> Hello, I am trying to build the Fortran interface to NetCDF4 on Windows, using the Intel Fortran compiler and "Nmake Makefiles" as the generator (see http://www.unidata.ucar.edu/downloads/netcdf/index.jsp). I had some trouble getting the first part to build, but that is solved (small issues with the code). The second part, which is supposed to build a C library that can be called from Fortran, presents a more serious problem: for some reason CMake picks parts of another toolchain to build this: The Makefile contains these lines to compile the sources: cd D:\netcdf\netcdf-build-fortran\libsrc C:\PROGRA~2\MICROS~3.0\VC\bin\amd64\cl.exe @<< /nologo $(C_FLAGS) $(C_DEFINES) /FoCMakeFiles\ncfortran.dir\fort-attio.c.obj /FdD:\netcdf\netcdf-build-fortran\libsrc\ncfortran.pdb -c D:\netcdf\netcdf-fortran-4.4.1\libsrc\fort-attio.c But to build the library it contains: libsrc\ncfortran.dll: d:\netcdf\netcdf-build\liblib\netcdf.lib libsrc\ncfortran.dll: libsrc\CMakeFiles\ncfortran.dir\objects1.rsp @$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) --red --bold "Linking C shared library ncfortran.dll" cd D:\netcdf\netcdf-build-fortran\libsrc d:\CMake2.8.10.2\bin\cmake.exe -E vs_link_dll C:\PROGRA~2\HASKEL~1\201320~1.0\mingw\bin\ld.exe /nologo @CMakeFiles\ncfortran.dir\objects1.rsp @<< /out:ncfortran.dll /implib:ncfortran.lib /pdb:D:\netcdf\netcdf-build-fortran\libsrc\ncfortran.pdb /dll /version:0.0 /STACK:10000000 /INCREMENTAL:YES /machine:x64 /debug d:\netcdf\netcdf-build\liblib\netcdf.lib kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib << As you can see, it has picked up a linker (ld.exe) belonging to a completely different compiler/package for this step. I have no idea where this is coming from and how to fix this. Does anyone have any suggestions? Regards, Arjen 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. From Arjen.Markus at deltares.nl Wed Feb 11 10:33:13 2015 From: Arjen.Markus at deltares.nl (Arjen Markus) Date: Wed, 11 Feb 2015 15:33:13 +0000 Subject: [CMake] Unexpected use of "ld" on Windows In-Reply-To: References: <8CF085736108634681FD03EC36E6A0723D98ED32@V-EXC-C02.DIRECTORY.INTRA> Message-ID: <8CF085736108634681FD03EC36E6A0723D98EF48@V-EXC-C02.DIRECTORY.INTRA> Hello Andreas, Hm, that has crossed my mind - maybe I should simply rename that particular directory. It still seems odd though that this occurs. Anyway, thanks for the suggestion. This is simple enough to try ;). Regards, Arjen From: Andreas Pakulat [mailto:apaku at gmx.de] Sent: Wednesday, February 11, 2015 4:30 PM To: Arjen Markus Cc: cmake at cmake.org Subject: Re: [CMake] Unexpected use of "ld" on Windows Hi, On Wed, Feb 11, 2015 at 3:16 PM, Arjen Markus > wrote: Hello, I am trying to build the Fortran interface to NetCDF4 on Windows, using the Intel Fortran compiler and "Nmake Makefiles" as the generator (see http://www.unidata.ucar.edu/downloads/netcdf/index.jsp). I had some trouble getting the first part to build, but that is solved (small issues with the code). The second part, which is supposed to build a C library that can be called from Fortran, presents a more serious problem: for some reason CMake picks parts of another toolchain to build this: The Makefile contains these lines to compile the sources: cd D:\netcdf\netcdf-build-fortran\libsrc C:\PROGRA~2\MICROS~3.0\VC\bin\amd64\cl.exe @<< /nologo $(C_FLAGS) $(C_DEFINES) /FoCMakeFiles\ncfortran.dir\fort-attio.c.obj /FdD:\netcdf\netcdf-build-fortran\libsrc\ncfortran.pdb -c D:\netcdf\netcdf-fortran-4.4.1\libsrc\fort-attio.c But to build the library it contains: libsrc\ncfortran.dll: d:\netcdf\netcdf-build\liblib\netcdf.lib libsrc\ncfortran.dll: libsrc\CMakeFiles\ncfortran.dir\objects1.rsp @$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) --red --bold "Linking C shared library ncfortran.dll" cd D:\netcdf\netcdf-build-fortran\libsrc d:\CMake2.8.10.2\bin\cmake.exe -E vs_link_dll C:\PROGRA~2\HASKEL~1\201320~1.0\mingw\bin\ld.exe /nologo @CMakeFiles\ncfortran.dir\objects1.rsp @<< /out:ncfortran.dll /implib:ncfortran.lib /pdb:D:\netcdf\netcdf-build-fortran\libsrc\ncfortran.pdb /dll /version:0.0 /STACK:10000000 /INCREMENTAL:YES /machine:x64 /debug d:\netcdf\netcdf-build\liblib\netcdf.lib kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib << As you can see, it has picked up a linker (ld.exe) belonging to a completely different compiler/package for this step. I have no idea where this is coming from and how to fix this. Does anyone have any suggestions? Seeing the path to that ld.exe I'm reminded of a problem a colleague recently had. He has Haskell installed on his system and either haskell itself or some haskell library came with mingw and his PATH ended up including the bin dir of that mingw installation. Even if that entry is after the VS compiler CMake apparently chooses to pick up the mingw toolchain (or parts of it), so one has to make sure that there's no MinGW compiler or linker or other part of the toolchain in any of the directories in PATH. At least thats how he resolved the issue. Andreas 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 apaku at gmx.de Wed Feb 11 10:30:21 2015 From: apaku at gmx.de (Andreas Pakulat) Date: Wed, 11 Feb 2015 16:30:21 +0100 Subject: [CMake] Unexpected use of "ld" on Windows In-Reply-To: <8CF085736108634681FD03EC36E6A0723D98ED32@V-EXC-C02.DIRECTORY.INTRA> References: <8CF085736108634681FD03EC36E6A0723D98ED32@V-EXC-C02.DIRECTORY.INTRA> Message-ID: Hi, On Wed, Feb 11, 2015 at 3:16 PM, Arjen Markus wrote: > Hello, > > I am trying to build the Fortran interface to NetCDF4 on Windows, using > the Intel Fortran compiler and "Nmake Makefiles" as the generator (see > http://www.unidata.ucar.edu/downloads/netcdf/index.jsp). > > I had some trouble getting the first part to build, but that is solved > (small issues with the code). The second part, which is supposed to build a > C library that can be called from Fortran, presents a more serious problem: > for some reason CMake picks parts of another toolchain to build this: > > The Makefile contains these lines to compile the sources: > cd D:\netcdf\netcdf-build-fortran\libsrc > C:\PROGRA~2\MICROS~3.0\VC\bin\amd64\cl.exe @<< > /nologo $(C_FLAGS) $(C_DEFINES) > /FoCMakeFiles\ncfortran.dir\fort-attio.c.obj > /FdD:\netcdf\netcdf-build-fortran\libsrc\ncfortran.pdb -c > D:\netcdf\netcdf-fortran-4.4.1\libsrc\fort-attio.c > > But to build the library it contains: > > libsrc\ncfortran.dll: d:\netcdf\netcdf-build\liblib\netcdf.lib > libsrc\ncfortran.dll: libsrc\CMakeFiles\ncfortran.dir\objects1.rsp > @$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) --red > --bold "Linking C shared library ncfortran.dll" > cd D:\netcdf\netcdf-build-fortran\libsrc > d:\CMake2.8.10.2\bin\cmake.exe -E vs_link_dll > C:\PROGRA~2\HASKEL~1\201320~1.0\mingw\bin\ld.exe /nologo > @CMakeFiles\ncfortran.dir\objects1.rsp @<< > /out:ncfortran.dll /implib:ncfortran.lib > /pdb:D:\netcdf\netcdf-build-fortran\libsrc\ncfortran.pdb /dll /version:0.0 > /STACK:10000000 /INCREMENTAL:YES /machine:x64 /debug > d:\netcdf\netcdf-build\liblib\netcdf.lib kernel32.lib user32.lib gdi32.lib > winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib > advapi32.lib > << > > As you can see, it has picked up a linker (ld.exe) belonging to a > completely different compiler/package for this step. > > I have no idea where this is coming from and how to fix this. Does anyone > have any suggestions? Seeing the path to that ld.exe I'm reminded of a problem a colleague recently had. He has Haskell installed on his system and either haskell itself or some haskell library came with mingw and his PATH ended up including the bin dir of that mingw installation. Even if that entry is after the VS compiler CMake apparently chooses to pick up the mingw toolchain (or parts of it), so one has to make sure that there's no MinGW compiler or linker or other part of the toolchain in any of the directories in PATH. At least thats how he resolved the issue. Andreas -------------- next part -------------- An HTML attachment was scrubbed... URL: From frankie.chan at ubisoft.com Wed Feb 11 14:01:17 2015 From: frankie.chan at ubisoft.com (Frankie Chan) Date: Wed, 11 Feb 2015 19:01:17 +0000 Subject: [CMake] How to add a resource .bundle into xcode using cmake? Message-ID: <67924686522e41b6a282e1cc765798c5@MSR-MAIL-EXCH03.ubisoft.org> I am trying to add a resource bundle into a generated xcode project with cmake. However I am having trouble getting this out. This is what i have so far? set(MACOSX_BUNDLE_RESOURCES "${CMAKE_SOURCE_DIR}/resource.bundle") set_source_files_properties(MACOSX_BUNDLE_RESOURCES PROPERTIES MACOSX_PACKAGE_LOCATION Resources) add_executable(project MACOSX_BUNDLE ${FILES_SRC} ${FILES_RSC}) It seems it doesn't see resource.bundle package at all. Any help will be appreciated. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Rene.Tschirley at SMI.DE Thu Feb 12 06:04:40 2015 From: Rene.Tschirley at SMI.DE (=?iso-8859-1?Q?Ren=E9_Tschirley?=) Date: Thu, 12 Feb 2015 11:04:40 +0000 Subject: [CMake] Problem with CMAKE_AUTOMOC files not being regenerated or cleaned Message-ID: <1904FC664D89404E819BA41903ECB2DD097857A0@SMITELMX02.SMINET.DE> Hi all, I have the problem that my automatically generated Qt files are not cleaned up, similar to the problem described in http://www.cmake.org/pipermail/cmake/2013-April/054555.html. Simplified the problem and verified if the set_directory_properties trick works. It does not work for me. Used software: Windows7 SP1, CMake 3.1.2, Ninja 1.5.3. Makefiles configuration is done by cmake -G "Eclipse CDT4 - Ninja" ../source in my build folder. Build is usually started using 'ninja' and a clean is triggered by 'ninja clean'. My top level CMakeLists.txt contains for testing purposes set_directory_properties(PROPERTIES ADDITIONAL_MAKE_CLEAN_FILES "foo.txt") set_directory_properties(PROPERTIES ADDITIONAL_MAKE_CLEAN_FILES "${CMAKE_CURRENT_BINARY_DIR}/foo.txt") MESSAGE(STATUS "CMAKE_CURRENT_BINARY_DIR = ${CMAKE_CURRENT_BINARY_DIR}") and when creating that file (manually, in my CMAKE_CURRENT_BINARY_DIR), it is still not cleaned up on 'ninja clean'. Am I forgetting something obvious? Is this an unfixed CMake bug? Cheers, Rene From sergio.vera at alma3d.com Thu Feb 12 12:40:14 2015 From: sergio.vera at alma3d.com (Sergio Vera) Date: Thu, 12 Feb 2015 18:40:14 +0100 Subject: [CMake] Buils executable vs Installed executable Message-ID: Dear CMake users, I'm developing an app using CMake in Fedora 20 and so far it's working properly in the build directory. However, I've recently added some Install target commands so I can prepare it for packaging with CPack. However, when I "make install" my app, the application no longer runs and complains about missing shared libraries. With ldd I can see that the binary in my build dir do references system libraries and my 3rd party dependencies, which I have built with cmake too (CTK and VTK) However my Install folder binary does not list any shared library to my CTK or VTK libs. I'm a bit puzzled by this behavior... Copying the build binary to the install folder works, but still I would like to know what is missing here. best regards and thanks in advance -- Sergio Vera Alma IT Systems C/ Vilana, 4B, 4? 1? 08022 Barcelona T. (+34) 932 380 592 www.alma3d.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Thu Feb 12 17:41:57 2015 From: robert.maynard at kitware.com (Robert Maynard) Date: Thu, 12 Feb 2015 17:41:57 -0500 Subject: [CMake] [ANNOUNCE] CMake 3.1.3 Released Message-ID: We are pleased to announce that CMake 3.1.3 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.3 since 3.1.2: Brad King (3): Do not call setlocale() globally in CMake applications (#15377) Add setlocale() calls around use of libarchive APIs (#14934, #15377) CMake 3.1.3 Nils Gladitz (1): Makefile: Fix regression in target-bound custom command COMMENT output From pa at letnes.com Fri Feb 13 01:52:12 2015 From: pa at letnes.com (Paul Anton Letnes) Date: Fri, 13 Feb 2015 06:52:12 GMT Subject: [CMake] creating start menu items Message-ID: <1423810332885.107350.71808@webmail5> Hi! I have been unable to come across any documentation on how the WiX CPack generator can create start menu items. I'll need to create items both for a few PDFs (documentation) and for an executable or two. Is this supported, or do I need to write my own XML patch file and give that to WiX? Cheers ----------- Paul Anton -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Fri Feb 13 02:56:55 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 13 Feb 2015 08:56:55 +0100 Subject: [CMake] creating start menu items In-Reply-To: <1423810332885.107350.71808@webmail5> References: <1423810332885.107350.71808@webmail5> Message-ID: <54DDAE47.7020502@gmail.com> On 02/13/2015 07:52 AM, Paul Anton Letnes wrote: > I have been unable to come across any documentation on how the WiX CPack > generator can create start menu items. I'll need to create items both > for a few PDFs (documentation) and for an executable or two. Is this > supported, or do I need to write my own XML patch file and give that to WiX? The WIX generator implements the generic CPACK_PACKAGE_EXECUTABLES [1] which like the name suggests is only for executables though. I was pondering adding another installed file property [2] for the creation of start menu / desktop shortcuts for convenience but for now CPACK_WIX_PATCH_FILE [3] should work for non-executables. Nils [1] http://www.cmake.org/cmake/help/v3.1/module/CPack.html [2] http://www.cmake.org/cmake/help/v3.1/manual/cmake-properties.7.html#properties-on-installed-files [3] http://www.cmake.org/cmake/help/v3.1/module/CPackWIX.html From nilsgladitz at gmail.com Fri Feb 13 05:28:49 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 13 Feb 2015 11:28:49 +0100 Subject: [CMake] Buils executable vs Installed executable In-Reply-To: References: Message-ID: <54DDD1E1.3050904@gmail.com> On 02/12/2015 06:40 PM, Sergio Vera wrote: > Dear CMake users, > > I'm developing an app using CMake in Fedora 20 and so far it's working > properly in the build directory. > However, I've recently added some Install target commands so I can > prepare it for packaging with CPack. > However, when I "make install" my app, the application no longer runs > and complains about missing shared libraries. > > With ldd I can see that the binary in my build dir do references system > libraries and my 3rd party dependencies, which I have built with cmake > too (CTK and VTK) > > However my Install folder binary does not list any shared library to my > CTK or VTK libs. > > I'm a bit puzzled by this behavior... Copying the build binary to the > install folder works, but still I would like to know what is missing here. The default behavior on Linux is that CMake manages two sets of RPATHs; build time and install time. The build time RPATHs are autogenerated to conveniently allow you to run your binaries from your build tree. At installation time the build time RPATHs are replaced with installation time RPATHs (which per default are empty). This is since when you deploy your applications you don't normally want RPATHs that refer to locations which are only valid on your own development system. You can adjust the behavior with the CMake variables that have RPATH in their name [1]. Assuming you only intend to deploy locally and your shared libraries aren't being added to the installation itself INSTALL_RPATH_USE_LINK_PATH [2] might be what you are looking for. Nils [1] http://www.cmake.org/cmake/help/v3.1/manual/cmake-variables.7.html [2] http://www.cmake.org/cmake/help/v3.1/variable/CMAKE_INSTALL_RPATH_USE_LINK_PATH.html From pellegrini at ill.fr Fri Feb 13 11:32:13 2015 From: pellegrini at ill.fr (pellegrini) Date: Fri, 13 Feb 2015 17:32:13 +0100 Subject: [CMake] cpack and boost dependencies when building a debian installer Message-ID: <54DE270D.1040902@ill.fr> Hello everybody, I would like to use cpack (2.8.7) in order to build a debian installer for a c++ library that has a few dependencies namely: - boost (headers + libraries) - fftw3-3 - eigen3 - hdf5 - tiff I would like to set my cpack file in such a way that the minimum version required for boost is the 1.54. So I introduced in my cmake/cpack file the following command according to my understanding of CPACK documentation. set(BOOST_MIN_VERSION 1.54) string(REPLACE "," ", " CPACK_DEBIAN_PACKAGE_DEPENDS "libboost-all-dev (>= ${BOOST_MIN_VERSION})," "libeigen3-dev," "libfftw3-3," "libtiff4-dev," "libhdf5-serial-dev,") Once my debian file is created, I get the following error when launching it with gdebi (but also with dpkg): ########################## Reading package lists... Done Building dependency tree Reading state information... Done Building data structures... Done Building data structures... Done This package is uninstallable Dependency is not satisfiable: libboost-all-dev (>= 1.54) ########################## However, boost is actually installed on my machine (version 1.55.0). Did I misunderstand something in the way to declare that we need a minimum version for a given library ? thanks for your help Eric From robert.maynard at kitware.com Fri Feb 13 15:12:33 2015 From: robert.maynard at kitware.com (Robert Maynard) Date: Fri, 13 Feb 2015 15:12:33 -0500 Subject: [CMake] [ANNOUNCE] CMake 3.2.0-rc1 now ready for testing! Message-ID: I am proud to announce that CMake 3.2 has entered the release candidate stage. Sources and binaries are available at: http://www.cmake.org/download/ http://www.cmake.org/files/v3.2/?C=M;O=D Documentation is available at: http://www.cmake.org/cmake/help/v3.2 Release notes appear below and are also published at http://www.cmake.org/cmake/help/v3.2/release/3.2.html Some of the more significant features of CMake 3.2 are: * CMake learned to support unicode characters *encoded as UTF-8* on Windows. This was already supported on platforms whose system APIs accept UTF-8 encoded strings. Unicode characters may now be used in CMake code, paths to source files, configured files such as ".h.in" files, and other files read and written by CMake. Note that because CMake interoperates with many other tools, there may still be some limitations when using certain unicode characters. * The "Compile Features" functionality is now aware of features supported by more compilers, including: * Apple Clang ("AppleClang") for Xcode versions 4.4 though 6.1. * GNU compiler versions 4.4 through 5.0 on UNIX and Apple ("GNU"). * Microsoft Visual Studio ("MSVC") for versions 2010 through 2015. * Oracle SolarisStudio ("SunPro") version 12.4. * The "add_custom_command()" and "add_custom_target()" commands learned a new "BYPRODUCTS" option to specify files produced as side effects of the custom commands. These are not outputs because they do not always have to be newer than inputs. * The "file(GENERATE)" command can now generate files which are used as source files for buildsystem targets. Generated files automatically get their "GENERATED" property set to "TRUE". Deprecated and Removed Features: * Files written in the "cmake-language(7)", such as "CMakeLists.txt" or "*.cmake" files, are now expected to be encoded as UTF-8. If files are already ASCII, they will be compatible. If files were in a different encoding, including Latin 1, they will need to be converted. * The "FindOpenGL" module no longer explicitly searches for any dependency on X11 libraries with the "FindX11" module. Such dependencies should not need to be explicit. Applications using X11 APIs themselves should find and link to X11 libraries explicitly. CMake 3.2 Release Notes *********************** Changes made since CMake 3.1 include the following. New Features ============ Syntax ------ * CMake learned to support unicode characters *encoded as UTF-8* on Windows. This was already supported on platforms whose system APIs accept UTF-8 encoded strings. Unicode characters may now be used in CMake code, paths to source files, configured files such as ".h.in" files, and other files read and written by CMake. Note that because CMake interoperates with many other tools, there may still be some limitations when using certain unicode characters. Commands -------- * The "add_custom_command()" and "add_custom_target()" commands learned a new "BYPRODUCTS" option to specify files produced as side effects of the custom commands. These are not outputs because they do not always have to be newer than inputs. * The "add_custom_command()" and "add_custom_target()" commands learned a new "USES_TERMINAL" option to request that the command be given direct access to the terminal if possible. The "Ninja" generator will places such commands in the "console" "pool". Build targets provided by CMake that are meant for individual interactive use, such as "install", are now placed in this pool. * A new "continue()" command was added that can be called inside loop contexts to end the current iteration and start the next one at the top of the loop block. * The "file(LOCK)" subcommand was created to allow CMake processes to synchronize through file and directory locks. * The "file(STRINGS)" now supports UTF-16LE, UTF-16BE, UTF-32LE, UTF- 32BE as "ENCODING" options. * The "install(EXPORT)" command now works with an absolute "DESTINATION" even if targets in the export set are installed with a destination or *usage requirements* specified relative to the install prefix. The value of the "CMAKE_INSTALL_PREFIX" variable is hard-coded into the installed export file as the base for relative references. * The "try_compile()" command source file signature now honors link flags (e.g. "CMAKE_EXE_LINKER_FLAGS") in the generated test project. See policy "CMP0056". * The "try_run()" command learned to honor the "LINK_LIBRARIES" option just as "try_compile()" already does. * The "file(GENERATE)" command now generates the output file with the same permissions as the input file if set. * The "file(GENERATE)" command can now generate files which are used as source files for buildsystem targets. Generated files automatically get their "GENERATED" property set to "TRUE". Variables --------- * The "CMAKE_MATCH_COUNT" variable was introduced to record the number of matches made in the last regular expression matched in an "if()" command or a "string()" command. Properties ---------- * An "ANDROID_API_MIN" target property was introduced to specify the minimum version to be targeted by the toolchain. * A "VS_SHADER_FLAGS" source file property was added to specify additional shader flags to ".hlsl" files, for the Visual Studio generators. Modules ------- * The "ExternalData" module learned to support *Custom Fetch Scripts*. This allows projects to specify custom ".cmake" scripts for fetching data objects during the build. * The "ExternalProject" module learned options to create independent external project step targets that do not depend on the builtin steps. * The "ExternalProject" module "ExternalProject_Add()" command learned a new "CMAKE_CACHE_DEFAULT_ARGS" option to initialize cache values in the external project without setting them on future builds. * The "ExternalProject" module "ExternalProject_Add()" command learned a new "TEST_EXCLUDE_FROM_MAIN" option to exclude tests from the main build. * The "ExternalProject" module "ExternalProject_Add()" command learned a new "UPDATE_DISCONNECTED" option to avoid automatically updating the source tree checkout from version control. * The "FindCUDA" module learned about the "cusolver" library in CUDA 7.0. * The "FindGit" module learned to find the "git" command-line tool that comes with GitHub for Windows installed in user home directories. * A "FindGSL" module was introduced to find the GNU Scientific Library. * A "FindIntl" module was introduced to find the Gettext "libintl" library. * A "FindJsonCpp" module was introduced to find the JsonCpp package. * The "FindLATEX" module learned to support components. * The "FindMPI" module learned to find MS-MPI on Windows. * The "FindOpenSSL" module now reports "crypto" and "ssl" libraries separately in "OPENSSL_CRYPTO_LIBRARY" and "OPENSSL_SSL_LIBRARY", respectively, to allow applications to link to one without the other. * The "WriteCompilerDetectionHeader" module learned to create a define for portability of the "cxx_thread_local" feature. The define expands to either the C++11 "thread_local" keyword, or a pre- standardization compiler-specific equivalent, as appropriate. * The "WriteCompilerDetectionHeader" module learned to create multiple output files per compiler and per language, instead of creating one large file. CTest ----- * The "ctest_coverage()" command learned to support Delphi coverage. * The "ctest_coverage()" command learned to support Javascript coverage. * The "CTestCoverageCollectGCOV" module was introduced as an alternative to the "ctest_coverage()" command for collecting "gcov" results for submission to CDash. CPack ----- * The "CPackRPM" module learned options to set per-component descriptions and summaries. See the "CPACK_RPM__PACKAGE_DESCRIPTION" and "CPACK_RPM__PACKAGE_SUMMARY" variables. * The "CPackRPM" module learned options to specify requirements for pre- and post-install scripts. See the "CPACK_RPM_PACKAGE_REQUIRES_PRE" and "CPACK_RPM_PACKAGE_REQUIRES_POST" variables. * The "CPackRPM" module learned options to specify requirements for pre- and post-uninstall scripts. See the "CPACK_RPM_PACKAGE_REQUIRES_PREUN" and "CPACK_RPM_PACKAGE_REQUIRES_POSTUN" variables. * The "CPackRPM" module learned a new "CPACK_RPM__PACKAGE_PREFIX" variable to specify a component-specific value to use instead of "CPACK_PACKAGING_INSTALL_PREFIX". * The "CPackRPM" module learned a new "CPACK_RPM_RELOCATION_PATHS" variable to specify multiple relocation prefixes for a single rpm package. Other ----- * The "cmake(1)" "-E tar" command now supports creating ".xz"-compressed archives with the "J" flag. * The "cmake(1)" "-E tar" command learned a new "--files- from=" option to specify file names using lines in a file to overcome command-line length limits. * The "cmake(1)" "-E tar" command learned a new "--mtime=" option to specify the modification time recorded in tarball entries. * The "Compile Features" functionality is now aware of features supported by more compilers, including: * Apple Clang ("AppleClang") for Xcode versions 4.4 though 6.1. * GNU compiler versions 4.4 through 5.0 on UNIX and Apple ("GNU"). * Microsoft Visual Studio ("MSVC") for versions 2010 through 2015. * Oracle SolarisStudio ("SunPro") version 12.4. * The *AUTORCC* feature now tracks files listed in ".qrc" files as dependencies. If an input file to the "rcc" tool is changed, the tool is automatically re-run. New Diagnostics =============== * The "break()" command now rejects calls outside of a loop context or that pass arguments to the command. See policy "CMP0055". Deprecated and Removed Features =============================== * Files written in the "cmake-language(7)", such as "CMakeLists.txt" or "*.cmake" files, are now expected to be encoded as UTF-8. If files are already ASCII, they will be compatible. If files were in a different encoding, including Latin 1, they will need to be converted. * The "FindOpenGL" module no longer explicitly searches for any dependency on X11 libraries with the "FindX11" module. Such dependencies should not need to be explicit. Applications using X11 APIs themselves should find and link to X11 libraries explicitly. * The implementation of CMake now relies on some C++ compiler features which are not supported by some older compilers. As a result, those old compilers can no longer be used to build CMake itself. CMake continues to be able to generate Makefiles and project files for users of those old compilers however. Compilers known to no longer be capable of building CMake are: * Visual Studio 6 and 7.0 -- superseded by VisualStudio 7.1 and newer. * GCC 2.95 -- superseded by GCC 3 and newer compilers. * Borland compilers -- superseded by other Windows compilers. * Compaq compilers -- superseded by other compilers. * SGI compilers -- IRIX was dropped as a host platform. Other Changes ============= * On Windows and OS X, commands supporting network communication via "https", such as "file(DOWNLOAD)", "file(UPLOAD)", and "ctest_submit()", now support SSL/TLS even when CMake is not built against OpenSSL. The Windows or OS X native SSL/TLS implementation is used by default. OS-configured certificate authorities will be trusted automatically. On other platforms, when CMake is built with OpenSSL, these commands now search for OS-configured certificate authorities in a few "/etc" paths to be trusted automatically. * On OS X with Makefile and Ninja generators, when a compiler is found in "/usr/bin" it is now mapped to the corresponding compiler inside the Xcode application folder, if any. This allows such build trees to continue to work with their original compiler even when "xcode- select" switches to a different Xcode installation. * The Visual Studio generators now write solution and project files in UTF-8 instead of Windows-1252. Windows-1252 supported Latin 1 languages such as those found in North and South America and Western Europe. With UTF-8, additional languages are now supported. * The "Xcode" generator no longer requires a value for the "CMAKE_MAKE_PROGRAM" variable to be located up front. It now locates "xcodebuild" when needed at build time. * When building CMake itself using SolarisStudio 12, the default "libCStd" standard library is not sufficient to build CMake. The SolarisStudio distribution supports compiler options to use "STLPort4" or "libstdc++". An appropriate option to select the standard library is now added automatically when building CMake with SolarisStudio compilers. From canergen.ac at googlemail.com Fri Feb 13 16:07:03 2015 From: canergen.ac at googlemail.com (Can Ergen) Date: Fri, 13 Feb 2015 22:07:03 +0100 Subject: [CMake] Assertion failed using make Message-ID: <9999F603-8661-436E-B33B-FD6E38758F4E@gmail.com> Hi, When using make in terminal after generating I get following error message: [ 1%] Performing configure step for 'ANN' -- Configuring done Assertion failed: (stdIt != stds.end()), function AddCompilerRequirementFlag, file /Users/can/Downloads/cmake-3.1.2/Source/cmLocalGenerator.cxx, line 2257. /bin/sh: line 1: 62776 Abort trap: 6 /usr/local/bin/cmake -DCMAKE_OSX_ARCHITECTURES:PATH= -DCMAKE_OSX_DEPLOYMENT_TARGET:PATH= -DCMAKE_OSX_SYSROOT:PATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk -DCMAKE_CXX_EXTENSIONS:STRING= -DCMAKE_CXX_STANDARD:STRING= -DCMAKE_CXX_STANDARD_REQUIRED:BOOL= -DCMAKE_DEBUG_POSTFIX:STRING=d -DCMAKE_MACOSX_RPATH:BOOL=TRUE -DCMAKE_INSTALL_RPATH:STRING=@loader_path/../lib -DBUILD_TESTING:BOOL=OFF -DCMAKE_INSTALL_PREFIX:PATH=/Users/can/MITK-superbuild/ep "-DCMAKE_PREFIX_PATH:PATH=/Users/can/MITK-superbuild/ep;" -DCMAKE_INCLUDE_PATH:PATH= -DCMAKE_LIBRARY_PATH:PATH= -DBUILD_SHARED_LIBS:BOOL=ON -DCMAKE_BUILD_TYPE:STRING=Release -DCMAKE_C_COMPILER:FILEPATH=/Applications/Xcode.app/Contents/Developer/usr/bin/gcc -DCMAKE_CXX_COMPILER:FILEPATH=/Applications/Xcode.app/Contents/Developer/usr/bin/gcc -DCMAKE_C_FLAGS:STRING= "-DCMAKE_CXX_FLAGS:STRING= -std=c++11" -DCMAKE_CXX_FLAGS_DEBUG:STRING=-g -DCMAKE_C_FLAGS_DEBUG:STRING=-g "-DCMAKE_CXX_FLAGS_RELEASE:STRING=-O3 -DNDEBUG" "-DCMAKE_C_FLAGS_RELEASE:STRING=-O3 -DNDEBUG" "-DCMAKE_CXX_FLAGS_RELWITHDEBINFO:STRING=-O2 -g -DNDEBUG" "-DCMAKE_C_FLAGS_RELWITHDEBINFO:STRING=-O2 -g -DNDEBUG" -DCMAKE_EXE_LINKER_FLAGS:STRING= -DCMAKE_SHARED_LINKER_FLAGS:STRING= -DCMAKE_MODULE_LINKER_FLAGS:STRING= "-GUnix Makefiles" /Users/can/MITK-superbuild/ep/src/ANN make[2]: *** [ep/src/ANN-stamp/ANN-configure] Error 134 make[1]: *** [CMakeFiles/ANN.dir/all] Error 2 make: *** [all] Error 2 I have followed the steps at http://docs.mitk.org/2014.10/BuildInstructionsPage.html in configuring. I am using Mavericks with Xcode 6.1.1. Do you have any suggestions? Thanks, Can -------------- next part -------------- An HTML attachment was scrubbed... URL: From iosif.neitzke+cmake at gmail.com Fri Feb 13 16:11:42 2015 From: iosif.neitzke+cmake at gmail.com (Iosif Neitzke) Date: Fri, 13 Feb 2015 15:11:42 -0600 Subject: [CMake] creating start menu items In-Reply-To: <54DDAE47.7020502@gmail.com> References: <1423810332885.107350.71808@webmail5> <54DDAE47.7020502@gmail.com> Message-ID: As a side note, remember that CPACK_PACKAGE_EXECUTABLES is problematic in another way too; it requires listed executables to be installed to /bin/. On Fri, Feb 13, 2015 at 1:56 AM, Nils Gladitz wrote: > On 02/13/2015 07:52 AM, Paul Anton Letnes wrote: >> >> I have been unable to come across any documentation on how the WiX CPack >> generator can create start menu items. I'll need to create items both >> for a few PDFs (documentation) and for an executable or two. Is this >> supported, or do I need to write my own XML patch file and give that to >> WiX? > > > The WIX generator implements the generic CPACK_PACKAGE_EXECUTABLES [1] which > like the name suggests is only for executables though. > > I was pondering adding another installed file property [2] for the creation > of start menu / desktop shortcuts for convenience but for now > CPACK_WIX_PATCH_FILE [3] should work for non-executables. > > Nils > > [1] http://www.cmake.org/cmake/help/v3.1/module/CPack.html > > [2] > http://www.cmake.org/cmake/help/v3.1/manual/cmake-properties.7.html#properties-on-installed-files > > [3] http://www.cmake.org/cmake/help/v3.1/module/CPackWIX.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 nilsgladitz at gmail.com Fri Feb 13 16:27:54 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 13 Feb 2015 22:27:54 +0100 Subject: [CMake] creating start menu items In-Reply-To: References: <1423810332885.107350.71808@webmail5> <54DDAE47.7020502@gmail.com> Message-ID: <54DE6C5A.2080401@gmail.com> On 13.02.2015 22:11, Iosif Neitzke wrote: > As a side note, remember that CPACK_PACKAGE_EXECUTABLES is problematic > in another way too; it requires listed executables to be installed to > /bin/. As far as I know that is just with the NSIS generator and can be mitigated with CPACK_NSIS_MENU_LINKS and CPACK_NSIS_EXECUTABLES_DIRECTORY. Nils From iosif.neitzke+cmake at gmail.com Fri Feb 13 16:32:04 2015 From: iosif.neitzke+cmake at gmail.com (Iosif Neitzke) Date: Fri, 13 Feb 2015 15:32:04 -0600 Subject: [CMake] creating start menu items In-Reply-To: <54DE6C5A.2080401@gmail.com> References: <1423810332885.107350.71808@webmail5> <54DDAE47.7020502@gmail.com> <54DE6C5A.2080401@gmail.com> Message-ID: Ah, very good. On Fri, Feb 13, 2015 at 3:27 PM, Nils Gladitz wrote: > On 13.02.2015 22:11, Iosif Neitzke wrote: >> >> As a side note, remember that CPACK_PACKAGE_EXECUTABLES is problematic >> in another way too; it requires listed executables to be installed to >> /bin/. > > > As far as I know that is just with the NSIS generator and can be mitigated > with CPACK_NSIS_MENU_LINKS and CPACK_NSIS_EXECUTABLES_DIRECTORY. > > Nils From a.neundorf-work at gmx.net Fri Feb 13 16:35:41 2015 From: a.neundorf-work at gmx.net (Alexander Neundorf) Date: Fri, 13 Feb 2015 22:35:41 +0100 Subject: [CMake] [ANNOUNCE] CMake 3.2.0-rc1 now ready for testing! In-Reply-To: References: Message-ID: <2074925.7VaAbS6l7i@tuxedo.neundorf.net> On Friday, February 13, 2015 15:12:33 Robert Maynard wrote: > I am proud to announce that CMake 3.2 has entered the release candidate > stage. the new format of the release notes is really nice :-) Alex From vano at mail.mipt.ru Sun Feb 15 01:31:09 2015 From: vano at mail.mipt.ru (vano at mail.mipt.ru) Date: Sun, 15 Feb 2015 10:31:09 +0400 (MSK) Subject: [CMake] "Conflicting types for 'cmsysProcess_SetPipeNative'" compiling in MinGW In-Reply-To: <304070819.2083456.1423979470741.JavaMail.zimbra@mail.mipt.ru> Message-ID: <1310118344.2086381.1423981869006.JavaMail.zimbra@mail.mipt.ru> Completely puzzled by this: a declaration conflicts with... itself?! $ uname -a MINGW32_NT-6.1 IVAN-POWERPC 1.0.18(0.48/3/2) 2012-11-21 22:34 i686 Msys The error part follows, full output is attached. This happens with both cmake-3.2.0-rc1 and cmake-3.1.3. <...> gcc -I/c/Users/native_api/Documents/cmake-3.2.0-rc1/Bootstrap.cmk -I/c/Users/native_api/Documents/cmake-3.2.0-rc1/Source -I/c/Users/native_api/Documents/cmake-3.2.0-rc1/Bootstrap.cmk -DKWSYS_NAMESPACE=cmsys -c /c/Users/native_api/Documents/cmake-3.2.0-rc1/Source/kwsys/ProcessWin32.c -o ProcessWin32.o In file included from c:/Users/native_api/Documents/cmake-3.2.0-rc1/Bootstrap.cmk/cmsys/Process.h:15:0, from c:/Users/native_api/Documents/cmake-3.2.0-rc1/Source/kwsys/ProcessWin32.c:13: c:/Users/native_api/Documents/cmake-3.2.0-rc1/Bootstrap.cmk/cmsys/Configure.h:40:22: error: conflicting types for 'cmsysProcess_SetPipeNative' # define kwsys_ns(x) cmsys##x ^ c:/Users/native_api/Documents/cmake-3.2.0-rc1/Bootstrap.cmk/cmsys/Process.h:35:43: note: in expansion of macro 'kwsys_ns' # define kwsysProcess_SetPipeNative kwsys_ns(Process_SetPipeNative) ^ c:/Users/native_api/Documents/cmake-3.2.0-rc1/Source/kwsys/ProcessWin32.c:749:6: note: in expansion of macro 'kwsysProcess_SetPipeNative' void kwsysProcess_SetPipeNative(kwsysProcess* cp, int pipe, HANDLE p[2]) ^ c:/Users/native_api/Documents/cmake-3.2.0-rc1/Bootstrap.cmk/cmsys/Configure.h:40:22: note: previous declaration of 'cmsysProcess_SetPipeNative' was here # define kwsys_ns(x) cmsys##x ^ c:/Users/native_api/Documents/cmake-3.2.0-rc1/Bootstrap.cmk/cmsys/Process.h:35:43: note: in expansion of macro 'kwsys_ns' # define kwsysProcess_SetPipeNative kwsys_ns(Process_SetPipeNative) ^ c:/Users/native_api/Documents/cmake-3.2.0-rc1/Bootstrap.cmk/cmsys/Process.h:175:18: note: in expansion of macro 'kwsysProcess_SetPipeNative' kwsysEXPORT void kwsysProcess_SetPipeNative(kwsysProcess* cp, int pipe, ^ make: *** [ProcessWin32.o] Error 1 --------------------------------------------- Error when bootstrapping CMake: Problem while running make --------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: bootstrap.tar.xz Type: application/x-xz-compressed-tar Size: 7220 bytes Desc: not available URL: From lice.adrian at gmail.com Sun Feb 15 04:22:12 2015 From: lice.adrian at gmail.com (Lice Adrian) Date: Sun, 15 Feb 2015 17:22:12 +0800 Subject: [CMake] how to insert the comment in Makefile by Cmake? Message-ID: hi there is the specific command need to call in build steps. how can i insert the comment before this command executed. add_custom_command ( OUTPUT ${OUTFILE} COMMENT #pragma runlocal COMMAND sudo -u app_x01 ..... DEPENDS ${DEPENDS} DEPENDS ${SUDO_PASS} ) i want get the makefile like this #pragma runlocal sudo -u app_x01 ..... thanks brs Adrian -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at mad-scientist.net Sun Feb 15 09:55:44 2015 From: paul at mad-scientist.net (Paul Smith) Date: Sun, 15 Feb 2015 09:55:44 -0500 Subject: [CMake] How to build a target on install (only)? Message-ID: <1424012144.4834.336.camel@homebase> In my Mac OSX builds I want to run dsymutil to create .dSYM debug contents. However, this is very slow so I don't want to do it during normal builds (where it's not needed because I have all the object files), I only want it to be done during the install step. I can create an add_custom_command() to run dsymutil easily enough, something like: function(stagedebug target dir) if(APPLE) set(destfile "${dir}/${target}.dSYM/Contents/Info.plist") add_custom_command(OUTPUT "$destfile" COMMAND dsymutil "${dir}/${target}" MAIN_DEPENDENCY ${target} COMMENT "Staging dSYM for ${target} to ${dir}" VERBATIM) # Now what? endif endfunction() but I have no idea how to hook this into the install step. I don't see anything in the install() command that lets me specify a target to be run, it just seems to be able to copy files. What am I missing? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From DLRdave at aol.com Sun Feb 15 12:16:15 2015 From: DLRdave at aol.com (David Cole) Date: Sun, 15 Feb 2015 12:16:15 -0500 Subject: [CMake] How to build a target on install (only)? In-Reply-To: <1424012144.4834.336.camel@homebase> References: <1424012144.4834.336.camel@homebase> Message-ID: The easiest thing is probably to use the install(SCRIPT or install(CODE signature of the install command rather than having a "build time" custom command. HTH, David C. On Sun, Feb 15, 2015 at 9:55 AM, Paul Smith wrote: > In my Mac OSX builds I want to run dsymutil to create .dSYM debug contents. > However, this is very slow so I don't want to do it during normal builds > (where it's not needed because I have all the object files), I only want it > to be done during the install step. > > I can create an add_custom_command() to run dsymutil easily enough, > something like: > > function(stagedebug target dir) > if(APPLE) > set(destfile "${dir}/${target}.dSYM/Contents/Info.plist") > add_custom_command(OUTPUT "$destfile" > COMMAND dsymutil "${dir}/${target}" > MAIN_DEPENDENCY ${target} > COMMENT "Staging dSYM for ${target} to ${dir}" > VERBATIM) > > # Now what? > endif > endfunction() > > > but I have no idea how to hook this into the install step. I don't see > anything in the install() command that lets me specify a target to be run, > it just seems to be able to copy files. > > What am I missing? > > Thanks! > > -- > > 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 paul at mad-scientist.net Sun Feb 15 14:59:43 2015 From: paul at mad-scientist.net (Paul Smith) Date: Sun, 15 Feb 2015 14:59:43 -0500 Subject: [CMake] How to build a target on install (only)? In-Reply-To: References: <1424012144.4834.336.camel@homebase> Message-ID: <1424030383.4834.345.camel@homebase> On Sun, 2015-02-15 at 12:16 -0500, David Cole wrote: > The easiest thing is probably to use the install(SCRIPT or > install(CODE signature of the install command rather than having a > "build time" custom command. Hm. That has the disadvantage that it runs every time, even if the binary hasn't been modified, but it does work: install(CODE "message(STATUS \"Creating dSYM for ${target} in ${dir}\")") install(CODE "execute_process(COMMAND dsymutil \"${dir}/${target}\" OUTPUT_QUIET)") It's too bad that execute_process() doesn't have a COMMENT field, but this works OK. It wasn't clear to me how to pass arguments to a SCRIPT so I used CODE instead. It'd be nice if I could make it a real target that only is invoked on install, so that we'd not re-run the command if it wasn't necessary, but this gets the work done; thanks for the pointer! From iosif.neitzke+cmake at gmail.com Sun Feb 15 19:26:10 2015 From: iosif.neitzke+cmake at gmail.com (Iosif Neitzke) Date: Sun, 15 Feb 2015 18:26:10 -0600 Subject: [CMake] How to build a target on install (only)? In-Reply-To: <1424030383.4834.345.camel@homebase> References: <1424012144.4834.336.camel@homebase> <1424030383.4834.345.camel@homebase> Message-ID: For conditional file install, you could try something like "cmake -E copy_if_different". On Sun, Feb 15, 2015 at 1:59 PM, Paul Smith wrote: > On Sun, 2015-02-15 at 12:16 -0500, David Cole wrote: >> The easiest thing is probably to use the install(SCRIPT or >> install(CODE signature of the install command rather than having a >> "build time" custom command. > > Hm. That has the disadvantage that it runs every time, even if the > binary hasn't been modified, but it does work: > > install(CODE "message(STATUS \"Creating dSYM for ${target} in ${dir}\")") > install(CODE "execute_process(COMMAND dsymutil \"${dir}/${target}\" OUTPUT_QUIET)") > > It's too bad that execute_process() doesn't have a COMMENT field, but > this works OK. It wasn't clear to me how to pass arguments to a SCRIPT > so I used CODE instead. > > It'd be nice if I could make it a real target that only is invoked on > install, so that we'd not re-run the command if it wasn't necessary, but > this gets the work done; thanks for the pointer! > > -- > > 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 paul at mad-scientist.net Mon Feb 16 09:25:57 2015 From: paul at mad-scientist.net (Paul Smith) Date: Mon, 16 Feb 2015 09:25:57 -0500 Subject: [CMake] How to build a target on install (only)? In-Reply-To: References: <1424012144.4834.336.camel@homebase> <1424030383.4834.345.camel@homebase> Message-ID: <1424096757.4834.361.camel@homebase> On Sun, 2015-02-15 at 18:26 -0600, Iosif Neitzke wrote: > For conditional file install, you could try something like "cmake -E > copy_if_different". That won't work; I don't have any files to copy. What I want is to run the dsymutil command during install only, not during the normal build (because it's slow), but only if the binary that was installed has changed. copy_if_different won't help here. > On Sun, Feb 15, 2015 at 1:59 PM, Paul Smith wrote: > > install(CODE "message(STATUS \"Creating dSYM for ${target} in ${dir}\")") > > install(CODE "execute_process(COMMAND dsymutil \"${dir}/${target}\" OUTPUT_QUIET)") From nilsgladitz at gmail.com Mon Feb 16 09:49:53 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Mon, 16 Feb 2015 15:49:53 +0100 Subject: [CMake] How to build a target on install (only)? In-Reply-To: <1424096757.4834.361.camel@homebase> References: <1424012144.4834.336.camel@homebase> <1424030383.4834.345.camel@homebase> <1424096757.4834.361.camel@homebase> Message-ID: <54E20391.4020605@gmail.com> On 02/16/2015 03:25 PM, Paul Smith wrote: > On Sun, 2015-02-15 at 18:26 -0600, Iosif Neitzke wrote: >> For conditional file install, you could try something like "cmake -E >> copy_if_different". > > That won't work; I don't have any files to copy. What I want is to run > the dsymutil command during install only, not during the normal build > (because it's slow), but only if the binary that was installed has > changed. > > copy_if_different won't help here. How about custom dependency checking? e.g. something like: if(${dependency} IS_NEWER_THAN ${output}) execute_process(...) endif() Nils From DLRdave at aol.com Mon Feb 16 09:46:20 2015 From: DLRdave at aol.com (David Cole) Date: Mon, 16 Feb 2015 09:46:20 -0500 Subject: [CMake] How to build a target on install (only)? In-Reply-To: <1424096757.4834.361.camel@homebase> References: <1424012144.4834.336.camel@homebase> <1424030383.4834.345.camel@homebase> <1424096757.4834.361.camel@homebase> Message-ID: The other way you could approach this, but which would not be as simple would be to invent *your own* custom install target (install_with_dSYM, or whatever name makes sense to you). Then you could have that target depend on all the custom targets that build the dSYM files. When you build this custom install_with_DSYM target, it would first build all the dSYM files via add_custom_command rules, and *then* run the same command that "make install" runs to install all the other files. Or vice versa, if the dSYM needs to be run on stuff in the install tree... HTH, D On Mon, Feb 16, 2015 at 9:25 AM, Paul Smith wrote: > On Sun, 2015-02-15 at 18:26 -0600, Iosif Neitzke wrote: >> For conditional file install, you could try something like "cmake -E >> copy_if_different". > > That won't work; I don't have any files to copy. What I want is to run > the dsymutil command during install only, not during the normal build > (because it's slow), but only if the binary that was installed has > changed. > > copy_if_different won't help here. > >> On Sun, Feb 15, 2015 at 1:59 PM, Paul Smith wrote: >> > install(CODE "message(STATUS \"Creating dSYM for ${target} in ${dir}\")") >> > install(CODE "execute_process(COMMAND dsymutil \"${dir}/${target}\" OUTPUT_QUIET)") > > > > -- > > 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 Mon Feb 16 09:55:46 2015 From: DLRdave at aol.com (David Cole) Date: Mon, 16 Feb 2015 09:55:46 -0500 Subject: [CMake] How to build a target on install (only)? In-Reply-To: <54E20391.4020605@gmail.com> References: <1424012144.4834.336.camel@homebase> <1424030383.4834.345.camel@homebase> <1424096757.4834.361.camel@homebase> <54E20391.4020605@gmail.com> Message-ID: Ah ha! Back to the simpler approach with install(CODE....! Good idea, Nils. Then you just need a stamp/sentinel file associated with running the operation, and you can check it against your input. For your "comment" line, you could use "cmake -E echo" to spit out a comment before running the dSYM tool, and for your stamp files, after the operation is done, you can use "cmake -E touch" to update the time stamp on the sentinel files. D On Mon, Feb 16, 2015 at 9:49 AM, Nils Gladitz wrote: > On 02/16/2015 03:25 PM, Paul Smith wrote: >> >> On Sun, 2015-02-15 at 18:26 -0600, Iosif Neitzke wrote: >>> >>> For conditional file install, you could try something like "cmake -E >>> copy_if_different". >> >> >> That won't work; I don't have any files to copy. What I want is to run >> the dsymutil command during install only, not during the normal build >> (because it's slow), but only if the binary that was installed has >> changed. >> >> copy_if_different won't help here. > > > How about custom dependency checking? > > e.g. something like: > > if(${dependency} IS_NEWER_THAN ${output}) > execute_process(...) > endif() > > Nils > > -- > > 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 paul at mad-scientist.net Mon Feb 16 12:29:03 2015 From: paul at mad-scientist.net (Paul Smith) Date: Mon, 16 Feb 2015 12:29:03 -0500 Subject: [CMake] How to build a target on install (only)? In-Reply-To: References: <1424012144.4834.336.camel@homebase> <1424030383.4834.345.camel@homebase> <1424096757.4834.361.camel@homebase> <54E20391.4020605@gmail.com> Message-ID: <1424107743.4834.375.camel@homebase> On Mon, 2015-02-16 at 09:55 -0500, David Cole wrote: > Ah ha! Back to the simpler approach with install(CODE....! > > Good idea, Nils. > > Then you just need a stamp/sentinel file associated with running the > operation, and you can check it against your input. Aha, that works well. I don't need a sentinel file since I can just test against one of the files that dsymutil generates. And, I discovered I can have a multi-line CODE just by adding newlines into the string, so that works well. Nice! Thanks all! From pa at letnes.com Mon Feb 16 14:22:27 2015 From: pa at letnes.com (Paul Anton Letnes) Date: Mon, 16 Feb 2015 20:22:27 +0100 Subject: [CMake] creating start menu items In-Reply-To: References: <1423810332885.107350.71808@webmail5> <54DDAE47.7020502@gmail.com> Message-ID: This seems to match what I've seen in my so-far light experimentation. What's the fix? Use wix XML patches? I'm betting my money on the WiX train as this is what we use elsewhere in my organization. Also I can live without the start menu items in the very worst case. cheers Paul > On 13. feb. 2015, at 22.11, Iosif Neitzke wrote: > > As a side note, remember that CPACK_PACKAGE_EXECUTABLES is problematic > in another way too; it requires listed executables to be installed to > /bin/. > > On Fri, Feb 13, 2015 at 1:56 AM, Nils Gladitz wrote: >> On 02/13/2015 07:52 AM, Paul Anton Letnes wrote: >>> >>> I have been unable to come across any documentation on how the WiX CPack >>> generator can create start menu items. I'll need to create items both >>> for a few PDFs (documentation) and for an executable or two. Is this >>> supported, or do I need to write my own XML patch file and give that to >>> WiX? >> >> >> The WIX generator implements the generic CPACK_PACKAGE_EXECUTABLES [1] which >> like the name suggests is only for executables though. >> >> I was pondering adding another installed file property [2] for the creation >> of start menu / desktop shortcuts for convenience but for now >> CPACK_WIX_PATCH_FILE [3] should work for non-executables. >> >> Nils >> >> [1] http://www.cmake.org/cmake/help/v3.1/module/CPack.html >> >> [2] >> http://www.cmake.org/cmake/help/v3.1/manual/cmake-properties.7.html#properties-on-installed-files >> >> [3] http://www.cmake.org/cmake/help/v3.1/module/CPackWIX.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 > -- > > 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 lectem at gmail.com Mon Feb 16 14:22:36 2015 From: lectem at gmail.com (=?UTF-8?Q?Cl=C3=A9ment_Gregoire?=) Date: Mon, 16 Feb 2015 20:22:36 +0100 Subject: [CMake] Cmake and devkitpro Message-ID: Hi, I'm looking for a way to use CMake with the devkitpro toolchain ( http://sourceforge.net/projects/devkitpro/files/ ) I would like to be able to compile nds and 3ds homebrews. It is a gcc based toolchain, and users have to define DEVKITPRO and DEVKITARM env variables, giving the location of the devkitpro files. the DEVKITARM folder contains the bin and lib folders, but those platforms need specific commands to build the final files. All the rules are based on makefiles available here : https://github.com/devkitPro/buildscripts/tree/master/dkarm-eabi/rules I started by looking at the cmake toolchain stuff (CMAKE_SYSTEM_NAME, CMAKE_FIND_ROOT_PATH etc) but I don't think it will work well. Any suggestions ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergio.vera at alma3d.com Tue Feb 17 05:02:52 2015 From: sergio.vera at alma3d.com (Sergio Vera) Date: Tue, 17 Feb 2015 11:02:52 +0100 Subject: [CMake] Buils executable vs Installed executable In-Reply-To: <54DDD1E1.3050904@gmail.com> References: <54DDD1E1.3050904@gmail.com> Message-ID: Thanks Nils, It makes perfect sense with your explanation! Did not know anything about this RPATH family of variables before. Cheers and thanks again On Fri, Feb 13, 2015 at 11:28 AM, Nils Gladitz wrote: > On 02/12/2015 06:40 PM, Sergio Vera wrote: > >> Dear CMake users, >> >> I'm developing an app using CMake in Fedora 20 and so far it's working >> properly in the build directory. >> However, I've recently added some Install target commands so I can >> prepare it for packaging with CPack. >> However, when I "make install" my app, the application no longer runs >> and complains about missing shared libraries. >> >> With ldd I can see that the binary in my build dir do references system >> libraries and my 3rd party dependencies, which I have built with cmake >> too (CTK and VTK) >> >> However my Install folder binary does not list any shared library to my >> CTK or VTK libs. >> >> I'm a bit puzzled by this behavior... Copying the build binary to the >> install folder works, but still I would like to know what is missing here. >> > > The default behavior on Linux is that CMake manages two sets of RPATHs; > build time and install time. > > The build time RPATHs are autogenerated to conveniently allow you to run > your binaries from your build tree. > > At installation time the build time RPATHs are replaced with installation > time RPATHs (which per default are empty). > > This is since when you deploy your applications you don't normally want > RPATHs that refer to locations which are only valid on your own development > system. > > You can adjust the behavior with the CMake variables that have RPATH in > their name [1]. > > Assuming you only intend to deploy locally and your shared libraries > aren't being added to the installation itself INSTALL_RPATH_USE_LINK_PATH > [2] might be what you are looking for. > > Nils > > [1] http://www.cmake.org/cmake/help/v3.1/manual/cmake-variables.7.html > > [2] http://www.cmake.org/cmake/help/v3.1/variable/CMAKE_ > INSTALL_RPATH_USE_LINK_PATH.html > -- Sergio Vera Alma IT Systems C/ Vilana, 4B, 4? 1? 08022 Barcelona T. (+34) 932 380 592 www.alma3d.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ramey at rrsd.com Tue Feb 17 12:28:26 2015 From: ramey at rrsd.com (Robert Ramey) Date: Tue, 17 Feb 2015 10:28:26 -0700 (MST) Subject: [CMake] CMake and Eclipse Luna Message-ID: <1424194106159-7589778.post@n2.nabble.com> I'm using CMake 3.02 through CMake GUI. I have a CMake project which I want to build using Eclipse Luna (the most recent eclipse). But the GUI doesn't present me with that option. I tried to use the latest one (Helios) but it seems that it won't work with this option. What should I do in order to build my project with Eclipse Luna Robert Ramey -- View this message in context: http://cmake.3232098.n2.nabble.com/CMake-and-Eclipse-Luna-tp7589778.html Sent from the CMake mailing list archive at Nabble.com. From a.neundorf-work at gmx.net Tue Feb 17 15:04:22 2015 From: a.neundorf-work at gmx.net (Alexander Neundorf) Date: Tue, 17 Feb 2015 21:04:22 +0100 Subject: [CMake] CMake and Eclipse Luna In-Reply-To: <1424194106159-7589778.post@n2.nabble.com> References: <1424194106159-7589778.post@n2.nabble.com> Message-ID: <2142797.bFJdoBs7Q4@tuxedo.neundorf.net> On Tuesday, February 17, 2015 10:28:26 Robert Ramey wrote: > I'm using CMake 3.02 through CMake GUI. > > I have a CMake project which I want to build using Eclipse Luna (the most > recent eclipse). But the GUI doesn't present me with that option. I tried > to use the latest one (Helios) but it seems that it won't work with this > option. > > What should I do in order to build my project with Eclipse Luna Helios should be Ok (I'll update it soon to add Luna). What doesn't work ? Alex From wonder.mice at gmail.com Tue Feb 17 15:27:23 2015 From: wonder.mice at gmail.com (Andrey Pokrovskiy) Date: Tue, 17 Feb 2015 12:27:23 -0800 Subject: [CMake] Consuming results of ExternalProject_Add Message-ID: Hi, I'm using ExternalProject_Add() to build OpenSLL library. After install step I have following artifacts available: * libcrypto.a * libssl.a * include/openssl/*.h I wonder, what is the "canonical" way to make those artifacts available for other targets in the project? FindPackage style thing with OPENSSL_LIBRARIES and OPENSSL_INCLUDE_DIR variables will not work, because OpenSSL target and executable that uses it are on the same level (I think using CACHE to propagate variable value up is a dirty hack): * src/openssl/CMakeLists.txt * src/my_executable/CMakeLists.txt Ideally I would like to use add_library() with target_include_directories() and target_link_libraries(). But the only way to do that is to use IMPORTED libraries, like that: add_library(crypto STATIC IMPORTED GLOBAL) add_dependencies(crypto openssl_external_project) set_property(TARGET crypto PROPERTY INTERFACE_LINK_LIBRARIES ${OPENSSL_PREFIX}/lib/libcrypto.a) set_property(TARGET crypto PROPERTY INTERFACE_INCLUDE_DIRECTORIES ${OPENSSL_PREFIX}/include) But then I get an error: $ cmake .. CMake Error in src/my_executable/CMakeLists.txt: Imported target "crypto" includes non-existent path "<...>/build.dir/src/openssl/openssl-1.0.2.install/include" Obviously, that happens because include directory was not created yet (it will after make). I understand that from general CMake standpoint - IMPORTED libraries are something that already exists and not part of the build. But then I don't understand how this ExternalProject_Add thing is supposed to be used. Any ideas what I'm doing wrong? From jchris.fillionr at kitware.com Tue Feb 17 16:53:19 2015 From: jchris.fillionr at kitware.com (Jean-Christophe Fillion-Robin) Date: Tue, 17 Feb 2015 16:53:19 -0500 Subject: [CMake] Consuming results of ExternalProject_Add In-Reply-To: References: Message-ID: Hi Andrey, Since there is already a FindOpenSSL.cmake module [1], configuring the consumer project with the variable expected by the FindOpenSSL.cmake module is the easiest. See https://github.com/Slicer/Slicer/blob/ee84fba523d85be3539bf8c83c8eb73d4f59cfff/SuperBuild/External_OpenSSL.cmake#L231-L239 [1] https://github.com/Kitware/CMake/blob/master/Modules/FindOpenSSL.cmake Hth Jc On Tue, Feb 17, 2015 at 3:27 PM, Andrey Pokrovskiy wrote: > Hi, > > I'm using ExternalProject_Add() to build OpenSLL library. After > install step I have following artifacts available: > * libcrypto.a > * libssl.a > * include/openssl/*.h > > I wonder, what is the "canonical" way to make those artifacts > available for other targets in the project? > > FindPackage style thing with OPENSSL_LIBRARIES and OPENSSL_INCLUDE_DIR > variables will not work, because OpenSSL target and executable that > uses it are on the same level (I think using CACHE to propagate > variable value up is a dirty hack): > * src/openssl/CMakeLists.txt > * src/my_executable/CMakeLists.txt > > Ideally I would like to use add_library() with > target_include_directories() and > target_link_libraries(). But the only way to do that is to use > IMPORTED libraries, like that: > > add_library(crypto STATIC IMPORTED GLOBAL) > add_dependencies(crypto openssl_external_project) > set_property(TARGET crypto PROPERTY INTERFACE_LINK_LIBRARIES > ${OPENSSL_PREFIX}/lib/libcrypto.a) > set_property(TARGET crypto PROPERTY INTERFACE_INCLUDE_DIRECTORIES > ${OPENSSL_PREFIX}/include) > > But then I get an error: > $ cmake .. > > CMake Error in src/my_executable/CMakeLists.txt: > > Imported target "crypto" includes non-existent path > > "<...>/build.dir/src/openssl/openssl-1.0.2.install/include" > > Obviously, that happens because include directory was not created yet > (it will after make). > > I understand that from general CMake standpoint - IMPORTED libraries > are something that already exists and not part of the build. But then > I don't understand how this ExternalProject_Add thing is supposed to > be used. > > Any ideas what I'm doing wrong? > -- > > 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 > -- +1 919 869 8849 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sasha-Shyrokov at idexx.com Tue Feb 17 16:14:36 2015 From: Sasha-Shyrokov at idexx.com (Shyrokov, Sasha) Date: Tue, 17 Feb 2015 21:14:36 +0000 Subject: [CMake] How to force package target generate a file before proceeding Message-ID: <201502172114.t1HLBft2014034@mx0a-00116901.pphosted.com> Hi, I would like to include a generated file into a package. I have something like that: include(CPack) add_custom_command (OUTPUT hgHash.txt COMMAND hg --debug id -i >hgHash.txt COMMENT "Getting hg hash") add_custom_target (hg_hash DEPENDS hgHash.txt COMMENT "hg_hash target") Now the following would solve my problems, but it does not work: add_dependencies(package hg_hash) I get: Cannot add target-level dependencies to non-existent target "package". I know I have CPack configured properly, because if I create the file manually it gets included. I also can add the dependency on one of my libraries, but I only want to generate this file when package is executed. What am I missing? Thanks, Sasha From wonder.mice at gmail.com Tue Feb 17 17:52:13 2015 From: wonder.mice at gmail.com (Andrey Pokrovskiy) Date: Tue, 17 Feb 2015 14:52:13 -0800 Subject: [CMake] Consuming results of ExternalProject_Add In-Reply-To: References: Message-ID: Thanks for your reply, Jean-Christophe. I don't see how External_OpenSSL.cmake is used in Slicer (probably some weird scheme is involved). But from what I see, it supposed to be used like that: include(External_OpenSSL) add_executable(my_executable main.cpp ...) target_include_directories(my_executable ${OPENSSL_INCLUDE_DIR}) target_link_libraries(my_executable ${OPENSSL_LIBRARIES}) That means that I will need to include External_OpenSSL in every CMakeLists.txt that uses OpenSSL. That doesn't sounds right to me. And if not, then something adds OPENSSL_INCLUDE_DIR and OPENSSL_LIBRARIES to CACHE which is also doesn't sounds right. Also this will not setup build dependency between target and OpenSSL. I know, I could use additional add_dependencies() for that, but that's clumsy. 3 lines instead of just: target_link_libraries(my_executable crypto ssl) CMake already has a concept of "libraries" (added with add_library). There should be a way of saying "Hey, this static library comes from that external project. It also requires such and such include directories". On Tue, Feb 17, 2015 at 1:53 PM, Jean-Christophe Fillion-Robin wrote: > Hi Andrey, > > Since there is already a FindOpenSSL.cmake module [1], configuring the > consumer project with the variable expected by the FindOpenSSL.cmake module > is the easiest. > > See > https://github.com/Slicer/Slicer/blob/ee84fba523d85be3539bf8c83c8eb73d4f59cfff/SuperBuild/External_OpenSSL.cmake#L231-L239 > > > [1] https://github.com/Kitware/CMake/blob/master/Modules/FindOpenSSL.cmake > > Hth > Jc > > On Tue, Feb 17, 2015 at 3:27 PM, Andrey Pokrovskiy > wrote: >> >> Hi, >> >> I'm using ExternalProject_Add() to build OpenSLL library. After >> install step I have following artifacts available: >> * libcrypto.a >> * libssl.a >> * include/openssl/*.h >> >> I wonder, what is the "canonical" way to make those artifacts >> available for other targets in the project? >> >> FindPackage style thing with OPENSSL_LIBRARIES and OPENSSL_INCLUDE_DIR >> variables will not work, because OpenSSL target and executable that >> uses it are on the same level (I think using CACHE to propagate >> variable value up is a dirty hack): >> * src/openssl/CMakeLists.txt >> * src/my_executable/CMakeLists.txt >> >> Ideally I would like to use add_library() with >> target_include_directories() and >> target_link_libraries(). But the only way to do that is to use >> IMPORTED libraries, like that: >> >> add_library(crypto STATIC IMPORTED GLOBAL) >> add_dependencies(crypto openssl_external_project) >> set_property(TARGET crypto PROPERTY INTERFACE_LINK_LIBRARIES >> ${OPENSSL_PREFIX}/lib/libcrypto.a) >> set_property(TARGET crypto PROPERTY INTERFACE_INCLUDE_DIRECTORIES >> ${OPENSSL_PREFIX}/include) >> >> But then I get an error: >> $ cmake .. >> >> CMake Error in src/my_executable/CMakeLists.txt: >> >> Imported target "crypto" includes non-existent path >> >> "<...>/build.dir/src/openssl/openssl-1.0.2.install/include" >> >> Obviously, that happens because include directory was not created yet >> (it will after make). >> >> I understand that from general CMake standpoint - IMPORTED libraries >> are something that already exists and not part of the build. But then >> I don't understand how this ExternalProject_Add thing is supposed to >> be used. >> >> Any ideas what I'm doing wrong? >> -- >> >> 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 > > > > > -- > +1 919 869 8849 From wonder.mice at gmail.com Tue Feb 17 20:14:24 2015 From: wonder.mice at gmail.com (Andrey Pokrovskiy) Date: Tue, 17 Feb 2015 17:14:24 -0800 Subject: [CMake] add_dependencies: Disallow use with INTERFACE_LIBRARY. WHY?!? Message-ID: Hi, Current CMake disallows Interface Libraries to have dependencies. However, I suspect that was done for a reason. Here is the commit for that change: commit 6db7e6d24c68085f16dcf6d8a86ae0f74e9a1f01 Author: Stephen Kelly Date: Wed Dec 25 15:11:50 2013 +0100 add_dependencies: Disallow use with INTERFACE_LIBRARY. It says what it does but not why... >From CMake documentation: "A primary use-case for INTERFACE libraries is header-only libraries". But what if those headers are generated during build time? Or what if it depends on libraries that are part of the build? Or what if that library is a result of ExternalProject_Add()? I though about it and I can't come with any idea why that was explicitly disallowed. Maybe it's possible to allow it back? Any ideas? From roolebo at gmail.com Tue Feb 17 20:36:56 2015 From: roolebo at gmail.com (Roman Bolshakov) Date: Tue, 17 Feb 2015 17:36:56 -0800 (PST) Subject: [CMake] add_dependencies: Disallow use with INTERFACE_LIBRARY. WHY?!? In-Reply-To: References: Message-ID: <1424223416289.6f0c5c82@Nodemailer> I agree with Andrey, there should be a way to use interface library type with generated headers. There's a workaround but it involves manual set up of extra dependencies solely for dependency tracking. You have to add dependency between a target which consumes the generated headers and a custom target which directly depends on the output of a custom command along with adding interface library into target_link_libraries of the consumer. Each additional target of the generated headers would require the extra dependency set up. It would be much more natural to add a dependency between interface library and the custom target.? Thanks, Roman -------------- next part -------------- An HTML attachment was scrubbed... URL: From jchris.fillionr at kitware.com Wed Feb 18 00:58:13 2015 From: jchris.fillionr at kitware.com (Jean-Christophe Fillion-Robin) Date: Wed, 18 Feb 2015 00:58:13 -0500 Subject: [CMake] Consuming results of ExternalProject_Add In-Reply-To: References: Message-ID: Hi Andrey, On Tue, Feb 17, 2015 at 5:52 PM, Andrey Pokrovskiy wrote: > > I don't see how External_OpenSSL.cmake is used in Slicer (probably > some weird scheme is involved). > We used "Artichoke" that provides a set of convenience function to managed "superbuild" based project. See [1] and [2] for mode details. [1] http://public.kitware.com/pipermail/cmake/2014-June/057735.html [2] https://github.com/commontk/Artichoke > But from what I see, it supposed to be used like that: > > include(External_OpenSSL) > add_executable(my_executable main.cpp ...) > target_include_directories(my_executable ${OPENSSL_INCLUDE_DIR}) > target_link_libraries(my_executable ${OPENSSL_LIBRARIES}) > > That means that I will need to include External_OpenSSL in every > CMakeLists.txt that uses OpenSSL. That doesn't sounds right to me. > One way of using external projects is to consider it automate the following steps: (1) manual build of OpenSSL (2) configuration of your project Foo passing either OPENSSL_CRYPTO_LIBRARY/OPENSSL_SSL_LIBRARY options on unix or LIB_EAY_DEBUG/LIB_EAY_RELEASE/SSL_EAY_DEBUG/SSL_EAY_RELEASE on windows, and then build of the project And since there are no need to manually rebuild openssl for each CMakeLists.txt in your project Foo, there are no need to include "External_OpenSSL" in every CMakeLists.txt. Reading [3] should also be helpful to understand the concepts. [3] http://www.kitware.com/media/html/BuildingExternalProjectsWithCMake2.8.html > > And if not, then something adds OPENSSL_INCLUDE_DIR and > OPENSSL_LIBRARIES to CACHE which is also doesn't sounds right. > > Also this will not setup build dependency between target and OpenSSL. > I know, I could use additional add_dependencies() for that, but that's > clumsy. 3 lines instead of just: > > target_link_libraries(my_executable crypto ssl) > After doing: find_package(OpenSSL) in your project, you could then do: target_link_libraries(my_executable ${OPENSSL_LIBRARIES}) > > CMake already has a concept of "libraries" (added with add_library). > There should be a way of saying "Hey, this static library comes from > that external project. It also requires such and such include > directories". In fact, all FindXXXX.cmake module are slowly been converted to create CMake imported targets. Since the current FindOpenSSL.cmake does not create imported targets, it could be updated to do so. For an example, see [4] [4] http://www.cmake.org/cmake/help/v3.1/manual/cmake-developer.7.html#a-sample-find-module [5] https://github.com/Kitware/CMake/commit/bcb0e38 Hth Jc -- +1 919 869 8849 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Micha.Renner at t-online.de Wed Feb 18 02:46:45 2015 From: Micha.Renner at t-online.de (Micha Renner) Date: Wed, 18 Feb 2015 08:46:45 +0100 Subject: [CMake] install(files... Message-ID: <1424245605.3526.1.camel@t-online.de> Hello, In the manual the install(FILES...) command is described as this: install( files... DESTINATION [PERMISSIONS permissions...] [CONFIGURATIONS [Debug|Release|...]] [COMPONENT ] [RENAME ] [OPTIONAL]) So what is the meaning of COMPONENT and OPTIONAL? Greetings Micha From petr.kmoch at gmail.com Wed Feb 18 03:03:20 2015 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Wed, 18 Feb 2015 09:03:20 +0100 Subject: [CMake] install(files... In-Reply-To: <1424245605.3526.1.camel@t-online.de> References: <1424245605.3526.1.camel@t-online.de> Message-ID: Hi Micha, these parameters, which are common to several install() commands, are described in the initial section of the command's docs: http://www.cmake.org/cmake/help/v3.2/command/install.html#introduction Petr On Wed, Feb 18, 2015 at 8:46 AM, Micha Renner wrote: > Hello, > > In the manual the install(FILES...) command is described as this: > install( files... DESTINATION > [PERMISSIONS permissions...] > [CONFIGURATIONS [Debug|Release|...]] > [COMPONENT ] > [RENAME ] [OPTIONAL]) > > So what is the meaning of COMPONENT and OPTIONAL? > > Greetings > > Micha > > > > -- > > 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 cutberto.escamilla at wasd.net Wed Feb 18 12:52:23 2015 From: cutberto.escamilla at wasd.net (Cutberto Escamilla) Date: Wed, 18 Feb 2015 09:52:23 -0800 Subject: [CMake] Minor documentation mistake Message-ID: Hello, I was trying to use the Graphviz feature on CMake and noticed a mistake on the documentation where it says to use "--graphiz=foo" instead of "--graphviz=foo" where the former doesn't work but the latter does. I tried searching the different archives, but there is no mention about this. Was wondering if I should submit a bug. Thanks, Juan Escamilla -------------- next part -------------- An HTML attachment was scrubbed... URL: From wonder.mice at gmail.com Wed Feb 18 16:12:45 2015 From: wonder.mice at gmail.com (Andrey Pokrovskiy) Date: Wed, 18 Feb 2015 13:12:45 -0800 Subject: [CMake] Consuming results of ExternalProject_Add In-Reply-To: References: Message-ID: Thanks for clarification, JC. The links you provided are a good read. However, I would like to avoid "super-build" technique. It needlessly (in my case) complicates and obfuscates things. > In fact, all FindXXXX.cmake module are slowly been converted to create CMake imported targets. FindXXXX.cmake modules assume that artifacts (libraries, headers) already exist and use INTERFACE or/and IMPORTED targets. But there are problems when headers and libraries generated with the build. See thread about that specific limitation [1]. * add_library(xxx INTERFACE) - target_link_libraries and target_include_directories can be used but library xxx can't depend on anything (but it must depend on external project that will generate it) * add_library(xxx IMPORTED GLOBAL) - INTERFACE_INCLUDE_DIRECTORIES and INTERFACE_LINK_LIBRARIES can be used, but will produce error during configuration that include dir doesn't exist and associated libraries will be "_NOT_FOUND". As for now, I ended up with the following: ExternalProject_Add(openssl ...) add_library(crypto INTERFACE) target_link_libraries(crypto INTERFACE ${OPENSSL_INSTALL_PREFIX}/lib/libcrypto.a) target_include_directories(crypto INTERFACE ${OPENSSL_INSTALL_PREFIX}/include) add_library(ssl INTERFACE) target_link_libraries(ssl INTERFACE ${OPENSSL_INSTALL_PREFIX}/lib/libssl.a) target_include_directories(ssl INTERFACE ${OPENSSL_INSTALL_PREFIX}/include) With the requirement to add_dependencies(... openssl) when target depends on ssl or crypto libraries, like that: add_executable(my_executable ${SOURCES}) add_dependencies(my_executable openssl) target_link_libraries(my_executable crypto ssl) Quite inconsistent behaviour if you ask me. Thanks, anyway. I will keep in mind this "super-build" thing in case my solution will not scale too well. [1] http://www.cmake.org/pipermail/cmake/2015-February/059885.html On Tue, Feb 17, 2015 at 9:58 PM, Jean-Christophe Fillion-Robin wrote: > Hi Andrey, > > On Tue, Feb 17, 2015 at 5:52 PM, Andrey Pokrovskiy > wrote: >> >> >> I don't see how External_OpenSSL.cmake is used in Slicer (probably >> some weird scheme is involved). > > > We used "Artichoke" that provides a set of convenience function to managed > "superbuild" based project. > See [1] and [2] for mode details. > > [1] http://public.kitware.com/pipermail/cmake/2014-June/057735.html > [2] https://github.com/commontk/Artichoke > > >> >> But from what I see, it supposed to be used like that: >> >> include(External_OpenSSL) >> add_executable(my_executable main.cpp ...) >> target_include_directories(my_executable ${OPENSSL_INCLUDE_DIR}) >> target_link_libraries(my_executable ${OPENSSL_LIBRARIES}) >> >> That means that I will need to include External_OpenSSL in every >> CMakeLists.txt that uses OpenSSL. That doesn't sounds right to me. > > > > One way of using external projects is to consider it automate the following > steps: > > (1) manual build of OpenSSL > (2) configuration of your project Foo passing either > OPENSSL_CRYPTO_LIBRARY/OPENSSL_SSL_LIBRARY options on unix or > LIB_EAY_DEBUG/LIB_EAY_RELEASE/SSL_EAY_DEBUG/SSL_EAY_RELEASE on windows, and > then build of the project > > > And since there are no need to manually rebuild openssl for each > CMakeLists.txt in your project Foo, there are no need to include > "External_OpenSSL" in every CMakeLists.txt. > > Reading [3] should also be helpful to understand the concepts. > > [3] > http://www.kitware.com/media/html/BuildingExternalProjectsWithCMake2.8.html > > > > > > >> >> >> And if not, then something adds OPENSSL_INCLUDE_DIR and >> OPENSSL_LIBRARIES to CACHE which is also doesn't sounds right. >> >> Also this will not setup build dependency between target and OpenSSL. >> I know, I could use additional add_dependencies() for that, but that's >> clumsy. 3 lines instead of just: >> >> target_link_libraries(my_executable crypto ssl) > > > After doing: > > find_package(OpenSSL) > > in your project, you could then do: > > target_link_libraries(my_executable ${OPENSSL_LIBRARIES}) > > > >> >> >> CMake already has a concept of "libraries" (added with add_library). >> There should be a way of saying "Hey, this static library comes from >> that external project. It also requires such and such include >> directories". > > > In fact, all FindXXXX.cmake module are slowly been converted to create CMake > imported targets. > > Since the current FindOpenSSL.cmake does not create imported targets, it > could be updated to do so. For an example, see [4] > > [4] > http://www.cmake.org/cmake/help/v3.1/manual/cmake-developer.7.html#a-sample-find-module > [5] https://github.com/Kitware/CMake/commit/bcb0e38 > > > Hth > Jc > > > > > -- > +1 919 869 8849 From Scott.Elliott at hgst.com Wed Feb 18 17:06:49 2015 From: Scott.Elliott at hgst.com (Scott Elliott) Date: Wed, 18 Feb 2015 22:06:49 +0000 Subject: [CMake] 'command line too long' when path contains a special character Message-ID: I am using CMake 2.8.12 on Windows. My directory/path name contains an exclamation point (e.g. C:\!Code\CommandLineTooLong). I get a 'The command line is too long.' error when linking an executable from 100 objects. After poking around in cmGlobalNinjaGenerator.cxx, this is what I think is causing the error. Due to the exclamation point in the path name, an 'identify' variable (e.g. ident350, ident351, etc.) is generated for each object when creating the EXECUTABLE_LINKER build rule. The generated build statement consists of the identify variable names (e.g. build $ident450: CXX_EXECUTABLE_LINKER $ident350 $ident351 $ident352 ... $ident449). The length of this build statement (with identify variables) is used in the calculation to determine if a response file is required. The length does not exceed the command line limit, so a response file is not used. However, when the identify variables are replaced with the path names during the build, the build statement is too long causing an error. Is this a known error? I searched in bug tracker, but didn't find it. If it is a known bug, is there a fix for it? Thanks...Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From masariello+cmake.org at gmail.com Wed Feb 18 18:11:58 2015 From: masariello+cmake.org at gmail.com (Alessio) Date: Wed, 18 Feb 2015 23:11:58 +0000 Subject: [CMake] Visual Studio add-in: adding non-cmake files as dependencies to trigger re-generation Message-ID: Subject: Visual Studio add-in: adding non-cmake files as dependencies to trigger re-generation Hello Is there a way to let the Visual Studio CMake add-in know that it needs to regenerate the project when certain non-cmake files change? I'm reading lists of file names from non-cmake txt files with file(STRINGS ...) calls. The variable is then used to form lists of files that need to be compiled. I'm aware that I could have the lists in set(var ...) statements inside "includable" cmake files, but unfortunately I have to do it this way because the txt files are also digested by our legacy build system. Any advice much appreciated! Thank you in advance! -------------- next part -------------- An HTML attachment was scrubbed... URL: From roolebo at gmail.com Wed Feb 18 19:26:20 2015 From: roolebo at gmail.com (Roman Bolshakov) Date: Wed, 18 Feb 2015 16:26:20 -0800 (PST) Subject: [CMake] Visual Studio add-in: adding non-cmake files as dependencies to trigger re-generation In-Reply-To: References: Message-ID: <1424305579916.ea7c6eda@Nodemailer> You might try to use CMAKE_CONFIGURE_DEPENDS (http://www.cmake.org/cmake/help/v3.0/prop_dir/CMAKE_CONFIGURE_DEPENDS.html) property: set_property(DIRECTORY APPEND PROPERTY CMAKE_CONFIGURE_DEPENDS dependency.txt) That would trigger CMake regeneration upon a change of dependency.txt -Roman -------------- next part -------------- An HTML attachment was scrubbed... URL: From roolebo at gmail.com Wed Feb 18 20:23:19 2015 From: roolebo at gmail.com (Roman Bolshakov) Date: Wed, 18 Feb 2015 17:23:19 -0800 (PST) Subject: [CMake] How to force package target generate a file before proceeding In-Reply-To: <201502172114.t1HLBft2014034@mx0a-00116901.pphosted.com> References: <201502172114.t1HLBft2014034@mx0a-00116901.pphosted.com> Message-ID: <1424308999246.d7f3e8a6@Nodemailer> add_custom_command is rather used for operations performed during build phase (which is completely separate off packaging) You could create hgHash.txt during packaging by using install(SCRIPT) command: install(SCRIPT hgHash.cmake) install( ? FILES hgHash.txt ? DESTINATION yourapp ) Hypothetical hgHash.cmake would be quite straightforward: message(STATUS "Getting hg hash") execute_process( ? COMMAND hg --debug id -i ? OUTPUT_FILE hgHash.txt ) That would create hgHash.txt unconditionally during each cpack/make install/cmake -P cmake_install.cmake invocation -Roman ? Sent from Mailbox On Wed, Feb 18, 2015 at 12:55 AM, Shyrokov, Sasha wrote: > Hi, > I would like to include a generated file into a package. I have something like that: > include(CPack) > add_custom_command (OUTPUT hgHash.txt > COMMAND hg --debug id -i >hgHash.txt > COMMENT "Getting hg hash") > add_custom_target (hg_hash > DEPENDS hgHash.txt > COMMENT "hg_hash target") > Now the following would solve my problems, but it does not work: > add_dependencies(package hg_hash) > I get: > Cannot add target-level dependencies to non-existent target "package". > I know I have CPack configured properly, because if I create the file manually it gets included. I also can add the dependency on one of my libraries, but I only want to generate this file when package is executed. > What am I missing? > Thanks, > Sasha > -- > 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 j.kreuzberger at procitec.de Thu Feb 19 03:44:38 2015 From: j.kreuzberger at procitec.de (=?utf-8?Q?J=C3=B6rg_Kreuzberger?=) Date: Thu, 19 Feb 2015 09:44:38 +0100 Subject: [CMake] Visual Studio Dependencies broken for custom target sln Message-ID: Hi! I have a problem with visual studio dependencies that i actually do not understand. Perhaps you can give me an hint. I have made my libs, apps with cmake successfull and everything is fine with any SINGLE Configuration generator, even jom nmake makefiles, linux, etc. For building my apps serveral custom targets and custom commands are defined to build additinal files (e.g. qm files and others) and dependencies added with add_dependencies() To have shortcuts for the build (that means build and install only a few of all apps) i have also made a custom target (empty) named e.g. "buildNetwork" with dependencies to some other targets (apps) for compilation and install in an extra CMakeLists.txt with seperate project() name Now the question: if i use the top-level-solution in ${CMAKE_BINARY_DIR}, the custom target "buildNetwork" builds with all dependencies, that means with all applications and their custom targets( e.g. for qm file creation). if i use the solution for my "buildNetwork" custom target, the sln includes all applications, custom targets. But if i build, it only builds the dependent applications, but not their dependent custom targets. That means e.g. if i use this solution, i do not get any qm files. It tries to build them, but they are excluded in the configuration of the sln (skipped during build) Workaround seems to be that i must use the ALL keyword in my custom targets, but i thought i do not need this and handle it via the explicit set dependencies, like it worked for the other generators Cmake Version used is 3.0.0 and Generator is VS 2013 x64 From masariello+cmake.org at gmail.com Thu Feb 19 04:30:58 2015 From: masariello+cmake.org at gmail.com (Alessio) Date: Thu, 19 Feb 2015 09:30:58 +0000 Subject: [CMake] Visual Studio add-in: adding non-cmake files as dependencies to trigger re-generation In-Reply-To: <1424305579916.ea7c6eda@Nodemailer> References: <1424305579916.ea7c6eda@Nodemailer> Message-ID: Works like a charm Thank you very much! On 19 February 2015 at 00:26, Roman Bolshakov wrote: > You might try to use CMAKE_CONFIGURE_DEPENDS ( > http://www.cmake.org/cmake/help/v3.0/prop_dir/CMAKE_CONFIGURE_DEPENDS.html) > property: > > set_property(DIRECTORY APPEND PROPERTY CMAKE_CONFIGURE_DEPENDS > dependency.txt) > > That would trigger CMake regeneration upon a change of dependency.txt > > -Roman > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.hufer at dionglobal.de Thu Feb 19 05:03:09 2015 From: michael.hufer at dionglobal.de (Michael Hufer) Date: Thu, 19 Feb 2015 11:03:09 +0100 Subject: [CMake] cmake shared library exported symbols on 64bit AIX XLC compiler Message-ID: <54E5B4DD.5020907@dionglobal.de> Hi, we have issues linking against shared libraries created in our project on AIX 7.1 with XLC 12.1 when creating 64bit applications. The created shared libraries to not export any symbols. After some digging around I figured out that this is due to a missing argument for IBM's XL CreateExportList tool called from the generated "link.txt" file. For 64bit shared libraries this tool should be called with -X64 (and -X32 for 32bit to be consistent). The arguments for this tool seems to be set in "Modules/Compiler/XL.cmake". Unfortunately I could not figure out myself how to add or not add the "-X64" to the commandline, depending on the whether a particular build run is creating 32 or 64bit objects. Could someone with more intimate knowledge of how the CMake internal modules handle this look into this, please? Thanks, -- Michael Hufer Senior Software Developer ------------------------------- Dion Global Solutions GmbH Mainzer Landstr. 199 I 60322 Frankfurt am Main I Germany phone: +49 69 50952 241 email:michael.hufer at dionglobal.com | web: www.dionglobal.com/de HRB-Nr./Commercial Register No. 83397 Gesch?ftsf?hrer / Managing Directors: Ralph James Horne, Joseph Nash From j.kreuzberger at procitec.de Thu Feb 19 05:55:51 2015 From: j.kreuzberger at procitec.de (=?utf-8?Q?J=C3=B6rg_Kreuzberger?=) Date: Thu, 19 Feb 2015 11:55:51 +0100 Subject: [CMake] =?utf-8?q?Visual_Studio_Dependencies_broken_for_custom_ta?= =?utf-8?q?rget_sln?= Message-ID: Dependency handling works with 3.2-rc1. So i will migrate. From Sasha-Shyrokov at idexx.com Thu Feb 19 09:26:12 2015 From: Sasha-Shyrokov at idexx.com (Shyrokov, Sasha) Date: Thu, 19 Feb 2015 14:26:12 +0000 Subject: [CMake] How to force package target generate a file before proceeding In-Reply-To: <1424308999246.d7f3e8a6@Nodemailer> References: <201502172114.t1HLBft2014034@mx0a-00116901.pphosted.com> <1424308999246.d7f3e8a6@Nodemailer> Message-ID: <201502191426.t1JEMf4C013194@mx0b-00116901.pphosted.com> Thanks Roman for the detailed response. I would like the hash generated when I use ?make package? command, not ?make install?. I can see that my hgHash.cmake is included, but it does not run on ?make package?. Thanks, Sasha From: Roman Bolshakov [mailto:roolebo at gmail.com] Sent: Wednesday, February 18, 2015 8:23 PM To: Shyrokov, Sasha Cc: cmake at cmake.org Subject: Re: [CMake] How to force package target generate a file before proceeding add_custom_command is rather used for operations performed during build phase (which is completely separate off packaging) You could create hgHash.txt during packaging by using install(SCRIPT) command: install(SCRIPT hgHash.cmake) install( FILES hgHash.txt DESTINATION yourapp ) Hypothetical hgHash.cmake would be quite straightforward: message(STATUS "Getting hg hash") execute_process( COMMAND hg --debug id -i OUTPUT_FILE hgHash.txt ) That would create hgHash.txt unconditionally during each cpack/make install/cmake -P cmake_install.cmake invocation -Roman On Wed, Feb 18, 2015 at 12:55 AM, Shyrokov, Sasha > wrote: Hi, I would like to include a generated file into a package. I have something like that: include(CPack) add_custom_command (OUTPUT hgHash.txt COMMAND hg --debug id -i >hgHash.txt COMMENT "Getting hg hash") add_custom_target (hg_hash DEPENDS hgHash.txt COMMENT "hg_hash target") Now the following would solve my problems, but it does not work: add_dependencies(package hg_hash) I get: Cannot add target-level dependencies to non-existent target "package". I know I have CPack configured properly, because if I create the file manually it gets included. I also can add the dependency on one of my libraries, but I only want to generate this file when package is executed. What am I missing? Thanks, Sasha -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.espak at ucl.ac.uk Thu Feb 19 10:47:20 2015 From: m.espak at ucl.ac.uk (Miklos Espak) Date: Thu, 19 Feb 2015 15:47:20 +0000 Subject: [CMake] EXTERNAL cache entries Message-ID: Hi, in CMakeCache.txt the entries are divided into two sections, external and internal cache entries. What does exactly get into the external section, and when does this section get updated? The CMake cache of my project has some external cache entries that come from an external project. If I update the external project and build it to a different location, the values in the cmake cache (in my project) are not updated, and still contain the old path. (Where the EP was built previously.) Is there a way to regenerate the external entries of the CMake cache somehow? Cheers, Miklos -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.espak at ucl.ac.uk Thu Feb 19 11:31:04 2015 From: m.espak at ucl.ac.uk (Miklos Espak) Date: Thu, 19 Feb 2015 16:31:04 +0000 Subject: [CMake] EXTERNAL cache entries In-Reply-To: References: Message-ID: The workaround I found was to delete the configure time stamp file. It is not very nice, though, so better suggestions are welcome. On 19 February 2015 at 15:47, Miklos Espak wrote: > Hi, > > in CMakeCache.txt the entries are divided into two sections, external and > internal cache entries. > > What does exactly get into the external section, and when does this > section get updated? > > The CMake cache of my project has some external cache entries that come > from an external project. If I update the external project and build it to > a different location, the values in the cmake cache (in my project) are not > updated, and still contain the old path. (Where the EP was built > previously.) > > Is there a way to regenerate the external entries of the CMake cache > somehow? > > Cheers, > Miklos > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From norulez at me.com Thu Feb 19 15:32:04 2015 From: norulez at me.com (NoRulez) Date: Thu, 19 Feb 2015 21:32:04 +0100 Subject: [CMake] CheckIncludeFiles doesn't find header files Message-ID: <8A444BEE-5148-4DEA-8E22-F32776EFC6F2@me.com> Hello, I hope someone could help me please. I've the following situation that when I run CMake from the command line, all is working as expected and CheckIncludeFiles find the header files. However, when I run the configure and build steps from within a CTestScript the CheckIncludeFiles doesn't find anything. It doesn't matter if I set specified CMake variables of not. The strange thing is that when I use the 10.7 sdk than it works in both situations. When I use the 10.5 sdk than it works only if I use CMake on the command line directly. I use CMake 3.0.2 on Mac OS 10.10.1 Did someone have some tips or tricks to get it working. Much thanks in advance Best Regards From jedwards at ucar.edu Thu Feb 19 16:23:09 2015 From: jedwards at ucar.edu (Jim Edwards) Date: Thu, 19 Feb 2015 14:23:09 -0700 Subject: [CMake] cmake link issue Message-ID: The FindHDF5.cmake returns this for HDF5_C_LIBRARIES /soft/libraries/hdf5/1.8.14/cnk-xl/V1R2M2-20150213/lib/libhdf5.a;/soft/libraries/alcf/current/xl/ZLIB/lib/libz.a;/usr/lib64/libdl.so;/usr/lib64/libm.so;/soft/libraries/hdf5/1.8.14/cnk-xl/V1R2M2-20150213/lib/libhdf5_hl.a;/soft/libraries/hdf5/1.8.14/cnk-xl/V1R2M2-20150213/lib/libhdf5.a ?Note that it contains a mixture of static and shared libraries?. Trying to link with this gives a predictable error: ld: attempted static link of dynamic object `/usr/lib64/libdl.so' How do I get cmake to give me a proper list of libs and dependancies for HDF5? -- Jim Edwards CESM Software Engineer National Center for Atmospheric Research Boulder, CO -------------- next part -------------- An HTML attachment was scrubbed... URL: From roolebo at gmail.com Thu Feb 19 21:34:12 2015 From: roolebo at gmail.com (Roman Bolshakov) Date: Fri, 20 Feb 2015 06:34:12 +0400 Subject: [CMake] cmake shared library exported symbols on 64bit AIX XLC compiler In-Reply-To: <54E5B4DD.5020907@dionglobal.de> References: <54E5B4DD.5020907@dionglobal.de> Message-ID: If your project is supposed to be built 64-bit only on 64-bit build host and 32-bit only on 32-bit one, you can just append proper flag into CMAKE_CXX_FLAGS and CMAKE_C_FLAGS depending on the value of CMAKE_SIZEOF_VOID_P ( http://www.cmake.org/cmake/help/v3.0/variable/CMAKE_SIZEOF_VOID_P.html). In the case of multi-lib OS (where you can build both 32-bit and 64-bit app on the same 64-bit build host) you could specify something like -DPLATFORM=32 -DPLATFORM=64 when you invoke CMake. The approach would require you to have two separate build trees though. -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.hufer at dionglobal.de Fri Feb 20 01:59:06 2015 From: michael.hufer at dionglobal.de (Michael Hufer) Date: Fri, 20 Feb 2015 07:59:06 +0100 Subject: [CMake] cmake shared library exported symbols on 64bit AIX XLC compiler In-Reply-To: References: <54E5B4DD.5020907@dionglobal.de> Message-ID: <54E6DB3A.4090207@dionglobal.de> Hi, We already supply the correct CMAKE_C_FLAGS and CMAKE_CXX_FLAGS to the compiler and link flags for 64bit. So the issue is not with the compiler or linker but the "CreateExportList"- tool cmake invokes to generate the list of symbols to be exported by the shared library before linking it. See the attached file for the link.txt, created by cmake for one of our libraries, to see what calls cmake generated to link it. The second step - to link the library - (/usr/vacpp/bin/xlC_r -q64 ...) has the correct flag to generate 64bit output (-q64), but the first step - to generate the exported symbols list -. (/usr/vacpp/bin/CreateExportList ... ) is missing the "-X64" argument it needs to find the symbols for a 64bit build. So the compile and link steps have the correct flags but the tool to create the list of exported symbols for the library has not. The consequence is that the generated library does not export ANY symbol and this of course provokes the missing symbol errors wenn linking against it. A workaround I found is to set the shell environment variable "OBJECT_MODE" to "64" before invoking a (c)make. But I think this should be handled correctly by cmake, as cmake knows whether it creates a 32 or 64 bit library (sizeof(void*)) and can then set the flag for "/usr/vacpp/bin/CreateExportList" correctly. Regards, Michael. On 02/20/2015 03:34 AM, Roman Bolshakov wrote: > If your project is supposed to be built 64-bit only on 64-bit build > host and 32-bit only on 32-bit one, you can just append proper flag > into CMAKE_CXX_FLAGS and CMAKE_C_FLAGS depending on the value of > CMAKE_SIZEOF_VOID_P > (http://www.cmake.org/cmake/help/v3.0/variable/CMAKE_SIZEOF_VOID_P.html). > > In the case of multi-lib OS (where you can build both 32-bit and > 64-bit app on the same 64-bit build host) you could specify something > like -DPLATFORM=32 -DPLATFORM=64 when you invoke CMake. The approach > would require you to have two separate build trees though. -- Michael Hufer Senior Software Developer ------------------------------- Dion Global Solutions GmbH Mainzer Landstr. 199 I 60322 Frankfurt am Main I Germany phone: +49 69 50952 241 email:michael.hufer at dionglobal.com | web: www.dionglobal.com/de HRB-Nr./Commercial Register No. 83397 Gesch?ftsf?hrer / Managing Directors: Ralph James Horne, Joseph Nash -------------- next part -------------- /usr/vacpp/bin/CreateExportList CMakeFiles/xmq_s.dir/objects.exp CMakeFiles/xmq_s.dir/Xmq.cpp.o CMakeFiles/xmq_s.dir/XmqMsgDump.cpp.o CMakeFiles/xmq_s.dir/xmq_s_version.cpp.o /usr/vacpp/bin/xlC_r -q64 -qthreaded -qalias=noansi -qhalt=e -qtwolink -qrtti=all -qinlglue -qnotemplateregistry -qnotempinc -qlanglvl=newexcp -g -L/home/xgbuild/xgen-trunk/lib/AIX_p64 -L/home/xgbuild/xgen-trunk/external/AIX_p64/libs/mqs-6.0/lib -qexpfile=export.symbols -q64 -bh:5 -lc -lm -G -Wl,-bnoipath -Wl,-bE:CMakeFiles/xmq_s.dir/objects.exp -o libxmq_s.so CMakeFiles/xmq_s.dir/Xmq.cpp.o CMakeFiles/xmq_s.dir/XmqMsgDump.cpp.o CMakeFiles/xmq_s.dir/xmq_s_version.cpp.o -L/home/xgbuild/xgen-trunk/lib/AIX_p64 ../libxgencore/libxgencore.so -lmqm_r -lmqmxa64_r -lACE -lexpat -lpcre -Wl,-blibpath:/home/xgbuild/xgen-trunk/build/pitbull/src/libxgencore:/home/xgbuild/xgen-trunk/lib/AIX_p64:/usr/lib:/lib From gonzalobg88 at gmail.com Fri Feb 20 10:45:24 2015 From: gonzalobg88 at gmail.com (Gonzalo BG) Date: Fri, 20 Feb 2015 16:45:24 +0100 Subject: [CMake] Lower the barrier of entry to the wiki In-Reply-To: References: Message-ID: This is what happened: - I couldn't just edit the wiki, I had to make an account. - For making an account I had to fill up a 50 words bio . - I had to retype the captcha 5 times because I wasn't sure if I arrived at the 50 words or not. - Then I have to confirm the email address. - My account is now waiting for review. - I complained about this being insane to the mailing list but got an error that you had to register in order to post messages, so this is my second complain. I think that having a wiki with such a high barrier of entry is pointless. By the time my account gets reviewed it is going to be a miracle if I actually get to contribute those recipes. I think that there is just no excuse for this. Bests, Gonzalo BG -------------- next part -------------- An HTML attachment was scrubbed... URL: From DLRdave at aol.com Fri Feb 20 11:07:35 2015 From: DLRdave at aol.com (David Cole) Date: Fri, 20 Feb 2015 11:07:35 -0500 Subject: [CMake] Lower the barrier of entry to the wiki In-Reply-To: References: Message-ID: Well, sorry you found it tedious to go through those steps, but please consider the flip side of the coin, too: The wiki has actually been defaced/attacked by spammers in the past, who have done some pretty silly things just to get the links to their trash "out there"... So, the "barriers" to entry are to prevent spammers from making the people hosting the wiki have to waste a bunch of their time when that happens. There have to be some barriers, or it's too easy for spammers to spam. Hope you still find the time and inspiration to contribute to the wiki once you're all registered and approved.... Cheers, David C. On Fri, Feb 20, 2015 at 10:45 AM, Gonzalo BG wrote: > This is what happened: > > - I couldn't just edit the wiki, I had to make an account. > - For making an account I had to fill up a 50 words bio . > - I had to retype the captcha 5 times because I wasn't sure if I arrived at > the 50 words or not. > - Then I have to confirm the email address. > - My account is now waiting for review. > - I complained about this being insane to the mailing list but got an error > that you had to register in order to post messages, so this is my second > complain. > > I think that having a wiki with such a high barrier of entry is pointless. > By the time my account gets reviewed it is going to be a miracle if I > actually get to contribute those recipes. > > I think that there is just no excuse for this. > > Bests, > Gonzalo BG > > -- > > 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 danst.18 at gmail.com Fri Feb 20 11:31:15 2015 From: danst.18 at gmail.com (=?UTF-8?B?RGFuaWVsIFPDoWV6?=) Date: Fri, 20 Feb 2015 16:31:15 +0000 Subject: [CMake] Cmake error when adding Boost library Message-ID: Hello, I am trying to add Boost library to my project using the CMakeLists.txt in the follwing way: set(BOOST_INCLUDEDIR "C:/boost_1_57_0")set(BOOST_LIBRARYDIR "C:/boost_1_57_0/stage/lib") find_package(Boost 1.57.0 COMPONENTS filesystem) include_directories(${Boost_INCLUDE_DIRS}) add_executable(test test.cpp) target_link_libraries(test ${Boost_LIBRARIES}) However, I get the followng error: LINK : fatal error LNK1104: cannot open file 'libboost_filesystem-vc120-mt-1_57.lib' libboost_filesystem-vc120-mt-1_57.lib is located in the stage/lib folder, so I don't know what is going on. I am compiling with Visual Studio 2013. Any thoughts? Thank you, Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: From parag at ionicsecurity.com Fri Feb 20 12:20:02 2015 From: parag at ionicsecurity.com (Parag Chandra) Date: Fri, 20 Feb 2015 17:20:02 +0000 Subject: [CMake] Cmake error when adding Boost library In-Reply-To: References: Message-ID: Hi Daniel, I had some trouble with this myself a while back. You may want to refer to the Boost module documentation for some help: http://www.cmake.org/cmake/help/v3.1/module/FindBoost.html There are some additional flags you can set which will help CMake locate Boost for you; I'm sorry I don't remember exactly which ones I set to locate it on Windows. In the end though, I needed to locate boost for many operating systems, so I compiled boost with system layout into individual configuration/architecture/operating system subdirectories, and then using the generic 'find_library' command. 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 S?ez > Date: Friday, February 20, 2015 at 11:31 AM To: "cmake at cmake.org" > Subject: [CMake] Cmake error when adding Boost library Hello, I am trying to add Boost library to my project using the CMakeLists.txt in the follwing way: set(BOOST_INCLUDEDIR "C:/boost_1_57_0")set(BOOST_LIBRARYDIR "C:/boost_1_57_0/stage/lib") find_package(Boost 1.57.0 COMPONENTS filesystem) include_directories(${Boost_INCLUDE_DIRS}) add_executable(test test.cpp) target_link_libraries(test ${Boost_LIBRARIES}) However, I get the followng error: LINK : fatal error LNK1104: cannot open file 'libboost_filesystem-vc120-mt-1_57.lib' libboost_filesystem-vc120-mt-1_57.lib is located in the stage/lib folder, so I don't know what is going on. I am compiling with Visual Studio 2013. Any thoughts? Thank you, Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: From danst.18 at gmail.com Fri Feb 20 13:19:01 2015 From: danst.18 at gmail.com (=?UTF-8?B?RGFuaWVsIFPDoWV6?=) Date: Fri, 20 Feb 2015 18:19:01 +0000 Subject: [CMake] Cmake error when adding Boost library In-Reply-To: References: Message-ID: Thank you Parag. I realized that I was missing the following: set(Boost_USE_STATIC_LIBS True) And also I needed to set BOOST_ROOT instead of BOOST_INCLUDEDIR. Regards, Daniel 2015-02-20 17:20 GMT+00:00 Parag Chandra : > Hi Daniel, > > I had some trouble with this myself a while back. You may want to refer > to the Boost module documentation for some help: > > http://www.cmake.org/cmake/help/v3.1/module/FindBoost.html > > There are some additional flags you can set which will help CMake locate > Boost for you; I?m sorry I don?t remember exactly which ones I set to > locate it on Windows. In the end though, I needed to locate boost for many > operating systems, so I compiled boost with system layout into individual > configuration/architecture/operating system subdirectories, and then using > the generic ?find_library? command. > > > > *Parag Chandra *Software Engineer, Mobile Team > Mobile: +1.919.824.1410 > > > > Ionic Security Inc. > 1170 Peachtree St. NE STE 400, Atlanta, GA 30309 > > > > > > > > > From: Daniel S?ez > Date: Friday, February 20, 2015 at 11:31 AM > To: "cmake at cmake.org" > Subject: [CMake] Cmake error when adding Boost library > > Hello, > > I am trying to add Boost library to my project using the CMakeLists.txt in > the follwing way: > > set(BOOST_INCLUDEDIR "C:/boost_1_57_0")set(BOOST_LIBRARYDIR "C:/boost_1_57_0/stage/lib") > > find_package(Boost 1.57.0 COMPONENTS filesystem) > include_directories(${Boost_INCLUDE_DIRS}) > add_executable(test test.cpp) > target_link_libraries(test ${Boost_LIBRARIES}) > > However, I get the followng error: LINK : fatal error LNK1104: cannot > open file 'libboost_filesystem-vc120-mt-1_57.lib' > > libboost_filesystem-vc120-mt-1_57.lib is located in the stage/lib folder, > so I don't know what is going on. I am compiling with Visual Studio 2013. > > Any thoughts? > > Thank you, > > Daniel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at markwalling.org Fri Feb 20 16:20:11 2015 From: mark at markwalling.org (Mark Walling) Date: Fri, 20 Feb 2015 16:20:11 -0500 Subject: [CMake] Altering the Librarian command line in a VS 2008 C project Message-ID: <1424467211.630021.230324857.2F49E780@webmail.messagingengine.com> Hi, I am trying to disable the warnings coming from an external dependency we're referencing in our project. One of the warnings requires specifying "/ignore:4221" in the Project Properties -> Librarian -> Command Line in order to suppress it. I can't for the life of me figure out how to pass that flag in though, since using SET_TARGET_PROPERTIES (${HDF5_LIB_TARGET} PROPERTIES LINK_FLAGS "/ignore:4221") doesn't seem to set it. If I try to pass it via COMPILE_FLAGS on the same target, I get a warning from cl that it is ignoring an unknown option. Hints welcome. Thanks, Mark From steveire at gmail.com Sat Feb 21 04:26:32 2015 From: steveire at gmail.com (Stephen Kelly) Date: Sat, 21 Feb 2015 10:26:32 +0100 Subject: [CMake] add_dependencies: Disallow use with INTERFACE_LIBRARY. WHY?!? References: Message-ID: Andrey Pokrovskiy wrote: > Hi, > > Current CMake disallows Interface Libraries to have dependencies. I filed http://public.kitware.com/Bug/view.php?id=15414 Thanks, Steve. From steveire at gmail.com Sat Feb 21 04:30:21 2015 From: steveire at gmail.com (Stephen Kelly) Date: Sat, 21 Feb 2015 10:30:21 +0100 Subject: [CMake] Minor documentation mistake References: Message-ID: Cutberto Escamilla wrote: > Hello, > I tried searching the different archives, but there is no mention about > this. Was wondering if I should submit a bug. Thanks for the note. I've pushed a fix here: http://www.cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f93438cd Fix typo, graphiz -> graphviz. Thanks, Steve. From steveire at gmail.com Sat Feb 21 04:39:06 2015 From: steveire at gmail.com (Stephen Kelly) Date: Sat, 21 Feb 2015 10:39:06 +0100 Subject: [CMake] Lower the barrier of entry to the wiki References: Message-ID: Gonzalo BG wrote: > This is what happened: > - For making an account I had to fill up a 50 words bio . Years ago this prevented me from creating a wiki account. I put 'this page intentionally left blank' in this field because I thought I shouldn't have to fill a bio to edit a wiki (like you presumably). My account request was rejected, so I used the kde wiki instead :). https://community.kde.org/Frameworks/Epics/CMake_target_usage_requirements > I think that having a wiki with such a high barrier of entry is pointless. > By the time my account gets reviewed it is going to be a miracle if I > actually get to contribute those recipes. What do you want to edit? Would it be better to improve the CMake documentation instead? http://www.cmake.org/cmake/help/v3.1/ Thanks, Steve. From steveire at gmail.com Sat Feb 21 04:43:24 2015 From: steveire at gmail.com (Stephen Kelly) Date: Sat, 21 Feb 2015 10:43:24 +0100 Subject: [CMake] Problem with CMAKE_AUTOMOC files not being regenerated or cleaned References: <1904FC664D89404E819BA41903ECB2DD097857A0@SMITELMX02.SMINET.DE> Message-ID: Ren? Tschirley wrote: > Simplified > the problem and verified if the set_directory_properties trick works. It > does not work for me. > > Used software: Windows7 SP1, CMake 3.1.2, Ninja 1.5.3. > Am I forgetting something obvious? Is this an unfixed CMake bug? Yes, it is: http://public.kitware.com/Bug/view.php?id=13371 Thanks, Steve. From steveire at gmail.com Sat Feb 21 04:53:33 2015 From: steveire at gmail.com (Stephen Kelly) Date: Sat, 21 Feb 2015 10:53:33 +0100 Subject: [CMake] Mixed linking References: Message-ID: Ghyslain Leclerc wrote: > Thanks for all the insight. I have been looking at this and quite a few > posts (mostly from you !) to try and understand. I think I get most of > it. > > That being said, I finally got a static executable for my application on > my mac. What I did is build my application using qmake, get the linker > command and manually find every library using cmake in order to recreate > the linker command from qmake (I don?t think it makes a difference, but > I?m not sure so I even kept the library order the same). Yes, I think it makes a difference. It also makes a difference whether find_library finds the exact same binary which Qt statically links or not. The inability to determine which static library (by exact path) is linked by the Qt libraries is the reason the Qt5 CMake files don't list the static libraries in their INTERFACE_LINK_LIBRARIES. Your find_library calls are not a fully generic solution because find_library might find a different binary to what Qt is linked to. > This seems like a lot of work to get what I want? But if it does the job. > The fun part will be to see what I need on Windows and then put > conditionals around that and all. > > If I misunderstood something and there is an easier way to get a static > executable from using static qt from CMake, please let me know. What I referred to with INTERFACE_SOURCES was just about automatically linking in the platform plugin in a static build. That is provided by Qt, so ew know the full path, but we need to generate a file which you compile into the executable so that your executable uses a symbol from it. Otherwise the linker discards it. So my message was just saying that that part can be made simpler. Thanks, Steve. From steveire at gmail.com Sat Feb 21 04:59:47 2015 From: steveire at gmail.com (Stephen Kelly) Date: Sat, 21 Feb 2015 10:59:47 +0100 Subject: [CMake] Mixed linking References: Message-ID: Ray Donnelly wrote: >> > >> > 1) Am I right when I say CMake, Qt and static linking don?t mix ? >> >> They should mix fine. What I meant when I wrote this was 'they should mix fine, but some convenience is not available - you need to specify the correct link flags yourself'. That is, it's 'fine' in the same way that other static libraries which don't provide any cmake files at all are 'fine' and leave everything to you. Thanks, Steve. From mingw.android at gmail.com Sat Feb 21 10:28:31 2015 From: mingw.android at gmail.com (Ray Donnelly) Date: Sat, 21 Feb 2015 15:28:31 +0000 Subject: [CMake] Mixed linking In-Reply-To: References: Message-ID: On Sat, Feb 21, 2015 at 9:59 AM, Stephen Kelly wrote: > Ray Donnelly wrote: > >>> > >>> > 1) Am I right when I say CMake, Qt and static linking don?t mix ? >>> >>> They should mix fine. > > What I meant when I wrote this was 'they should mix fine, but some > convenience is not available - you need to specify the correct link flags > yourself'. > > That is, it's 'fine' in the same way that other static libraries which don't > provide any cmake files at all are 'fine' and leave everything to you. > Right, thanks Steve. When/if I get time, I might try to make some new patches for this for Qt5 and CMake that aren't reliant on MSYS2's many Qt5 patches and test them on OS X and GNU/Linux. > 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 From norulez at me.com Sat Feb 21 14:18:01 2015 From: norulez at me.com (=?iso-8859-1?Q?Roman_W=FCger?=) Date: Sat, 21 Feb 2015 20:18:01 +0100 Subject: [CMake] CheckIncludeFiles doesn't find header files In-Reply-To: <8A444BEE-5148-4DEA-8E22-F32776EFC6F2@me.com> References: <8A444BEE-5148-4DEA-8E22-F32776EFC6F2@me.com> Message-ID: <014701d04e0b$1dac9200$5905b600$@me.com> Hi, I think I found additional strange behaviors. Here are some informations from my systems, the strange behavior is on both systems: System A: Mac OS 10.10.1 CMake 3.0.2 Qt 4.8.4 Bullseye Coverage 8.9.41 System B: Mac OS 10.6.8 CMake 3.0.2 Qt 4.8.4 Bullseye Coverage 8.9.41 First i thought that the problem is bullseye, but after I removed it, the behavior was the same. Sometimes the build went ok, but mostly not. The strange thing ist hat when i run it a second time for example than Qt also wouldn?t be found or half not found, see below. Here is the output from System A when all is went ok: -- 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: /opt/bullseye/bin/cc -- Check for working C compiler: /opt/bullseye/bin/cc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /opt/bullseye/bin/c++ -- Check for working CXX compiler: /opt/bullseye/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Mediamid logging mechanism: log4cplus -- AppKit framework found ("/Developer/SDKs/MacOSX10.5.sdk/System/Library/Frameworks/AppKit.framework" ) -- Carbon framework found ("/Developer/SDKs/MacOSX10.5.sdk/System/Library/Frameworks/Carbon.framework" ) -- Cocoa framework found ("/Developer/SDKs/MacOSX10.5.sdk/System/Library/Frameworks/Cocoa.framework") -- Looking for Q_WS_X11 sh: ps: command not found sh: ps: command not found -- Looking for Q_WS_X11 - not found -- Looking for Q_WS_WIN sh: ps: command not found sh: ps: command not found -- Looking for Q_WS_WIN - not found -- Looking for Q_WS_QWS sh: ps: command not found sh: ps: command not found -- Looking for Q_WS_QWS - not found -- Looking for Q_WS_MAC sh: ps: command not found sh: ps: command not found -- Looking for Q_WS_MAC - found -- Looking for QT_MAC_USE_COCOA sh: ps: command not found sh: ps: command not found -- Looking for QT_MAC_USE_COCOA - found -- Found Qt4: /Users/nbuild/workspace/MyProject/source/externals/qt-mac/bin/qmake (found version "4.8.4") -- Boost version: 1.55.0 -- Found the following Boost libraries: -- chrono -- date_time -- filesystem -- regex -- locale -- system -- thread -- unit_test_framework -- Found Boost: /Users/nbuild/workspace/MyProject/source/externals/boost -- Include directory: /Users/nbuild/workspace/MyProject/source/externals/boost/include -- Library directory: /Users/nbuild/workspace/MyProject/source/externals/boost/lib_macosx_cs6 -- Found OpenSSL: /Developer/SDKs/MacOSX10.5.sdk/usr/lib/libssl.dylib;/Developer/SDKs/MacOSX10 .5.sdk/usr/lib/libcrypto.dylib (found version "0.9.8z") -- Found LibXml2: /Developer/SDKs/MacOSX10.5.sdk/usr/lib/libxml2.dylib (found version "2.6.16") -- Could NOT find Doxygen (missing: DOXYGEN_EXECUTABLE) -- Found Git: /usr/bin/git (found version "1.9.3 (Apple Git-50)") Current revision is 2.1.1.3 -- InDesignModelAndUI framework found ("/Users/nbuild/workspace/MyProject/source/externals/sdk/InDesign/mac/cs6/bu ild/mac/release/packagefolder/contents/macos/InDesignModelAndUI.framework") -- Generating build for Log4cplus version 1.2.0 -- Looking for include file pthread.h sh: ps: command not found sh: ps: command not found -- Looking for include file pthread.h - found -- Looking for pthread_create sh: ps: command not found sh: ps: command not found -- Looking for pthread_create - found -- Found Threads: TRUE -- Threads: -- Looking for include file dlfcn.h sh: ps: command not found sh: ps: command not found -- Looking for include file dlfcn.h - found -- Looking for include file errno.h sh: ps: command not found sh: ps: command not found -- Looking for include file errno.h ? found . . . And here is the output when the failure occur: -- 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: /opt/bullseye/bin/cc -- Check for working C compiler: /opt/bullseye/bin/cc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /opt/bullseye/bin/c++ -- Check for working CXX compiler: /opt/bullseye/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Mediamid logging mechanism: log4cplus -- AppKit framework found ("/Developer/SDKs/MacOSX10.5.sdk/System/Library/Frameworks/AppKit.framework" ) -- Carbon framework found ("/Developer/SDKs/MacOSX10.5.sdk/System/Library/Frameworks/Carbon.framework" ) -- Cocoa framework found ("/Developer/SDKs/MacOSX10.5.sdk/System/Library/Frameworks/Cocoa.framework") -- Looking for Q_WS_X11 sh: ps: command not found sh: ps: command not found -- Looking for Q_WS_X11 - not found -- Looking for Q_WS_WIN sh: ps: command not found sh: ps: command not found -- Looking for Q_WS_WIN - not found -- Looking for Q_WS_QWS sh: ps: command not found sh: ps: command not found -- Looking for Q_WS_QWS - not found -- Looking for Q_WS_MAC sh: ps: command not found sh: ps: command not found -- Looking for Q_WS_MAC - not found -- Found Qt4: /Users/nbuild/workspace/MyProject/source/externals/qt-mac/bin/qmake (found version "4.8.4") -- Boost version: 1.55.0 -- Found the following Boost libraries: -- chrono -- date_time -- filesystem -- regex -- locale -- system -- thread -- unit_test_framework -- Found Boost: /Users/nbuild/workspace/MyProject/source/externals/boost -- Include directory: /Users/nbuild/workspace/MyProject/source/externals/boost/include -- Library directory: /Users/nbuild/workspace/MyProject/source/externals/boost/lib_macosx_cs6 -- Found OpenSSL: /Developer/SDKs/MacOSX10.5.sdk/usr/lib/libssl.dylib;/Developer/SDKs/MacOSX10 .5.sdk/usr/lib/libcrypto.dylib (found version "0.9.8z") -- Found LibXml2: /Developer/SDKs/MacOSX10.5.sdk/usr/lib/libxml2.dylib (found version "2.6.16") -- Could NOT find Doxygen (missing: DOXYGEN_EXECUTABLE) -- Found Git: /usr/bin/git (found version "1.9.3 (Apple Git-50)") -- InDesignModelAndUI framework found ("/Users/nbuild/workspace/MyProject/source/externals/sdk/InDesign/mac/cs6/bu ild/mac/release/packagefolder/contents/macos/InDesignModelAndUI.framework") -- Generating build for Log4cplus version 1.2.0 -- Looking for include file pthread.h sh: ps: command not found sh: ps: command not found -- Looking for include file pthread.h - not found -- Could NOT find Threads (missing: Threads_FOUND) -- Threads: -- Looking for include file dlfcn.h sh: ps: command not found sh: ps: command not found -- Looking for include file dlfcn.h - not found -- Looking for include file errno.h sh: ps: command not found sh: ps: command not found -- Looking for include file errno.h - not found . . . Could someone please help me to find the misbehavior/bug/ whatever? Thanks in advance -----Urspr?ngliche Nachricht----- Von: CMake [mailto:cmake-bounces at cmake.org] Im Auftrag von NoRulez Gesendet: Donnerstag, 19. Februar 2015 21:32 An: CMake MailingList Betreff: [CMake] CheckIncludeFiles doesn't find header files Hello, I hope someone could help me please. I've the following situation that when I run CMake from the command line, all is working as expected and CheckIncludeFiles find the header files. However, when I run the configure and build steps from within a CTestScript the CheckIncludeFiles doesn't find anything. It doesn't matter if I set specified CMake variables of not. The strange thing is that when I use the 10.7 sdk than it works in both situations. When I use the 10.5 sdk than it works only if I use CMake on the command line directly. I use CMake 3.0.2 on Mac OS 10.10.1 Did someone have some tips or tricks to get it working. Much thanks in advance 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From llvm.999 at outlook.com Sat Feb 21 15:55:01 2015 From: llvm.999 at outlook.com (llvm 999) Date: Sat, 21 Feb 2015 12:55:01 -0800 Subject: [CMake] How to disable specific warnings in VS IDE Message-ID: Hi, I am using cmake to generate build file for a MS Visual Studio project/solution. I would like to get some help in specifying a list of (VC++) compiler's warnings so that the generated project file will have the list of warnings in the "Disable Specific Warnings" field in the project file. I have tried for quite a while to figure this out but have no success. Any help/hint will be very much appreciated. -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.enright at gmail.com Sat Feb 21 16:09:23 2015 From: michael.enright at gmail.com (Michael Enright) Date: Sat, 21 Feb 2015 13:09:23 -0800 Subject: [CMake] Lower the barrier of entry to the wiki In-Reply-To: References: Message-ID: As I write this in 2015, I believe it is possible to ask questions on Stack Exchange, and answer them yourself. Your answers will be fairly visible to the search engines, so the World will benefit, and Stack Exchange doesn't mind self-answered questions, as long as the question itself fits what the moderators there think of as a good question. You can "accept" your own answer but you can't upvote it. You have to create an account to be able to ask a question, but they use OpenID so it can be an existing OpenID-based account like Facebook. On Sat, Feb 21, 2015 at 1:39 AM, Stephen Kelly wrote: > Gonzalo BG wrote: > > > This is what happened: > > > - For making an account I had to fill up a 50 words bio . > > Years ago this prevented me from creating a wiki account. I put 'this page > intentionally left blank' in this field because I thought I shouldn't have > to fill a bio to edit a wiki (like you presumably). My account request was > rejected, so I used the kde wiki instead :). > > > https://community.kde.org/Frameworks/Epics/CMake_target_usage_requirements > > > I think that having a wiki with such a high barrier of entry is > pointless. > > By the time my account gets reviewed it is going to be a miracle if I > > actually get to contribute those recipes. > > What do you want to edit? Would it be better to improve the CMake > documentation instead? > > http://www.cmake.org/cmake/help/v3.1/ > > 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 petr.kmoch at gmail.com Mon Feb 23 02:25:25 2015 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Mon, 23 Feb 2015 08:25:25 +0100 Subject: [CMake] How to disable specific warnings in VS IDE In-Reply-To: References: Message-ID: Hi, Simply pass the appropriate compiler flags to the compiler. The flag in question is /wd1234 To disable warning C1234 (more info on MSDN: https://msdn.microsoft.com/en-us/library/thxezb7y%28v=vs.120%29.aspx ) How you pass them to the compiler depends on what you normally use. The options are: Variable CMAKE_CXX_FLAGS Per-configuration variables CMAKE_CXX_FLAGS_CONFIGNAME Target or source property COMPILE_FLAGS (space-separated) Directory or target property COMPILE_OPTIONS (normal list, supports generator expressions) Hope this helps. Petr On Sat, Feb 21, 2015 at 9:55 PM, llvm 999 wrote: > Hi, I am using cmake to generate build file for a MS Visual Studio > project/solution. > > I would like to get some help in specifying a list of (VC++) compiler's > warnings so that the generated project file will have the list of warnings > in the "Disable Specific Warnings" field in the project file. > > I have tried for quite a while to figure this out but have no success. > > Any help/hint will be very much appreciated. > > -- > > 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 mathieu.malaterre at gmail.com Mon Feb 23 07:37:24 2015 From: mathieu.malaterre at gmail.com (Mathieu Malaterre) Date: Mon, 23 Feb 2015 13:37:24 +0100 Subject: [CMake] Make add_custom_target depends on cmake macro/function Message-ID: Hi there, I am trying to setup a rule which always execute, however it needs to depends on a cmake macro. Here is an equivalent code: [...] cmake_minimum_required(VERSION 3.0) string(TIMESTAMP curdate UTC) add_custom_target( dummy ALL COMMAND echo "${curdate}" ) [...] Is there any simple way to have the `dummy` rule re-execute the above cmake TIMESTAMP macro ? Thanks much, -- Mathieu From mathieu.malaterre at gmail.com Mon Feb 23 07:46:45 2015 From: mathieu.malaterre at gmail.com (Mathieu Malaterre) Date: Mon, 23 Feb 2015 13:46:45 +0100 Subject: [CMake] Make add_custom_target depends on cmake macro/function In-Reply-To: References: Message-ID: On Mon, Feb 23, 2015 at 1:37 PM, Mathieu Malaterre wrote: > Hi there, > > I am trying to setup a rule which always execute, however it needs to > depends on a cmake macro. Here is an equivalent code: > > [...] > cmake_minimum_required(VERSION 3.0) > string(TIMESTAMP curdate UTC) > add_custom_target( > dummy ALL > COMMAND echo "${curdate}" > ) > [...] > > Is there any simple way to have the `dummy` rule re-execute the above > cmake TIMESTAMP macro ? Nevermind, that was easy: cmake_minimum_required(VERSION 3.0) file(WRITE ${CMAKE_CURRENT_BINARY_DIR}/dummy.cmake "string(TIMESTAMP curdate UTC) execute_process(COMMAND echo \"\${curdate}\")" ) add_custom_target( dummy ALL COMMAND cmake -P ${CMAKE_CURRENT_BINARY_DIR}/dummy.cmake ) Sorry for the noise, -- Mathieu From petr.kmoch at gmail.com Mon Feb 23 07:52:33 2015 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Mon, 23 Feb 2015 13:52:33 +0100 Subject: [CMake] Make add_custom_target depends on cmake macro/function In-Reply-To: References: Message-ID: You could have the custom target execute CMake in script mode: add_custom_target( dummy ALL COMMAND ${CMAKE_COMMAND} -P timescript.cmake ) The file timescript.cmake could look like this: string(TIMESTAMP curdate UTC) message("${curdate}") Feel free to play around with stdout/stderr distinction etc. You could also generate the script from the master CMake file using file(WRITE) instead of storing it as a stand-alone file. Petr On Mon, Feb 23, 2015 at 1:37 PM, Mathieu Malaterre < mathieu.malaterre at gmail.com> wrote: > Hi there, > > I am trying to setup a rule which always execute, however it needs to > depends on a cmake macro. Here is an equivalent code: > > [...] > cmake_minimum_required(VERSION 3.0) > string(TIMESTAMP curdate UTC) > add_custom_target( > dummy ALL > COMMAND echo "${curdate}" > ) > [...] > > Is there any simple way to have the `dummy` rule re-execute the above > cmake TIMESTAMP macro ? > > Thanks much, > -- > Mathieu > -- > > 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 mdietze at gmail.com Mon Feb 23 12:38:09 2015 From: mdietze at gmail.com (Martin Dietze) Date: Mon, 23 Feb 2015 18:38:09 +0100 Subject: [CMake] Eclipse CDT project for VC++ toolchain - debug information? Message-ID: I need to maintain a multi platform project. The Windows version requires the Visual C++ tools. I would however like to use Eclipse. Now I have succeeded doing the basic setup, and I can build inside Eclipse. Only I never get debug information generated. The commadn line I use is this: cmake -G "Eclipse CDT4 - NMake Makefiles" -D CMAKE_BUILD_TYPE=Debug -D CMAKE_ECLIPSE_VERSION=4.3 . When I look into the files cmake generates I find that the calls to cl.exe do not contain the necessary switches. Is this a bug, or do I miss some necessary information? Cheers, Martin -- ---------- MDietze at gmail.com --/-- martin at the-little-red-haired-girl.org ---- ------------- / http://herbert.the-little-red-haired-girl.org / ------------- From roolebo at gmail.com Tue Feb 24 00:57:10 2015 From: roolebo at gmail.com (Roman Bolshakov) Date: Tue, 24 Feb 2015 09:57:10 +0400 Subject: [CMake] cmake shared library exported symbols on 64bit AIX XLC compiler In-Reply-To: <54E6DB3A.4090207@dionglobal.de> References: <54E5B4DD.5020907@dionglobal.de> <54E6DB3A.4090207@dionglobal.de> Message-ID: Hi Michael, Gotcha, thanks for explanation. Right, there should be a way to pass -X32/-X64 for CreateExportList right prior to /objects.exp. Current definition in Modules/Compiler/XL.cmake doesn't have a spot for that: set(CMAKE_${lang}_CREATE_SHARED_LIBRARY "${CMAKE_XL_CreateExportList} /objects.exp " -Wl,-bE:/objects.exp -o " ) I think it's worth a bug report/contribution. Not sure if it'd work but if you might try to modify your local installation of CMake and add something like right after ${CMAKE_XL_CreateExportList} in XL.cmake and then add -X32/-X64 into CMAKE_XL_CreateExportLists_FLAGS in your CMakeLists.txt Roman From zjfroot at gmail.com Tue Feb 24 03:40:45 2015 From: zjfroot at gmail.com (Jifeng ZHANG) Date: Tue, 24 Feb 2015 09:40:45 +0100 Subject: [CMake] CMP0026 - Disallow use of the LOCATION target property In-Reply-To: <1D9B19F0-F52E-42E5-8666-5728ABDFB579@me.com> References: <1D9B19F0-F52E-42E5-8666-5728ABDFB579@me.com> Message-ID: Thank you Steve and NoRulez. We actually make some manipulations on the string (TEST_PATH) that returned from get_target_property, before we pass it to add_test. So if we directly pass the generator expression, it won't work. We need to change this part obviously. Any idea when CMake 4.0 is planned to release? So we can get a general idea when the old behavior will stop working. Regards, Jifeng From michael.hufer at dionglobal.de Tue Feb 24 03:49:49 2015 From: michael.hufer at dionglobal.de (Michael Hufer) Date: Tue, 24 Feb 2015 09:49:49 +0100 Subject: [CMake] cmake shared library exported symbols on 64bit AIX XLC compiler In-Reply-To: References: <54E5B4DD.5020907@dionglobal.de> <54E6DB3A.4090207@dionglobal.de> Message-ID: <54EC3B2D.9050906@dionglobal.de> Hi Roman, you approach (" right after ${CMAKE_XL_CreateExportList} in XL.cmake and then add -X32/-X64 into CMAKE_XL_CreateExportList_FLAGS in your CMakeLists.txt") did not work. It generated the attached link.txt, where it did not replace with "-X64" (I set it with "set( CMAKE_XL_CreateExportList_FLAGS -X64 )" in the CMakeLists.txt). Furthermore, I think the whole handling of 64bit builds on AIX is broken in cmake. Other tools dealing with object files like ar, nm, and ranlib also need a "-X64" flag when dealing with 64bit object files. cmake does not set them itself when CMAKE_SIZEOF_VOID_P indicates a 64bit build and also does not have CMAKE_${tool}_FLAGS variables to be able to set these flags manually in a CMakeLists.txt. Regards, Michael. On 02/24/2015 06:57 AM, Roman Bolshakov wrote: > Hi Michael, > > Gotcha, thanks for explanation. Right, there should be a way to pass > -X32/-X64 for CreateExportList right prior to > /objects.exp. Current definition in > Modules/Compiler/XL.cmake doesn't have a spot for that: > set(CMAKE_${lang}_CREATE_SHARED_LIBRARY > "${CMAKE_XL_CreateExportList} /objects.exp > " > > > -Wl,-bE:/objects.exp -o > " > ) > > I think it's worth a bug report/contribution. Not sure if it'd work > but if you might try to modify your local installation of CMake and > add something like right after > ${CMAKE_XL_CreateExportList} in XL.cmake and then add -X32/-X64 into > CMAKE_XL_CreateExportLists_FLAGS in your CMakeLists.txt > > Roman -- Michael Hufer Senior Software Developer ------------------------------- Dion Global Solutions GmbH Mainzer Landstr. 199 I 60322 Frankfurt am Main I Germany phone: +49 69 50952 241 email:michael.hufer at dionglobal.com | web: www.dionglobal.com/de HRB-Nr./Commercial Register No. 83397 Gesch?ftsf?hrer / Managing Directors: Ralph James Horne, Joseph Nash -------------- next part -------------- /usr/vacpp/bin/CreateExportList CMAKE_XL_CreateExportList_FLAGS CMakeFiles/xmq_s.dir/objects.exp CMakeFiles/xmq_s.dir/Xmq.cpp.o CMakeFiles/xmq_s.dir/XmqMsgDump.cpp.o CMakeFiles/xmq_s.dir/xmq_s_version.cpp.o /usr/vacpp/bin/xlC_r -q64 -qthreaded -qalias=noansi -qhalt=e -qtwolink -qrtti=all -qinlglue -qnotemplateregistry -qnotempinc -qlanglvl=newexcp -g -L/home/xgbuild/xgen-trunk/lib/AIX_p64 -L/home/xgbuild/xgen-trunk/external/AIX_p64/libs/mqs-6.0/lib -qexpfile=export.symbols -q64 -bh:5 -lc -lm -G -Wl,-bnoipath -Wl,-bE:CMakeFiles/xmq_s.dir/objects.exp -o libxmq_s.so CMakeFiles/xmq_s.dir/Xmq.cpp.o CMakeFiles/xmq_s.dir/XmqMsgDump.cpp.o CMakeFiles/xmq_s.dir/xmq_s_version.cpp.o -L/home/xgbuild/xgen-trunk/lib/AIX_p64 ../libxgencore/libxgencore.so -lmqm_r -lmqmxa64_r -lACE -lexpat -lpcre -Wl,-blibpath:/home/xgbuild/xgen-trunk/build/pitbull/src/libxgencore:/home/xgbuild/xgen-trunk/lib/AIX_p64:/usr/lib:/lib -------------- next part -------------- A non-text attachment was scrubbed... Name: XL.cmake Type: text/x-cmake Size: 2648 bytes Desc: not available URL: From loose at astron.nl Tue Feb 24 06:05:36 2015 From: loose at astron.nl (Marcel Loose) Date: Tue, 24 Feb 2015 12:05:36 +0100 Subject: [CMake] Module CMakeParseArguments: confusing last paragraph in documentation Message-ID: <54EC5B00.8070407@astron.nl> Hi all, Several times I've read the last paragraph of the documentation of module CMakeParseArguments, but I can't get my head around it. Keywords terminate lists of values, e.g. if directly after a one_value_keyword another recognized keyword follows, this is interpreted as the beginning of the new option. E.g. my_install(TARGETS foo DESTINATION OPTIONAL) would result in MY_INSTALL_DESTINATION set to ?OPTIONAL?, but MY_INSTALL_DESTINATION would be empty and MY_INSTALL_OPTIONAL would be set to TRUE therefor. Huh? [...] MY_INSTALL_DESTINATION will be set to "OPTIONAL", but would be empty [...] ??? Reading the first sentence of this paragraph, I concluded that MY_INSTALL_DESTINATION will be empty, not would be. Best regards, Marcel Loose. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: loose.vcf Type: text/x-vcard Size: 292 bytes Desc: not available URL: From petr.kmoch at gmail.com Tue Feb 24 06:31:04 2015 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Tue, 24 Feb 2015 12:31:04 +0100 Subject: [CMake] Module CMakeParseArguments: confusing last paragraph in documentation In-Reply-To: <54EC5B00.8070407@astron.nl> References: <54EC5B00.8070407@astron.nl> Message-ID: My guess is there's a "not" missing between "would" and "result in MY_INSTALL_DESTINATION set to" Petr On Tue, Feb 24, 2015 at 12:05 PM, Marcel Loose wrote: > Hi all, > > Several times I've read the last paragraph of the documentation of module > CMakeParseArguments, but I can't get my head around it. > > Keywords terminate lists of values, e.g. if directly after a > one_value_keyword another recognized keyword follows, this is interpreted > as the beginning of the new option. E.g. my_install(TARGETS foo DESTINATION > OPTIONAL) would result in MY_INSTALL_DESTINATION set to ?OPTIONAL?, but > MY_INSTALL_DESTINATION would be empty and MY_INSTALL_OPTIONAL would be set > to TRUE therefor. > > Huh? [...] MY_INSTALL_DESTINATION will be set to "OPTIONAL", but would be > empty [...] ??? > > Reading the first sentence of this paragraph, I concluded that > MY_INSTALL_DESTINATION will be empty, not would be. > > Best regards, > Marcel Loose. > > > -- > > 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 robert.maynard at kitware.com Tue Feb 24 10:01:52 2015 From: robert.maynard at kitware.com (Robert Maynard) Date: Tue, 24 Feb 2015 10:01:52 -0500 Subject: [CMake] [ANNOUNCE] CMake 3.2.0-rc2 now ready for testing! Message-ID: I am proud to announce the CMake 3.2 second release candidate. Sources and binaries are available at: http://www.cmake.org/download/ http://www.cmake.org/files/v3.2/?C=M;O=D Documentation is available at: http://www.cmake.org/cmake/help/v3.2 Release notes appear below and are also published at http://www.cmake.org/cmake/help/v3.2/release/3.2.html Some of the more significant features of CMake 3.2 are: * CMake learned to support unicode characters *encoded as UTF-8* on Windows. This was already supported on platforms whose system APIs accept UTF-8 encoded strings. Unicode characters may now be used in CMake code, paths to source files, configured files such as ".h.in" files, and other files read and written by CMake. Note that because CMake interoperates with many other tools, there may still be some limitations when using certain unicode characters. * The "Compile Features" functionality is now aware of features supported by more compilers, including: * Apple Clang ("AppleClang") for Xcode versions 4.4 though 6.1. * GNU compiler versions 4.4 through 5.0 on UNIX and Apple ("GNU"). * Microsoft Visual Studio ("MSVC") for versions 2010 through 2015. * Oracle SolarisStudio ("SunPro") version 12.4. * The "add_custom_command()" and "add_custom_target()" commands learned a new "BYPRODUCTS" option to specify files produced as side effects of the custom commands. These are not outputs because they do not always have to be newer than inputs. * The "file(GENERATE)" command can now generate files which are used as source files for buildsystem targets. Generated files automatically get their "GENERATED" property set to "TRUE". Deprecated and Removed Features: * Files written in the "cmake-language(7)", such as "CMakeLists.txt" or "*.cmake" files, are now expected to be encoded as UTF-8. If files are already ASCII, they will be compatible. If files were in a different encoding, including Latin 1, they will need to be converted. * The "FindOpenGL" module no longer explicitly searches for any dependency on X11 libraries with the "FindX11" module. Such dependencies should not need to be explicit. Applications using X11 APIs themselves should find and link to X11 libraries explicitly. CMake 3.2 Release Notes *********************** Changes made since CMake 3.1 include the following. New Features ============ Syntax ------ * CMake learned to support unicode characters *encoded as UTF-8* on Windows. This was already supported on platforms whose system APIs accept UTF-8 encoded strings. Unicode characters may now be used in CMake code, paths to source files, configured files such as ".h.in" files, and other files read and written by CMake. Note that because CMake interoperates with many other tools, there may still be some limitations when using certain unicode characters. Commands -------- * The "add_custom_command()" and "add_custom_target()" commands learned a new "BYPRODUCTS" option to specify files produced as side effects of the custom commands. These are not outputs because they do not always have to be newer than inputs. * The "add_custom_command()" and "add_custom_target()" commands learned a new "USES_TERMINAL" option to request that the command be given direct access to the terminal if possible. The "Ninja" generator will places such commands in the "console" "pool". Build targets provided by CMake that are meant for individual interactive use, such as "install", are now placed in this pool. * A new "continue()" command was added that can be called inside loop contexts to end the current iteration and start the next one at the top of the loop block. * The "file(LOCK)" subcommand was created to allow CMake processes to synchronize through file and directory locks. * The "file(STRINGS)" now supports UTF-16LE, UTF-16BE, UTF-32LE, UTF- 32BE as "ENCODING" options. * The "install(EXPORT)" command now works with an absolute "DESTINATION" even if targets in the export set are installed with a destination or *usage requirements* specified relative to the install prefix. The value of the "CMAKE_INSTALL_PREFIX" variable is hard-coded into the installed export file as the base for relative references. * The "try_compile()" command source file signature now honors link flags (e.g. "CMAKE_EXE_LINKER_FLAGS") in the generated test project. See policy "CMP0056". * The "try_run()" command learned to honor the "LINK_LIBRARIES" option just as "try_compile()" already does. * The "file(GENERATE)" command now generates the output file with the same permissions as the input file if set. * The "file(GENERATE)" command can now generate files which are used as source files for buildsystem targets. Generated files automatically get their "GENERATED" property set to "TRUE". Variables --------- * The "CMAKE_MATCH_COUNT" variable was introduced to record the number of matches made in the last regular expression matched in an "if()" command or a "string()" command. Properties ---------- * An "ANDROID_API_MIN" target property was introduced to specify the minimum version to be targeted by the toolchain. * A "VS_SHADER_FLAGS" source file property was added to specify additional shader flags to ".hlsl" files, for the Visual Studio generators. Modules ------- * The "ExternalData" module learned to support *Custom Fetch Scripts*. This allows projects to specify custom ".cmake" scripts for fetching data objects during the build. * The "ExternalProject" module learned options to create independent external project step targets that do not depend on the builtin steps. * The "ExternalProject" module "ExternalProject_Add()" command learned a new "CMAKE_CACHE_DEFAULT_ARGS" option to initialize cache values in the external project without setting them on future builds. * The "ExternalProject" module "ExternalProject_Add()" command learned a new "TEST_EXCLUDE_FROM_MAIN" option to exclude tests from the main build. * The "ExternalProject" module "ExternalProject_Add()" command learned a new "UPDATE_DISCONNECTED" option to avoid automatically updating the source tree checkout from version control. * The "FindCUDA" module learned about the "cusolver" library in CUDA 7.0. * The "FindGit" module learned to find the "git" command-line tool that comes with GitHub for Windows installed in user home directories. * A "FindGSL" module was introduced to find the GNU Scientific Library. * A "FindIntl" module was introduced to find the Gettext "libintl" library. * The "FindLATEX" module learned to support components. * The "FindMPI" module learned to find MS-MPI on Windows. * The "FindOpenSSL" module now reports "crypto" and "ssl" libraries separately in "OPENSSL_CRYPTO_LIBRARY" and "OPENSSL_SSL_LIBRARY", respectively, to allow applications to link to one without the other. * The "WriteCompilerDetectionHeader" module learned to create a define for portability of the "cxx_thread_local" feature. The define expands to either the C++11 "thread_local" keyword, or a pre- standardization compiler-specific equivalent, as appropriate. * The "WriteCompilerDetectionHeader" module learned to create multiple output files per compiler and per language, instead of creating one large file. CTest ----- * The "ctest_coverage()" command learned to support Delphi coverage. * The "ctest_coverage()" command learned to support Javascript coverage. * The "CTestCoverageCollectGCOV" module was introduced as an alternative to the "ctest_coverage()" command for collecting "gcov" results for submission to CDash. CPack ----- * The "CPackRPM" module learned options to set per-component descriptions and summaries. See the "CPACK_RPM__PACKAGE_DESCRIPTION" and "CPACK_RPM__PACKAGE_SUMMARY" variables. * The "CPackRPM" module learned options to specify requirements for pre- and post-install scripts. See the "CPACK_RPM_PACKAGE_REQUIRES_PRE" and "CPACK_RPM_PACKAGE_REQUIRES_POST" variables. * The "CPackRPM" module learned options to specify requirements for pre- and post-uninstall scripts. See the "CPACK_RPM_PACKAGE_REQUIRES_PREUN" and "CPACK_RPM_PACKAGE_REQUIRES_POSTUN" variables. * The "CPackRPM" module learned a new "CPACK_RPM__PACKAGE_PREFIX" variable to specify a component-specific value to use instead of "CPACK_PACKAGING_INSTALL_PREFIX". * The "CPackRPM" module learned a new "CPACK_RPM_RELOCATION_PATHS" variable to specify multiple relocation prefixes for a single rpm package. Other ----- * The "cmake(1)" "-E tar" command now supports creating ".xz"-compressed archives with the "J" flag. * The "cmake(1)" "-E tar" command learned a new "--files- from=" option to specify file names using lines in a file to overcome command-line length limits. * The "cmake(1)" "-E tar" command learned a new "--mtime=" option to specify the modification time recorded in tarball entries. * The "Compile Features" functionality is now aware of features supported by more compilers, including: * Apple Clang ("AppleClang") for Xcode versions 4.4 though 6.1. * GNU compiler versions 4.4 through 5.0 on UNIX and Apple ("GNU"). * Microsoft Visual Studio ("MSVC") for versions 2010 through 2015. * Oracle SolarisStudio ("SunPro") version 12.4. * The *AUTORCC* feature now tracks files listed in ".qrc" files as dependencies. If an input file to the "rcc" tool is changed, the tool is automatically re-run. New Diagnostics =============== * The "break()" command now rejects calls outside of a loop context or that pass arguments to the command. See policy "CMP0055". Deprecated and Removed Features =============================== * Files written in the "cmake-language(7)", such as "CMakeLists.txt" or "*.cmake" files, are now expected to be encoded as UTF-8. If files are already ASCII, they will be compatible. If files were in a different encoding, including Latin 1, they will need to be converted. * The "FindOpenGL" module no longer explicitly searches for any dependency on X11 libraries with the "FindX11" module. Such dependencies should not need to be explicit. Applications using X11 APIs themselves should find and link to X11 libraries explicitly. * The implementation of CMake now relies on some C++ compiler features which are not supported by some older compilers. As a result, those old compilers can no longer be used to build CMake itself. CMake continues to be able to generate Makefiles and project files for users of those old compilers however. Compilers known to no longer be capable of building CMake are: * Visual Studio 6 and 7.0 -- superseded by VisualStudio 7.1 and newer. * GCC 2.95 -- superseded by GCC 3 and newer compilers. * Borland compilers -- superseded by other Windows compilers. * Compaq compilers -- superseded by other compilers. * SGI compilers -- IRIX was dropped as a host platform. Other Changes ============= * On Windows and OS X, commands supporting network communication via "https", such as "file(DOWNLOAD)", "file(UPLOAD)", and "ctest_submit()", now support SSL/TLS even when CMake is not built against OpenSSL. The Windows or OS X native SSL/TLS implementation is used by default. OS-configured certificate authorities will be trusted automatically. On other platforms, when CMake is built with OpenSSL, these commands now search for OS-configured certificate authorities in a few "/etc" paths to be trusted automatically. * On OS X with Makefile and Ninja generators, when a compiler is found in "/usr/bin" it is now mapped to the corresponding compiler inside the Xcode application folder, if any. This allows such build trees to continue to work with their original compiler even when "xcode- select" switches to a different Xcode installation. * The Visual Studio generators now write solution and project files in UTF-8 instead of Windows-1252. Windows-1252 supported Latin 1 languages such as those found in North and South America and Western Europe. With UTF-8, additional languages are now supported. * The "Xcode" generator no longer requires a value for the "CMAKE_MAKE_PROGRAM" variable to be located up front. It now locates "xcodebuild" when needed at build time. * When building CMake itself using SolarisStudio 12, the default "libCStd" standard library is not sufficient to build CMake. The SolarisStudio distribution supports compiler options to use "STLPort4" or "libstdc++". An appropriate option to select the standard library is now added automatically when building CMake with SolarisStudio compilers. ------------------------------------------------------------------- Changes made since CMake 3.1.0-rc1: Brad King (8): Help: Revise configure_file documentation (#15403) Help: In 3.2 relnotes move OpenGL/X11 to deprecated/removed section Utilities/Release: Build OS X and Win binaries without OpenSSL cmake-gui: Reset generator platform and toolset on configure (#15411) FindJsonCpp: Drop new module due to upstream jsoncpp providing package bootstrap: Add --(no-)system-jsoncpp options FindCurses: Drop unused check for cbreak in tinfo library CMake 3.2.0-rc2 Tiago St?rmer Daitx (1): FindJNI: Add arch-specific library dir for JDK 9 layout (#15408) From jsvanbethlehem at gmail.com Tue Feb 24 10:48:49 2015 From: jsvanbethlehem at gmail.com (Jakob van Bethlehem) Date: Tue, 24 Feb 2015 16:48:49 +0100 Subject: [CMake] Problems with combo CMake/MSVC2013/Qt5 Message-ID: Dear users, It has been a while since I used CMake and it's the first time I'm using it on Windows/MSVC2013, so hopefully I'm not missing something obvious. I tried to create the most basic example that shows the problem. I'm trying to compile a subfolder of my Qt5 project into a shared library. The CMakeLists.txt file in the main folder looks like: CMAKE_MINIMUM_REQUIRED(VERSION 3.0.0) PROJECT(qtapp) set(CMAKE_PREFIX_PATH "C:/Qt/Qt5.4.0/5.4/msvc2013_64_opengl/lib/cmake") FIND_PACKAGE(Qt5Widgets REQUIRED) FIND_PACKAGE(Qt5Core REQUIRED) SET(CMAKE_AUTOMOC ON) SET(CMAKE_INCLUDE_CURRENT_DIR ON) add_subdirectory(mylib) add_executable(mymain WIN32 mymain.cpp) target_link_libraries(mymain mylib) The CMakeLists.txt file in the subfolder looks like this: CMAKE_MINIMUM_REQUIRED(VERSION 3.0.0) FILE(GLOB lib_sources *.cpp *.h) ADD_LIBRARY(mylib SHARED ${lib_sources}) TARGET_LINK_LIBRARIES(mylib Qt5::Widgets) include(GenerateExportHeader) generate_export_header(mylib) Inside the subfolder I have one header file mylib.h: #pragma once #include "mylib_export.h" class MYLIB_EXPORT MyClass { public: MyClass(); }; And there is one source file mylib.cpp: #include "myclass.h" MyClass::MyClass() {} In the main file mymain.cpp in the main folder I try to instantiate an object: #include "mylib/myclass.h" int main() { MyClass klass(); } I create a 'build' folder, where I execute 'cmake -G "Visual Studio 12 2013 Win64" ..'; subsequently I open the resulting solution file, which I try to build. The problem: for some reason when compiling mymain.cpp I get: fatal error C1083: Cannot open include file: 'mylib_export.h': No such file or directory I already checked that the build-folder is added as an include directory, both to the main-project and to the library-project. I already noticed that compilation will succeed if I #include explicitly from the build directory inside mylib.h (#include "../build/mylib/mylib_export.h") but that obviously is not my intention. What am I doing wrong or what did I miss? Any ideas? Sincerely, Jakob van Bethlehem -------------- next part -------------- An HTML attachment was scrubbed... URL: From loose at astron.nl Tue Feb 24 12:01:25 2015 From: loose at astron.nl (Marcel Loose) Date: Tue, 24 Feb 2015 18:01:25 +0100 Subject: [CMake] Module CMakeParseArguments: confusing last paragraph in documentation In-Reply-To: References: <54EC5B00.8070407@astron.nl> Message-ID: <54ECAE65.6070705@astron.nl> I guess that would imply that "not" is missing twice, [...] would not be empty [...] and [...] would not be set to TRUE [...]. Marcel. On 24/02/15 12:31, Petr Kmoch wrote: > My guess is there's a "not" missing between "would" and "result in > MY_INSTALL_DESTINATION set to" > > Petr > > On Tue, Feb 24, 2015 at 12:05 PM, Marcel Loose > wrote: > > Hi all, > > Several times I've read the last paragraph of the documentation of > module CMakeParseArguments, but I can't get my head around it. > > Keywords terminate lists of values, e.g. if directly after a > one_value_keyword another recognized keyword follows, this is > interpreted as the beginning of the new option. E.g. > my_install(TARGETS foo DESTINATION OPTIONAL) would result in > MY_INSTALL_DESTINATION set to ?OPTIONAL?, but > MY_INSTALL_DESTINATION would be empty and MY_INSTALL_OPTIONAL > would be set to TRUE therefor. > > Huh? [...] MY_INSTALL_DESTINATION will be set to "OPTIONAL", but > would be empty [...] ??? > > Reading the first sentence of this paragraph, I concluded that > MY_INSTALL_DESTINATION will be empty, not would be. > > Best regards, > Marcel Loose. > > > -- > > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: loose.vcf Type: text/x-vcard Size: 292 bytes Desc: not available URL: From steveire at gmail.com Tue Feb 24 13:54:27 2015 From: steveire at gmail.com (Stephen Kelly) Date: Tue, 24 Feb 2015 19:54:27 +0100 Subject: [CMake] Problems with combo CMake/MSVC2013/Qt5 References: Message-ID: Jakob van Bethlehem wrote: > Dear users, > set(CMAKE_PREFIX_PATH "C:/Qt/Qt5.4.0/5.4/msvc2013_64_opengl/lib/cmake") Don't do this. Pass CMAKE_PREFIX_PATH as an argument to cmake. > The CMakeLists.txt file in the subfolder looks like this: > > CMAKE_MINIMUM_REQUIRED(VERSION 3.0.0) This has effects you probably don't intend. I suggest removing it. http://www.cmake.org/cmake/help/v3.1/manual/cmake-policies.7.html > The problem: for some reason when compiling mymain.cpp I get: > fatal error C1083: Cannot open include file: 'mylib_export.h': No such > file or directory > > I already checked that the build-folder is added as an include directory, The build folder of the top-level is added as an include directory. Your export.h file is in the subdirectory. Thanks, Steve. From steveire at gmail.com Tue Feb 24 14:14:23 2015 From: steveire at gmail.com (Stephen Kelly) Date: Tue, 24 Feb 2015 20:14:23 +0100 Subject: [CMake] CMP0026 - Disallow use of the LOCATION target property References: <1D9B19F0-F52E-42E5-8666-5728ABDFB579@me.com> Message-ID: Jifeng ZHANG wrote: > Any idea when CMake 4.0 is planned to release? So we can get a general > idea when the old behavior will stop working. What will you do when it is released and the LOCATION property does stop working for build targets? Whatever it is, any reason not to do it now? Thanks, Steve. From adam.getchell at gmail.com Tue Feb 24 14:42:03 2015 From: adam.getchell at gmail.com (Adam Getchell) Date: Tue, 24 Feb 2015 11:42:03 -0800 Subject: [CMake] Setting build type Message-ID: Hello all, I've browsed this thread: http://www.cmake.org/pipermail/cmake/2008-September/023808.html But it doesn't work. My project is set to Release regardless, whether I do: project( CDT-plusplus_ ) set(CMAKE_BUILD_TYPE RelWithDebInfo) Or: # # If the user specifies -DCMAKE_BUILD_TYPE on the command line, take their definition # and dump it in the cache along with proper documentation, otherwise set CMAKE_BUILD_TYPE # to Debug prior to calling PROJECT() # IF(DEFINED CMAKE_BUILD_TYPE) SET(CMAKE_BUILD_TYPE ${CMAKE_BUILD_TYPE} CACHE STRING "Choose the type of build, options are: None(CMAKE_CXX_FLAGS or CMAKE_C_FLAGS used) Debug Release RelWithDebInfo MinSizeRel.") ELSE() SET(CMAKE_BUILD_TYPE Debug CACHE STRING "Choose the type of build, options are: None(CMAKE_CXX_FLAGS or CMAKE_C_FLAGS used) Debug Release RelWithDebInfo MinSizeRel.") ENDIF() project( CDT-plusplus_ ) The only way I can change the build type is by going into my build directory and editing CMakeCache.txt. However, I use an out of source build, so my build directory is generated automatically by scripts such as: https://github.com/acgetchell/CDT-plusplus/blob/master/scan-build.sh What's the correct method for being able to set the type of build via the command line? -- Adam Getchell about.me/adamgetchell "Invincibility is in oneself, vulnerability in the opponent." -- Sun Tzu -------------- next part -------------- An HTML attachment was scrubbed... URL: From d3ck0r at gmail.com Tue Feb 24 15:20:42 2015 From: d3ck0r at gmail.com (J Decker) Date: Tue, 24 Feb 2015 12:20:42 -0800 Subject: [CMake] Setting build type In-Reply-To: References: Message-ID: I use a different directory to build release and debug versions.... if you didn't delete, then when it goes to build partial things, the .obj files will still be newer than the .c files and will cause mixed release-debug builds which generally results in bizarre crashes. Once chosen, can't change the build type of a build; although if you could it should do a clean also. On Tue, Feb 24, 2015 at 11:42 AM, Adam Getchell wrote: > Hello all, > > I've browsed this thread: > > http://www.cmake.org/pipermail/cmake/2008-September/023808.html > > But it doesn't work. My project is set to Release regardless, whether I do: > > project( CDT-plusplus_ ) > set(CMAKE_BUILD_TYPE RelWithDebInfo) > > Or: > > # > # If the user specifies -DCMAKE_BUILD_TYPE on the command line, take their > definition > # and dump it in the cache along with proper documentation, otherwise set > CMAKE_BUILD_TYPE > # to Debug prior to calling PROJECT() > # > IF(DEFINED CMAKE_BUILD_TYPE) > SET(CMAKE_BUILD_TYPE ${CMAKE_BUILD_TYPE} CACHE STRING "Choose the type > of > build, options are: None(CMAKE_CXX_FLAGS or CMAKE_C_FLAGS used) Debug > Release RelWithDebInfo MinSizeRel.") > ELSE() > SET(CMAKE_BUILD_TYPE Debug CACHE STRING "Choose the type of build, > options are: None(CMAKE_CXX_FLAGS or CMAKE_C_FLAGS used) Debug Release > RelWithDebInfo MinSizeRel.") > ENDIF() > > project( CDT-plusplus_ ) > > The only way I can change the build type is by going into my build > directory and editing CMakeCache.txt. However, I use an out of source > build, so my build directory is generated automatically by scripts such as: > > https://github.com/acgetchell/CDT-plusplus/blob/master/scan-build.sh > > What's the correct method for being able to set the type of build via the > command line? > > -- > Adam Getchell > about.me/adamgetchell > "Invincibility is in oneself, vulnerability in the opponent." -- Sun Tzu > > -- > > 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 a.neundorf-work at gmx.net Tue Feb 24 16:36:31 2015 From: a.neundorf-work at gmx.net (Alexander Neundorf) Date: Tue, 24 Feb 2015 22:36:31 +0100 Subject: [CMake] CMP0026 - Disallow use of the LOCATION target property In-Reply-To: References: Message-ID: <1849318.vtp5o5Y3xc@tuxedo.neundorf.net> On Tuesday, February 24, 2015 20:14:23 Stephen Kelly wrote: > Jifeng ZHANG wrote: > > Any idea when CMake 4.0 is planned to release? So we can get a general > > idea when the old behavior will stop working. > > What will you do when it is released and the LOCATION property does stop > working for build targets? Whatever it is, any reason not to do it now? Always a good reason not to do it now while it still works is that by not doing it now the saved time can be used to work on other things which really need to be done now, maybe on a deadline. Once it's not working anymore it really needs to be done, and then it will be done. Yes, this postpones a problem into the future, but that's not always a bad thing. Alex From dpoplavskiy at topcon.com Tue Feb 24 18:50:54 2015 From: dpoplavskiy at topcon.com (Dmytro Poplavskiy) Date: Wed, 25 Feb 2015 09:50:54 +1000 Subject: [CMake] Listing generated source files in cmake project Message-ID: <54ED0E5E.7070702@topcon.com> Hello, I have some source files generated as a part of build process, generated using add_custom_command(). Building works fine, but would be nice to have generated source files to be displayed in IDE project (QtCreator using CodeBlocks generator). I tried to use add_custom_target(... SOURCES ) but it only works for files located in the source tree, generated files located in the build directory outside of the source tree are excluded. Regards Dmytro. Confidentiality Notice: This message (including attachments) is a private communication solely for use of the intended recipient(s). If you are not the intended recipient(s) or believe you received this message in error, notify the sender immediately and then delete this message. Any other use, retention, dissemination or copying is prohibited and may be a violation of law, including the Electronic Communication Privacy Act of 1986." From loose at astron.nl Wed Feb 25 03:27:40 2015 From: loose at astron.nl (Marcel Loose) Date: Wed, 25 Feb 2015 09:27:40 +0100 Subject: [CMake] CMake Version Compatibility Matrix Message-ID: <54ED877C.5000906@astron.nl> Hi all, Is there any chance that the version compatibility matrix will be updated for cmake 3.x features? Best regards, 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 Feb 25 03:36:32 2015 From: biddisco at cscs.ch (Biddiscombe, John A.) Date: Wed, 25 Feb 2015 08:36:32 +0000 Subject: [CMake] xcodeproj cannot be opened because the project file cannot be parsed Message-ID: When generating Xcode projects on OSX, for larger projects I get this error when I attempt to open them (smaller/simpler ones seem to be ok). In one particular example the Xcode generated project is approx 14MB in size. Does anyone know of any tools to diagnose what is wrong with the generated project and how cmake might be coaxed into generating it correctly? Using cmake version 3.1.0 Thanks JB -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam.getchell at gmail.com Wed Feb 25 04:16:27 2015 From: adam.getchell at gmail.com (Adam Getchell) Date: Wed, 25 Feb 2015 01:16:27 -0800 Subject: [CMake] Setting build type In-Reply-To: References: Message-ID: Thanks for your reply. I'm not sure I follow your answer. I do delete the directory each time I build, but I'm still not understanding how you're building release or debug versions to begin with. I'm just automatically getting Release, unless I edit CMakeCache.txt after I've built once. I just checked CGAL_CreateSingleSourceCGALProgram.cmake which is invoked in my CMakeLists.txt, but I do not see it setting the build type to Release. https://github.com/acgetchell/CDT-plusplus/blob/master/CMakeLists.txt On Tue, Feb 24, 2015 at 12:20 PM, J Decker wrote: > I use a different directory to build release and debug versions.... > > if you didn't delete, then when it goes to build partial things, the .obj > files will still be newer than the .c files and will cause mixed > release-debug builds which generally results in bizarre crashes. > Once chosen, can't change the build type of a build; although if you could > it should do a clean also. > > > On Tue, Feb 24, 2015 at 11:42 AM, Adam Getchell > wrote: > >> Hello all, >> >> I've browsed this thread: >> >> http://www.cmake.org/pipermail/cmake/2008-September/023808.html >> >> But it doesn't work. My project is set to Release regardless, whether I >> do: >> >> project( CDT-plusplus_ ) >> set(CMAKE_BUILD_TYPE RelWithDebInfo) >> >> Or: >> >> # >> # If the user specifies -DCMAKE_BUILD_TYPE on the command line, take >> their definition >> # and dump it in the cache along with proper documentation, otherwise set >> CMAKE_BUILD_TYPE >> # to Debug prior to calling PROJECT() >> # >> IF(DEFINED CMAKE_BUILD_TYPE) >> SET(CMAKE_BUILD_TYPE ${CMAKE_BUILD_TYPE} CACHE STRING "Choose the type >> of >> build, options are: None(CMAKE_CXX_FLAGS or CMAKE_C_FLAGS used) Debug >> Release RelWithDebInfo MinSizeRel.") >> ELSE() >> SET(CMAKE_BUILD_TYPE Debug CACHE STRING "Choose the type of build, >> options are: None(CMAKE_CXX_FLAGS or CMAKE_C_FLAGS used) Debug Release >> RelWithDebInfo MinSizeRel.") >> ENDIF() >> >> project( CDT-plusplus_ ) >> >> The only way I can change the build type is by going into my build >> directory and editing CMakeCache.txt. However, I use an out of source >> build, so my build directory is generated automatically by scripts such as: >> >> https://github.com/acgetchell/CDT-plusplus/blob/master/scan-build.sh >> >> What's the correct method for being able to set the type of build via the >> command line? >> >> -- >> Adam Getchell >> about.me/adamgetchell >> "Invincibility is in oneself, vulnerability in the opponent." -- Sun Tzu >> >> -- >> >> 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 >> > > -- Adam Getchell about.me/adamgetchell "Invincibility is in oneself, vulnerability in the opponent." -- Sun Tzu -------------- next part -------------- An HTML attachment was scrubbed... URL: From d3ck0r at gmail.com Wed Feb 25 04:37:25 2015 From: d3ck0r at gmail.com (J Decker) Date: Wed, 25 Feb 2015 01:37:25 -0800 Subject: [CMake] Setting build type In-Reply-To: References: Message-ID: mkdir build-d cd build-d cmake -DCMAKE_BUILD_TYPE=Debug -DCMAKE_INSTALL_PREFIX=out ../your/source/procject cmake --build . cd .. mkdir build-r cd build-r cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=out ../your/source/procject cmake --build . --target install cd .. On Wed, Feb 25, 2015 at 1:16 AM, Adam Getchell wrote: > Thanks for your reply. > > I'm not sure I follow your answer. I do delete the directory each time I > build, but I'm still not understanding how you're building release or debug > versions to begin with. > > I'm just automatically getting Release, unless I edit CMakeCache.txt after > I've built once. > > I just checked CGAL_CreateSingleSourceCGALProgram.cmake which is invoked > in my CMakeLists.txt, but I do not see it setting the build type to Release. > > https://github.com/acgetchell/CDT-plusplus/blob/master/CMakeLists.txt > > > > On Tue, Feb 24, 2015 at 12:20 PM, J Decker wrote: > >> I use a different directory to build release and debug versions.... >> >> if you didn't delete, then when it goes to build partial things, the .obj >> files will still be newer than the .c files and will cause mixed >> release-debug builds which generally results in bizarre crashes. >> Once chosen, can't change the build type of a build; although if you >> could it should do a clean also. >> >> >> On Tue, Feb 24, 2015 at 11:42 AM, Adam Getchell >> wrote: >> >>> Hello all, >>> >>> I've browsed this thread: >>> >>> http://www.cmake.org/pipermail/cmake/2008-September/023808.html >>> >>> But it doesn't work. My project is set to Release regardless, whether I >>> do: >>> >>> project( CDT-plusplus_ ) >>> set(CMAKE_BUILD_TYPE RelWithDebInfo) >>> >>> Or: >>> >>> # >>> # If the user specifies -DCMAKE_BUILD_TYPE on the command line, take >>> their definition >>> # and dump it in the cache along with proper documentation, otherwise >>> set CMAKE_BUILD_TYPE >>> # to Debug prior to calling PROJECT() >>> # >>> IF(DEFINED CMAKE_BUILD_TYPE) >>> SET(CMAKE_BUILD_TYPE ${CMAKE_BUILD_TYPE} CACHE STRING "Choose the >>> type of >>> build, options are: None(CMAKE_CXX_FLAGS or CMAKE_C_FLAGS used) Debug >>> Release RelWithDebInfo MinSizeRel.") >>> ELSE() >>> SET(CMAKE_BUILD_TYPE Debug CACHE STRING "Choose the type of build, >>> options are: None(CMAKE_CXX_FLAGS or CMAKE_C_FLAGS used) Debug Release >>> RelWithDebInfo MinSizeRel.") >>> ENDIF() >>> >>> project( CDT-plusplus_ ) >>> >>> The only way I can change the build type is by going into my build >>> directory and editing CMakeCache.txt. However, I use an out of source >>> build, so my build directory is generated automatically by scripts such as: >>> >>> https://github.com/acgetchell/CDT-plusplus/blob/master/scan-build.sh >>> >>> What's the correct method for being able to set the type of build via >>> the command line? >>> >>> -- >>> Adam Getchell >>> about.me/adamgetchell >>> "Invincibility is in oneself, vulnerability in the opponent." -- Sun Tzu >>> >>> -- >>> >>> 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 >>> >> >> > > > -- > Adam Getchell > about.me/adamgetchell > "Invincibility is in oneself, vulnerability in the opponent." -- Sun Tzu > -------------- next part -------------- An HTML attachment was scrubbed... URL: From becker.tobi at gmail.com Wed Feb 25 05:46:57 2015 From: becker.tobi at gmail.com (Tobias Becker) Date: Wed, 25 Feb 2015 11:46:57 +0100 Subject: [CMake] load_command not scriptable Message-ID: Hi I've been working on an open source project which provides alot of extra cmake (in pure cmake) https://github.com/toeb/cmakepp. I am however hitting a performance bottleneck and want to get around that by using load_command (I know it is discouraged) however I have the problem that it is not scriptable and all of my functions need to be available in script mode. Is there a way to load compiled commands into cmake after it was compiled? (I have even thinking about patching the executable to make cmLoadCommandCommand return true in its IsScriptable method) But there should be a simple way? Cheers, Tobias -------------- next part -------------- An HTML attachment was scrubbed... URL: From DLRdave at aol.com Wed Feb 25 07:21:42 2015 From: DLRdave at aol.com (David Cole) Date: Wed, 25 Feb 2015 07:21:42 -0500 Subject: [CMake] load_command not scriptable In-Reply-To: References: Message-ID: You could patch the executable to make cmLoadCommandCommand return true from IsScriptable... but if you're going to the trouble of patching CMake anyhow, why not simply build your loadable command directly into CMake...? The other thing might be to mention specifically what the performance problem is on the mailing list here to see if anybody has any ideas how we could make things faster..... And totally preclude your need to load an additional command in the first place. Or profile it and submit a patch to improve the performance in this situation. HTH, David C. On Wed, Feb 25, 2015 at 5:46 AM, Tobias Becker wrote: > Hi > > I've been working on an open source project which provides alot of extra > cmake (in pure cmake) https://github.com/toeb/cmakepp. I am however hitting > a performance bottleneck and want to get around that by using load_command > (I know it is discouraged) however I have the problem that it is not > scriptable and all of my functions need to be available in script mode. > > Is there a way to load compiled commands into cmake after it was compiled? > (I have even thinking about patching the executable to make > cmLoadCommandCommand return true in its IsScriptable method) > > But there should be a simple way? > > > Cheers, > > Tobias > > -- > > 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 jsvanbethlehem at gmail.com Wed Feb 25 07:27:06 2015 From: jsvanbethlehem at gmail.com (Jakob van Bethlehem) Date: Wed, 25 Feb 2015 13:27:06 +0100 Subject: [CMake] Problems with combo CMake/MSVC2013/Qt5 In-Reply-To: References: Message-ID: Hello, Thanks for the quick reply! On Tue, Feb 24, 2015 at 7:54 PM, Stephen Kelly wrote: > Jakob van Bethlehem wrote: > > > Dear users, > > > set(CMAKE_PREFIX_PATH "C:/Qt/Qt5.4.0/5.4/msvc2013_64_opengl/lib/cmake") > > Don't do this. Pass CMAKE_PREFIX_PATH as an argument to cmake. > Good point; currently I'm in kind of a proof-of-concept phase, but I'll make this change asap > > > The CMakeLists.txt file in the subfolder looks like this: > > > > CMAKE_MINIMUM_REQUIRED(VERSION 3.0.0) > > This has effects you probably don't intend. I suggest removing it. > > http://www.cmake.org/cmake/help/v3.1/manual/cmake-policies.7.html Hm, that's new to me, especially because the examples-page does not mention this. Alas, something learned today! > > > The problem: for some reason when compiling mymain.cpp I get: > > fatal error C1083: Cannot open include file: 'mylib_export.h': No such > > file or directory > > > > I already checked that the build-folder is added as an include directory, > > The build folder of the top-level is added as an include directory. Your > export.h file is in the subdirectory. > > No, the mylib_export.h is created in the top-level build folder, which, as you mentioned, is added as an include directory as expected. It is _included_ though from a subdirectory, but AFAIK that shouldn't make a difference (not that I remember from my Linux experience at least) Sincerely, Jakob van Bethlehem -------------- next part -------------- An HTML attachment was scrubbed... URL: From klepachd at gmail.com Wed Feb 25 07:57:53 2015 From: klepachd at gmail.com (Doron Klepach) Date: Wed, 25 Feb 2015 14:57:53 +0200 Subject: [CMake] Creating DLL from FORTRAN code Message-ID: Hello there, I am new to CMake and I am trying to convert a project to work with CMake. As a part of the process I need to create a DLL from a FORTRAN code. Here are some details: *The code works on Visual Studio and creates the DLL as required. *The main subroutine looks like this: subroutine sub1(var1,var2 ...) !DEC$ ATTRIBUTES DLLEXPORT :: sub1 ... ens subroutine sub1 * I looked at the CMake command add_library( [STATIC | SHARED | MODULE] [EXCLUDE_FROM_ALL] source1 [source2 ...]) and tried the SHARED option, but that did not work, giving an error. * I looked at several sources for help, including http://www.kitware.com/blog/home/post/231 but I was not able to figure out how to create the DLL (the link to the example is not working) I would appreciate a simple example that shows how to do this. Thank you for your help, Doron -------------- next part -------------- An HTML attachment was scrubbed... URL: From petr.kmoch at gmail.com Wed Feb 25 08:07:26 2015 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Wed, 25 Feb 2015 14:07:26 +0100 Subject: [CMake] Creating DLL from FORTRAN code In-Reply-To: References: Message-ID: Hi Doron, it would be helpful if you provided the error you're getting from add_library(), and also showed the exact CMake code you used. Petr On Wed, Feb 25, 2015 at 1:57 PM, Doron Klepach wrote: > Hello there, > > I am new to CMake and I am trying to convert a project to work with CMake. > > As a part of the process I need to create a DLL from a FORTRAN code. > > Here are some details: > *The code works on Visual Studio and creates the DLL as required. > > *The main subroutine looks like this: > > subroutine sub1(var1,var2 ...) > > !DEC$ ATTRIBUTES DLLEXPORT :: sub1 > > ... > > ens subroutine sub1 > > * I looked at the CMake command > > add_library( [STATIC | SHARED | MODULE] > [EXCLUDE_FROM_ALL] > source1 [source2 ...]) > > and tried the SHARED option, but that did not work, giving an error. > > * I looked at several sources for help, including > http://www.kitware.com/blog/home/post/231 > > but I was not able to figure out how to create the DLL (the link to the example is not working) > > I would appreciate a simple example that shows how to do this. > > Thank you for your help, > > Doron > > > > -- > > 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 kim at rthansen.dk Wed Feb 25 08:09:58 2015 From: kim at rthansen.dk (Kim Rydhof Thor Hansen) Date: Wed, 25 Feb 2015 14:09:58 +0100 Subject: [CMake] can I make an AUTOMOC generated file depend on something ? In-Reply-To: References: <1505810.OWG1IaMX4b@lapi.koller> Message-ID: Hi, On Mon, Nov 17, 2014 at 10:23 PM, Stephen Kelly wrote: > Martin Koller wrote: > >> What rules can I add so that the tar extraction is done BEFORE the moc >> generation ? > > You can add depends in the AUTOGEN_TARGET_DEPENDS target property of > particular targets. > > http://www.cmake.org/cmake/help/v3.0/prop_tgt/AUTOGEN_TARGET_DEPENDS.html I have a similar problem because automoc doesn't pick up that my metadata.json file is a dependency to the generated moc_plugin.cpp when building a Qt plugin with: Q_PLUGIN_METADATA(IID "com.example.cmake.test" FILE "metadata.json") Given the suggestion here I have tried to fix my problem using AUTOGEN_TARGET_DEPENDS, but that also doesn't work. Am I using AUTOGEN_TARGET_DEPENDS in a wrong way? >From my CMakeLists.txt add_library(plugin MODULE plugin.cpp) target_link_libraries(plugin Qt5::Core) set_property(TARGET plugin PROPERTY AUTOGEN_TARGET_DEPENDS metadata.json) I have attached a minimal example showing how the module is not rebuild when metadata.json is edited. I have tested using 3.0.2, 3.1.3 and 3.2.0-rc2. Regards, Kim Hansen -------------- next part -------------- A non-text attachment was scrubbed... Name: plugin-rebuild.zip Type: application/zip Size: 1357 bytes Desc: not available URL: From klepachd at gmail.com Wed Feb 25 08:21:37 2015 From: klepachd at gmail.com (Doron Klepach) Date: Wed, 25 Feb 2015 15:21:37 +0200 Subject: [CMake] Creating DLL from FORTRAN code In-Reply-To: References: Message-ID: Hello Petr, Thank you for the quick reply. At this point I am not getting any errors, but nothing happens when I build the sln in Visual Studio -> no dll is created. Here is the main CMake code: cmake_minimum_required (VERSION 3.1) project (micro_linMatl_I) enable_language (Fortran) # The version number. set (micro_linMatl_I_VERSION_MAJOR 4) set (micro_linMatl_I_VERSION_MINOR 0) #include all the required modules from the folder "Modules" include_directories ("${PROJECT_SOURCE_DIR}/Modules") set (EXTRA_LIBS ${EXTRA_LIBS} Modules) ADD_Library(micro_linMatl_I SHARED ${EXTRA_LIBS}) SET_TARGET_PROPERTIES(micro_linMatl_I PROPERTIES LINKER_LANGUAGE Fortran) target_link_libraries (micro_linMatl_I ${EXTRA_LIBS}) and here is the one in the folder "Modules" add_library(Modules mod1.F90 mod2.F90 ...) Thank you for your help, Doron On Wed, Feb 25, 2015 at 3:07 PM, Petr Kmoch wrote: > Hi Doron, > > it would be helpful if you provided the error you're getting from > add_library(), and also showed the exact CMake code you used. > > Petr > > On Wed, Feb 25, 2015 at 1:57 PM, Doron Klepach wrote: > >> Hello there, >> >> I am new to CMake and I am trying to convert a project to work with CMake. >> >> As a part of the process I need to create a DLL from a FORTRAN code. >> >> Here are some details: >> *The code works on Visual Studio and creates the DLL as required. >> >> *The main subroutine looks like this: >> >> subroutine sub1(var1,var2 ...) >> >> !DEC$ ATTRIBUTES DLLEXPORT :: sub1 >> >> ... >> >> ens subroutine sub1 >> >> * I looked at the CMake command >> >> add_library( [STATIC | SHARED | MODULE] >> [EXCLUDE_FROM_ALL] >> source1 [source2 ...]) >> >> and tried the SHARED option, but that did not work, giving an error. >> >> * I looked at several sources for help, including >> http://www.kitware.com/blog/home/post/231 >> >> but I was not able to figure out how to create the DLL (the link to the example is not working) >> >> I would appreciate a simple example that shows how to do this. >> >> Thank you for your help, >> >> Doron >> >> >> >> -- >> >> 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 petr.kmoch at gmail.com Wed Feb 25 08:47:36 2015 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Wed, 25 Feb 2015 14:47:36 +0100 Subject: [CMake] Creating DLL from FORTRAN code In-Reply-To: References: Message-ID: You're not giving the DLL micro_linMatl_l any source files, so there's nothing to build. You need to list at least one source file in the add_library() call. You mentioned a main subroutine in your first e-mail; the file containing the main subroutine should be listed in the add_library(SHARED) call. Your use of ${EXTRA_LIBS} in that command is strange - from what I can tell, it only contains a directory name, which should definitely not be listed. include_directories() controls the compiler switch which specifies paths to look for include files. If you have a CMakeLists.txt file in Modules and want to process that, you need add_subdirectory(). You should probably look at some CMake tutorials or example simple CMake files to get better hang of how individual CMake commands work and interoperate. Petr On Wed, Feb 25, 2015 at 2:21 PM, Doron Klepach wrote: > Hello Petr, > > Thank you for the quick reply. At this point I am not getting any errors, > but nothing happens when I build the sln in Visual Studio -> no dll is > created. > Here is the main CMake code: > > cmake_minimum_required (VERSION 3.1) > project (micro_linMatl_I) > enable_language (Fortran) > > # The version number. > set (micro_linMatl_I_VERSION_MAJOR 4) > set (micro_linMatl_I_VERSION_MINOR 0) > > #include all the required modules from the folder "Modules" > include_directories ("${PROJECT_SOURCE_DIR}/Modules") > set (EXTRA_LIBS ${EXTRA_LIBS} Modules) > > ADD_Library(micro_linMatl_I SHARED ${EXTRA_LIBS}) > SET_TARGET_PROPERTIES(micro_linMatl_I PROPERTIES LINKER_LANGUAGE Fortran) > target_link_libraries (micro_linMatl_I ${EXTRA_LIBS}) > > and here is the one in the folder "Modules" > > add_library(Modules mod1.F90 mod2.F90 ...) > > Thank you for your help, > Doron > > On Wed, Feb 25, 2015 at 3:07 PM, Petr Kmoch wrote: > >> Hi Doron, >> >> it would be helpful if you provided the error you're getting from >> add_library(), and also showed the exact CMake code you used. >> >> Petr >> >> On Wed, Feb 25, 2015 at 1:57 PM, Doron Klepach >> wrote: >> >>> Hello there, >>> >>> I am new to CMake and I am trying to convert a project to work with >>> CMake. >>> >>> As a part of the process I need to create a DLL from a FORTRAN code. >>> >>> Here are some details: >>> *The code works on Visual Studio and creates the DLL as required. >>> >>> *The main subroutine looks like this: >>> >>> subroutine sub1(var1,var2 ...) >>> >>> !DEC$ ATTRIBUTES DLLEXPORT :: sub1 >>> >>> ... >>> >>> ens subroutine sub1 >>> >>> * I looked at the CMake command >>> >>> add_library( [STATIC | SHARED | MODULE] >>> [EXCLUDE_FROM_ALL] >>> source1 [source2 ...]) >>> >>> and tried the SHARED option, but that did not work, giving an error. >>> >>> * I looked at several sources for help, including >>> http://www.kitware.com/blog/home/post/231 >>> >>> but I was not able to figure out how to create the DLL (the link to the example is not working) >>> >>> I would appreciate a simple example that shows how to do this. >>> >>> Thank you for your help, >>> >>> Doron >>> >>> >>> >>> -- >>> >>> 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 roman.wueger at gmx.at Wed Feb 25 09:07:03 2015 From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=) Date: Wed, 25 Feb 2015 15:07:03 +0100 Subject: [CMake] [cmake-developers] [ANNOUNCE] CMake 3.2.0-rc2 now ready for testing! In-Reply-To: References: Message-ID: Hello Robert, is there a list which showing the changes between rc1 and rc2, to test such things explicitly? Regards Roman > Am 24.02.2015 um 16:01 schrieb Robert Maynard : > > I am proud to announce the CMake 3.2 second release candidate. > > Sources and binaries are available at: > http://www.cmake.org/download/ > http://www.cmake.org/files/v3.2/?C=M;O=D > > Documentation is available at: > http://www.cmake.org/cmake/help/v3.2 > > Release notes appear below and are also published at > http://www.cmake.org/cmake/help/v3.2/release/3.2.html > Some of the more significant features of CMake 3.2 are: > > * CMake learned to support unicode characters *encoded as UTF-8* on > Windows. This was already supported on platforms whose system APIs > accept UTF-8 encoded strings. Unicode characters may now be used in > CMake code, paths to source files, configured files such as ".h.in" > files, and other files read and written by CMake. Note that because > CMake interoperates with many other tools, there may still be some > limitations when using certain unicode characters. > > * The "Compile Features" functionality is now aware of features > supported by more compilers, including: > > * Apple Clang ("AppleClang") for Xcode versions 4.4 though 6.1. > > * GNU compiler versions 4.4 through 5.0 on UNIX and Apple ("GNU"). > > * Microsoft Visual Studio ("MSVC") for versions 2010 through 2015. > > * Oracle SolarisStudio ("SunPro") version 12.4. > > * The "add_custom_command()" and "add_custom_target()" commands > learned a new "BYPRODUCTS" option to specify files produced as side > effects of the custom commands. These are not outputs because they > do not always have to be newer than inputs. > > * The "file(GENERATE)" command can now generate files which are used > as source files for buildsystem targets. Generated files > automatically get their "GENERATED" property set to "TRUE". > > Deprecated and Removed Features: > > * Files written in the "cmake-language(7)", such as "CMakeLists.txt" > or "*.cmake" files, are now expected to be encoded as UTF-8. If > files are already ASCII, they will be compatible. If files were in > a different encoding, including Latin 1, they will need to be > converted. > > * The "FindOpenGL" module no longer explicitly searches for any > dependency on X11 libraries with the "FindX11" module. Such > dependencies should not need to be explicit. Applications using X11 > APIs themselves should find and link to X11 libraries explicitly. > > > CMake 3.2 Release Notes > *********************** > > Changes made since CMake 3.1 include the following. > > > New Features > ============ > > > Syntax > ------ > > * CMake learned to support unicode characters *encoded as UTF-8* on > Windows. This was already supported on platforms whose system APIs > accept UTF-8 encoded strings. Unicode characters may now be used in > CMake code, paths to source files, configured files such as ".h.in" > files, and other files read and written by CMake. Note that because > CMake interoperates with many other tools, there may still be some > limitations when using certain unicode characters. > > > Commands > -------- > > * The "add_custom_command()" and "add_custom_target()" commands > learned a new "BYPRODUCTS" option to specify files produced as side > effects of the custom commands. These are not outputs because they > do not always have to be newer than inputs. > > * The "add_custom_command()" and "add_custom_target()" commands > learned a new "USES_TERMINAL" option to request that the command be > given direct access to the terminal if possible. The "Ninja" > generator will places such commands in the "console" "pool". Build > targets provided by CMake that are meant for individual interactive > use, such as "install", are now placed in this pool. > > * A new "continue()" command was added that can be called inside > loop contexts to end the current iteration and start the next one at > the top of the loop block. > > * The "file(LOCK)" subcommand was created to allow CMake processes > to synchronize through file and directory locks. > > * The "file(STRINGS)" now supports UTF-16LE, UTF-16BE, UTF-32LE, > UTF- 32BE as "ENCODING" options. > > * The "install(EXPORT)" command now works with an absolute > "DESTINATION" even if targets in the export set are installed with a > destination or *usage requirements* specified relative to the > install prefix. The value of the "CMAKE_INSTALL_PREFIX" variable is > hard-coded into the installed export file as the base for relative > references. > > * The "try_compile()" command source file signature now honors link > flags (e.g. "CMAKE_EXE_LINKER_FLAGS") in the generated test project. > See policy "CMP0056". > > * The "try_run()" command learned to honor the "LINK_LIBRARIES" > option just as "try_compile()" already does. > > * The "file(GENERATE)" command now generates the output file with > the same permissions as the input file if set. > > * The "file(GENERATE)" command can now generate files which are used > as source files for buildsystem targets. Generated files > automatically get their "GENERATED" property set to "TRUE". > > > Variables > --------- > > * The "CMAKE_MATCH_COUNT" variable was introduced to record the > number of matches made in the last regular expression matched in an > "if()" command or a "string()" command. > > > Properties > ---------- > > * An "ANDROID_API_MIN" target property was introduced to specify the > minimum version to be targeted by the toolchain. > > * A "VS_SHADER_FLAGS" source file property was added to specify > additional shader flags to ".hlsl" files, for the Visual Studio > generators. > > > Modules > ------- > > * The "ExternalData" module learned to support *Custom Fetch > Scripts*. This allows projects to specify custom ".cmake" scripts > for fetching data objects during the build. > > * The "ExternalProject" module learned options to create independent > external project step targets that do not depend on the builtin > steps. > > * The "ExternalProject" module "ExternalProject_Add()" command > learned a new "CMAKE_CACHE_DEFAULT_ARGS" option to initialize cache > values in the external project without setting them on future > builds. > > * The "ExternalProject" module "ExternalProject_Add()" command > learned a new "TEST_EXCLUDE_FROM_MAIN" option to exclude tests from > the main build. > > * The "ExternalProject" module "ExternalProject_Add()" command > learned a new "UPDATE_DISCONNECTED" option to avoid automatically > updating the source tree checkout from version control. > > * The "FindCUDA" module learned about the "cusolver" library in CUDA > 7.0. > > * The "FindGit" module learned to find the "git" command-line tool > that comes with GitHub for Windows installed in user home > directories. > > * A "FindGSL" module was introduced to find the GNU Scientific > Library. > > * A "FindIntl" module was introduced to find the Gettext "libintl" > library. > > * The "FindLATEX" module learned to support components. > > * The "FindMPI" module learned to find MS-MPI on Windows. > > * The "FindOpenSSL" module now reports "crypto" and "ssl" libraries > separately in "OPENSSL_CRYPTO_LIBRARY" and "OPENSSL_SSL_LIBRARY", > respectively, to allow applications to link to one without the > other. > > * The "WriteCompilerDetectionHeader" module learned to create a > define for portability of the "cxx_thread_local" feature. The define > expands to either the C++11 "thread_local" keyword, or a pre- > standardization compiler-specific equivalent, as appropriate. > > * The "WriteCompilerDetectionHeader" module learned to create > multiple output files per compiler and per language, instead of > creating one large file. > > > CTest > ----- > > * The "ctest_coverage()" command learned to support Delphi coverage. > > * The "ctest_coverage()" command learned to support Javascript > coverage. > > * The "CTestCoverageCollectGCOV" module was introduced as an > alternative to the "ctest_coverage()" command for collecting "gcov" > results for submission to CDash. > > > CPack > ----- > > * The "CPackRPM" module learned options to set per-component > descriptions and summaries. See the > "CPACK_RPM__PACKAGE_DESCRIPTION" and > "CPACK_RPM__PACKAGE_SUMMARY" variables. > > * The "CPackRPM" module learned options to specify requirements for > pre- and post-install scripts. See the > "CPACK_RPM_PACKAGE_REQUIRES_PRE" and > "CPACK_RPM_PACKAGE_REQUIRES_POST" variables. > > * The "CPackRPM" module learned options to specify requirements for > pre- and post-uninstall scripts. See the > "CPACK_RPM_PACKAGE_REQUIRES_PREUN" and > "CPACK_RPM_PACKAGE_REQUIRES_POSTUN" variables. > > * The "CPackRPM" module learned a new > "CPACK_RPM__PACKAGE_PREFIX" variable to specify a > component-specific value to use instead of > "CPACK_PACKAGING_INSTALL_PREFIX". > > * The "CPackRPM" module learned a new "CPACK_RPM_RELOCATION_PATHS" > variable to specify multiple relocation prefixes for a single rpm > package. > > > Other > ----- > > * The "cmake(1)" "-E tar" command now supports creating > ".xz"-compressed archives with the "J" flag. > > * The "cmake(1)" "-E tar" command learned a new "--files- > from=" option to specify file names using lines in a file to > overcome command-line length limits. > > * The "cmake(1)" "-E tar" command learned a new "--mtime=" > option to specify the modification time recorded in tarball entries. > > * The "Compile Features" functionality is now aware of features > supported by more compilers, including: > > * Apple Clang ("AppleClang") for Xcode versions 4.4 though 6.1. > > * GNU compiler versions 4.4 through 5.0 on UNIX and Apple ("GNU"). > > * Microsoft Visual Studio ("MSVC") for versions 2010 through 2015. > > * Oracle SolarisStudio ("SunPro") version 12.4. > > * The *AUTORCC* feature now tracks files listed in ".qrc" files as > dependencies. If an input file to the "rcc" tool is changed, the > tool is automatically re-run. > > > New Diagnostics > =============== > > * The "break()" command now rejects calls outside of a loop context > or that pass arguments to the command. See policy "CMP0055". > > > Deprecated and Removed Features > =============================== > > * Files written in the "cmake-language(7)", such as "CMakeLists.txt" > or "*.cmake" files, are now expected to be encoded as UTF-8. If > files are already ASCII, they will be compatible. If files were in > a different encoding, including Latin 1, they will need to be > converted. > > * The "FindOpenGL" module no longer explicitly searches for any > dependency on X11 libraries with the "FindX11" module. Such > dependencies should not need to be explicit. Applications using X11 > APIs themselves should find and link to X11 libraries explicitly. > > * The implementation of CMake now relies on some C++ compiler > features which are not supported by some older compilers. As a > result, those old compilers can no longer be used to build CMake > itself. CMake continues to be able to generate Makefiles and > project files for users of those old compilers however. Compilers > known to no longer be capable of building CMake are: > > * Visual Studio 6 and 7.0 -- superseded by VisualStudio 7.1 and > newer. > > * GCC 2.95 -- superseded by GCC 3 and newer compilers. > > * Borland compilers -- superseded by other Windows compilers. > > * Compaq compilers -- superseded by other compilers. > > * SGI compilers -- IRIX was dropped as a host platform. > > > Other Changes > ============= > > * On Windows and OS X, commands supporting network communication via > "https", such as "file(DOWNLOAD)", "file(UPLOAD)", and > "ctest_submit()", now support SSL/TLS even when CMake is not built > against OpenSSL. The Windows or OS X native SSL/TLS implementation > is used by default. OS-configured certificate authorities will be > trusted automatically. > > On other platforms, when CMake is built with OpenSSL, these commands > now search for OS-configured certificate authorities in a few "/etc" > paths to be trusted automatically. > > * On OS X with Makefile and Ninja generators, when a compiler is > found in "/usr/bin" it is now mapped to the corresponding compiler > inside the Xcode application folder, if any. This allows such build > trees to continue to work with their original compiler even when > "xcode- select" switches to a different Xcode installation. > > * The Visual Studio generators now write solution and project files > in UTF-8 instead of Windows-1252. Windows-1252 supported Latin 1 > languages such as those found in North and South America and Western > Europe. With UTF-8, additional languages are now supported. > > * The "Xcode" generator no longer requires a value for the > "CMAKE_MAKE_PROGRAM" variable to be located up front. It now locates > "xcodebuild" when needed at build time. > > * When building CMake itself using SolarisStudio 12, the default > "libCStd" standard library is not sufficient to build CMake. The > SolarisStudio distribution supports compiler options to use > "STLPort4" or "libstdc++". An appropriate option to select the > standard library is now added automatically when building CMake with > SolarisStudio compilers. > > ------------------------------------------------------------------- > > Changes made since CMake 3.1.0-rc1: > > Brad King (8): > Help: Revise configure_file documentation (#15403) > Help: In 3.2 relnotes move OpenGL/X11 to deprecated/removed section > Utilities/Release: Build OS X and Win binaries without OpenSSL > cmake-gui: Reset generator platform and toolset on configure (#15411) > FindJsonCpp: Drop new module due to upstream jsoncpp providing package > bootstrap: Add --(no-)system-jsoncpp options > FindCurses: Drop unused check for cbreak in tinfo library > CMake 3.2.0-rc2 > > Tiago St?rmer Daitx (1): > FindJNI: Add arch-specific library dir for JDK 9 layout (#15408) > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake-developers From robert.maynard at kitware.com Wed Feb 25 09:12:17 2015 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 25 Feb 2015 09:12:17 -0500 Subject: [CMake] [cmake-developers] [ANNOUNCE] CMake 3.2.0-rc2 now ready for testing! In-Reply-To: References: Message-ID: Hi Roman, We do attach the short-log of all changes made between each RC version to the bottom of the annoucement. But here are the changes plus the git SHA1's for each ( produced with git log --no-merges --oneline v3.2.0-rc1..v3.2.0-rc2) 99575c9 CMake 3.2.0-rc2 b4005a3 FindCurses: Drop unused check for cbreak in tinfo library a41d621 bootstrap: Add --(no-)system-jsoncpp options a576844 FindJsonCpp: Drop new module due to upstream jsoncpp providing package 1ade687 cmake-gui: Reset generator platform and toolset on configure (#15411) 7e6608f Utilities/Release: Build OS X and Win binaries without OpenSSL bce4e20 FindJNI: Add arch-specific library dir for JDK 9 layout (#15408) 6d19ef9 Help: In 3.2 relnotes move OpenGL/X11 to deprecated/removed section 029d38f Help: Revise configure_file documentation (#15403) On Wed, Feb 25, 2015 at 9:07 AM, Roman W?ger wrote: > Hello Robert, > > is there a list which showing the changes between rc1 and rc2, to test such things explicitly? > > Regards > Roman > > >> Am 24.02.2015 um 16:01 schrieb Robert Maynard : >> >> I am proud to announce the CMake 3.2 second release candidate. >> >> Sources and binaries are available at: >> http://www.cmake.org/download/ >> http://www.cmake.org/files/v3.2/?C=M;O=D >> >> Documentation is available at: >> http://www.cmake.org/cmake/help/v3.2 >> >> Release notes appear below and are also published at >> http://www.cmake.org/cmake/help/v3.2/release/3.2.html >> Some of the more significant features of CMake 3.2 are: >> >> * CMake learned to support unicode characters *encoded as UTF-8* on >> Windows. This was already supported on platforms whose system APIs >> accept UTF-8 encoded strings. Unicode characters may now be used in >> CMake code, paths to source files, configured files such as ".h.in" >> files, and other files read and written by CMake. Note that because >> CMake interoperates with many other tools, there may still be some >> limitations when using certain unicode characters. >> >> * The "Compile Features" functionality is now aware of features >> supported by more compilers, including: >> >> * Apple Clang ("AppleClang") for Xcode versions 4.4 though 6.1. >> >> * GNU compiler versions 4.4 through 5.0 on UNIX and Apple ("GNU"). >> >> * Microsoft Visual Studio ("MSVC") for versions 2010 through 2015. >> >> * Oracle SolarisStudio ("SunPro") version 12.4. >> >> * The "add_custom_command()" and "add_custom_target()" commands >> learned a new "BYPRODUCTS" option to specify files produced as side >> effects of the custom commands. These are not outputs because they >> do not always have to be newer than inputs. >> >> * The "file(GENERATE)" command can now generate files which are used >> as source files for buildsystem targets. Generated files >> automatically get their "GENERATED" property set to "TRUE". >> >> Deprecated and Removed Features: >> >> * Files written in the "cmake-language(7)", such as "CMakeLists.txt" >> or "*.cmake" files, are now expected to be encoded as UTF-8. If >> files are already ASCII, they will be compatible. If files were in >> a different encoding, including Latin 1, they will need to be >> converted. >> >> * The "FindOpenGL" module no longer explicitly searches for any >> dependency on X11 libraries with the "FindX11" module. Such >> dependencies should not need to be explicit. Applications using X11 >> APIs themselves should find and link to X11 libraries explicitly. >> >> >> CMake 3.2 Release Notes >> *********************** >> >> Changes made since CMake 3.1 include the following. >> >> >> New Features >> ============ >> >> >> Syntax >> ------ >> >> * CMake learned to support unicode characters *encoded as UTF-8* on >> Windows. This was already supported on platforms whose system APIs >> accept UTF-8 encoded strings. Unicode characters may now be used in >> CMake code, paths to source files, configured files such as ".h.in" >> files, and other files read and written by CMake. Note that because >> CMake interoperates with many other tools, there may still be some >> limitations when using certain unicode characters. >> >> >> Commands >> -------- >> >> * The "add_custom_command()" and "add_custom_target()" commands >> learned a new "BYPRODUCTS" option to specify files produced as side >> effects of the custom commands. These are not outputs because they >> do not always have to be newer than inputs. >> >> * The "add_custom_command()" and "add_custom_target()" commands >> learned a new "USES_TERMINAL" option to request that the command be >> given direct access to the terminal if possible. The "Ninja" >> generator will places such commands in the "console" "pool". Build >> targets provided by CMake that are meant for individual interactive >> use, such as "install", are now placed in this pool. >> >> * A new "continue()" command was added that can be called inside >> loop contexts to end the current iteration and start the next one at >> the top of the loop block. >> >> * The "file(LOCK)" subcommand was created to allow CMake processes >> to synchronize through file and directory locks. >> >> * The "file(STRINGS)" now supports UTF-16LE, UTF-16BE, UTF-32LE, >> UTF- 32BE as "ENCODING" options. >> >> * The "install(EXPORT)" command now works with an absolute >> "DESTINATION" even if targets in the export set are installed with a >> destination or *usage requirements* specified relative to the >> install prefix. The value of the "CMAKE_INSTALL_PREFIX" variable is >> hard-coded into the installed export file as the base for relative >> references. >> >> * The "try_compile()" command source file signature now honors link >> flags (e.g. "CMAKE_EXE_LINKER_FLAGS") in the generated test project. >> See policy "CMP0056". >> >> * The "try_run()" command learned to honor the "LINK_LIBRARIES" >> option just as "try_compile()" already does. >> >> * The "file(GENERATE)" command now generates the output file with >> the same permissions as the input file if set. >> >> * The "file(GENERATE)" command can now generate files which are used >> as source files for buildsystem targets. Generated files >> automatically get their "GENERATED" property set to "TRUE". >> >> >> Variables >> --------- >> >> * The "CMAKE_MATCH_COUNT" variable was introduced to record the >> number of matches made in the last regular expression matched in an >> "if()" command or a "string()" command. >> >> >> Properties >> ---------- >> >> * An "ANDROID_API_MIN" target property was introduced to specify the >> minimum version to be targeted by the toolchain. >> >> * A "VS_SHADER_FLAGS" source file property was added to specify >> additional shader flags to ".hlsl" files, for the Visual Studio >> generators. >> >> >> Modules >> ------- >> >> * The "ExternalData" module learned to support *Custom Fetch >> Scripts*. This allows projects to specify custom ".cmake" scripts >> for fetching data objects during the build. >> >> * The "ExternalProject" module learned options to create independent >> external project step targets that do not depend on the builtin >> steps. >> >> * The "ExternalProject" module "ExternalProject_Add()" command >> learned a new "CMAKE_CACHE_DEFAULT_ARGS" option to initialize cache >> values in the external project without setting them on future >> builds. >> >> * The "ExternalProject" module "ExternalProject_Add()" command >> learned a new "TEST_EXCLUDE_FROM_MAIN" option to exclude tests from >> the main build. >> >> * The "ExternalProject" module "ExternalProject_Add()" command >> learned a new "UPDATE_DISCONNECTED" option to avoid automatically >> updating the source tree checkout from version control. >> >> * The "FindCUDA" module learned about the "cusolver" library in CUDA >> 7.0. >> >> * The "FindGit" module learned to find the "git" command-line tool >> that comes with GitHub for Windows installed in user home >> directories. >> >> * A "FindGSL" module was introduced to find the GNU Scientific >> Library. >> >> * A "FindIntl" module was introduced to find the Gettext "libintl" >> library. >> >> * The "FindLATEX" module learned to support components. >> >> * The "FindMPI" module learned to find MS-MPI on Windows. >> >> * The "FindOpenSSL" module now reports "crypto" and "ssl" libraries >> separately in "OPENSSL_CRYPTO_LIBRARY" and "OPENSSL_SSL_LIBRARY", >> respectively, to allow applications to link to one without the >> other. >> >> * The "WriteCompilerDetectionHeader" module learned to create a >> define for portability of the "cxx_thread_local" feature. The define >> expands to either the C++11 "thread_local" keyword, or a pre- >> standardization compiler-specific equivalent, as appropriate. >> >> * The "WriteCompilerDetectionHeader" module learned to create >> multiple output files per compiler and per language, instead of >> creating one large file. >> >> >> CTest >> ----- >> >> * The "ctest_coverage()" command learned to support Delphi coverage. >> >> * The "ctest_coverage()" command learned to support Javascript >> coverage. >> >> * The "CTestCoverageCollectGCOV" module was introduced as an >> alternative to the "ctest_coverage()" command for collecting "gcov" >> results for submission to CDash. >> >> >> CPack >> ----- >> >> * The "CPackRPM" module learned options to set per-component >> descriptions and summaries. See the >> "CPACK_RPM__PACKAGE_DESCRIPTION" and >> "CPACK_RPM__PACKAGE_SUMMARY" variables. >> >> * The "CPackRPM" module learned options to specify requirements for >> pre- and post-install scripts. See the >> "CPACK_RPM_PACKAGE_REQUIRES_PRE" and >> "CPACK_RPM_PACKAGE_REQUIRES_POST" variables. >> >> * The "CPackRPM" module learned options to specify requirements for >> pre- and post-uninstall scripts. See the >> "CPACK_RPM_PACKAGE_REQUIRES_PREUN" and >> "CPACK_RPM_PACKAGE_REQUIRES_POSTUN" variables. >> >> * The "CPackRPM" module learned a new >> "CPACK_RPM__PACKAGE_PREFIX" variable to specify a >> component-specific value to use instead of >> "CPACK_PACKAGING_INSTALL_PREFIX". >> >> * The "CPackRPM" module learned a new "CPACK_RPM_RELOCATION_PATHS" >> variable to specify multiple relocation prefixes for a single rpm >> package. >> >> >> Other >> ----- >> >> * The "cmake(1)" "-E tar" command now supports creating >> ".xz"-compressed archives with the "J" flag. >> >> * The "cmake(1)" "-E tar" command learned a new "--files- >> from=" option to specify file names using lines in a file to >> overcome command-line length limits. >> >> * The "cmake(1)" "-E tar" command learned a new "--mtime=" >> option to specify the modification time recorded in tarball entries. >> >> * The "Compile Features" functionality is now aware of features >> supported by more compilers, including: >> >> * Apple Clang ("AppleClang") for Xcode versions 4.4 though 6.1. >> >> * GNU compiler versions 4.4 through 5.0 on UNIX and Apple ("GNU"). >> >> * Microsoft Visual Studio ("MSVC") for versions 2010 through 2015. >> >> * Oracle SolarisStudio ("SunPro") version 12.4. >> >> * The *AUTORCC* feature now tracks files listed in ".qrc" files as >> dependencies. If an input file to the "rcc" tool is changed, the >> tool is automatically re-run. >> >> >> New Diagnostics >> =============== >> >> * The "break()" command now rejects calls outside of a loop context >> or that pass arguments to the command. See policy "CMP0055". >> >> >> Deprecated and Removed Features >> =============================== >> >> * Files written in the "cmake-language(7)", such as "CMakeLists.txt" >> or "*.cmake" files, are now expected to be encoded as UTF-8. If >> files are already ASCII, they will be compatible. If files were in >> a different encoding, including Latin 1, they will need to be >> converted. >> >> * The "FindOpenGL" module no longer explicitly searches for any >> dependency on X11 libraries with the "FindX11" module. Such >> dependencies should not need to be explicit. Applications using X11 >> APIs themselves should find and link to X11 libraries explicitly. >> >> * The implementation of CMake now relies on some C++ compiler >> features which are not supported by some older compilers. As a >> result, those old compilers can no longer be used to build CMake >> itself. CMake continues to be able to generate Makefiles and >> project files for users of those old compilers however. Compilers >> known to no longer be capable of building CMake are: >> >> * Visual Studio 6 and 7.0 -- superseded by VisualStudio 7.1 and >> newer. >> >> * GCC 2.95 -- superseded by GCC 3 and newer compilers. >> >> * Borland compilers -- superseded by other Windows compilers. >> >> * Compaq compilers -- superseded by other compilers. >> >> * SGI compilers -- IRIX was dropped as a host platform. >> >> >> Other Changes >> ============= >> >> * On Windows and OS X, commands supporting network communication via >> "https", such as "file(DOWNLOAD)", "file(UPLOAD)", and >> "ctest_submit()", now support SSL/TLS even when CMake is not built >> against OpenSSL. The Windows or OS X native SSL/TLS implementation >> is used by default. OS-configured certificate authorities will be >> trusted automatically. >> >> On other platforms, when CMake is built with OpenSSL, these commands >> now search for OS-configured certificate authorities in a few "/etc" >> paths to be trusted automatically. >> >> * On OS X with Makefile and Ninja generators, when a compiler is >> found in "/usr/bin" it is now mapped to the corresponding compiler >> inside the Xcode application folder, if any. This allows such build >> trees to continue to work with their original compiler even when >> "xcode- select" switches to a different Xcode installation. >> >> * The Visual Studio generators now write solution and project files >> in UTF-8 instead of Windows-1252. Windows-1252 supported Latin 1 >> languages such as those found in North and South America and Western >> Europe. With UTF-8, additional languages are now supported. >> >> * The "Xcode" generator no longer requires a value for the >> "CMAKE_MAKE_PROGRAM" variable to be located up front. It now locates >> "xcodebuild" when needed at build time. >> >> * When building CMake itself using SolarisStudio 12, the default >> "libCStd" standard library is not sufficient to build CMake. The >> SolarisStudio distribution supports compiler options to use >> "STLPort4" or "libstdc++". An appropriate option to select the >> standard library is now added automatically when building CMake with >> SolarisStudio compilers. >> >> ------------------------------------------------------------------- >> >> Changes made since CMake 3.1.0-rc1: >> >> Brad King (8): >> Help: Revise configure_file documentation (#15403) >> Help: In 3.2 relnotes move OpenGL/X11 to deprecated/removed section >> Utilities/Release: Build OS X and Win binaries without OpenSSL >> cmake-gui: Reset generator platform and toolset on configure (#15411) >> FindJsonCpp: Drop new module due to upstream jsoncpp providing package >> bootstrap: Add --(no-)system-jsoncpp options >> FindCurses: Drop unused check for cbreak in tinfo library >> CMake 3.2.0-rc2 >> >> Tiago St?rmer Daitx (1): >> FindJNI: Add arch-specific library dir for JDK 9 layout (#15408) >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake-developers From m.espak at ucl.ac.uk Wed Feb 25 09:50:00 2015 From: m.espak at ucl.ac.uk (Miklos Espak) Date: Wed, 25 Feb 2015 14:50:00 +0000 Subject: [CMake] external project add, clone without history Message-ID: Hi, is it possible to specify the --depth 1 argument in ExternalProject_Add for cloning projects from git? Cheers, Miklos -------------- next part -------------- An HTML attachment was scrubbed... URL: From roman.wueger at gmx.at Wed Feb 25 12:10:43 2015 From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=) Date: Wed, 25 Feb 2015 18:10:43 +0100 Subject: [CMake] [cmake-developers] [ANNOUNCE] CMake 3.2.0-rc2 now ready for testing! In-Reply-To: References: Message-ID: <88A622F3-B593-4FCF-8357-3A6CD88EAF04@gmx.at> Thank you very much > Am 25.02.2015 um 15:12 schrieb Robert Maynard : > > Hi Roman, > > We do attach the short-log of all changes made between each RC version > to the bottom of the annoucement. But here are the changes plus the > git SHA1's for each ( produced with git log --no-merges --oneline > v3.2.0-rc1..v3.2.0-rc2) > > 99575c9 CMake 3.2.0-rc2 > b4005a3 FindCurses: Drop unused check for cbreak in tinfo library > a41d621 bootstrap: Add --(no-)system-jsoncpp options > a576844 FindJsonCpp: Drop new module due to upstream jsoncpp providing package > 1ade687 cmake-gui: Reset generator platform and toolset on configure (#15411) > 7e6608f Utilities/Release: Build OS X and Win binaries without OpenSSL > bce4e20 FindJNI: Add arch-specific library dir for JDK 9 layout (#15408) > 6d19ef9 Help: In 3.2 relnotes move OpenGL/X11 to deprecated/removed section > 029d38f Help: Revise configure_file documentation (#15403) > >> On Wed, Feb 25, 2015 at 9:07 AM, Roman W?ger wrote: >> Hello Robert, >> >> is there a list which showing the changes between rc1 and rc2, to test such things explicitly? >> >> Regards >> Roman >> >> >>> Am 24.02.2015 um 16:01 schrieb Robert Maynard : >>> >>> I am proud to announce the CMake 3.2 second release candidate. >>> >>> Sources and binaries are available at: >>> http://www.cmake.org/download/ >>> http://www.cmake.org/files/v3.2/?C=M;O=D >>> >>> Documentation is available at: >>> http://www.cmake.org/cmake/help/v3.2 >>> >>> Release notes appear below and are also published at >>> http://www.cmake.org/cmake/help/v3.2/release/3.2.html >>> Some of the more significant features of CMake 3.2 are: >>> >>> * CMake learned to support unicode characters *encoded as UTF-8* on >>> Windows. This was already supported on platforms whose system APIs >>> accept UTF-8 encoded strings. Unicode characters may now be used in >>> CMake code, paths to source files, configured files such as ".h.in" >>> files, and other files read and written by CMake. Note that because >>> CMake interoperates with many other tools, there may still be some >>> limitations when using certain unicode characters. >>> >>> * The "Compile Features" functionality is now aware of features >>> supported by more compilers, including: >>> >>> * Apple Clang ("AppleClang") for Xcode versions 4.4 though 6.1. >>> >>> * GNU compiler versions 4.4 through 5.0 on UNIX and Apple ("GNU"). >>> >>> * Microsoft Visual Studio ("MSVC") for versions 2010 through 2015. >>> >>> * Oracle SolarisStudio ("SunPro") version 12.4. >>> >>> * The "add_custom_command()" and "add_custom_target()" commands >>> learned a new "BYPRODUCTS" option to specify files produced as side >>> effects of the custom commands. These are not outputs because they >>> do not always have to be newer than inputs. >>> >>> * The "file(GENERATE)" command can now generate files which are used >>> as source files for buildsystem targets. Generated files >>> automatically get their "GENERATED" property set to "TRUE". >>> >>> Deprecated and Removed Features: >>> >>> * Files written in the "cmake-language(7)", such as "CMakeLists.txt" >>> or "*.cmake" files, are now expected to be encoded as UTF-8. If >>> files are already ASCII, they will be compatible. If files were in >>> a different encoding, including Latin 1, they will need to be >>> converted. >>> >>> * The "FindOpenGL" module no longer explicitly searches for any >>> dependency on X11 libraries with the "FindX11" module. Such >>> dependencies should not need to be explicit. Applications using X11 >>> APIs themselves should find and link to X11 libraries explicitly. >>> >>> >>> CMake 3.2 Release Notes >>> *********************** >>> >>> Changes made since CMake 3.1 include the following. >>> >>> >>> New Features >>> ============ >>> >>> >>> Syntax >>> ------ >>> >>> * CMake learned to support unicode characters *encoded as UTF-8* on >>> Windows. This was already supported on platforms whose system APIs >>> accept UTF-8 encoded strings. Unicode characters may now be used in >>> CMake code, paths to source files, configured files such as ".h.in" >>> files, and other files read and written by CMake. Note that because >>> CMake interoperates with many other tools, there may still be some >>> limitations when using certain unicode characters. >>> >>> >>> Commands >>> -------- >>> >>> * The "add_custom_command()" and "add_custom_target()" commands >>> learned a new "BYPRODUCTS" option to specify files produced as side >>> effects of the custom commands. These are not outputs because they >>> do not always have to be newer than inputs. >>> >>> * The "add_custom_command()" and "add_custom_target()" commands >>> learned a new "USES_TERMINAL" option to request that the command be >>> given direct access to the terminal if possible. The "Ninja" >>> generator will places such commands in the "console" "pool". Build >>> targets provided by CMake that are meant for individual interactive >>> use, such as "install", are now placed in this pool. >>> >>> * A new "continue()" command was added that can be called inside >>> loop contexts to end the current iteration and start the next one at >>> the top of the loop block. >>> >>> * The "file(LOCK)" subcommand was created to allow CMake processes >>> to synchronize through file and directory locks. >>> >>> * The "file(STRINGS)" now supports UTF-16LE, UTF-16BE, UTF-32LE, >>> UTF- 32BE as "ENCODING" options. >>> >>> * The "install(EXPORT)" command now works with an absolute >>> "DESTINATION" even if targets in the export set are installed with a >>> destination or *usage requirements* specified relative to the >>> install prefix. The value of the "CMAKE_INSTALL_PREFIX" variable is >>> hard-coded into the installed export file as the base for relative >>> references. >>> >>> * The "try_compile()" command source file signature now honors link >>> flags (e.g. "CMAKE_EXE_LINKER_FLAGS") in the generated test project. >>> See policy "CMP0056". >>> >>> * The "try_run()" command learned to honor the "LINK_LIBRARIES" >>> option just as "try_compile()" already does. >>> >>> * The "file(GENERATE)" command now generates the output file with >>> the same permissions as the input file if set. >>> >>> * The "file(GENERATE)" command can now generate files which are used >>> as source files for buildsystem targets. Generated files >>> automatically get their "GENERATED" property set to "TRUE". >>> >>> >>> Variables >>> --------- >>> >>> * The "CMAKE_MATCH_COUNT" variable was introduced to record the >>> number of matches made in the last regular expression matched in an >>> "if()" command or a "string()" command. >>> >>> >>> Properties >>> ---------- >>> >>> * An "ANDROID_API_MIN" target property was introduced to specify the >>> minimum version to be targeted by the toolchain. >>> >>> * A "VS_SHADER_FLAGS" source file property was added to specify >>> additional shader flags to ".hlsl" files, for the Visual Studio >>> generators. >>> >>> >>> Modules >>> ------- >>> >>> * The "ExternalData" module learned to support *Custom Fetch >>> Scripts*. This allows projects to specify custom ".cmake" scripts >>> for fetching data objects during the build. >>> >>> * The "ExternalProject" module learned options to create independent >>> external project step targets that do not depend on the builtin >>> steps. >>> >>> * The "ExternalProject" module "ExternalProject_Add()" command >>> learned a new "CMAKE_CACHE_DEFAULT_ARGS" option to initialize cache >>> values in the external project without setting them on future >>> builds. >>> >>> * The "ExternalProject" module "ExternalProject_Add()" command >>> learned a new "TEST_EXCLUDE_FROM_MAIN" option to exclude tests from >>> the main build. >>> >>> * The "ExternalProject" module "ExternalProject_Add()" command >>> learned a new "UPDATE_DISCONNECTED" option to avoid automatically >>> updating the source tree checkout from version control. >>> >>> * The "FindCUDA" module learned about the "cusolver" library in CUDA >>> 7.0. >>> >>> * The "FindGit" module learned to find the "git" command-line tool >>> that comes with GitHub for Windows installed in user home >>> directories. >>> >>> * A "FindGSL" module was introduced to find the GNU Scientific >>> Library. >>> >>> * A "FindIntl" module was introduced to find the Gettext "libintl" >>> library. >>> >>> * The "FindLATEX" module learned to support components. >>> >>> * The "FindMPI" module learned to find MS-MPI on Windows. >>> >>> * The "FindOpenSSL" module now reports "crypto" and "ssl" libraries >>> separately in "OPENSSL_CRYPTO_LIBRARY" and "OPENSSL_SSL_LIBRARY", >>> respectively, to allow applications to link to one without the >>> other. >>> >>> * The "WriteCompilerDetectionHeader" module learned to create a >>> define for portability of the "cxx_thread_local" feature. The define >>> expands to either the C++11 "thread_local" keyword, or a pre- >>> standardization compiler-specific equivalent, as appropriate. >>> >>> * The "WriteCompilerDetectionHeader" module learned to create >>> multiple output files per compiler and per language, instead of >>> creating one large file. >>> >>> >>> CTest >>> ----- >>> >>> * The "ctest_coverage()" command learned to support Delphi coverage. >>> >>> * The "ctest_coverage()" command learned to support Javascript >>> coverage. >>> >>> * The "CTestCoverageCollectGCOV" module was introduced as an >>> alternative to the "ctest_coverage()" command for collecting "gcov" >>> results for submission to CDash. >>> >>> >>> CPack >>> ----- >>> >>> * The "CPackRPM" module learned options to set per-component >>> descriptions and summaries. See the >>> "CPACK_RPM__PACKAGE_DESCRIPTION" and >>> "CPACK_RPM__PACKAGE_SUMMARY" variables. >>> >>> * The "CPackRPM" module learned options to specify requirements for >>> pre- and post-install scripts. See the >>> "CPACK_RPM_PACKAGE_REQUIRES_PRE" and >>> "CPACK_RPM_PACKAGE_REQUIRES_POST" variables. >>> >>> * The "CPackRPM" module learned options to specify requirements for >>> pre- and post-uninstall scripts. See the >>> "CPACK_RPM_PACKAGE_REQUIRES_PREUN" and >>> "CPACK_RPM_PACKAGE_REQUIRES_POSTUN" variables. >>> >>> * The "CPackRPM" module learned a new >>> "CPACK_RPM__PACKAGE_PREFIX" variable to specify a >>> component-specific value to use instead of >>> "CPACK_PACKAGING_INSTALL_PREFIX". >>> >>> * The "CPackRPM" module learned a new "CPACK_RPM_RELOCATION_PATHS" >>> variable to specify multiple relocation prefixes for a single rpm >>> package. >>> >>> >>> Other >>> ----- >>> >>> * The "cmake(1)" "-E tar" command now supports creating >>> ".xz"-compressed archives with the "J" flag. >>> >>> * The "cmake(1)" "-E tar" command learned a new "--files- >>> from=" option to specify file names using lines in a file to >>> overcome command-line length limits. >>> >>> * The "cmake(1)" "-E tar" command learned a new "--mtime=" >>> option to specify the modification time recorded in tarball entries. >>> >>> * The "Compile Features" functionality is now aware of features >>> supported by more compilers, including: >>> >>> * Apple Clang ("AppleClang") for Xcode versions 4.4 though 6.1. >>> >>> * GNU compiler versions 4.4 through 5.0 on UNIX and Apple ("GNU"). >>> >>> * Microsoft Visual Studio ("MSVC") for versions 2010 through 2015. >>> >>> * Oracle SolarisStudio ("SunPro") version 12.4. >>> >>> * The *AUTORCC* feature now tracks files listed in ".qrc" files as >>> dependencies. If an input file to the "rcc" tool is changed, the >>> tool is automatically re-run. >>> >>> >>> New Diagnostics >>> =============== >>> >>> * The "break()" command now rejects calls outside of a loop context >>> or that pass arguments to the command. See policy "CMP0055". >>> >>> >>> Deprecated and Removed Features >>> =============================== >>> >>> * Files written in the "cmake-language(7)", such as "CMakeLists.txt" >>> or "*.cmake" files, are now expected to be encoded as UTF-8. If >>> files are already ASCII, they will be compatible. If files were in >>> a different encoding, including Latin 1, they will need to be >>> converted. >>> >>> * The "FindOpenGL" module no longer explicitly searches for any >>> dependency on X11 libraries with the "FindX11" module. Such >>> dependencies should not need to be explicit. Applications using X11 >>> APIs themselves should find and link to X11 libraries explicitly. >>> >>> * The implementation of CMake now relies on some C++ compiler >>> features which are not supported by some older compilers. As a >>> result, those old compilers can no longer be used to build CMake >>> itself. CMake continues to be able to generate Makefiles and >>> project files for users of those old compilers however. Compilers >>> known to no longer be capable of building CMake are: >>> >>> * Visual Studio 6 and 7.0 -- superseded by VisualStudio 7.1 and >>> newer. >>> >>> * GCC 2.95 -- superseded by GCC 3 and newer compilers. >>> >>> * Borland compilers -- superseded by other Windows compilers. >>> >>> * Compaq compilers -- superseded by other compilers. >>> >>> * SGI compilers -- IRIX was dropped as a host platform. >>> >>> >>> Other Changes >>> ============= >>> >>> * On Windows and OS X, commands supporting network communication via >>> "https", such as "file(DOWNLOAD)", "file(UPLOAD)", and >>> "ctest_submit()", now support SSL/TLS even when CMake is not built >>> against OpenSSL. The Windows or OS X native SSL/TLS implementation >>> is used by default. OS-configured certificate authorities will be >>> trusted automatically. >>> >>> On other platforms, when CMake is built with OpenSSL, these commands >>> now search for OS-configured certificate authorities in a few "/etc" >>> paths to be trusted automatically. >>> >>> * On OS X with Makefile and Ninja generators, when a compiler is >>> found in "/usr/bin" it is now mapped to the corresponding compiler >>> inside the Xcode application folder, if any. This allows such build >>> trees to continue to work with their original compiler even when >>> "xcode- select" switches to a different Xcode installation. >>> >>> * The Visual Studio generators now write solution and project files >>> in UTF-8 instead of Windows-1252. Windows-1252 supported Latin 1 >>> languages such as those found in North and South America and Western >>> Europe. With UTF-8, additional languages are now supported. >>> >>> * The "Xcode" generator no longer requires a value for the >>> "CMAKE_MAKE_PROGRAM" variable to be located up front. It now locates >>> "xcodebuild" when needed at build time. >>> >>> * When building CMake itself using SolarisStudio 12, the default >>> "libCStd" standard library is not sufficient to build CMake. The >>> SolarisStudio distribution supports compiler options to use >>> "STLPort4" or "libstdc++". An appropriate option to select the >>> standard library is now added automatically when building CMake with >>> SolarisStudio compilers. >>> >>> ------------------------------------------------------------------- >>> >>> Changes made since CMake 3.1.0-rc1: >>> >>> Brad King (8): >>> Help: Revise configure_file documentation (#15403) >>> Help: In 3.2 relnotes move OpenGL/X11 to deprecated/removed section >>> Utilities/Release: Build OS X and Win binaries without OpenSSL >>> cmake-gui: Reset generator platform and toolset on configure (#15411) >>> FindJsonCpp: Drop new module due to upstream jsoncpp providing package >>> bootstrap: Add --(no-)system-jsoncpp options >>> FindCurses: Drop unused check for cbreak in tinfo library >>> CMake 3.2.0-rc2 >>> >>> Tiago St?rmer Daitx (1): >>> FindJNI: Add arch-specific library dir for JDK 9 layout (#15408) >>> -- >>> >>> Powered by www.kitware.com >>> >>> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ >>> >>> Kitware offers various services to support the CMake community. For more information on each offering, please visit: >>> >>> CMake Support: http://cmake.org/cmake/help/support.html >>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>> >>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html >>> >>> Follow this link to subscribe/unsubscribe: >>> http://public.kitware.com/mailman/listinfo/cmake-developers From zbeekman at gmail.com Wed Feb 25 13:58:17 2015 From: zbeekman at gmail.com (Zaak Beekman) Date: Wed, 25 Feb 2015 18:58:17 +0000 Subject: [CMake] fortran modules and parallel builds Message-ID: When multiple executables or libraries depend on the same fortran source file that contains a module, parallel (Makefile) builds are failing for me because the .mod file is getting moved/renamed/written by more than one process at a time. Is there a way to have the same module containing sourcefile listed as one of the sources for multiple executable and/or library targets without this happening? Right now my work around/hack is change the Fortran_MODULE_DIRECTORY property to something unique for each target, but this is a pain, and very sloppy. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Wed Feb 25 16:22:56 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 25 Feb 2015 16:22:56 -0500 Subject: [CMake] fortran modules and parallel builds In-Reply-To: References: Message-ID: <54EE3D30.3060402@kitware.com> On 02/25/2015 01:58 PM, Zaak Beekman wrote: > When multiple executables or libraries depend on the same > fortran source file that contains a module, parallel (Makefile) > builds are failing for me because the .mod file is getting > moved/renamed/written by more than one process at a time. Is > there a way to have the same module containing sourcefile > listed as one of the sources for multiple executable and/or > library targets without this happening? Right now my work > around/hack is change the Fortran_MODULE_DIRECTORY property to > something unique for each target, but this is a pain, and very > sloppy. If a source is listed in multiple targets then it is compiled separately for each target. If that source provides a module then one *must* use a distinct Fortran_MODULE_DIRECTORY for each one or it not well-defined what provides the .mod file, hence your conflict. If you really only want to compile the source once but use it from multiple executables then you should put it in a static library instead: add_library(mymod STATIC mymod.F90) add_executable(myexe1 myexe1.F90) target_link_libraries(myexe1 mymod) add_executable(myexe2 myexe2.F90) target_link_libraries(myexe1 mymod) Then there will be only one compilation of the module-providing source. CMake will hook up the dependencies so that the exe sources do not compile before the module is made available by compiling the library. -Brad From steveire at gmail.com Wed Feb 25 16:45:09 2015 From: steveire at gmail.com (Stephen Kelly) Date: Wed, 25 Feb 2015 22:45:09 +0100 Subject: [CMake] can I make an AUTOMOC generated file depend on something ? References: <1505810.OWG1IaMX4b@lapi.koller> Message-ID: Kim Rydhof Thor Hansen wrote: > http://www.cmake.org/cmake/help/v3.0/prop_tgt/AUTOGEN_TARGET_DEPENDS.html > > I have a similar problem because automoc doesn't pick up that my > metadata.json file is a dependency to the generated moc_plugin.cpp > when building a Qt plugin Thanks for the testcase. I filed http://public.kitware.com/Bug/view.php?id=15419 with more information on what should be done to fix this. Thanks, Steve. From becker.tobi at gmail.com Wed Feb 25 17:57:48 2015 From: becker.tobi at gmail.com (Tobias Becker) Date: Wed, 25 Feb 2015 23:57:48 +0100 Subject: [CMake] load_command not scriptable In-Reply-To: References: Message-ID: Thanks for the Answer! I actually do not want to alter CMake in any way (and I don't want to create a custom cmake executable) if possible. load_command would have been perfekt. I am losing alot of performance in my map_set() map_get() etc functions which translate down to set_property(GLOBAL...) and get_property(GLOBAL) I am further losing especially much performance when using my eval() function which dynamically runs cmake code and on which alot of my lib is based as it is the basis for dynamic method calls, objects&inheritance, callbacks, events etc. I have already condensed down my functions to work with the minimal cmake script statements possible the only way to further improve is by creating a C/C++ cmake command. The problem is: I have so many function calls that the time it takes is not negligable any more I guess the only viable and platform independent solution is - as you wrote - to create a cmake with some custom command which replaces the users current cmake. Performance Comparison (cmake code): timer_start(t1) foreach(i RANGE 0 10000) map_set(asd "${i}" "${i}") endforeach() timer_print_elapsed(t1) ## almost equivalent code timer_start(t2) foreach(i RANGE 0 10000) set_property(GLOBAL PROPERTY "asd.${i}" ${I}) set_property(GLOBAL APPEND PROPERTY "asd" ${i}) endforeach() timer_print_elapsed(t2) timer_start(t3) foreach(i RANGE 0 10000) eval("") endforeach() timer_print_elapsed(t3) output: t1: 2038 ms t2: 204 ms t3: 9424 ms On Wed, Feb 25, 2015 at 1:21 PM, David Cole wrote: > You could patch the executable to make cmLoadCommandCommand return > true from IsScriptable... but if you're going to the trouble of > patching CMake anyhow, why not simply build your loadable command > directly into CMake...? > > The other thing might be to mention specifically what the performance > problem is on the mailing list here to see if anybody has any ideas > how we could make things faster..... And totally preclude your need to > load an additional command in the first place. > > Or profile it and submit a patch to improve the performance in this > situation. > > > HTH, > David C. > > > > On Wed, Feb 25, 2015 at 5:46 AM, Tobias Becker > wrote: > > Hi > > > > I've been working on an open source project which provides alot of extra > > cmake (in pure cmake) https://github.com/toeb/cmakepp. I am however > hitting > > a performance bottleneck and want to get around that by using > load_command > > (I know it is discouraged) however I have the problem that it is not > > scriptable and all of my functions need to be available in script mode. > > > > Is there a way to load compiled commands into cmake after it was > compiled? > > (I have even thinking about patching the executable to make > > cmLoadCommandCommand return true in its IsScriptable method) > > > > But there should be a simple way? > > > > > > Cheers, > > > > Tobias > > > > -- > > > > 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 calebwherry at gmail.com Wed Feb 25 18:32:38 2015 From: calebwherry at gmail.com (J. Caleb Wherry) Date: Wed, 25 Feb 2015 18:32:38 -0500 Subject: [CMake] external project add, clone without history In-Reply-To: References: Message-ID: Miklos, I did a quick test and using the DOWNLOAD_COMMAND option to ExternalProject_Add works nicely: ExternalProject_Add(sfml PREFIX ${sfml_PREFIX} DOWNLOAD_COMMAND git clone --depth 1 https://github.com/LaurentGomila/SFML.git INSTALL_DIR ${sfml_INSTALL_DIR} CMAKE_ARGS ${sfml_CMAKE_ARGS} ) I could not, however, get it to work along with specifying the GIT_REPOSITORY option. I believe this is because using the DOWNLOAD_COMMAND completely overrides all other download options. I think this is the best way to get what you want. I'm surprised no one else has commented since cloning a git repo with submodules needs the 'recursive' option to actually pull in the submodule code. It's a similar problem you are facing with needing to pass in extra options to the download executable. -Caleb On Wed, Feb 25, 2015 at 9:50 AM, Miklos Espak wrote: > Hi, > > is it possible to specify the --depth 1 argument in ExternalProject_Add > for cloning projects from git? > > Cheers, > Miklos > > > -- > > 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 > -- J. Caleb Wherry *Scientific Software Engineer* http://www.calebwherry.com +1 (615) 708-5651 calebwherry at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From calebwherry at gmail.com Wed Feb 25 18:36:34 2015 From: calebwherry at gmail.com (J. Caleb Wherry) Date: Wed, 25 Feb 2015 18:36:34 -0500 Subject: [CMake] external project add, clone without history In-Reply-To: References: Message-ID: Actually, scratch my last comment and submodules. There looks to be a GIT_SUBMODULES option that says if not given, all submodules will be updated. I am assuming that means the CMake passes in the --recursive option automatically when cloning. Haven't tested it yet though... -Caleb On Wed, Feb 25, 2015 at 9:50 AM, Miklos Espak wrote: > Hi, > > is it possible to specify the --depth 1 argument in ExternalProject_Add > for cloning projects from git? > > Cheers, > Miklos > > > -- > > 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 > -- J. Caleb Wherry *Scientific Software Engineer* http://www.calebwherry.com +1 (615) 708-5651 calebwherry at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.espak at ucl.ac.uk Wed Feb 25 18:42:14 2015 From: m.espak at ucl.ac.uk (Miklos Espak) Date: Wed, 25 Feb 2015 23:42:14 +0000 Subject: [CMake] external project add, clone without history In-Reply-To: References: Message-ID: That's great, I will try that. Thanks very much, Miklos On 25 February 2015 at 23:32, J. Caleb Wherry wrote: > Miklos, > > I did a quick test and using the DOWNLOAD_COMMAND option to > ExternalProject_Add works nicely: > > ExternalProject_Add(sfml > PREFIX ${sfml_PREFIX} > DOWNLOAD_COMMAND git clone --depth 1 > https://github.com/LaurentGomila/SFML.git > INSTALL_DIR ${sfml_INSTALL_DIR} > CMAKE_ARGS ${sfml_CMAKE_ARGS} > ) > > I could not, however, get it to work along with specifying the > GIT_REPOSITORY option. I believe this is because using the DOWNLOAD_COMMAND > completely overrides all other download options. > > I think this is the best way to get what you want. I'm surprised no one > else has commented since cloning a git repo with submodules needs the > 'recursive' option to actually pull in the submodule code. It's a similar > problem you are facing with needing to pass in extra options to the > download executable. > > -Caleb > > On Wed, Feb 25, 2015 at 9:50 AM, Miklos Espak wrote: > >> Hi, >> >> is it possible to specify the --depth 1 argument in ExternalProject_Add >> for cloning projects from git? >> >> Cheers, >> Miklos >> >> >> -- >> >> 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 >> > > > > -- > J. Caleb Wherry > *Scientific Software Engineer* > > > http://www.calebwherry.com > +1 (615) 708-5651 > calebwherry at gmail.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 nicolas.adamic at pskx.net Wed Feb 25 19:43:39 2015 From: nicolas.adamic at pskx.net (=?UTF-8?B?Tmljb2zDoXMgQWRhbWnEhw==?=) Date: Thu, 26 Feb 2015 01:43:39 +0100 Subject: [CMake] Listing generated source files in cmake project In-Reply-To: <54ED0E5E.7070702@topcon.com> References: <54ED0E5E.7070702@topcon.com> Message-ID: <54EE6C3B.9010305@pskx.net> On 02/25/2015 12:50 AM, Dmytro Poplavskiy wrote: > I have some source files generated as a part of build process, generated > using add_custom_command(). > Building works fine, but would be nice to have generated source files to > be displayed in IDE project (QtCreator using CodeBlocks generator). I'd like to know that, too. Very much. -- Nicol?s From omar.valerio at gmail.com Thu Feb 26 12:35:02 2015 From: omar.valerio at gmail.com (Omar Valerio) Date: Thu, 26 Feb 2015 18:35:02 +0100 Subject: [CMake] Problems with the cuda_link_separable_compilation_objects defined in FindCUDA.cmake module Message-ID: Hello list, Normally I use dynamic compilation in all my CMake projects with CUDA. But recently I found about CUFFT callbacks, and in order to use them I'm forced to compile against the cufft_static library, which means that I have to use the separate compilation functionality. After several attempts, I have got something that resembles close to what I want to do. However the cuda_link_separable_compilation_objects macro is somehow stripping the flags I want to pass to nvcc. I uploaded a test code in Github (https://github.com/ovalerio/thrust_fft.git), together with compilation instructions for the command line, and the CMake project file that I'm unable to get right. Interesting bits look as follows: set(CUDA_SEPARABLE_COMPILATION ON) cuda_compile(DEVICE_OBJS ${PROJECT_SRC} OPTIONS ${NVCC_OPTS}) cuda_compute_separable_compilation_object_file_name(LINK_OBJS thrust_fft ${DEVICE_OBJS}) cuda_link_separable_compilation_objects(${LINK_OBJS} thrust_fft ${NVCC_OPTS} ${DEVICE_OBJS} ${CUDA_LIBRARIES} ${CUFFT_STATIC_LIBRARY} ${CULIBOS_LIBRARY} ) This lines correspond to the following command line instructions: /usr/local/cuda-6.5/bin/nvcc src/thrust_fft_example.cu -dc -o thrust_fft_example.o -ccbin /usr/bin/gcc-4.6 -m64 -Xcompiler ,\"-g\",\"-L/usr/local/cuda-6.5/lib64\",\"-g\" -gencode=arch=compute_35,code=sm_35 -DNVCC -I/usr/local/cuda-6.5/include /usr/local/cuda-6.5/bin/nvcc -gencode=arch=compute_35,code=sm_35 -m64 -ccbin "/usr/bin/gcc-4.6" -dlink thrust_fft_example.o -o thrust_fft_example_link.o /usr/bin/c++ -g -L/usr/local/cuda-6.5/lib64 thrust_fft_example.o thrust_fft_example_link.o -o thrust_fft -rdynamic /usr/local/cuda-6.5/lib64/libcudart.so /usr/local/cuda-6.5/lib64/libcufft_static.a /usr/local/cuda-6.5/lib64/libculibos.a -Wl,-rpath,/usr/local/cuda-6.5/lib64: >From close inspection what is happening is that the second line from above, should instead read as: /usr/local/cuda-6.5/bin/nvcc -gencode=arch=compute_35,code=sm_35 -m64 -ccbin "/usr/bin/gcc-4.6" -dlink thrust_fft_example.o -o thrust_fft_example_link.o *-lcudart -lcufft_static* Notice that I have strip all the custom path names added by CMake. Big kudos to the CMake community and the module maintainers that make our work easier. Hopefully some of you can help me to figure this out. =) Cheers! -- Omar V.M. -------------- next part -------------- An HTML attachment was scrubbed... URL: From karo at cupdev.net Thu Feb 26 18:28:26 2015 From: karo at cupdev.net (Karolin Varner) Date: Fri, 27 Feb 2015 00:28:26 +0100 Subject: [CMake] find_library/find_path not working on mingw Message-ID: <54EFAC1A.2070406@cupdev.net> Hi, I am in the process of refactoring some build configuration for windows/mingw; the application I am working on heavily relies on find_library/find_path on linux and I am adding that for windows too. Neither of those functions seems to do anything when I am compiling with mingw though. Here is what I ended up tesing with: find_library(ZLIB_LIBRARY2 z zdll zdll.lib HINTS "/home/karo/pr0j/inexor/code/src/platform_windows/lib/common64") find_path(ZLIB_INCLUDE_DIR2 zlib.h PATHS "/home/karo/pr0j/inexor/code/src/platform_windows/include/") $ ls -l /home/karo/pr0j/inexor/code/src/platform_windows/lib/common64/zdll.lib /home/karo/pr0j/inexor/code/src/platform_windows/include/zlib.h -rw-r--r-- 1 karo karo 79564 Feb 1 15:01 /home/karo/pr0j/inexor/code/src/platform_windows/include/zlib.h -rw-r--r-- 1 karo karo 12900 Feb 26 21:31 /home/karo/pr0j/inexor/code/src/platform_windows/lib/common64/zdll.lib Not even that works! I've tried a couple different things before, including setting CMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH both as variables and in the environment. I did the same with the CMAKE_SYSTEM_* variables. But no matter what, the variables are always being set to ZLIB_LIBRARY2-NOTFOUND and ZLIB_INCLUDE_DIR2-NOTFOUND . Does anybody have an idea what this could be caused by? Thanks a lot! Karolin Varner From kim at rthansen.dk Fri Feb 27 03:54:08 2015 From: kim at rthansen.dk (Kim Rydhof Thor Hansen) Date: Fri, 27 Feb 2015 09:54:08 +0100 Subject: [CMake] can I make an AUTOMOC generated file depend on something ? In-Reply-To: References: <1505810.OWG1IaMX4b@lapi.koller> Message-ID: On Wed, Feb 25, 2015 at 10:45 PM, Stephen Kelly wrote: > Kim Rydhof Thor Hansen wrote: > >> http://www.cmake.org/cmake/help/v3.0/prop_tgt/AUTOGEN_TARGET_DEPENDS.html >> >> I have a similar problem because automoc doesn't pick up that my >> metadata.json file is a dependency to the generated moc_plugin.cpp >> when building a Qt plugin > > Thanks for the testcase. I filed > > http://public.kitware.com/Bug/view.php?id=15419 > > with more information on what should be done to fix this. Thanks for your work on this. I can't find a good workaround, I tried using autoget_target_depends without success but I suspect that it is because I have done something wrong. Can anyone suggest a line to put in CMakeLists.txt in order to manually register the dependency between metadata.json and moc_plugin.cpp? Regards, -- Kim Rydhof Thor Hansen Vadg?rdsvej 3, 2. tv. 2860 S?borg Phone: +45 3091 2437 From scott.bloom at onshorecs.com Fri Feb 27 10:44:54 2015 From: scott.bloom at onshorecs.com (Scott Aron Bloom) Date: Fri, 27 Feb 2015 15:44:54 +0000 Subject: [CMake] Multi-platform visual studio projects Message-ID: <6FD2E165340D9A429CF831C7A2D4F42E60068FAE@WIN-R92V03RFJ85.onshorecs.local> Is it possible with cmake, to build a VS 2013, win32 and win64 vsproj solution file set? If not, I understand, then I have a follow on question.. Once the two solutions have been built, does it matter how you bring up VS 2013? Or does it only matter for the initial running of cmake ? Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From drescherjm at gmail.com Fri Feb 27 11:06:29 2015 From: drescherjm at gmail.com (John Drescher) Date: Fri, 27 Feb 2015 11:06:29 -0500 Subject: [CMake] Multi-platform visual studio projects In-Reply-To: <6FD2E165340D9A429CF831C7A2D4F42E60068FAE@WIN-R92V03RFJ85.onshorecs.local> References: <6FD2E165340D9A429CF831C7A2D4F42E60068FAE@WIN-R92V03RFJ85.onshorecs.local> Message-ID: On Fri, Feb 27, 2015 at 10:44 AM, Scott Aron Bloom wrote: > Is it possible with cmake, to build a VS 2013, win32 and win64 vsproj > solution file set? > > If not, I understand, then I have a follow on question.. > No create 2 independent trees. I keep the source in a separate tree also. For example I have my source code in x:\CMakeBased\Libraries\ITK-4.7.0 x:\CMakeBased\Libraries\VTK-5.10.2 ... x:\CMakeBased\Qt\LungAnalysis x:\CMakeBased\Qt\StudyManager ... Where Libraries are source code libraries like ITK, VTK, GDCM, DCMTK ... And LungAnalysis, StudyManager ... are applications written by me. Then the build tress look like x:\64bit\VC.100\Libraries\ITK-4.7.0 x:\64bit\VC.100\Libraries\VTK-5.10.2 x:\64bit\VC.100\Qt\LungAnalysis ... x:\64bit\VC.120\Libraries\ITK-4.7.0 x:\64bit\VC.120\Libraries\VTK-5.10.2 x:\64bit\VC.120\Qt\LungAnalysis ... x:\32bit\VC.100\Libraries\ITK-4.7.0 x:\32bit\VC.100\Libraries\VTK-5.10.2 x:\32bit\VC.100\Qt\LungAnalysis John From scott.bloom at onshorecs.com Fri Feb 27 11:19:22 2015 From: scott.bloom at onshorecs.com (Scott Aron Bloom) Date: Fri, 27 Feb 2015 16:19:22 +0000 Subject: [CMake] Multi-platform visual studio projects In-Reply-To: References: <6FD2E165340D9A429CF831C7A2D4F42E60068FAE@WIN-R92V03RFJ85.onshorecs.local> Message-ID: <6FD2E165340D9A429CF831C7A2D4F42E600691B5@WIN-R92V03RFJ85.onshorecs.local> Thanks.. I have been successful with Src\build.32 and src\build.64 so that on svn update effects both. The problem, for my automated build flow, I was hoping to make a mix, 32/64 installer.. it?s a lot harder to do with two completely separate build trees :( As to my second question, and this is purely my newb'ness with 64 bit visual studio. I know, to us "cl.exe" you must run the "vsvars" with the correct parameters, either for 32 or 64, before running cmake from the command line. And to create the proper vcproj files you must append "Win64" to the generator name. However, once the solution is created, does the "path" of the shell matter at all? Scott -----Original Message----- From: John Drescher [mailto:drescherjm at gmail.com] Sent: Friday, February 27, 2015 8:06 AM To: Scott Aron Bloom Cc: cmake at cmake.org Subject: Re: [CMake] Multi-platform visual studio projects On Fri, Feb 27, 2015 at 10:44 AM, Scott Aron Bloom wrote: > Is it possible with cmake, to build a VS 2013, win32 and win64 vsproj > solution file set? > > If not, I understand, then I have a follow on question.. > No create 2 independent trees. I keep the source in a separate tree also. For example I have my source code in x:\CMakeBased\Libraries\ITK-4.7.0 x:\CMakeBased\Libraries\VTK-5.10.2 ... x:\CMakeBased\Qt\LungAnalysis x:\CMakeBased\Qt\StudyManager ... Where Libraries are source code libraries like ITK, VTK, GDCM, DCMTK ... And LungAnalysis, StudyManager ... are applications written by me. Then the build tress look like x:\64bit\VC.100\Libraries\ITK-4.7.0 x:\64bit\VC.100\Libraries\VTK-5.10.2 x:\64bit\VC.100\Qt\LungAnalysis ... x:\64bit\VC.120\Libraries\ITK-4.7.0 x:\64bit\VC.120\Libraries\VTK-5.10.2 x:\64bit\VC.120\Qt\LungAnalysis ... x:\32bit\VC.100\Libraries\ITK-4.7.0 x:\32bit\VC.100\Libraries\VTK-5.10.2 x:\32bit\VC.100\Qt\LungAnalysis John From drescherjm at gmail.com Fri Feb 27 11:25:36 2015 From: drescherjm at gmail.com (John Drescher) Date: Fri, 27 Feb 2015 11:25:36 -0500 Subject: [CMake] Multi-platform visual studio projects In-Reply-To: <6FD2E165340D9A429CF831C7A2D4F42E600691B5@WIN-R92V03RFJ85.onshorecs.local> References: <6FD2E165340D9A429CF831C7A2D4F42E60068FAE@WIN-R92V03RFJ85.onshorecs.local> <6FD2E165340D9A429CF831C7A2D4F42E600691B5@WIN-R92V03RFJ85.onshorecs.local> Message-ID: > However, once the solution is created, does the "path" of the shell matter at all? No. John From scott.bloom at onshorecs.com Fri Feb 27 11:26:17 2015 From: scott.bloom at onshorecs.com (Scott Aron Bloom) Date: Fri, 27 Feb 2015 16:26:17 +0000 Subject: [CMake] Multi-platform visual studio projects In-Reply-To: References: <6FD2E165340D9A429CF831C7A2D4F42E60068FAE@WIN-R92V03RFJ85.onshorecs.local> <6FD2E165340D9A429CF831C7A2D4F42E600691B5@WIN-R92V03RFJ85.onshorecs.local> Message-ID: <6FD2E165340D9A429CF831C7A2D4F42E60069275@WIN-R92V03RFJ85.onshorecs.local> Thanks! -----Original Message----- From: John Drescher [mailto:drescherjm at gmail.com] Sent: Friday, February 27, 2015 8:26 AM To: Scott Aron Bloom Cc: cmake at cmake.org Subject: Re: [CMake] Multi-platform visual studio projects > However, once the solution is created, does the "path" of the shell matter at all? No. John From drescherjm at gmail.com Fri Feb 27 11:32:48 2015 From: drescherjm at gmail.com (John Drescher) Date: Fri, 27 Feb 2015 11:32:48 -0500 Subject: [CMake] Multi-platform visual studio projects In-Reply-To: <6FD2E165340D9A429CF831C7A2D4F42E600691B5@WIN-R92V03RFJ85.onshorecs.local> References: <6FD2E165340D9A429CF831C7A2D4F42E60068FAE@WIN-R92V03RFJ85.onshorecs.local> <6FD2E165340D9A429CF831C7A2D4F42E600691B5@WIN-R92V03RFJ85.onshorecs.local> Message-ID: > I have been successful with > > Src\build.32 and src\build.64 so that on svn update effects both. > > The problem, for my automated build flow, I was hoping to make a mix, 32/64 installer.. it?s a lot harder to do with two completely separate build trees :( For this I just make separate installers. I use a naming convention such that win32 / win64 is part of the name of the generated nsis executable installer. John From adam.getchell at gmail.com Fri Feb 27 11:46:14 2015 From: adam.getchell at gmail.com (Adam Getchell) Date: Fri, 27 Feb 2015 08:46:14 -0800 Subject: [CMake] Setting build type In-Reply-To: References: Message-ID: Thanks for the help! It still runs Release mode: Here's my project: https://github.com/acgetchell/CDT-plusplus ??[*adam*][Hapkido][*?*][master *?*][~/CDT-plusplus] ??? tree . |____.git | |____config | |____description | |____HEAD | |____hooks | | |____applypatch-msg.sample | | |____commit-msg.sample | | |____post-update.sample | | |____pre-applypatch.sample | | |____pre-commit.sample | | |____pre-push.sample | | |____pre-rebase.sample | | |____prepare-commit-msg.sample | | |____update.sample | |____index | |____info | | |____exclude | |____logs | | |____HEAD | | |____refs | | | |____heads | | | | |____master | | | |____remotes | | | | |____origin | | | | | |____HEAD | |____objects | | |____info | | |____pack | | | |____pack-a9db5eb5c90025a8ca13bddf15822cb0e57cbead.idx | | | |____pack-a9db5eb5c90025a8ca13bddf15822cb0e57cbead.pack | |____packed-refs | |____refs | | |____heads | | | |____master | | |____remotes | | | |____origin | | | | |____HEAD | | |____tags |____.gitignore |____.travis-linux.yml |____.travis-macosx.yml |____.travis.yml |____build.sh |____CMakeLists.txt |____Doxyfile |____LICENSE |____README.md |____scan-build.sh |____src | |____cdt.cpp | |____Delaunay.h | |____docopt | | |____docopt.cpp | | |____docopt.h | | |____docopt_private.h | | |____docopt_util.h | | |____docopt_value.h | | |____examples | | | |____naval_fate.cpp | | |____LICENSE-Boost-1.0 | | |____LICENSE-MIT | | |____main.cpp | | |____README.rst | | |____run_testcase.cpp | | |____run_tests.py | | |____testcases.docopt | |____grid_d.cpp | |____grid_d.h | |____periodic_3_complex.h | |____periodic_3_triangulations.h | |____Point.h | |____S3Action.h | |____S3ErgodicMoves.h | |____S3Triangulation.h | |____sphere_d.h | |____utilities.h |____unittests | |____.gitignore | |____main.cpp | |____PointTest.cpp | |____S3BulkActionTest.cpp | |____S3ErgodicMovesTest.cpp | |____S3TetrahedronTest.cpp | |____SdTriangulationTest.cpp | |____SphereTest.cpp | |____Triangulated2SphereTest.cpp | |____VertexTest.cpp ??[*adam*][Hapkido][*?*][master *?*][~/CDT-plusplus] ??? mkdir build-d ??[*adam*][Hapkido][*?*][master *?*][~/CDT-plusplus] ??? cd build-d ??[*adam*][Hapkido][*?*][master *?*][~/CDT-plusplus/build-d] ??? cmake -DCMAKE_BUILD_TYPE=Debug -DCMAKE_INSTALL_PREFIX=out .. -- 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: /usr/bin/cc -- Check for working C compiler: /usr/bin/cc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Build type: Release -- USING CXXFLAGS = ' -O3 -DNDEBUG' -- USING EXEFLAGS = ' -Wl,-dylib_file,/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib:/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib ' -- Targetting Unix Makefiles -- Using /usr/bin/c++ compiler. -- DARWIN_VERSION=14 -- Mac Leopard detected -- Requested component: Core -- Requested component: MPFR -- Requested component: GMP -- Found Eigen3: /usr/local/include/eigen3 (found suitable version "3.2.4", minimum required is "3.1.0") -- Found Intel TBB -- Configuring done -- Generating done -- Build files have been written to: /Users/adam/CDT-plusplus/build-d ??[*adam*][Hapkido][*?*][master *?*][~/CDT-plusplus/build-d] On Wed, Feb 25, 2015 at 1:37 AM, J Decker wrote: > mkdir build-d > cd build-d > cmake > -DCMAKE_BUILD_TYPE=Debug -DCMAKE_INSTALL_PREFIX=out ../your/source/procject > cmake --build . > cd .. > > mkdir build-r > cd build-r > cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=out > ../your/source/procject > cmake --build . --target install > cd .. > > > On Wed, Feb 25, 2015 at 1:16 AM, Adam Getchell > wrote: > >> Thanks for your reply. >> >> I'm not sure I follow your answer. I do delete the directory each time I >> build, but I'm still not understanding how you're building release or debug >> versions to begin with. >> >> I'm just automatically getting Release, unless I edit CMakeCache.txt >> after I've built once. >> >> I just checked CGAL_CreateSingleSourceCGALProgram.cmake which is invoked >> in my CMakeLists.txt, but I do not see it setting the build type to Release. >> >> https://github.com/acgetchell/CDT-plusplus/blob/master/CMakeLists.txt >> >> >> >> On Tue, Feb 24, 2015 at 12:20 PM, J Decker wrote: >> >>> I use a different directory to build release and debug versions.... >>> >>> if you didn't delete, then when it goes to build partial things, the >>> .obj files will still be newer than the .c files and will cause mixed >>> release-debug builds which generally results in bizarre crashes. >>> Once chosen, can't change the build type of a build; although if you >>> could it should do a clean also. >>> >>> >>> On Tue, Feb 24, 2015 at 11:42 AM, Adam Getchell >> > wrote: >>> >>>> Hello all, >>>> >>>> I've browsed this thread: >>>> >>>> http://www.cmake.org/pipermail/cmake/2008-September/023808.html >>>> >>>> But it doesn't work. My project is set to Release regardless, whether I >>>> do: >>>> >>>> project( CDT-plusplus_ ) >>>> set(CMAKE_BUILD_TYPE RelWithDebInfo) >>>> >>>> Or: >>>> >>>> # >>>> # If the user specifies -DCMAKE_BUILD_TYPE on the command line, take >>>> their definition >>>> # and dump it in the cache along with proper documentation, otherwise >>>> set CMAKE_BUILD_TYPE >>>> # to Debug prior to calling PROJECT() >>>> # >>>> IF(DEFINED CMAKE_BUILD_TYPE) >>>> SET(CMAKE_BUILD_TYPE ${CMAKE_BUILD_TYPE} CACHE STRING "Choose the >>>> type of >>>> build, options are: None(CMAKE_CXX_FLAGS or CMAKE_C_FLAGS used) Debug >>>> Release RelWithDebInfo MinSizeRel.") >>>> ELSE() >>>> SET(CMAKE_BUILD_TYPE Debug CACHE STRING "Choose the type of build, >>>> options are: None(CMAKE_CXX_FLAGS or CMAKE_C_FLAGS used) Debug Release >>>> RelWithDebInfo MinSizeRel.") >>>> ENDIF() >>>> >>>> project( CDT-plusplus_ ) >>>> >>>> The only way I can change the build type is by going into my build >>>> directory and editing CMakeCache.txt. However, I use an out of source >>>> build, so my build directory is generated automatically by scripts such as: >>>> >>>> https://github.com/acgetchell/CDT-plusplus/blob/master/scan-build.sh >>>> >>>> What's the correct method for being able to set the type of build via >>>> the command line? >>>> >>>> -- >>>> Adam Getchell >>>> about.me/adamgetchell >>>> "Invincibility is in oneself, vulnerability in the opponent." -- Sun Tzu >>>> >>>> -- >>>> >>>> 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 >>>> >>> >>> >> >> >> -- >> Adam Getchell >> about.me/adamgetchell >> "Invincibility is in oneself, vulnerability in the opponent." -- Sun Tzu >> > > -- Adam Getchell about.me/adamgetchell "Invincibility is in oneself, vulnerability in the opponent." -- Sun Tzu -------------- next part -------------- An HTML attachment was scrubbed... URL: From scott.bloom at onshorecs.com Fri Feb 27 11:47:07 2015 From: scott.bloom at onshorecs.com (Scott Aron Bloom) Date: Fri, 27 Feb 2015 16:47:07 +0000 Subject: [CMake] Multi-platform visual studio projects In-Reply-To: References: <6FD2E165340D9A429CF831C7A2D4F42E60068FAE@WIN-R92V03RFJ85.onshorecs.local> <6FD2E165340D9A429CF831C7A2D4F42E600691B5@WIN-R92V03RFJ85.onshorecs.local> Message-ID: <6FD2E165340D9A429CF831C7A2D4F42E60069330@WIN-R92V03RFJ85.onshorecs.local> That?s what I have been doing... :( -----Original Message----- From: John Drescher [mailto:drescherjm at gmail.com] Sent: Friday, February 27, 2015 8:33 AM To: Scott Aron Bloom; CMake ML Subject: Re: [CMake] Multi-platform visual studio projects > I have been successful with > > Src\build.32 and src\build.64 so that on svn update effects both. > > The problem, for my automated build flow, I was hoping to make a mix, > 32/64 installer.. it?s a lot harder to do with two completely separate > build trees :( For this I just make separate installers. I use a naming convention such that win32 / win64 is part of the name of the generated nsis executable installer. John From derek.cole at gmail.com Fri Feb 27 16:03:07 2015 From: derek.cole at gmail.com (Derek Cole) Date: Fri, 27 Feb 2015 16:03:07 -0500 Subject: [CMake] creating a DLL with an OpenCV dependency Message-ID: Hello, I have posted my question here because I forgot I was on this mailing list: http://stackoverflow.com/questions/28773650/cmake-for-windows-dll-with-opencv-project there you can find my Cmakelists.txt and some code snippets. This is my first time trying to build a DLL for windows with CMAKE. The gist of my problem is I am generating a .dll file, manifests, etc, but I am unable to load it using jsctypes and it is not giving me much error output other than "couldn't open dll" I would just like to find a way that my DLL is built correctly, before I switch to trying to build my project with VS2012 Thanks, Derek -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.amaclean at gmail.com Sat Feb 28 23:51:06 2015 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Sun, 1 Mar 2015 15:51:06 +1100 Subject: [CMake] FindMPI.cmake and MS-MPI Message-ID: I downloaded and installed MS-MPI from http://www.microsoft.com/en-us/download/details.aspx?id=44990 This implementation does not work with FindMPI.cmake. The includes and libs are found in: C:/Program Files (x86)/Microsoft SDKs/MPI/ and mpiexec.exe is in: C:/Program Files/Microsoft MPI/Bin/ I had to do the following changes to get it working. Perhaps you would like to edit FIndMPI.cmake to incorporate these changes: ---------- # Require MPI for this project: if(WIN32) #This is for finding MS-MPI. #set(_MPI_PREFIX_PATH) #list(APPEND _MPI_PREFIX_PATH "[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\MPI;Path]/..") set(MPIEXEC "C:/Program Files/Microsoft MPI/Bin/mpiexec.exe") # For building MPI programs the selected Visual Studio compiler is used, namely cl.exe. # So there is no need to set a specific MPI compiler. #set(MPI_CXX_COMPILER "${CMAKE_CXX_COMPILER}") set(MPI_CXX_INCLUDE_PATH "C:/Program Files (x86)/Microsoft SDKs/MPI/Include") # Make sure the correct libraries (64-bit or 32-bit) are selected. # Decide between 32-bit and 64-bit libraries for Microsoft's MPI if("${CMAKE_SIZEOF_VOID_P}" EQUAL 8) set(MS_MPI_ARCH_DIR x64) else() set(MS_MPI_ARCH_DIR x86) endif() set(MPI_CXX_LIBRARIES "C:/Program Files (x86)/Microsoft SDKs/MPI/Lib/${MS_MPI_ARCH_DIR}/msmpi.lib") set(MPI_C_INCLUDE_PATH "${MPI_CXX_INCLUDE_PATH}") set(MPI_C_LIBRARIES "{${MPI_CXX_LIBRARIES}") set(MPIEXEC_NUMPROC_FLAG "-np" CACHE STRING "Flag used by MPI to specify the number of processes for MPIEXEC; the next option will be the number of processes.") else() find_package(MPI REQUIRED) endif() -------- Some of this is taken from FindMPI.cmake. Attached is a zipped up file of the working CMakeLists.txt file and a test file for you. I looked at FindMPI.cmake but I think you guys are better placed to make the changes. Also in the case of FindMPI.cmake, you will need to fix the following warning message: CMake Warning (dev) at C:/Program Files (x86)/CMake/share/cmake-3.1/Modules/FindMPI.cmake:163 (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:5 (find_package) This warning is for project developers. Use -Wno-dev to suppress it.CMake Warning (dev) at C:/Program Files (x86)/CMake/share/cmake-3.1/Modules/FindMPI.cmake:163 (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:5 (find_package) This warning is for project developers. Use -Wno-dev to suppress it. Regards Andrew -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: test.zip Type: application/zip Size: 2088 bytes Desc: not available URL: From andrew.amaclean at gmail.com Sat Feb 28 23:54:46 2015 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Sun, 1 Mar 2015 15:54:46 +1100 Subject: [CMake] FindMPI.cmake and MS-MPI Message-ID: Re-sending because David in no longer at Kitware. I downloaded and installed MS-MPI from http://www.microsoft.com/en-us/download/details.aspx?id=44990 This implementation does not work with FindMPI.cmake. The includes and libs are found in: C:/Program Files (x86)/Microsoft SDKs/MPI/ and mpiexec.exe is in: C:/Program Files/Microsoft MPI/Bin/ I had to do the following changes to get it working. Perhaps you would like to edit FIndMPI.cmake to incorporate these changes: ---------- # Require MPI for this project: if(WIN32) #This is for finding MS-MPI. #set(_MPI_PREFIX_PATH) #list(APPEND _MPI_PREFIX_PATH "[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\MPI;Path]/..") set(MPIEXEC "C:/Program Files/Microsoft MPI/Bin/mpiexec.exe") # For building MPI programs the selected Visual Studio compiler is used, namely cl.exe. # So there is no need to set a specific MPI compiler. #set(MPI_CXX_COMPILER "${CMAKE_CXX_COMPILER}") set(MPI_CXX_INCLUDE_PATH "C:/Program Files (x86)/Microsoft SDKs/MPI/Include") # Make sure the correct libraries (64-bit or 32-bit) are selected. # Decide between 32-bit and 64-bit libraries for Microsoft's MPI if("${CMAKE_SIZEOF_VOID_P}" EQUAL 8) set(MS_MPI_ARCH_DIR x64) else() set(MS_MPI_ARCH_DIR x86) endif() set(MPI_CXX_LIBRARIES "C:/Program Files (x86)/Microsoft SDKs/MPI/Lib/${MS_MPI_ARCH_DIR}/msmpi.lib") set(MPI_C_INCLUDE_PATH "${MPI_CXX_INCLUDE_PATH}") set(MPI_C_LIBRARIES "{${MPI_CXX_LIBRARIES}") set(MPIEXEC_NUMPROC_FLAG "-np" CACHE STRING "Flag used by MPI to specify the number of processes for MPIEXEC; the next option will be the number of processes.") else() find_package(MPI REQUIRED) endif() -------- Some of this is taken from FindMPI.cmake. Attached is a zipped up file of the working CMakeLists.txt file and a test file for you. I looked at FindMPI.cmake but I think you guys are better placed to make the changes. Also in the case of FindMPI.cmake, you will need to fix the following warning message: CMake Warning (dev) at C:/Program Files (x86)/CMake/share/cmake-3.1/Modules/FindMPI.cmake:163 (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:5 (find_package) This warning is for project developers. Use -Wno-dev to suppress it.CMake Warning (dev) at C:/Program Files (x86)/CMake/share/cmake-3.1/Modules/FindMPI.cmake:163 (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:5 (find_package) This warning is for project developers. Use -Wno-dev to suppress it. Regards Andrew -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: test.zip Type: application/zip Size: 2088 bytes Desc: not available URL: