From volker.enderlein at ifm-chemnitz.de Mon Apr 3 06:30:21 2017 From: volker.enderlein at ifm-chemnitz.de (Volker Enderlein) Date: Mon, 3 Apr 2017 12:30:21 +0200 Subject: [CMake] Packaging issues Message-ID: <7c2e6f72-4a77-c7ac-46c4-f2f71fd46fbf@ifm-chemnitz.de> Hi, I'm facing problems using the packaging with CPACK. I try to build three different packages, a MSI (via WIX), an IFW, and a ZIP package. According to the documentation I set the following variables in my CMakeLists.txt (and a few more which are required): set(CPACK_WIX_ROOT "C:/Temp/WiX-3.10/binaries") set(QTIFWDIR "${GLOBAL}/Qt/Tools/QtInstallerFramework/2.0/bin") set(CPACK_GENERATOR "WIX;IFW;ZIP") After creating the build dir and running from there cmake -G "Visual Studio 14 2015 Win64" ..\TestProject the files CMakeCache.txt, CPackConfig.cmake, CPackSourceConfig.cmake, and CPackProperties.cmake are generated. When running `cpack -C Release` to build all three installers at once, the first one (WIX) is built, but the second one (QtIFW) fails with the messages CPack Error: Cannot find QtIFW compiler "binarycreator": likely it is not installed, or not in your PATH CPack Error: Cannot initialize the generator IFW I inspected the CMakeCache.txt file but found the following entries properly defined: //QtIFW binarycreator command line client CPACK_IFW_BINARYCREATOR_EXECUTABLE:FILEPATH=N:/Global/Qt/Tools/QtInstallerFramework/2.0/bin/binarycreator.exe //QtIFW devtool command line client CPACK_IFW_DEVTOOL_EXECUTABLE:FILEPATH=N:/Global/Qt/Tools/QtInstallerFramework/2.0/bin/devtool.exe //QtIFW installer executable base CPACK_IFW_INSTALLERBASE_EXECUTABLE:FILEPATH=N:/Global/Qt/Tools/QtInstallerFramework/2.0/bin/installerbase.exe //QtIFW repogen command line client CPACK_IFW_REPOGEN_EXECUTABLE:FILEPATH=N:/Global/Qt/Tools/QtInstallerFramework/2.0/bin/repogen.exe //Enable to build 7-Zip source packages CPACK_SOURCE_7Z:BOOL=ON //Enable to build ZIP source packages CPACK_SOURCE_ZIP:BOOL=ON //Path to a program. CPACK_WIX_CANDLE_EXECUTABLE:FILEPATH=C:/Temp/WiX-3.10/binaries/candle.exe //Path to a program. CPACK_WIX_LIGHT_EXECUTABLE:FILEPATH=C:/Temp/WiX-3.10/binaries/light.exe But when I checked the CPack*Config.cmake files none of the entries above are referenced. After running the `cmake -G "Visual Studio 14 2015 Win64" ..\TestProject` a second time everything is fine; the entries are referenced in CPack*Config.cmake files and all three installers can be built. So I really get stuck at this point. Any ideas what could be the issue and how to avoid it? Cheers Volker From domen.vrankar at gmail.com Mon Apr 3 06:54:50 2017 From: domen.vrankar at gmail.com (Domen Vrankar) Date: Mon, 3 Apr 2017 12:54:50 +0200 Subject: [CMake] Packaging issues In-Reply-To: <7c2e6f72-4a77-c7ac-46c4-f2f71fd46fbf@ifm-chemnitz.de> References: <7c2e6f72-4a77-c7ac-46c4-f2f71fd46fbf@ifm-chemnitz.de> Message-ID: 2017-04-03 12:30 GMT+02:00 Volker Enderlein < volker.enderlein at ifm-chemnitz.de>: > But when I checked the CPack*Config.cmake files none of the entries above > are referenced. After running the `cmake -G "Visual Studio 14 2015 Win64" > ..\TestProject` a second time everything is fine; the entries are > referenced in CPack*Config.cmake files and all three installers can be > built. > > So I really get stuck at this point. > > > Any ideas what could be the issue and how to avoid it? > >From what you have described my best guess would be that "include( CPack )" is called before the variables are set and that second configure step then sets variables in CPack.cmake script correctly since their values are already cached by the first configure step. If I'm correct then calling "include( CPack )" at the end - this is the intended use - of the script would solve your problem. Regards, Domen -------------- next part -------------- An HTML attachment was scrubbed... URL: From volker.enderlein at ifm-chemnitz.de Mon Apr 3 07:10:59 2017 From: volker.enderlein at ifm-chemnitz.de (Volker Enderlein) Date: Mon, 3 Apr 2017 13:10:59 +0200 Subject: [CMake] Packaging issues In-Reply-To: References: <7c2e6f72-4a77-c7ac-46c4-f2f71fd46fbf@ifm-chemnitz.de> Message-ID: Am 03/04/2017 um 12:54 schrieb Domen Vrankar: > 2017-04-03 12:30 GMT+02:00 Volker Enderlein > >: > > But when I checked the CPack*Config.cmake files none of the > entries above are referenced. After running the `cmake -G "Visual > Studio 14 2015 Win64" ..\TestProject` a second time everything is > fine; the entries are referenced in CPack*Config.cmake files and > all three installers can be built. > > So I really get stuck at this point. > > > Any ideas what could be the issue and how to avoid it? > > > From what you have described my best guess would be that "include( > CPack )" is called before the variables are set and that second > configure step then sets variables in CPack.cmake script correctly > since their values are already cached by the first configure step. If > I'm correct then calling "include( CPack )" at the end - this is the > intended use - of the script would solve your problem. > > Regards, > Domen Hi Domen, pardon for not responding to the list. Thanks for helping, I'm already including CPack at the last possible position before any components are defined. BTW. I'm using CMake 3.7.2 < all variables have been defined before this point> include(CPack) include(CPackWIX) include(CPackIFW) cpack_add_component(AppBinaries DISPLAY_NAME "MyAppBinaries" DESCRIPTION "My Application Binaries") cpack_ifw_configure_component(AppBinaries VERSION ${CPACK_PACKAGE_VERSION} SCRIPT "${CMAKE_SOURCE_DIR}/cpack/installscript.qs") cpack_add_component(AppDocs DISPLAY_NAME "MyAppDocs" DESCRIPTION "My Application Docs") cpack_add_component(AppData DISPLAY_NAME "MyAppData" DESCRIPTION "My Application Data") Cheers Volker From volker.enderlein at ifm-chemnitz.de Mon Apr 3 11:50:09 2017 From: volker.enderlein at ifm-chemnitz.de (Volker Enderlein) Date: Mon, 3 Apr 2017 17:50:09 +0200 Subject: [CMake] Packaging issues In-Reply-To: <7c2e6f72-4a77-c7ac-46c4-f2f71fd46fbf@ifm-chemnitz.de> References: <7c2e6f72-4a77-c7ac-46c4-f2f71fd46fbf@ifm-chemnitz.de> Message-ID: <39448ffa-1cab-f8ce-b6f2-47ba2e5881c5@ifm-chemnitz.de> Am 03/04/2017 um 12:30 schrieb Volker Enderlein: > Hi, > > > I'm facing problems using the packaging with CPACK. > > I try to build three different packages, a MSI (via WIX), an IFW, and > a ZIP package. > > According to the documentation I set the following variables in my > CMakeLists.txt (and a few more which are required): > > set(CPACK_WIX_ROOT "C:/Temp/WiX-3.10/binaries") > > set(QTIFWDIR "${GLOBAL}/Qt/Tools/QtInstallerFramework/2.0/bin") > > set(CPACK_GENERATOR "WIX;IFW;ZIP") > > After creating the build dir and running from there > > cmake -G "Visual Studio 14 2015 Win64" ..\TestProject > > the files CMakeCache.txt, CPackConfig.cmake, CPackSourceConfig.cmake, > and CPackProperties.cmake are generated. > > When running `cpack -C Release` to build all three installers at once, > the first one (WIX) is built, but the second one (QtIFW) fails with > the messages > > CPack Error: Cannot find QtIFW compiler "binarycreator": likely it is > not installed, or not in your PATH > CPack Error: Cannot initialize the generator IFW > > I inspected the CMakeCache.txt file but found the following entries > properly defined: > > //QtIFW binarycreator command line client > CPACK_IFW_BINARYCREATOR_EXECUTABLE:FILEPATH=N:/Global/Qt/Tools/QtInstallerFramework/2.0/bin/binarycreator.exe > > > //QtIFW devtool command line client > CPACK_IFW_DEVTOOL_EXECUTABLE:FILEPATH=N:/Global/Qt/Tools/QtInstallerFramework/2.0/bin/devtool.exe > > > //QtIFW installer executable base > CPACK_IFW_INSTALLERBASE_EXECUTABLE:FILEPATH=N:/Global/Qt/Tools/QtInstallerFramework/2.0/bin/installerbase.exe > > > //QtIFW repogen command line client > CPACK_IFW_REPOGEN_EXECUTABLE:FILEPATH=N:/Global/Qt/Tools/QtInstallerFramework/2.0/bin/repogen.exe > > > //Enable to build 7-Zip source packages > CPACK_SOURCE_7Z:BOOL=ON > > //Enable to build ZIP source packages > CPACK_SOURCE_ZIP:BOOL=ON > > //Path to a program. > CPACK_WIX_CANDLE_EXECUTABLE:FILEPATH=C:/Temp/WiX-3.10/binaries/candle.exe > > //Path to a program. > CPACK_WIX_LIGHT_EXECUTABLE:FILEPATH=C:/Temp/WiX-3.10/binaries/light.exe > > But when I checked the CPack*Config.cmake files none of the entries > above are referenced. After running the `cmake -G "Visual Studio 14 > 2015 Win64" ..\TestProject` a second time everything is fine; the > entries are referenced in CPack*Config.cmake files and all three > installers can be built. > > So I really get stuck at this point. > > > Any ideas what could be the issue and how to avoid it? > > > Cheers Volker > A close follow up. I finally figured out what didn't work. The setting of the QTIFWDIR variable is not saved to the CPack*Config.cmake files. But the CMAKE_WIX_ROOT variable is. Those variables seem to be evaluated at runtime by CPack. Therefore the WIX build run successfully but the IFW build complained about a the path. Adding the variable with its current setting made everything run as expected. Cheers Volker From konstantin at podsvirov.pro Mon Apr 3 12:38:36 2017 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Mon, 03 Apr 2017 19:38:36 +0300 Subject: [CMake] Packaging issues In-Reply-To: <39448ffa-1cab-f8ce-b6f2-47ba2e5881c5@ifm-chemnitz.de> References: <7c2e6f72-4a77-c7ac-46c4-f2f71fd46fbf@ifm-chemnitz.de> <39448ffa-1cab-f8ce-b6f2-47ba2e5881c5@ifm-chemnitz.de> Message-ID: <90901491237516@web44j.yandex.ru> Hello Volker! 03.04.2017, 18:50, "Volker Enderlein" : > Am 03/04/2017 um 12:30 schrieb Volker Enderlein: >> ?Hi, >> >> ?I'm facing problems using the packaging with CPACK. >> >> ?I try to build three different packages, a MSI (via WIX), an IFW, and >> ?a ZIP package. >> >> ?According to the documentation I set the following variables in my >> ?CMakeLists.txt (and a few more which are required): >> >> ?set(CPACK_WIX_ROOT "C:/Temp/WiX-3.10/binaries") >> >> ?set(QTIFWDIR "${GLOBAL}/Qt/Tools/QtInstallerFramework/2.0/bin") As wrote in the documentation: https://cmake.org/cmake/help/latest/module/CPackIFW.html#overview QTIFWDIR (like QTDIR) - it's QtIFW installation path (without "/bin"). You can set it's as your environment variable and use for all your projects. >> ?set(CPACK_GENERATOR "WIX;IFW;ZIP") >> >> ?After creating the build dir and running from there >> >> ?cmake -G "Visual Studio 14 2015 Win64" ..\TestProject >> >> ?the files CMakeCache.txt, CPackConfig.cmake, CPackSourceConfig.cmake, >> ?and CPackProperties.cmake are generated. >> >> ?When running `cpack -C Release` to build all three installers at once, >> ?the first one (WIX) is built, but the second one (QtIFW) fails with >> ?the messages >> >> ?CPack Error: Cannot find QtIFW compiler "binarycreator": likely it is >> ?not installed, or not in your PATH >> ?CPack Error: Cannot initialize the generator IFW >> >> ?I inspected the CMakeCache.txt file but found the following entries >> ?properly defined: >> >> ?//QtIFW binarycreator command line client >> ?CPACK_IFW_BINARYCREATOR_EXECUTABLE:FILEPATH=N:/Global/Qt/Tools/QtInstallerFramework/2.0/bin/binarycreator.exe >> >> ?//QtIFW devtool command line client >> ?CPACK_IFW_DEVTOOL_EXECUTABLE:FILEPATH=N:/Global/Qt/Tools/QtInstallerFramework/2.0/bin/devtool.exe >> >> ?//QtIFW installer executable base >> ?CPACK_IFW_INSTALLERBASE_EXECUTABLE:FILEPATH=N:/Global/Qt/Tools/QtInstallerFramework/2.0/bin/installerbase.exe >> >> ?//QtIFW repogen command line client >> ?CPACK_IFW_REPOGEN_EXECUTABLE:FILEPATH=N:/Global/Qt/Tools/QtInstallerFramework/2.0/bin/repogen.exe >> >> ?//Enable to build 7-Zip source packages >> ?CPACK_SOURCE_7Z:BOOL=ON >> >> ?//Enable to build ZIP source packages >> ?CPACK_SOURCE_ZIP:BOOL=ON >> >> ?//Path to a program. >> ?CPACK_WIX_CANDLE_EXECUTABLE:FILEPATH=C:/Temp/WiX-3.10/binaries/candle.exe >> >> ?//Path to a program. >> ?CPACK_WIX_LIGHT_EXECUTABLE:FILEPATH=C:/Temp/WiX-3.10/binaries/light.exe >> >> ?But when I checked the CPack*Config.cmake files none of the entries >> ?above are referenced. After running the `cmake -G "Visual Studio 14 >> ?2015 Win64" ..\TestProject` a second time everything is fine; the >> ?entries are referenced in CPack*Config.cmake files and all three >> ?installers can be built. >> >> ?So I really get stuck at this point. >> >> ?Any ideas what could be the issue and how to avoid it? >> >> ?Cheers Volker > > A close follow up. > > I finally figured out what didn't work. > > The setting of the QTIFWDIR variable is not saved to the > CPack*Config.cmake files. But the CMAKE_WIX_ROOT variable is. Those > variables seem to be evaluated at runtime by CPack. Therefore the WIX > build run successfully but the IFW build complained about a the path. > Adding the variable with its current setting made everything run as > expected. > > Cheers Volker > > -- > > 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 Good luck with creating your installers! -- Regards, Konstantin Podsvirov (CPackIFW author) From patrick.boettcher at posteo.de Tue Apr 4 04:47:41 2017 From: patrick.boettcher at posteo.de (Patrick Boettcher) Date: Tue, 4 Apr 2017 10:47:41 +0200 Subject: [CMake] Is it possible to run ctest outside build tree? In-Reply-To: References: Message-ID: <20170404104741.164a81fe@posteo.de> Hi, Answering a little bit late: I had a similar problem I wanted to run only parts of my tests (-R) dedicated test-reports. As cmake is using absolute paths to the executable the only thing I needed to copy were the CTestFiles in all sub-directories. # copy all ctest-files to the current dir rsync -avm --include='*CTestTestfile.cmake' -f 'hide,! */' \ ${TESTING_WORKSPACE}/* . TESTING_WORKSPACE is the build-dir. 'current dir' is a path per test-selection. I then can run different ctest -R in the different paths using on the same binaries from one build dir and having different test-reports. HTH, -- Patrick. On Fri, 24 Mar 2017 20:11:14 +0100 Eric Noulard wrote: > Hi David, > Thank you for you for checking the code. Would you think adding such a > command line option would be acceptable upstream? > > Le 24 mars 2017 18:43, "David Cole" a ?crit : > > This code: > > https://github.com/Kitware/CMake/blob/master/Source/ctest.cxx#L139-L157 > > shows ctest will look for a CTestTestfile.cmake or DartTestfile.txt > file in the current working directory as soon as it starts. Except in > the case of processing a "--launch" directive, in which case, it > dispatches that in the code just above there. > > So. I think you have not much choice other than to propose adding a > new command line argument for such purpose, or wrapping existing ctest > with your own script or program of some sort. > > > HTH, > David C. > > > > > On Fri, Mar 24, 2017 at 6:04 AM, Eric Noulard > wrote: > > Is possible to run ctest outside the builld tree and how? > > typical use is when I have an out of source build I may be in the > > source tree > > and want to run tests without manually going to build tree. > > > > i.e. I currently do: > > > > ninja -C /my/build/tree > > > > is there a similar way to do that with ctest (other than creating > > my own script, shell alias etc...)? > > > > -- > > Eric > > > > -- > > > > 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 magnus at therning.org Tue Apr 4 05:17:20 2017 From: magnus at therning.org (Magnus Therning) Date: Tue, 04 Apr 2017 11:17:20 +0200 Subject: [CMake] get complete list of compile definitions In-Reply-To: <002801d2a877$e7fc9370$b7f5ba50$@googlemail.com> References: <002801d2a877$e7fc9370$b7f5ba50$@googlemail.com> Message-ID: <87o9wcfs67.fsf@therning.org> Robert Schwarzelt writes: > Hi all, > I need to implement a code export function, that will only export code used > in a specific project configuration. > For this purpose I want to use unifdef (http://dotat.at/prog/unifdef/), > which is capable of removing unused #ifdef blocks. > > The project uses static libraries like in following example: > > add_library( > foo STATIC > foo.c > ) > > add_library( > bar STATIC > bar.c > ) > > target_compile_definitions(bar INTERFACE HAVE_BAR) > target_link_libraries(foo LINK_PUBLIC bar) > > > Now foo.c will be compiled with -DHAVE_BAR at build time. > To create a custom target using unifdef i need this information at cmake > configure time. I expected to find this in the property COMPILE_DEFINITIONS > of either the source file foo.c or target foo, but both are empty. > > Does anyone know, how to get a list of definitions (that will be used at > build time) for targets or files? Not to discourage you, but *every time* I've asked a question along the lines of "how can I get a list of foo for a source file / target at cmake configuration time" the answer has been "oh, that's not easy", or even "oh, that's not possible". In every case I've resorted to trying to find a way to push what I want to do until build time. If you *can* find a way to do it post-configuration time I believe you will have access to everything you need if you set "CMAKE_EXPORT_COMPILE_COMMANDS" and then look at the resulting `compile_commands.json`. /M -- Magnus Therning OpenPGP: 0x927912051716CE39 email: magnus at therning.org jabber: magnus at therning.org twitter: magthe http://therning.org/magnus Finagle's Second Law: Always keep a record of data ? it indicates you've been working. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From david.jobet at free.fr Wed Apr 5 11:33:37 2017 From: david.jobet at free.fr (David Jobet) Date: Wed, 05 Apr 2017 16:33:37 +0100 Subject: [CMake] Transitive include and link libraries on imported targets ? Message-ID: <236AA806-3730-4049-8436-E9476A2D458C@free.fr> Hello, Let's say I build some external libs A and B with B depending on A. B and A do not use cmake, so I build them and install them in a 3rdparty directory. I now have access to includes and libs. I then create some cmake file to describe those libs so I can use them in my project : Add_library(A_imported STATIC imported) Set_property(TARGET A_imported APPEND PROPERTY INTERFACE_INCLUDE_DIRECTORIES 3rdparty/include/A) Set_property(TARGET A_imported APPEND PROPERTY IMPORTED_LOCATION 3rdparty/libs/libA.a) Add_library(A INTERFACE) Target_link_library(A INTERFACE A_imported) Same thing for B Now let's say I create a top-level target T that depends on B. Compilation might fail because B might include files from A and A is currently not a dependency of T. I can fix it in 2 ways : 1- add A as a dependency of T, but I will need to do it on all my Ts 2- somehow make B have transitive dependencies for include and link on A. That would be my prefered choice... But I don't know how to do it. Is it possible ? How ? Tx for your help. David -------------- next part -------------- An HTML attachment was scrubbed... URL: From volker.enderlein at ifm-chemnitz.de Wed Apr 5 11:42:37 2017 From: volker.enderlein at ifm-chemnitz.de (Volker Enderlein) Date: Wed, 5 Apr 2017 17:42:37 +0200 Subject: [CMake] get complete list of compile definitions In-Reply-To: <87o9wcfs67.fsf@therning.org> References: <002801d2a877$e7fc9370$b7f5ba50$@googlemail.com> <87o9wcfs67.fsf@therning.org> Message-ID: <944c90c7-9bbb-6c57-0b1d-fc84ec004ffd@ifm-chemnitz.de> Am 04/04/2017 um 11:17 schrieb Magnus Therning: > Robert Schwarzelt writes: > >> Hi all, >> I need to implement a code export function, that will only export code used >> in a specific project configuration. >> For this purpose I want to use unifdef (http://dotat.at/prog/unifdef/), >> which is capable of removing unused #ifdef blocks. >> >> The project uses static libraries like in following example: >> >> add_library( >> foo STATIC >> foo.c >> ) >> >> add_library( >> bar STATIC >> bar.c >> ) >> >> target_compile_definitions(bar INTERFACE HAVE_BAR) >> target_link_libraries(foo LINK_PUBLIC bar) >> >> >> Now foo.c will be compiled with -DHAVE_BAR at build time. >> To create a custom target using unifdef i need this information at cmake >> configure time. I expected to find this in the property COMPILE_DEFINITIONS >> of either the source file foo.c or target foo, but both are empty. >> >> Does anyone know, how to get a list of definitions (that will be used at >> build time) for targets or files? > Not to discourage you, but *every time* I've asked a question along the > lines of "how can I get a list of foo for a source file / target at > cmake configuration time" the answer has been "oh, that's not easy", or > even "oh, that's not possible". In every case I've resorted to trying to > find a way to push what I want to do until build time. > > If you *can* find a way to do it post-configuration time I believe you will have > access to everything you need if you set "CMAKE_EXPORT_COMPILE_COMMANDS" > and then look at the resulting `compile_commands.json`. > > /M > > -- > Magnus Therning OpenPGP: 0x927912051716CE39 > email: magnus at therning.org jabber: magnus at therning.org > twitter: magthe http://therning.org/magnus > > Finagle's Second Law: > Always keep a record of data ? it indicates you've been working. > > I successfully used the following commands to get the INTERFACE_COMPILE_DEFINITIONS and the COMPILE_DEFINITIONS of a target (yes, both of them may exist). And because the OP has specified INTERFACE_COMPILE_DEFINITIONS he should evaluate that property of the target. get_target_property(_if_compile_defs YourTargetNameHere INTERFACE_COMPILE_DEFINITIONS) get_target_property(_compile_defs YourTargetNameHere COMPILE_DEFINITIONS) Cheers Volker From harrison37 at llnl.gov Wed Apr 5 16:54:10 2017 From: harrison37 at llnl.gov (Harrison, Cyrus D.) Date: Wed, 5 Apr 2017 20:54:10 +0000 Subject: [CMake] Is it possible to detecting if -C was used, and if so which file was passed? Message-ID: <075F6342-3157-4858-9ABC-F834675363A7@llnl.gov> Hi Everyone, I have a simple quandary ? I was wondering if -C was used when cmake is run ? is it possible to find the name of this file via any cmake state? Thanks! -Cyrus From craig.scott at crascit.com Wed Apr 5 18:55:58 2017 From: craig.scott at crascit.com (Craig Scott) Date: Thu, 6 Apr 2017 08:55:58 +1000 Subject: [CMake] cmake -E remove -f Message-ID: Can anyone identify a scenario where the -f option to the CMake command mode's "remove" command makes any difference? Testing a range of possibilities has so far yielded no difference for the cases I can think of. The documentation simply says "use -f to force it", which doesn't explain when such forcing would be needed. -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at cognomen.co.uk Wed Apr 5 19:22:52 2017 From: mark at cognomen.co.uk (Mark Ferry) Date: Thu, 6 Apr 2017 00:22:52 +0100 Subject: [CMake] cmake -E remove -f In-Reply-To: References: Message-ID: <20170405232252.GE2748@shochu.local> Hi Craig On Thu, 06 Apr 2017 08:55:58 +1000, Craig Scott wrote: > Can anyone identify a scenario where the -f option to the CMake command > mode's "remove" command makes any difference? > How about removing directories: ~/src/cmake-test$ cmake --version cmake version 3.0.2 CMake suite maintained and supported by Kitware (kitware.com/cmake). ~/src/cmake-test$ mkdir foo ~/src/cmake-test$ cmake -E remove foo ~/src/cmake-test$ echo $? 1 ~/src/cmake-test$ cmake -E remove -f foo ~/src/cmake-test$ echo $? 0 -- Cognomen Ltd http://cognomen.co.uk +44 7855 790184 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: Digital signature URL: From craig.scott at crascit.com Wed Apr 5 19:35:23 2017 From: craig.scott at crascit.com (Craig Scott) Date: Thu, 6 Apr 2017 09:35:23 +1000 Subject: [CMake] cmake -E remove -f In-Reply-To: <20170405232252.GE2748@shochu.local> References: <20170405232252.GE2748@shochu.local> Message-ID: Yes, but in both cases the directory foo is still not deleted! At least on OSX any way. On Thu, Apr 6, 2017 at 9:22 AM, Mark Ferry wrote: > Hi Craig > > On Thu, 06 Apr 2017 08:55:58 +1000, Craig Scott wrote: > > Can anyone identify a scenario where the -f option to the CMake command > > mode's "remove" command makes any difference? > > > > How about removing directories: > > ~/src/cmake-test$ cmake --version > cmake version 3.0.2 > > CMake suite maintained and supported by Kitware (kitware.com/cmake). > ~/src/cmake-test$ mkdir foo > > ~/src/cmake-test$ cmake -E remove foo > ~/src/cmake-test$ echo $? > 1 > > ~/src/cmake-test$ cmake -E remove -f foo > ~/src/cmake-test$ echo $? > 0 > > > > -- > Cognomen Ltd > http://cognomen.co.uk > +44 7855 790184 > -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From Dvir.Yitzchaki at ceva-dsp.com Thu Apr 6 00:11:46 2017 From: Dvir.Yitzchaki at ceva-dsp.com (Dvir Yitzchaki) Date: Thu, 6 Apr 2017 04:11:46 +0000 Subject: [CMake] Transitive include and link libraries on imported targets ? In-Reply-To: <236AA806-3730-4049-8436-E9476A2D458C@free.fr> References: <236AA806-3730-4049-8436-E9476A2D458C@free.fr> Message-ID: <8d336e07056e4e2996c5a307948b1df3@ceva-dsp.com> target_link_libraries(B INTERFACE A) Regards, Dvir From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of David Jobet Sent: Wednesday, April 5, 2017 18:34 To: cmake at cmake.org Subject: [CMake] Transitive include and link libraries on imported targets ? Hello, Let's say I build some external libs A and B with B depending on A. B and A do not use cmake, so I build them and install them in a 3rdparty directory. I now have access to includes and libs. I then create some cmake file to describe those libs so I can use them in my project : Add_library(A_imported STATIC imported) Set_property(TARGET A_imported APPEND PROPERTY INTERFACE_INCLUDE_DIRECTORIES 3rdparty/include/A) Set_property(TARGET A_imported APPEND PROPERTY IMPORTED_LOCATION 3rdparty/libs/libA.a) Add_library(A INTERFACE) Target_link_library(A INTERFACE A_imported) Same thing for B Now let's say I create a top-level target T that depends on B. Compilation might fail because B might include files from A and A is currently not a dependency of T. I can fix it in 2 ways : 1- add A as a dependency of T, but I will need to do it on all my Ts 2- somehow make B have transitive dependencies for include and link on A. That would be my prefered choice... But I don't know how to do it. Is it possible ? How ? Tx for your help. David -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ch.Ehrlicher at gmx.de Thu Apr 6 10:18:34 2017 From: Ch.Ehrlicher at gmx.de (Christian Ehrlicher) Date: Thu, 6 Apr 2017 16:18:34 +0200 Subject: [CMake] QT4/5_WRAP_CPP / INTERFACE_INCLUDE_DIRECTORIES Message-ID: An HTML attachment was scrubbed... URL: From rcdailey.lists at gmail.com Thu Apr 6 10:38:10 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Thu, 6 Apr 2017 09:38:10 -0500 Subject: [CMake] Need advice on dual-build APK setup in CMake Message-ID: I have CMake setup to build native shared libraries (*.so) that are included in an APK built for Android. The "ant release" command is invoked by a custom target I define in CMake, which handles building the java pieces as well as packaging the final app into an APK file. So the build pipeline when I invoke my custom target is: Build Native Library (library target, output is *.so) -> Run Ant Release (output is an APK) This worked fine, until I needed to support multiple architectures on the native side. So basically now I need to rebuild the C++ code 2 times: Once for ARM platform, another for x86 Android platform. Once both native libraries are built (end up with two *.so files), I need to copy both of those libraries into the android project directory structure and run the custom target to do "ant release". Since a single CMake binary directory is tied to 1 combination of configuration/platform build for the C++ code, I can't make it build twice through CMake itself. Basically I've had to take away responsibility of the java build (via the custom target) away from CMake and invoke it manually on the build server. So our continuous build server does the following: 1. Generate CMake for ARM Android -> Build it -> Publish the *.so 2. Generate CMake for x86 Android -> Build it -> Publish the *.so 3. Gather previously published two *.so files, run "ant release" manually The goal here is 1 APK that can be deployed to both platforms since it has both shared libraries inside it. Android knows which shared library to load when you launch the application based on whichever platform you are on. If I used the old method, I'd have 2 APK files (one for each platform) which won't work for me. Is there a way I can have CMake still responsible for running the non-native tasks via custom commands and targets, while also building two libraries? What would be the best setup for this? Note that it is ideal to be able to replicate deployments locally, the same way the build server would. So even if a single CMake binary directory can't accomplish this somehow, I'd be OK with a superbuild approach of some sort (superbuild would build the native parts 2 times, one for each platform, then do another CMake generate that just runs custom targets and nothing else). Ideas are appreciated! From canngree at umich.edu Thu Apr 6 11:51:25 2017 From: canngree at umich.edu (Crystal Green) Date: Thu, 6 Apr 2017 11:51:25 -0400 Subject: [CMake] Config file for windows system In-Reply-To: References: Message-ID: Hello, I am a PhD student at the University of Michigan. I am trying to install ITK on my Windows computer. I keep getting an error to send the CMakeCache.txt to this address. Please advise. Crystal A. Green PhD Candidate Nuclear Engineering and Radiological Sciences University of Michigan http://dnng.engin.umich.edu ASEE DoD SMART Scholar https://smart.asee.org/ On Thu, Apr 6, 2017 at 11:42 AM, Crystal Green wrote: > Hello, > > I am a PhD student at the University of Michigan. I am trying to install > ITK on my Windows computer. I keep getting an error to send the > CMakeCache.txt to this address. Please advise. > > > Crystal A. Green > PhD Candidate > Nuclear Engineering and Radiological Sciences > University of Michigan > http://dnng.engin.umich.edu > ASEE DoD SMART Scholar > https://smart.asee.org/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- # This is the CMakeCache file. # For build in directory: c:/ITK/Build # It was generated by CMake: C:/ITK/CMake/bin/cmake.exe # You can edit this file to change values found and used by cmake. # If you do not want to change any of the values, simply exit the editor. # If you do want to change a value, simply edit, save, and exit the editor. # The syntax for the file is as follows: # KEY:TYPE=VALUE # KEY is the name of a variable in the cache. # TYPE is a hint to GUIs for the type of VALUE, DO NOT EDIT TYPE!. # VALUE is the current value for the KEY. ######################## # EXTERNAL cache entries ######################## ######################## # INTERNAL cache entries ######################## //This is the directory where this CMakeCache.txt was created CMAKE_CACHEFILE_DIR:INTERNAL=c:/ITK/Build //Major version of cmake used to create the current loaded cache CMAKE_CACHE_MAJOR_VERSION:INTERNAL=3 //Minor version of cmake used to create the current loaded cache CMAKE_CACHE_MINOR_VERSION:INTERNAL=8 //Patch version of cmake used to create the current loaded cache CMAKE_CACHE_PATCH_VERSION:INTERNAL=0 From canngree at umich.edu Thu Apr 6 11:53:51 2017 From: canngree at umich.edu (Crystal Green) Date: Thu, 6 Apr 2017 11:53:51 -0400 Subject: [CMake] Help: Installation error for CMake Cache Message-ID: Hello, I am a PhD student at the University of Michigan. I am trying to install ITK on my Windows computer. I keep getting an error to send the CMakeCache.txt to this address. Please advise. Crystal A. Green PhD Candidate Nuclear Engineering and Radiological Sciences University of Michigan http://dnng.engin.umich.edu ASEE DoD SMART Scholar https://smart.asee.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- # This is the CMakeCache file. # For build in directory: c:/ITK/Build # It was generated by CMake: C:/ITK/CMake/bin/cmake.exe # You can edit this file to change values found and used by cmake. # If you do not want to change any of the values, simply exit the editor. # If you do want to change a value, simply edit, save, and exit the editor. # The syntax for the file is as follows: # KEY:TYPE=VALUE # KEY is the name of a variable in the cache. # TYPE is a hint to GUIs for the type of VALUE, DO NOT EDIT TYPE!. # VALUE is the current value for the KEY. ######################## # EXTERNAL cache entries ######################## ######################## # INTERNAL cache entries ######################## //This is the directory where this CMakeCache.txt was created CMAKE_CACHEFILE_DIR:INTERNAL=c:/ITK/Build //Major version of cmake used to create the current loaded cache CMAKE_CACHE_MAJOR_VERSION:INTERNAL=3 //Minor version of cmake used to create the current loaded cache CMAKE_CACHE_MINOR_VERSION:INTERNAL=8 //Patch version of cmake used to create the current loaded cache CMAKE_CACHE_PATCH_VERSION:INTERNAL=0 From gknowles at ieee.org Fri Apr 7 03:37:29 2017 From: gknowles at ieee.org (Glen Knowles) Date: Fri, 7 Apr 2017 00:37:29 -0700 Subject: [CMake] Setting top level source_group with regex Message-ID: On Windows, cmake version 3.7.2, generating project files for visual studio 2017. I have a file called "configure.bat" that I would like to place at the root of the visual studio project via regex. Here is what I have tried along with where it put configure.bat: 1. no source_group -> "Source Files" folder 2. source_group("" FILES "configure.bat") -> at the root 3. source_group(" " FILES "configure.bat") -> at the root 4. source_group("x" REGULAR_EXPRESSION "configure\.bat") -> "x" folder 5. source_group("" REGULAR_EXPRESSION "configure\.bat") -> "Source Files" folder 6. source_group(" " REGULAR_EXPRESSION "configure\.bat") -> at the root So it's possible to get the result I want using #6, but #5 seems wrong to me. Or if it's not wrong, and "" is suppose to restore the default, than #2 has a problem. #3 and #6 are actually adding a filter with a single space as it's name, I suspect it only works because VS is normalizing it to an empty string when it reads the *.vcxproj.filters file. -------------- next part -------------- An HTML attachment was scrubbed... URL: From aishwaryaselvaraj1708 at gmail.com Fri Apr 7 06:48:16 2017 From: aishwaryaselvaraj1708 at gmail.com (aishwarya selvaraj) Date: Fri, 7 Apr 2017 16:18:16 +0530 Subject: [CMake] Cmake for fftw library Message-ID: Hi all , I was writing CMakelist.txt to compile my cpp code(prose ) which makes use of two external libraries :libsndfile and fftw . The script I have written is below : CMAKE_MINIMUM_REQUIRED(VERSION 2.8) PROJECT(PROSE) ######################################################################################################################################################################################################################################################## include(ExternalProject) MESSAGE(STATUS "Trying to install fftw...") ExternalProject_Add(fftw #GIT_REPOSITORY https://github.com/FFTW/fftw3 URL "http://www.fftw.org/fftw-3.3.2.tar.gz" PREFIX ${CMAKE_CURRENT_BINARY_DIR}/fftw_library CONFIGURE_COMMAND "" #--Build step----------------- BUILD_COMMAND "" #--Install step--------------- UPDATE_COMMAND "" # Skip annoying updates for every build INSTALL_COMMAND "" ) include_directories(${CMAKE_CURRENT_BINARY_DIR}/fftw_library/src/fftw/api) ######################################################################################################################################################################################################################################################## include(ExternalProject) MESSAGE(STATUS "Trying to install libsndfile...") ExternalProject_Add(project_libsndfile GIT_REPOSITORY https://github.com/erikd/libsndfile.git PREFIX lib/libsndfile CONFIGURE_COMMAND /configure BUILD_COMMAND make BUILD_IN_SOURCE 1 INSTALL_COMMAND echo Skipping install step for libsndfile ) ExternalProject_Add_Step(project_libsndfile autogen COMMAND /autogen.sh DEPENDEES update DEPENDERS configure ) ExternalProject_Get_Property(project_libsndfile BINARY_DIR) SET(libsndfile_lib_dir "${BINARY_DIR}/src/.libs") SET(libsndfile_inc_dir "${BINARY_DIR}/src") ADD_LIBRARY(libsndfile STATIC IMPORTED) SET_PROPERTY(TARGET libsndfile PROPERTY IMPORTED_LOCATION ${libsndfile_lib_dir}/libsndfile.a) SET(LIBSNDFILE_INCLUDE_PATH "${install_dir}/src/project_libsndfile-build/src/") INCLUDE_DIRECTORIES(include ${libsndfile_inc_dir}) ######################################################################################################################################################################################################################################################## ADD_EXECUTABLE(prose ${PROJECT_SOURCE_DIR}/src/prose.cpp) TARGET_LINK_LIBRARIES(prose ${fftw} libsndfile ) ######################################################################################################################################################################################################################################################## ? When cmake .. is done building is done without any problem But when make is one , I get the following error: *Linking CXX executable proseCMakeFiles/prose.dir/src/prose.cpp.o: In function `prose(std::vector >, int, double)':prose.cpp:(.text+0x1c86): undefined reference to `fftw_plan_r2r_1d'prose.cpp:(.text+0x1c9c): undefined reference to `fftw_execute'prose.cpp:(.text+0x311d): undefined reference to `fftw_plan_r2r_1d'prose.cpp:(.text+0x3133): undefined reference to `fftw_execute'collect2: error: ld returned 1 exit statusmake[2]: *** [prose] Error 1make[1]: *** [CMakeFiles/prose.dir/all] Error 2make: *** [all] Error 2* Where Am I going wrong ? Can anyone please help me out ? P.S *`fftw_plan_r2r_1d',* * `fftw_execute' are functions from fftw library I have used to find dct .* -- Regards, Aishwarya Selvaraj -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.jobet at free.fr Fri Apr 7 07:32:52 2017 From: david.jobet at free.fr (David Jobet) Date: Fri, 07 Apr 2017 12:32:52 +0100 Subject: [CMake] Transitive include and link libraries on imported targets ? In-Reply-To: <8d336e07056e4e2996c5a307948b1df3@ceva-dsp.com> References: <236AA806-3730-4049-8436-E9476A2D458C@free.fr> <8d336e07056e4e2996c5a307948b1df3@ceva-dsp.com> Message-ID: <54DDE9B5-707C-4CB4-B243-BC3762F9C2C0@free.fr> Well not quite. I tried that, but my current definition is rather Target_link_libraries(B interface B_imported) I don't remember for which reason I had to do it in 2 stages like that (the A/A_imported and B/B_imported versions) If I add A in the list to read : Target_link_libraries(B interface B_imported A) Then linking against B does add B_imported and A, but it does not keep the link order and might put B_imported before A on the command line. I'll try with property INTERFACE_LINK_LIBRARIES instead, and will also try to remove those 2 stages... With regards David Le 6 avril 2017 05:11:46 GMT+01:00, Dvir Yitzchaki a ?crit : >target_link_libraries(B INTERFACE A) > >Regards, >Dvir > >From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of David Jobet >Sent: Wednesday, April 5, 2017 18:34 >To: cmake at cmake.org >Subject: [CMake] Transitive include and link libraries on imported >targets ? > >Hello, > >Let's say I build some external libs A and B with B depending on A. >B and A do not use cmake, so I build them and install them in a >3rdparty directory. I now have access to includes and libs. >I then create some cmake file to describe those libs so I can use them >in my project : >Add_library(A_imported STATIC imported) >Set_property(TARGET A_imported APPEND PROPERTY >INTERFACE_INCLUDE_DIRECTORIES 3rdparty/include/A) >Set_property(TARGET A_imported APPEND PROPERTY IMPORTED_LOCATION >3rdparty/libs/libA.a) >Add_library(A INTERFACE) >Target_link_library(A INTERFACE A_imported) > >Same thing for B > >Now let's say I create a top-level target T that depends on B. >Compilation might fail because B might include files from A and A is >currently not a dependency of T. > >I can fix it in 2 ways : >1- add A as a dependency of T, but I will need to do it on all my Ts >2- somehow make B have transitive dependencies for include and link on >A. That would be my prefered choice... But I don't know how to do it. > >Is it possible ? How ? > >Tx for your help. > >David -- Envoy? de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma bri?vet?. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcdailey.lists at gmail.com Fri Apr 7 09:40:32 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Fri, 7 Apr 2017 08:40:32 -0500 Subject: [CMake] custom command comments not showing up Message-ID: So I probably am not understanding how this works. I have a custom target, that I later add multiple custom commands to. Each custom command has a COMMENT set, but the target itself does too: add_custom_target(zApp_zip COMMENT "test1") add_custom_command( TARGET zApp_zip POST_BUILD COMMAND ${CMAKE_COMMAND} ARGS ...snip... COMMENT "test2" ) Instead of seeing "test1" or "test2" when running, I get: $ ninja zApp_zip [1/1] Running utility command for zApp_zip Why does it say "Running utility command"? What is the behavior of all the comments supposed to be? Is this a ninja-specific issue or behavior? From david.jobet at free.fr Fri Apr 7 10:27:23 2017 From: david.jobet at free.fr (David Jobet) Date: Fri, 07 Apr 2017 15:27:23 +0100 Subject: [CMake] Transitive include and link libraries on imported targets ? In-Reply-To: <54DDE9B5-707C-4CB4-B243-BC3762F9C2C0@free.fr> References: <236AA806-3730-4049-8436-E9476A2D458C@free.fr> <8d336e07056e4e2996c5a307948b1df3@ceva-dsp.com> <54DDE9B5-707C-4CB4-B243-BC3762F9C2C0@free.fr> Message-ID: <46CC27EB-110B-4547-8E52-A1504EA60F4A@free.fr> INTERFACE_LINK_LIBRARIES won't work since it won't pull out include path for dependants. Using target_link_libraries() on the imported lib does not work because "it is not built". So the question remains open : how to represent include and link dependencies between 2 imported libs ? With regards, David PS : as to why I had to have 2 stages (A_imported and A), this is because I wanted to add an alias which is not possible on an imported target Le 7 avril 2017 12:32:52 GMT+01:00, David Jobet a ?crit : >Well not quite. >I tried that, but my current definition is rather >Target_link_libraries(B interface B_imported) > >I don't remember for which reason I had to do it in 2 stages like that >(the A/A_imported and B/B_imported versions) > >If I add A in the list to read : >Target_link_libraries(B interface B_imported A) > >Then linking against B does add B_imported and A, but it does not keep >the link order and might put B_imported before A on the command line. > >I'll try with property INTERFACE_LINK_LIBRARIES instead, and will also >try to remove those 2 stages... > >With regards > >David > >Le 6 avril 2017 05:11:46 GMT+01:00, Dvir Yitzchaki > a ?crit : >>target_link_libraries(B INTERFACE A) >> >>Regards, >>Dvir >> >>From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of David Jobet >>Sent: Wednesday, April 5, 2017 18:34 >>To: cmake at cmake.org >>Subject: [CMake] Transitive include and link libraries on imported >>targets ? >> >>Hello, >> >>Let's say I build some external libs A and B with B depending on A. >>B and A do not use cmake, so I build them and install them in a >>3rdparty directory. I now have access to includes and libs. >>I then create some cmake file to describe those libs so I can use them >>in my project : >>Add_library(A_imported STATIC imported) >>Set_property(TARGET A_imported APPEND PROPERTY >>INTERFACE_INCLUDE_DIRECTORIES 3rdparty/include/A) >>Set_property(TARGET A_imported APPEND PROPERTY IMPORTED_LOCATION >>3rdparty/libs/libA.a) >>Add_library(A INTERFACE) >>Target_link_library(A INTERFACE A_imported) >> >>Same thing for B >> >>Now let's say I create a top-level target T that depends on B. >>Compilation might fail because B might include files from A and A is >>currently not a dependency of T. >> >>I can fix it in 2 ways : >>1- add A as a dependency of T, but I will need to do it on all my Ts >>2- somehow make B have transitive dependencies for include and link on >>A. That would be my prefered choice... But I don't know how to do it. >> >>Is it possible ? How ? >> >>Tx for your help. >> >>David > >-- >Envoy? de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser >ma bri?vet?. -- Envoy? de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma bri?vet?. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ayla at sci.utah.edu Fri Apr 7 15:44:55 2017 From: ayla at sci.utah.edu (Ayla Khan) Date: Fri, 7 Apr 2017 13:44:55 -0600 Subject: [CMake] CPack not detecting pkgbuild or product build Message-ID: I?m trying to build a Mac OS X installer package on 10.10.5 using Xcode 7.2 tools with the CPack that ships with CMake 3.7.2. I can generate a package from the CMake build directory if I call cpack directly on the command line with -G productbuild, but not through the CMake build using make package. Is there a CPack setting I need or some other build configuration information? Is the Xcode version too old? Thanks, Ayla From craig.scott at crascit.com Fri Apr 7 16:22:08 2017 From: craig.scott at crascit.com (Craig Scott) Date: Sat, 8 Apr 2017 06:22:08 +1000 Subject: [CMake] custom command comments not showing up In-Reply-To: References: Message-ID: Unfortunately, COMMENT is unreliable. Some generators will honour it, others won't. A more robust alternative is to use CMake's command mode to echo the comment instead. Eg: add_custom_command( TARGET zApp_zip POST_BUILD COMMAND ${CMAKE_COMMAND} -E echo "test2" COMMAND ${CMAKE_COMMAND} ARGS ...snip... ) On Fri, Apr 7, 2017 at 11:40 PM, Robert Dailey wrote: > So I probably am not understanding how this works. > > I have a custom target, that I later add multiple custom commands to. > Each custom command has a COMMENT set, but the target itself does too: > > add_custom_target(zApp_zip COMMENT "test1") > > add_custom_command( TARGET zApp_zip POST_BUILD > COMMAND ${CMAKE_COMMAND} ARGS ...snip... > COMMENT "test2" > ) > > Instead of seeing "test1" or "test2" when running, I get: > > $ ninja zApp_zip > [1/1] Running utility command for zApp_zip > > Why does it say "Running utility command"? What is the behavior of all > the comments supposed to be? Is this a ninja-specific issue or > behavior? > -- > > 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 > -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan at su-root.co.uk Fri Apr 7 18:58:16 2017 From: dan at su-root.co.uk (Dan Liew) Date: Fri, 7 Apr 2017 23:58:16 +0100 Subject: [CMake] Cmake for fftw library In-Reply-To: References: Message-ID: > Where Am I going wrong ? > Can anyone please help me out ? You don't link against fftw which is why you get linking errors. The `${fftw}` variable is empty. From post at hendrik-sattler.de Sat Apr 8 01:33:15 2017 From: post at hendrik-sattler.de (Hendrik Sattler) Date: Sat, 08 Apr 2017 07:33:15 +0200 Subject: [CMake] custom command comments not showing up In-Reply-To: References: Message-ID: However, this messes up parallel make progress output. Am 7. April 2017 22:22:08 MESZ schrieb Craig Scott : >Unfortunately, COMMENT is unreliable. Some generators will honour it, >others won't. A more robust alternative is to use CMake's command mode >to >echo the comment instead. Eg: > >add_custom_command( TARGET zApp_zip POST_BUILD > COMMAND ${CMAKE_COMMAND} -E echo "test2" > COMMAND ${CMAKE_COMMAND} ARGS ...snip... > ) > > > >On Fri, Apr 7, 2017 at 11:40 PM, Robert Dailey > >wrote: > >> So I probably am not understanding how this works. >> >> I have a custom target, that I later add multiple custom commands to. >> Each custom command has a COMMENT set, but the target itself does >too: >> >> add_custom_target(zApp_zip COMMENT "test1") >> >> add_custom_command( TARGET zApp_zip POST_BUILD >> COMMAND ${CMAKE_COMMAND} ARGS ...snip... >> COMMENT "test2" >> ) >> >> Instead of seeing "test1" or "test2" when running, I get: >> >> $ ninja zApp_zip >> [1/1] Running utility command for zApp_zip >> >> Why does it say "Running utility command"? What is the behavior of >all >> the comments supposed to be? Is this a ninja-specific issue or >> behavior? >> -- >> >> 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 >> -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. From craig.scott at crascit.com Sat Apr 8 06:24:23 2017 From: craig.scott at crascit.com (Craig Scott) Date: Sat, 8 Apr 2017 20:24:23 +1000 Subject: [CMake] cmake -E remove -f In-Reply-To: References: <20170405232252.GE2748@shochu.local> Message-ID: After taking a look at the source code, I'm convinced this option is questionable. Issue created in gitlab here . On Thu, Apr 6, 2017 at 9:35 AM, Craig Scott wrote: > Yes, but in both cases the directory foo is still not deleted! At least on > OSX any way. > > On Thu, Apr 6, 2017 at 9:22 AM, Mark Ferry wrote: > >> Hi Craig >> >> On Thu, 06 Apr 2017 08:55:58 +1000, Craig Scott wrote: >> > Can anyone identify a scenario where the -f option to the CMake command >> > mode's "remove" command makes any difference? >> > >> >> How about removing directories: >> >> ~/src/cmake-test$ cmake --version >> cmake version 3.0.2 >> >> CMake suite maintained and supported by Kitware (kitware.com/cmake). >> ~/src/cmake-test$ mkdir foo >> >> ~/src/cmake-test$ cmake -E remove foo >> ~/src/cmake-test$ echo $? >> 1 >> >> ~/src/cmake-test$ cmake -E remove -f foo >> ~/src/cmake-test$ echo $? >> 0 >> >> >> >> -- >> Cognomen Ltd >> http://cognomen.co.uk >> +44 7855 790184 >> > > > > -- > Craig Scott > Melbourne, Australia > https://crascit.com > -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From bitminer at gmail.com Sat Apr 8 13:09:06 2017 From: bitminer at gmail.com (Brian Davis) Date: Sat, 8 Apr 2017 12:09:06 -0500 Subject: [CMake] ExternalProject_Add and include_external_msproject dynamic duo... but what if their powers combined? In-Reply-To: References: Message-ID: crickets.... crickets... crickets... That's the response I get from the internet? Here are some other interesting bits: https://cmake.org/cmake/help/v3.8/manual/cmake-packages.7.html Does not make any reference to configure_package_config_file in https://cmake.org/cmake/help/v3.8/module/CMakePackageConfigHelpers.html But happily goes about telling pkg maintainers to go about and do with config_file what doc on configure_package_config_file says not to do... and that is NOT to use configure_file in the first place at: https://cmake.org/cmake/help/v3.8/manual/cmake-packages.7.html#id16 And then there is INSTALL_DESTINATION in: configure_package_config_file( INSTALL_DESTINATION which gives the pkg maintainer just enough rope to hang themselves with. I mean hey they could (and have) put it just about anywhere like ${CMAKE_INSTALL_PREFIX}/CMake or ${CMAKE_INSTALL_PREFIX}/lib/cmake or ${CMAKE_INSTALL_PREFIX}/lib/cmake/pkgname or ${CMAKE_INSTALL_PREFIX}/lib/cmake/pkgname- or ${CMAKE_INSTALL_PREFIX}/share/pkgname or ${CMAKE_INSTALL_PREFIX}/share/cmake/pkgname or ... well you get the idea. With or without version info. Where IMO configure_package_config_file should require version info and put in "standard directory" whatever that may be. Please someone in internet land tell me I am wrong. I'll await the crickets. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ggarra13 at gmail.com Sat Apr 8 13:28:19 2017 From: ggarra13 at gmail.com (=?UTF-8?Q?Gonzalo_Garramu=c3=b1o?=) Date: Sat, 8 Apr 2017 14:28:19 -0300 Subject: [CMake] .so link and cpack Message-ID: Currently, I have a project where I build a library and an executable that depends on the library. Finally, I package a .deb package with cpack. Now, my problem is that cpack packs the symbolic link of my library and that creates problems with the deb installer ( dpkg -i ) whenever I try to install the same version of my program twice. The error I get is that the symbolic link changed value from 20 to 42 (or something like that). I tried removing the symbolic link previous to packaging, but then I get cpack erroring out with: CMake Error at /media/gga/Datos/code/applications/mrViewer/BUILD/Linux-3.13.0-108-generic-64/Release/tmp/libACESclip/cmake_install.cmake:47 (file): file INSTALL cannot find "/media/gga/Datos/code/applications/mrViewer/BUILD/Linux-3.13.0-108-generic-64/Release/lib/libACESclip.so". Following a post on stackoverflow, I also tried using NAMELINK_SKIP on the library, like: set_target_properties( ACESclip PROPERTIES SOVERSION ${SOVERSION}) install( TARGETS ACESclip RUNTIME DESTINATION bin LIBRARY DESTINATION lib ARCHIVE DESTINATION lib NAMELINK_SKIP ) But then the executable: ADD_EXECUTABLE( mrViewer WIN32 ${SOURCES} ) TARGET_LINK_LIBRARIES( mrViewer ${LIBRARIES} ACESclip ) would not find my library and would error out. Therefore, I turn to the list for help. How do I prevent cpack from packaging symbolic links (a feature which is kind of wrong at least for .deb files)? Or how do I make my executable use the library without symlinks? Thanks in advance. From eric.noulard at gmail.com Sun Apr 9 06:13:35 2017 From: eric.noulard at gmail.com (Eric Noulard) Date: Sun, 9 Apr 2017 12:13:35 +0200 Subject: [CMake] .so link and cpack In-Reply-To: References: Message-ID: Hi Gonzalo, You should be able to build Deb package including symlink without trouble. Could you give the exact sequence of dpkg command which leads to the error you are speaking of? Does it work ok if you uninstall the previously installed deb package first? Do you install the very same package twice or did you change somehow the package version? Le 8 avr. 2017 19:28, "Gonzalo Garramu?o" a ?crit : Currently, I have a project where I build a library and an executable that depends on the library. Finally, I package a .deb package with cpack. Now, my problem is that cpack packs the symbolic link of my library and that creates problems with the deb installer ( dpkg -i ) whenever I try to install the same version of my program twice. The error I get is that the symbolic link changed value from 20 to 42 (or something like that). I tried removing the symbolic link previous to packaging, but then I get cpack erroring out with: CMake Error at /media/gga/Datos/code/applications/mrViewer/BUILD/Linux-3. 13.0-108-generic-64/Release/tmp/libACESclip/cmake_install.cmake:47 (file): file INSTALL cannot find "/media/gga/Datos/code/applications/mrViewer/BUILD/Linux-3. 13.0-108-generic-64/Release/lib/libACESclip.so". Following a post on stackoverflow, I also tried using NAMELINK_SKIP on the library, like: set_target_properties( ACESclip PROPERTIES SOVERSION ${SOVERSION}) install( TARGETS ACESclip RUNTIME DESTINATION bin LIBRARY DESTINATION lib ARCHIVE DESTINATION lib NAMELINK_SKIP ) But then the executable: ADD_EXECUTABLE( mrViewer WIN32 ${SOURCES} ) TARGET_LINK_LIBRARIES( mrViewer ${LIBRARIES} ACESclip ) would not find my library and would error out. Therefore, I turn to the list for help. How do I prevent cpack from packaging symbolic links (a feature which is kind of wrong at least for .deb files)? Or how do I make my executable use the library without symlinks? Thanks in advance. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensou rce/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake -------------- next part -------------- An HTML attachment was scrubbed... URL: From ggarra13 at gmail.com Sun Apr 9 13:48:40 2017 From: ggarra13 at gmail.com (=?UTF-8?Q?Gonzalo_Garramu=c3=b1o?=) Date: Sun, 9 Apr 2017 14:48:40 -0300 Subject: [CMake] .so link and cpack In-Reply-To: References: Message-ID: <1772de9d-e416-999b-2469-9d155f4dd9fb@gmail.com> El 09/04/17 a las 07:13, Eric Noulard escribi?: > Hi Gonzalo, > > You should be able to build Deb package including symlink without trouble. > > Could you give the exact sequence of dpkg command which leads to the > error you are speaking of? > $ dpkg -i mrViewer-v3.5.8-Linux-64.deb (Leyendo la base de datos ... 309470 ficheros o directorios instalados actualmente.) Preparando para desempaquetar mrViewer-v3.5.8-Linux-64.deb ... Desempaquetando mrviewer (3.5.8) sobre (3.5.8) ... dpkg: error al procesar el archivo mrViewer-v3.5.8-Linux-64.deb (--install): el tama?o del enlace simb?lico '/usr/local/mrViewer-v3.5.8-Linux-64/lib/libACESclip.so' ha cambiado de 48 a 20 > Does it work ok if you uninstall the previously installed deb package > first? > Yes. > Do you install the very same package twice or did you change somehow > the package version? > I install a different revision of the same version of the package. So it unpacks v3.5.8 over v3.5.8 I think the problem is that I am installing it into an NTFS partition. I have both Ubuntu 12.04 and Ubuntu 16.04.1 and the problem appears on Ubuntu 16.04, which has its /usr/local pointing to a NTFS partition. Sorry for the noise. From annulen at yandex.ru Sun Apr 9 13:57:08 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Sun, 09 Apr 2017 20:57:08 +0300 Subject: [CMake] _debug postfix in macOS frameworks Message-ID: <6093821491760628@web22o.yandex.ru> Hello, I'd like to put debug and release version of framework into the same bungle by adding "_debug" postfix to debug binaries. However it seems like CMAKE_DEBUG_POSTFIX is ignored b frameworks. What is the best way to achieve this? Is there any alternative cmake module for making frameworks/bundles that allows more flexibility? -- Regards, Konstantin From david.jobet at free.fr Mon Apr 10 04:25:42 2017 From: david.jobet at free.fr (David Jobet) Date: Mon, 10 Apr 2017 09:25:42 +0100 Subject: [CMake] Transitive include and link libraries on imported targets ? In-Reply-To: <46CC27EB-110B-4547-8E52-A1504EA60F4A@free.fr> References: <236AA806-3730-4049-8436-E9476A2D458C@free.fr> <8d336e07056e4e2996c5a307948b1df3@ceva-dsp.com> <54DDE9B5-707C-4CB4-B243-BC3762F9C2C0@free.fr> <46CC27EB-110B-4547-8E52-A1504EA60F4A@free.fr> Message-ID: <53A7C307-FDD9-4316-9F30-0FDE77AC98BB@free.fr> Hello, After googling a bit I found this post which I think describe exactly what I'm facing : https://cmake.org/pipermail/cmake/2016-August/064100.html However I fail to understand the answers. Maybe I'm expecting too much. Basically, I have 2 imported static targets (A and B with B that needs A to compile and link) that I'd like to treat them as "first class cmake citizen". What I mean by that is that if one of my project lib depends on B, then I want both B and A's include directories to be added to my lib's include directories and I want both A and B's lib to be linked against my lib. So far I can use INTERFACE_LINK_LIBRARIES on B to add A's lib, and I guess I can use INTERFACE_INCLUDE_DIRECTORIES to add A's includes, but that won't pull transitive dependencies of A into B. I can use target_link_libraries on an interface of B to add A as described in my first email : that will properly pull any transitive include or libs but that won't make sure that link order is preserved. Please help. David Le 7 avril 2017 15:27:23 GMT+01:00, David Jobet a ?crit : >INTERFACE_LINK_LIBRARIES won't work since it won't pull out include >path for dependants. > >Using target_link_libraries() on the imported lib does not work because >"it is not built". > >So the question remains open : how to represent include and link >dependencies between 2 imported libs ? > >With regards, > >David > >PS : as to why I had to have 2 stages (A_imported and A), this is >because I wanted to add an alias which is not possible on an imported >target > >Le 7 avril 2017 12:32:52 GMT+01:00, David Jobet a >?crit : >>Well not quite. >>I tried that, but my current definition is rather >>Target_link_libraries(B interface B_imported) >> >>I don't remember for which reason I had to do it in 2 stages like that >>(the A/A_imported and B/B_imported versions) >> >>If I add A in the list to read : >>Target_link_libraries(B interface B_imported A) >> >>Then linking against B does add B_imported and A, but it does not keep >>the link order and might put B_imported before A on the command line. >> >>I'll try with property INTERFACE_LINK_LIBRARIES instead, and will also >>try to remove those 2 stages... >> >>With regards >> >>David >> >>Le 6 avril 2017 05:11:46 GMT+01:00, Dvir Yitzchaki >> a ?crit : >>>target_link_libraries(B INTERFACE A) >>> >>>Regards, >>>Dvir >>> >>>From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of David Jobet >>>Sent: Wednesday, April 5, 2017 18:34 >>>To: cmake at cmake.org >>>Subject: [CMake] Transitive include and link libraries on imported >>>targets ? >>> >>>Hello, >>> >>>Let's say I build some external libs A and B with B depending on A. >>>B and A do not use cmake, so I build them and install them in a >>>3rdparty directory. I now have access to includes and libs. >>>I then create some cmake file to describe those libs so I can use >them >>>in my project : >>>Add_library(A_imported STATIC imported) >>>Set_property(TARGET A_imported APPEND PROPERTY >>>INTERFACE_INCLUDE_DIRECTORIES 3rdparty/include/A) >>>Set_property(TARGET A_imported APPEND PROPERTY IMPORTED_LOCATION >>>3rdparty/libs/libA.a) >>>Add_library(A INTERFACE) >>>Target_link_library(A INTERFACE A_imported) >>> >>>Same thing for B >>> >>>Now let's say I create a top-level target T that depends on B. >>>Compilation might fail because B might include files from A and A is >>>currently not a dependency of T. >>> >>>I can fix it in 2 ways : >>>1- add A as a dependency of T, but I will need to do it on all my Ts >>>2- somehow make B have transitive dependencies for include and link >on >>>A. That would be my prefered choice... But I don't know how to do it. >>> >>>Is it possible ? How ? >>> >>>Tx for your help. >>> >>>David >> >>-- >>Envoy? de mon appareil Android avec Courriel K-9 Mail. Veuillez >excuser >>ma bri?vet?. > >-- >Envoy? de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser >ma bri?vet?. -- Envoy? de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma bri?vet?. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcdailey.lists at gmail.com Mon Apr 10 09:23:46 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Mon, 10 Apr 2017 08:23:46 -0500 Subject: [CMake] custom command comments not showing up In-Reply-To: References: Message-ID: Seems like the solution here is to make COMMENT work properly/consistently across all generators. That's the point, after all, right? On Sat, Apr 8, 2017 at 12:33 AM, Hendrik Sattler wrote: > However, this messes up parallel make progress output. > > Am 7. April 2017 22:22:08 MESZ schrieb Craig Scott : >>Unfortunately, COMMENT is unreliable. Some generators will honour it, >>others won't. A more robust alternative is to use CMake's command mode >>to >>echo the comment instead. Eg: >> >>add_custom_command( TARGET zApp_zip POST_BUILD >> COMMAND ${CMAKE_COMMAND} -E echo "test2" >> COMMAND ${CMAKE_COMMAND} ARGS ...snip... >> ) >> >> >> >>On Fri, Apr 7, 2017 at 11:40 PM, Robert Dailey >> >>wrote: >> >>> So I probably am not understanding how this works. >>> >>> I have a custom target, that I later add multiple custom commands to. >>> Each custom command has a COMMENT set, but the target itself does >>too: >>> >>> add_custom_target(zApp_zip COMMENT "test1") >>> >>> add_custom_command( TARGET zApp_zip POST_BUILD >>> COMMAND ${CMAKE_COMMAND} ARGS ...snip... >>> COMMENT "test2" >>> ) >>> >>> Instead of seeing "test1" or "test2" when running, I get: >>> >>> $ ninja zApp_zip >>> [1/1] Running utility command for zApp_zip >>> >>> Why does it say "Running utility command"? What is the behavior of >>all >>> the comments supposed to be? Is this a ninja-specific issue or >>> behavior? >>> -- >>> >>> 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 >>> > > -- > Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. From rcdailey.lists at gmail.com Mon Apr 10 09:29:20 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Mon, 10 Apr 2017 08:29:20 -0500 Subject: [CMake] How to properly handle build version number in CMake script for project Message-ID: I have a file called version.cmake that my root CMakeLists.txt includes. There is only a single line in this file: set( BUILD_VERSION 1.2.3.4 CACHE STRING "Version of the product" ) I have two scenarios where this version number setting needs to work slightly differently from a CMake perspective: 1. Our CI build server does a fresh clone of our repo, and generates from scratch. It sometimes needs to override the version number from the command line via arguments. So it will do: -D BUILD_VERSION=99.99.1.2 This works since it's a cache variable. In fact, the current solution ONLY works well for this scenario (since it will allow overriding from command line, but also allow the file to set the value if it is not specified as a -D argument). 2. Local work machine builds. Local builds never override using -D, they always use what is in the version.cmake file. However, because it's a cache variable and I'm not using FORCE with set(), it never updates if I change the version and push it to origin. This is the missing requirement: it needs to update when the number (value) changes in version control I thought of making a BUILD_VERSION_OVERRIDE that is only accepted on the command line, and if specified, it will set the BUILD_VERSION value to the overridden value. However, I don't like the idea of 2 separate variables to manage this. Using a non-cache variable doesn't allow overriding with the same variable value on the command line either. What's the best solution here for my situation? From bruce.r.stephens at gmail.com Mon Apr 10 09:36:11 2017 From: bruce.r.stephens at gmail.com (Bruce Stephens) Date: Mon, 10 Apr 2017 14:36:11 +0100 Subject: [CMake] How to properly handle build version number in CMake script for project In-Reply-To: References: Message-ID: You could do something like if(NOT "${BUILD_VERSION}") set(BUILD_VERSION 1.2.3.4) endif() On Mon, Apr 10, 2017 at 2:29 PM, Robert Dailey wrote: > I have a file called version.cmake that my root CMakeLists.txt > includes. There is only a single line in this file: > > set( BUILD_VERSION 1.2.3.4 CACHE STRING "Version of the product" ) > > I have two scenarios where this version number setting needs to work > slightly differently from a CMake perspective: > > 1. Our CI build server does a fresh clone of our repo, and generates > from scratch. It sometimes needs to override the version number from > the command line via arguments. So it will do: > > -D BUILD_VERSION=99.99.1.2 > > This works since it's a cache variable. In fact, the current solution > ONLY works well for this scenario (since it will allow overriding from > command line, but also allow the file to set the value if it is not > specified as a -D argument). > > 2. Local work machine builds. Local builds never override using -D, > they always use what is in the version.cmake file. However, because > it's a cache variable and I'm not using FORCE with set(), it never > updates if I change the version and push it to origin. This is the > missing requirement: it needs to update when the number (value) > changes in version control > > I thought of making a BUILD_VERSION_OVERRIDE that is only accepted on > the command line, and if specified, it will set the BUILD_VERSION > value to the overridden value. However, I don't like the idea of 2 > separate variables to manage this. Using a non-cache variable doesn't > allow overriding with the same variable value on the command line > either. > > What's the best solution here for my situation? > -- > > 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 bruce.r.stephens at gmail.com Mon Apr 10 10:15:27 2017 From: bruce.r.stephens at gmail.com (Bruce Stephens) Date: Mon, 10 Apr 2017 15:15:27 +0100 Subject: [CMake] How to properly handle build version number in CMake script for project In-Reply-To: References: Message-ID: On Mon, Apr 10, 2017 at 2:36 PM, Bruce Stephens wrote: > You could do something like > > if(NOT "${BUILD_VERSION}") > set(BUILD_VERSION 1.2.3.4) > endif() That doesn't work at all, come to think of it. I suspect your best bet is to handle the caching yourself (likely using a file in ${CMAKE_BINARY_DIR} and maybe "include(... OPTIONAL)"). That should allow whatever behaviour you want. I note that llvm's builds have the same sort of problem, so whatever fix is required isn't obvious even to obviously bright people. (That is, when the version switched from 4.0.0 to 5.0.0 my builds didn't change their version number. I had to remove the build directory and build again from clean.) From rcdailey.lists at gmail.com Mon Apr 10 12:04:03 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Mon, 10 Apr 2017 11:04:03 -0500 Subject: [CMake] How to properly handle build version number in CMake script for project In-Reply-To: References: Message-ID: Actually I think your idea does work. Why do you think it won't? I'm using it right now and so far it seems OK. 1. On build server, if it overrides it with -D, then it does not set it by hand. If it doesn't override, it will use the fixed version in the file 2. On work machines, it's never defined prior, so it sets it with the fixed version. On Mon, Apr 10, 2017 at 9:15 AM, Bruce Stephens wrote: > On Mon, Apr 10, 2017 at 2:36 PM, Bruce Stephens > wrote: >> You could do something like >> >> if(NOT "${BUILD_VERSION}") >> set(BUILD_VERSION 1.2.3.4) >> endif() > > > That doesn't work at all, come to think of it. I suspect your best bet > is to handle > the caching yourself (likely using a file in ${CMAKE_BINARY_DIR} and > maybe "include(... OPTIONAL)"). That should allow whatever behaviour > you want. > > I note that llvm's builds have the same sort of problem, so whatever > fix is required > isn't obvious even to obviously bright people. (That is, when the > version switched > from 4.0.0 to 5.0.0 my builds didn't change their version number. I > had to remove the > build directory and build again from clean.) From post at hendrik-sattler.de Mon Apr 10 12:10:12 2017 From: post at hendrik-sattler.de (Hendrik Sattler) Date: Mon, 10 Apr 2017 18:10:12 +0200 Subject: [CMake] How to properly handle build version number in CMake script for project In-Reply-To: References: Message-ID: Hi, You could make it a non-cache variable and manage the caching yourself. The cache is your version.cmake. Before including it, check if the variable is set and update your version cmake file, possibly with configure_file(). After that, unset() the cache variable and include your cmake file, this having a non-cache variable. Add the cmake file to the list of dependent files to let cmake run when that file changes. Regards HS Am 10. April 2017 15:29:20 MESZ schrieb Robert Dailey : >I have a file called version.cmake that my root CMakeLists.txt >includes. There is only a single line in this file: > >set( BUILD_VERSION 1.2.3.4 CACHE STRING "Version of the product" ) > >I have two scenarios where this version number setting needs to work >slightly differently from a CMake perspective: > >1. Our CI build server does a fresh clone of our repo, and generates >from scratch. It sometimes needs to override the version number from >the command line via arguments. So it will do: > >-D BUILD_VERSION=99.99.1.2 > >This works since it's a cache variable. In fact, the current solution >ONLY works well for this scenario (since it will allow overriding from >command line, but also allow the file to set the value if it is not >specified as a -D argument). > >2. Local work machine builds. Local builds never override using -D, >they always use what is in the version.cmake file. However, because >it's a cache variable and I'm not using FORCE with set(), it never >updates if I change the version and push it to origin. This is the >missing requirement: it needs to update when the number (value) >changes in version control > >I thought of making a BUILD_VERSION_OVERRIDE that is only accepted on >the command line, and if specified, it will set the BUILD_VERSION >value to the overridden value. However, I don't like the idea of 2 >separate variables to manage this. Using a non-cache variable doesn't >allow overriding with the same variable value on the command line >either. > >What's the best solution here for my situation? -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. From bruce.r.stephens at gmail.com Mon Apr 10 13:48:24 2017 From: bruce.r.stephens at gmail.com (Bruce Stephens) Date: Mon, 10 Apr 2017 18:48:24 +0100 Subject: [CMake] How to properly handle build version number in CMake script for project In-Reply-To: References: Message-ID: On Mon, Apr 10, 2017 at 5:04 PM, Robert Dailey wrote: > Actually I think your idea does work. Why do you think it won't? I'm > using it right now and so far it seems OK. I assumed (without testing, admittedly) is that it would fail if someone used -D to set the value, then changed some CMakeLists.txt file, then executed the build command again. I'd expect that to rerun cmake to update the build files and I'd fear that you'd then get BUILD_VERSION from the CMakeLists.txt file rather than the value explicitly set. However, I haven't tried it, and maybe it works fine (with the generators you care about) even without caching? From rcdailey.lists at gmail.com Mon Apr 10 14:15:12 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Mon, 10 Apr 2017 13:15:12 -0500 Subject: [CMake] How to properly handle build version number in CMake script for project In-Reply-To: References: Message-ID: Sorry you're right, this isn't working because -D creates a cache entry for the variable, which breaks it. So maybe more ideas on the configure_file() solution would be ideal... unsetting the cache variable might work as well, I have to toy around with this. On Mon, Apr 10, 2017 at 12:48 PM, Bruce Stephens wrote: > On Mon, Apr 10, 2017 at 5:04 PM, Robert Dailey wrote: >> Actually I think your idea does work. Why do you think it won't? I'm >> using it right now and so far it seems OK. > > I assumed (without testing, admittedly) is that it would fail if > someone used -D to set the value, > then changed some CMakeLists.txt file, then executed the build command > again. I'd expect that > to rerun cmake to update the build files and I'd fear that you'd then > get BUILD_VERSION from > the CMakeLists.txt file rather than the value explicitly set. > > However, I haven't tried it, and maybe it works fine (with the > generators you care about) even without > caching? From rcdailey.lists at gmail.com Mon Apr 10 14:32:32 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Mon, 10 Apr 2017 13:32:32 -0500 Subject: [CMake] How to properly handle build version number in CMake script for project In-Reply-To: References: Message-ID: Actually this seems to work: if( BUILD_VERSION ) set( version_override ${BUILD_VERSION} ) unset( BUILD_VERSION CACHE ) set( BUILD_VERSION ${version_override} ) unset( version_override ) else() set( BUILD_VERSION 7.1.1.2 ) endif() It's a bit messy but gets the job done, and doesn't require configure_file(). Maybe there is a way to clean this up even more? I noticed that unset( BUILD_VERSION CACHE ) actually unsets non-cache versions of a variable too, so I had to use the temporary variable to transfer the value. On Mon, Apr 10, 2017 at 1:15 PM, Robert Dailey wrote: > Sorry you're right, this isn't working because -D creates a cache > entry for the variable, which breaks it. > > So maybe more ideas on the configure_file() solution would be ideal... > unsetting the cache variable might work as well, I have to toy around > with this. > > On Mon, Apr 10, 2017 at 12:48 PM, Bruce Stephens > wrote: >> On Mon, Apr 10, 2017 at 5:04 PM, Robert Dailey wrote: >>> Actually I think your idea does work. Why do you think it won't? I'm >>> using it right now and so far it seems OK. >> >> I assumed (without testing, admittedly) is that it would fail if >> someone used -D to set the value, >> then changed some CMakeLists.txt file, then executed the build command >> again. I'd expect that >> to rerun cmake to update the build files and I'd fear that you'd then >> get BUILD_VERSION from >> the CMakeLists.txt file rather than the value explicitly set. >> >> However, I haven't tried it, and maybe it works fine (with the >> generators you care about) even without >> caching? From rcdailey.lists at gmail.com Mon Apr 10 14:35:36 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Mon, 10 Apr 2017 13:35:36 -0500 Subject: [CMake] How to properly handle build version number in CMake script for project In-Reply-To: References: Message-ID: OK weirdly, tested again, this also works and is a little more simplified (although more confusing, since now we're intermixing non-cache and cache variables with the same name; behavior is not exactly clear, or well-defined. if( BUILD_VERSION ) set( BUILD_VERSION ${BUILD_VERSION} ) unset( BUILD_VERSION CACHE ) else() set( BUILD_VERSION 7.1.1.2 ) endif() On Mon, Apr 10, 2017 at 1:32 PM, Robert Dailey wrote: > Actually this seems to work: > > if( BUILD_VERSION ) > > set( version_override ${BUILD_VERSION} ) > unset( BUILD_VERSION CACHE ) > set( BUILD_VERSION ${version_override} ) > unset( version_override ) > > else() > > set( BUILD_VERSION 7.1.1.2 ) > > endif() > > It's a bit messy but gets the job done, and doesn't require > configure_file(). Maybe there is a way to clean this up even more? > > I noticed that unset( BUILD_VERSION CACHE ) actually unsets non-cache > versions of a variable too, so I had to use the temporary variable to > transfer the value. > > On Mon, Apr 10, 2017 at 1:15 PM, Robert Dailey wrote: >> Sorry you're right, this isn't working because -D creates a cache >> entry for the variable, which breaks it. >> >> So maybe more ideas on the configure_file() solution would be ideal... >> unsetting the cache variable might work as well, I have to toy around >> with this. >> >> On Mon, Apr 10, 2017 at 12:48 PM, Bruce Stephens >> wrote: >>> On Mon, Apr 10, 2017 at 5:04 PM, Robert Dailey wrote: >>>> Actually I think your idea does work. Why do you think it won't? I'm >>>> using it right now and so far it seems OK. >>> >>> I assumed (without testing, admittedly) is that it would fail if >>> someone used -D to set the value, >>> then changed some CMakeLists.txt file, then executed the build command >>> again. I'd expect that >>> to rerun cmake to update the build files and I'd fear that you'd then >>> get BUILD_VERSION from >>> the CMakeLists.txt file rather than the value explicitly set. >>> >>> However, I haven't tried it, and maybe it works fine (with the >>> generators you care about) even without >>> caching? From robert.maynard at kitware.com Mon Apr 10 15:19:06 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Mon, 10 Apr 2017 15:19:06 -0400 Subject: [CMake] [ANNOUNCE] CMake 3.8.0 available for download Message-ID: I am proud to announce that CMake 3.8.0 is now available for download at: https://cmake.org/download/ Documentation is available at: https://cmake.org/cmake/help/v3.8 Release notes appear below and are also published at https://cmake.org/cmake/help/v3.8/release/3.8.html Some of the more significant changes in CMake 3.8 are: * CMake now supports "CSharp" (C#) as a first-class language. It is currently supported by the Visual Studio Generators for VS 2010 and above. * CMake now supports "CUDA" as a first-class language. It is currently supported by the Makefile Generators and the "Ninja" generator on Linux, macOS, and Windows. Support for the Visual Studio IDE is under development but not included in this release. * The "Compile Features" functionality now offers meta-features that request compiler modes for specific language standard levels (e.g. "cxx_std_11"). See "CMAKE_C_KNOWN_FEATURES" and "CMAKE_CXX_KNOWN_FEATURES". * The "Compile Features" functionality is now aware of C++ 17. No specific features are yet enumerated besides the "cxx_std_17" meta- feature. * The Visual Studio Generators for VS 2013 and above learned to support a "host=x64" option in the "CMAKE_GENERATOR_TOOLSET" value (e.g. via the "cmake(1)" "-T" option) to request use of a VS 64-bit toolchain on 64-bit hosts. * The Visual Studio Generators learned to treat files passed to "target_link_libraries()" whose names end in ".targets" as MSBuild "targets" files to be imported into generated project files. * The "try_compile()" command source file signature gained new options to specify the language standard to use in the generated test project. * The "try_compile()" command source file signature now honors language standard variables like "CMAKE_CXX_STANDARD". See policy "CMP0067". * A "BUILD_RPATH" target property and corresponding "CMAKE_BUILD_RPATH" variable were added to support custom "RPATH" locations to be added to binaries in the build tree. * The "COMPILE_FLAGS" source file property learned to support "generator expressions". * A new generator expression "$" was added. It resolves to the true-value if the condition is "1" and resolves to the false-value if the condition is "0". * The "Compile Features" functionality is now aware of features supported by Intel C++ compilers versions 12.1 through 17.0 on UNIX and Windows platforms. * The Visual Studio Generators for VS 2010 and above now place per- source file flags after target-wide flags when they are classified as raw flags with no project file setting ("AdditionalOptions"). This behavior is more consistent with the ordering of flags produced by other generators, and allows flags on more-specific properties (per-source) to override those on more general ones (per-target). * The precompiled Windows binary MSI package provided on "cmake.org" now records the installation directory in the Windows Registry under the key "HKLM\Software\Kitware\CMake" with a value named "InstallDir". CMake 3.8 Release Notes *********************** Changes made since CMake 3.7 include the following. New Features ============ Languages --------- C# ~~ * CMake learned to support "CSharp" (C#) as a first-class language that can be enabled via the "project()" and "enable_language()" commands. It is currently supported by the Visual Studio Generators for VS 2010 and above. C# assemblies and programs can be added just like common C++ targets using the "add_library()" and "add_executable()" commands. References between C# targets in the same source tree may be specified by "target_link_libraries()" like for C++. References to system or 3rd-party assemblies may be specified by the target properties "VS_DOTNET_REFERENCE_" and "VS_DOTNET_REFERENCES". * More fine tuning of C# targets may be done using target and source file properties. Specifically the target properties related to Visual Studio ("VS_*") are worth a look (for setting toolset versions, root namespaces, assembly icons, ...). CUDA ~~~~ * CMake learned to support "CUDA" as a first-class language that can be enabled via the "project()" and "enable_language()" commands. * "CUDA" is currently supported by the Makefile Generators and the "Ninja" generator on Linux, macOS, and Windows. Support for the Visual Studio IDE is under development but not included in this release. * The NVIDIA CUDA Toolkit compiler ("nvcc") is supported. C & C++ ~~~~~~~ * The "Compile Features" functionality now offers meta-features that request compiler modes for specific language standard levels (e.g. "cxx_std_11"). See "CMAKE_C_KNOWN_FEATURES" and "CMAKE_CXX_KNOWN_FEATURES". * The "Compile Features" functionality is now aware of C++ 17. No specific features are yet enumerated besides the "cxx_std_17" meta- feature. * The "Compile Features" functionality is now aware of the availability of C99 in gcc since version 3.4. Platforms --------- * A new minimal platform file for "Fuchsia" was added. Generators ---------- * The "CodeBlocks" extra generator may now be used to generate with "NMake Makefiles JOM". * The Visual Studio Generators for VS 2013 and above learned to support a "host=x64" option in the "CMAKE_GENERATOR_TOOLSET" value (e.g. via the "cmake(1)" "-T" option) to request use of a VS 64-bit toolchain on 64-bit hosts. * The Visual Studio Generators learned to treat files passed to "target_link_libraries()" whose names end in ".targets" as MSBuild "targets" files to be imported into generated project files. Commands -------- * The "add_custom_command()" and "add_custom_target()" commands learned the option "COMMAND_EXPAND_LISTS" which causes lists in the "COMMAND" argument to be expanded, including lists created by generator expressions. * The "execute_process()" command gained an "ENCODING" option to specify on Windows which encoding is used for output from child process. * The "math(EXPR)" command gained support for unary "+" and "-" operators. * The "source_group()" command gained "TREE" and "PREFIX" options to add groups following source tree directory structure. * The "string(TIMESTAMP)" command learned to treat "%%" as a way to encode plain "%". * The "string(TIMESTAMP)" command will now honor the "SOURCE_DATE_EPOCH" environment variable and use its value instead of the current time. * The "try_compile()" command source file signature gained new options to specify the language standard to use in the generated test project. * The "try_compile()" command source file signature now honors language standard variables like "CMAKE_CXX_STANDARD". See policy "CMP0067". Variables --------- * A "CMAKE_CODELITE_USE_TARGETS" variable was added to tell the "CodeLite" extra generator to change the generated project to have target-centric organization. The "build", "rebuild", and "clean" operations within "CodeLite" then work on a selected target rather than the whole workspace. (Note that the "Ninja" clean operation on a target includes its dependencies, though.) * The "CMAKE_SUBLIME_TEXT_2_ENV_SETTINGS" variable was added to tell the "Sublime Text 2" extra generator to place specified environment variables in the generated ".sublime-project". * The "CMAKE_SUBLIME_TEXT_2_EXCLUDE_BUILD_TREE" variable was added to tell the "Sublime Text 2" extra generator whether to exclude the build tree from the ".sublime-project" when it is inside the source tree. * A "CMAKE_VS_INCLUDE_PACKAGE_TO_DEFAULT_BUILD" variable was added to tell Visual Studio Generators for VS 2010 and above to include the "PACKAGE" target in the default build, similar to the existing "CMAKE_VS_INCLUDE_INSTALL_TO_DEFAULT_BUILD" variable for the "INSTALL" target. Properties ---------- * A "BUILD_RPATH" target property and corresponding "CMAKE_BUILD_RPATH" variable were added to support custom "RPATH" locations to be added to binaries in the build tree. * The "COMPILE_FLAGS" source file property learned to support "generator expressions". * The "FRAMEWORK" target property may now also be applied to static libraries on Apple targets. It will result in a proper Framework but with a static library inside. * Imported Interface Libraries learned new "IMPORTED_LIBNAME" and "IMPORTED_LIBNAME_" target properties to specify a link library name since interface libraries do not build their own library files. * A "_CPPLINT" target property and supporting "CMAKE__CPPLINT" variable were introduced to tell the Makefile Generators and the "Ninja" generator to run the "cpplint" style checker along with the compiler for "C" and "CXX" languages. * A "MANUALLY_ADDED_DEPENDENCIES" target property has been added. It provides a read-only list of dependencies that have been added with the "add_dependencies()" command. * The "MAP_IMPORTED_CONFIG_" target property learned to interpret empty list elements as referring to the configuration-less imported location specified by "IMPORTED_LOCATION". * The "NO_SYSTEM_FROM_IMPORTED" target property is now supported on Imported Interface Libraries. * New source file properties "SKIP_AUTOMOC", "SKIP_AUTOUIC", "SKIP_AUTORCC", and "SKIP_AUTOGEN" were added to allow source files to be excluded from processing by "AUTOMOC", "AUTOUIC", and "AUTORCC" target properties. * A "VS_COPY_TO_OUT_DIR" source file property was added to tell Visual Studio Generators for VS 2010 and above whether or not a file should e copied to the output directory. * A "VS_DEBUGGER_WORKING_DIRECTORY" target property was added to tell Visual Studio Generators for VS 2010 and above what debugger working directory should be set for the target. * A "VS_DOTNET_REFERENCES_COPY_LOCAL" target property was added to specify whether to copy referenced assemblies to the output directory. * A "VS_DOTNET_REFERENCE_" target property was added to tell Visual Studio Generators for VS 2010 and above to add a .NET reference with a given hint path. * A "VS_INCLUDE_IN_VSIX" source file property was added to tell Visual Studio Generators for VS 2010 and above whether to include the file in a Visual Studio extension package. * A "VS_RESOURCE_GENERATOR" source file property was added to give Visual Studio Generators for VS 2010 and above a setting for the resource generator ("C#" only). * A "VS_USER_PROPS" target property was added to tell Visual Studio Generators for VS 2010 and above to use a custom MSBuild user ".props" file. * A "XCODE_EMIT_EFFECTIVE_PLATFORM_NAME" global property was added to tell the "Xcode" generator whether to emit the "EFFECTIVE_PLATFORM_NAME" variable. This is useful when building with multiple SDKs like "macosx" and "iphoneos" in parallel. * New "XCODE_PRODUCT_TYPE" and "XCODE_EXPLICIT_FILE_TYPE" target properties were created to tell the "Xcode" generator to use custom values of the corresponding attributes for a target in the generated Xcode project. Modules ------- * A "CSharpUtilities" module was added to aid parameterization of Visual Studio C# targets. It provides functions to allow automated setting of source file properties to support Windows Forms, WPF/XAML or other technologies as needed. * The "ExternalData" module learned to support multiple content links for one data file using different hashes, e.g. "img.png.sha256" and "img.png.sha1". This allows objects to be fetched from sources indexed by different hash algorithms. * The "ExternalProject" module gained the "GIT_PROGRESS" option to force Git to show progress when cloning repositories. * The "ExternalProject" module gained a "GIT_CONFIG" option to pass " --config" options to Git when cloning repositories. * The "FeatureSummary" module "feature_summary()" command now accepts a new "QUIET_ON_EMPTY" option that suppresses the output when the list of packages that belong to the selected category is empty. * The "FeatureSummary" module "add_feature_info()" command now accepts lists of dependencies for deciding whether a feature is enabled or not. * The package types accepted by the "FeatureSummary" module can now be tweaked by changing the "FeatureSummary_PKG_TYPES", "FeatureSummary_REQUIRED_PKG_TYPES" and "FeatureSummary_DEFAULT_PKG_TYPE" global properties. * The "FindOpenGL" module now provides imported targets "OpenGL::GL" and "OpenGL::GLU" when the libraries are found. * The "UseSWIG" module gained a "swig_add_library" command to give more flexibility over the old "swig_add_module" command. * The "UseSWIG" module "swig_add_source_to_module" command learned a new "SWIG_OUTFILE_DIR" option to control the output file location ("swig -o"). * The "WriteCompilerDetectionHeader" module gained the "ALLOW_UNKNOWN_COMPILERS" and "ALLOW_UNKNOWN_COMPILER_VERSIONS" options that allow creation of headers that will work also with unknown or old compilers by simply assuming they do not support any of the requested features. CTest ----- * The "ctest_memcheck()" command gained a "DEFECT_COUNT " option to capture the number of memory defects detected. * The "ctest_memcheck()" command learned to read the location of suppressions files for sanitizers from the "CTEST_MEMORYCHECK_SUPPRESSIONS_FILE" variable. * The "ctest_memcheck()" command learned to support "LeakSanitizer" independently from "AddressSanitizer". * The "ctest_update()" command "CDASH_UPLOAD" signature was taught to honor the "RETRY_COUNT", "RETRY_DELAY", and "QUIET" options. CPack ----- * The "CPackIFWConfigureFile" module was added to define a new "cpack_ifw_configure_file()" command to configure file templates prepared in QtIFW/SDK/Creator style. * The "CPackIFW" module "cpack_ifw_configure_component()" and "cpack_ifw_configure_component_group()" commands gained a new "DEFAULT", "VIRTUAL", "FORCED_INSTALLATION", "REQUIRES_ADMIN_RIGHTS", "DISPLAY_NAME", "UPDATE_TEXT", "DESCRIPTION", "RELEASE_DATE", "AUTO_DEPEND_ON" and "TRANSLATIONS" options to more specific configuration. * The "CPackIFW" module "cpack_ifw_configure_component()" command gained a new "DEPENDENCIES" alias for "DEPENDS" option. * The "CPackIFW" module "cpack_ifw_configure_component_group()" command gained a new "DEPENDS" option. The "DEPENDENCIES" alias also added. * The "CPackIFW" module "cpack_ifw_configure_component()" and "cpack_ifw_configure_component_group()" commands "PRIORITY" option now is deprecated and will be removed in a future version of CMake. Please use new "SORTING_PRIORITY" option instead. * The "CPackIFW" module gained new "CPACK_IFW_PACKAGE_WATERMARK", "CPACK_IFW_PACKAGE_BANNER", "CPACK_IFW_PACKAGE_BACKGROUND", "CPACK_IFW_PACKAGE_WIZARD_STYLE", "CPACK_IFW_PACKAGE_WIZARD_DEFAULT_WIDTH", "CPACK_IFW_PACKAGE_WIZARD_DEFAULT_HEIGHT", and "CPACK_IFW_PACKAGE_TITLE_COLOR" variables to customize a QtIFW installer look. * The "CPackProductBuild" module gained options to sign packages. See the variables "CPACK_PRODUCTBUILD_IDENTITY_NAME", "CPACK_PRODUCTBUILD_KEYCHAIN_PATH", "CPACK_PKGBUILD_IDENTITY_NAME", and "CPACK_PKGBUILD_KEYCHAIN_PATH". * The "CPackRPM" module learned to omit tags that are not supported by provided "rpmbuild" tool. If unsupported tags are set they are ignored and a developer warning is printed out. * The "CPackRPM" module learned to generate main component package which forces generation of a rpm for defined component without component suffix in filename and package name. See "CPACK_RPM_MAIN_COMPONENT" variable. * The "CPackRPM" module learned to generate a single "debuginfo" package on demand even if components packaging is used. See "CPACK_RPM_DEBUGINFO_SINGLE_PACKAGE" variable. * The "CPackRPM" module learned to support multiple directives per file when using "CPACK_RPM_USER_FILELIST" variable. Other ----- * CMake functionality using cryptographic hashes now supports SHA-3 algorithms. * A new generator expression "$" was added. It resolves to the true-value if the condition is "1" and resolves to the false-value if the condition is "0". Deprecated and Removed Features =============================== * The "FeatureSummary" module commands "set_package_info()", "set_feature_info()", "print_enabled_features()", and "print_disabled_features()" are now deprecated. * The "UseSWIG" module "swig_add_module" command is now deprecated in favor of "swig_add_library". Other Changes ============= * If a command specified by the "_CLANG_TIDY" target property returns non-zero at build time this is now treated as an error instead of silently ignored. * The "ctest_memcheck()" command no longer automatically adds "leak_check=1" to the options used by "AddressSanitizer". The default behavior of "AddressSanitizer" is to run *LeakSanitizer* to check leaks unless "leak_check=0". * The "ctest_memcheck()" command was fixed to correctly append extra sanitizer options read from the "CTEST_MEMORYCHECK_SANITIZER_OPTIONS" variable to the environment variables used internally by the sanitizers. * The "FeatureSummary" module "set_package_properties()" command no longer forces the package type to "OPTIONAL" when the type is not explicitly set. * The "Compile Features" functionality is now aware of features supported by Intel C++ compilers versions 12.1 through 17.0 on UNIX and Windows platforms. * Calls to the "FindPkgConfig" module "pkg_check_modules()" command following a successful call learned to re-evaluate the cached values for a given prefix after changes to the parameters to the command for that prefix. * When using "AUTOMOC" or "AUTOUIC", generated "moc_*", "*.moc" and "ui_*" are placed in the "/_autogen/include" directory which is automatically added to the target's "INCLUDE_DIRECTORIES". It is therefore not necessary anymore to have "CMAKE_CURRENT_BINARY_DIR" in the target's "INCLUDE_DIRECTORIES". * The "Sublime Text 2" generator no longer runs the native build command (e.g. "ninja" or "make") with verbose build output enabled. * The "try_compile()" command source file signature now honors the "CMAKE_WARN_DEPRECATED" variable value in the generated test project. * The Visual Studio Generators for VS 2010 and above now place per- source file flags after target-wide flags when they are classified as raw flags with no project file setting ("AdditionalOptions"). This behavior is more consistent with the ordering of flags produced by other generators, and allows flags on more-specific properties (per-source) to override those on more general ones (per-target). * The precompiled Windows binary MSI package provided on "cmake.org" now records the installation directory in the Windows Registry under the key "HKLM\Software\Kitware\CMake" with a value named "InstallDir". ---------------------------------------------------------------------------- Changes made since CMake 3.8.0-rc4: Brad King (7): ExternalProject: Fix regression in GIT_TAG with remote branch name Tests: Fix spurious CTestTestParallel failures Features: Update features for Intel C++ 17.0.2 on UNIX CMakeParseImplicitLinkInfo: Ignore ld -lto_library flag Tests: Avoid generating .pyc files during Server test RC: Mark CMAKE_RC_FLAGS_ cache entries as advanced CMake 3.8.0 Craig Scott (3): Help: Clarify what the -f option does for the remove command Help: Cross compile variable used as initial value for target property Help: Clarify file(GENERATE) only writes output file at generation phase Konstantin Podsvirov (1): QtIFW: Improved packaging as part of the QtSDK Vadim Zeitlin (1): FindwxWidgets: link with the new required libs under MSW From rcdailey.lists at gmail.com Mon Apr 10 18:44:26 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Mon, 10 Apr 2017 17:44:26 -0500 Subject: [CMake] How to get message() to go to stdout when executed from -P? Message-ID: When I execute a CMake script as a custom command, message() logs are not shown in stdout from that script. Is there a way to make it pipe out messages? From DLRdave at aol.com Mon Apr 10 21:47:23 2017 From: DLRdave at aol.com (David Cole) Date: Mon, 10 Apr 2017 21:47:23 -0400 Subject: [CMake] How to get message() to go to stdout when executed from -P? In-Reply-To: References: Message-ID: <2066F8E2-70CB-4994-ADAC-DFFDAB713925@aol.com> From the Windows command line, you would do it with 2>&1 after the command (2 is stderr, and 1 is stdout). You could write your custom command as a batch file or bash script (unfortunately platform dependent) which uses this technique with a single command inside the batch file. HTH, David C. > On Apr 10, 2017, at 6:44 PM, Robert Dailey wrote: > > When I execute a CMake script as a custom command, message() logs are > not shown in stdout from that script. > > Is there a way to make it pipe out messages? > -- > > 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 algiane.froehly at inria.fr Tue Apr 11 05:31:55 2017 From: algiane.froehly at inria.fr (Algiane Froehly) Date: Tue, 11 Apr 2017 11:31:55 +0200 Subject: [CMake] Link Fortran executable with C library using CommandLineTools C compiler on Mac OSX Message-ID: <23FA066C-A0CF-4A87-B0D5-85C874C0D074@inria.fr> Hi, I am trying to link a fotran program with a C library on Mac. Using the gcc compiler it works perfectly but if I use the commandLineTools compiler, I end up with an error at linking. It happens with both gfortran and pgf90 (not ifort). I can build manually my executable if I remove the -lto_library library that is added by the CMAKE_C_IMPLICIT_LINK_LIBRARIES variable. What can I do to make it work automatically (I have found a post saying that it is not possible to overwrite the CMAKE_C_IMPLICIT_LINK_LIBRARIES variable)? Is it normal that gfortran and pgf90 adds the link to the to_library and not ifort? Thank you for your help, Regards, Algiane Froehly. From 50295 at web.de Tue Apr 11 08:45:56 2017 From: 50295 at web.de (Olumide) Date: Tue, 11 Apr 2017 13:45:56 +0100 Subject: [CMake] Directing cmake to link against shared object with debug postfix (_d) Message-ID: <9e6be8b6-a7f6-a79f-e55d-971da295689d@web.de> Dear List, I've got a cmake project that pretty much looks like this: ############################################################### cmake_minimum_required(VERSION 3.0) SET(CMAKE_DEBUG_POSTFIX "_d") include_directories(../TransfunctionerProject) include_directories(../TransmogrifierProject) set(Libraries ContinuumTransfunctioner Transmogrifier ) set(SourceFiles Wrapper.cpp Logger.cpp ) add_library(Frobnigator SHARED ${SourceFiles}) add_library(FrobnigatorStatic STATIC ${SourceFiles}) set_target_properties(FrobnigatorStatic PROPERTIES OUTPUT_NAME Frobnigator) target_link_libraries(Frobnigator ${Libraries}) ############################################################### Where ContinuumTransfunctioner and Transmogrifier projects include the debug postfix directive SET(CMAKE_DEBUG_POSTFIX "_d") so that libContinuumTransfunctioner_d.so and libTransmogrifier_d.so both exist. The problem is that the current project appears to be linking against the static library without the _d suffix and complains: /usr/bin/ld: cannot find -lContinuumTransfunctioner How can I direct cmake to link against shared object with debug postfix (_d) Thanks - Olumide From reuben.kraft at gmail.com Tue Apr 11 11:43:17 2017 From: reuben.kraft at gmail.com (Reuben Kraft) Date: Tue, 11 Apr 2017 11:43:17 -0400 Subject: [CMake] single static library from many subdirectories Message-ID: Hello, I was reading this page about how to make a single library from many subdirectories using object files: https://cmake.org/Wiki/CMake/Tutorials/Object_Library It is exactly what I want to do but my problem is that I do not have any source files in my "top directory" they are all in the subdirectories. I have something like this: top-dir --CMakeLists.txt ------sub-dir-a --------------CMakeLists.txt --------------file1.cpp ------sub-dir-b --------------CMakeLists.txt --------------file2.cpp However, I get the follow error message when I run cmake: You have called ADD_LIBRARY for library eema without any source files. This typically indicates a problem with your CMakeLists.txt file. Is there a way to do this without haveing any source files in the top directory? Thanks, Reuben -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Tue Apr 11 14:46:36 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Tue, 11 Apr 2017 14:46:36 -0400 Subject: [CMake] single static library from many subdirectories In-Reply-To: References: Message-ID: Instead of having a per directory CMakeLists.txt you can do something like the following. add_library(eema STATIC sub-dir-a/file1.cpp sub-dir-b/file2.cpp) On Tue, Apr 11, 2017 at 11:43 AM, Reuben Kraft wrote: > Hello, > > I was reading this page about how to make a single library from many > subdirectories using object files: > https://cmake.org/Wiki/CMake/Tutorials/Object_Library > > It is exactly what I want to do but my problem is that I do not have any > source files in my "top directory" they are all in the subdirectories. I > have something like this: > > top-dir > --CMakeLists.txt > ------sub-dir-a > --------------CMakeLists.txt > --------------file1.cpp > ------sub-dir-b > --------------CMakeLists.txt > --------------file2.cpp > > However, I get the follow error message when I run cmake: > > You have called ADD_LIBRARY for library eema without any source files. This > typically indicates a problem with your CMakeLists.txt file. > > Is there a way to do this without haveing any source files in the top > directory? > > Thanks, > > Reuben > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake From robert.maynard at kitware.com Tue Apr 11 14:50:26 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Tue, 11 Apr 2017 14:50:26 -0400 Subject: [CMake] Directing cmake to link against shared object with debug postfix (_d) In-Reply-To: <9e6be8b6-a7f6-a79f-e55d-971da295689d@web.de> References: <9e6be8b6-a7f6-a79f-e55d-971da295689d@web.de> Message-ID: CMAKE_DEBUG_POSTFIX is only used by CMake when it builds libraries to determine what exact file name the executable/library should have. In your case you will need to do something like: set(Libraries ContinuumTransfunctioner${CMAKE_DEBUG_POSTFIX} Transmogrifier${CMAKE_DEBUG_POSTFIX} ) Another option would to generate proper import targets for your libraries, as that would allow you to specify different paths for the release and debug components. On Tue, Apr 11, 2017 at 8:45 AM, Olumide <50295 at web.de> wrote: > Dear List, > > I've got a cmake project that pretty much looks like this: > > ############################################################### > > cmake_minimum_required(VERSION 3.0) > > SET(CMAKE_DEBUG_POSTFIX "_d") > > include_directories(../TransfunctionerProject) > include_directories(../TransmogrifierProject) > > set(Libraries > ContinuumTransfunctioner > Transmogrifier > ) > > set(SourceFiles > Wrapper.cpp > Logger.cpp > ) > > add_library(Frobnigator SHARED ${SourceFiles}) > add_library(FrobnigatorStatic STATIC ${SourceFiles}) > set_target_properties(FrobnigatorStatic PROPERTIES OUTPUT_NAME Frobnigator) > target_link_libraries(Frobnigator ${Libraries}) > > ############################################################### > > Where ContinuumTransfunctioner and Transmogrifier projects include the debug > postfix directive SET(CMAKE_DEBUG_POSTFIX "_d") so that > libContinuumTransfunctioner_d.so and libTransmogrifier_d.so both exist. > > The problem is that the current project appears to be linking against the > static library without the _d suffix and complains: > > /usr/bin/ld: cannot find -lContinuumTransfunctioner > > How can I direct cmake to link against shared object with debug postfix (_d) > > Thanks > > - Olumide > > > > > -- > > 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 heefan at gmail.com Tue Apr 11 23:38:58 2017 From: heefan at gmail.com (Heefan) Date: Wed, 12 Apr 2017 11:38:58 +0800 Subject: [CMake] How do I generate VS2015 project with win32 win64 and ARM all in one solution ? Message-ID: Hi all, I have a question to inquire as the following, ## Description: I can successfully generate VS2015 solution file with win32, win64 and ARM separately. However, I would like to make the architectures all in one solution. ## Test Environment Local host: Windows 10. IDE: Visual Studio 2015 Source Code: C Target: Windows Phone C:>cmake ../ -G"Visual Studio 14 2015" -DCMAKE_SYSTEM_NAME=WindowsPhone -DCMAKE_SYSTEM_VERSION=10.0 C:>cmake ../ -G"Visual Studio 14 2015 Win64" -DCMAKE_SYSTEM_NAME=WindowsPhone -DCMAKE_SYSTEM_VERSION=10.0 C:>cmake ../ -G"Visual Studio 14 2015 ARM" -DCMAKE_SYSTEM_NAME=WindowsPhone -DCMAKE_SYSTEM_VERSION=10.0 It will generate 3 solution files with win32, win64 and ARM respectively. ## Question Shall I generate one solution with the 3 architecture? ## Reference: https://blogs.msdn.microsoft.com/vcblog/2016/10/05/cmake-support-in-visual-studio/#configure-cmake However, it is for vs2017. Thanks Regards Heefan -------------- next part -------------- An HTML attachment was scrubbed... URL: From 50295 at web.de Wed Apr 12 07:28:46 2017 From: 50295 at web.de (Olumide) Date: Wed, 12 Apr 2017 12:28:46 +0100 Subject: [CMake] Directing cmake to link against shared object with debug postfix (_d) In-Reply-To: References: <9e6be8b6-a7f6-a79f-e55d-971da295689d@web.de> Message-ID: <4c94bc7c-7639-14e1-fc40-86359a428e2f@web.de> Thanks Robert. However it appears that the release build is linking against ContinuumTransfunctioner_d and Transmogrifier_d. How can I omit the _d suffix in the release build. Regards, - Olumide On 11/04/2017 19:50, Robert Maynard wrote: > CMAKE_DEBUG_POSTFIX is only used by CMake when it builds libraries to > determine what exact file name the executable/library should have. > > In your case you will need to do something like: > > set(Libraries > ContinuumTransfunctioner${CMAKE_DEBUG_POSTFIX} > Transmogrifier${CMAKE_DEBUG_POSTFIX} > ) > > Another option would to generate proper import targets for your > libraries, as that would allow you to specify different paths for the > release and debug components. > > On Tue, Apr 11, 2017 at 8:45 AM, Olumide <50295-S0/GAf8tV78 at public.gmane.org> wrote: >> Dear List, >> >> I've got a cmake project that pretty much looks like this: >> >> ############################################################### >> >> cmake_minimum_required(VERSION 3.0) >> >> SET(CMAKE_DEBUG_POSTFIX "_d") >> >> include_directories(../TransfunctionerProject) >> include_directories(../TransmogrifierProject) >> >> set(Libraries >> ContinuumTransfunctioner >> Transmogrifier >> ) >> >> set(SourceFiles >> Wrapper.cpp >> Logger.cpp >> ) >> >> add_library(Frobnigator SHARED ${SourceFiles}) >> add_library(FrobnigatorStatic STATIC ${SourceFiles}) >> set_target_properties(FrobnigatorStatic PROPERTIES OUTPUT_NAME Frobnigator) >> target_link_libraries(Frobnigator ${Libraries}) >> >> ############################################################### >> >> Where ContinuumTransfunctioner and Transmogrifier projects include the debug >> postfix directive SET(CMAKE_DEBUG_POSTFIX "_d") so that >> libContinuumTransfunctioner_d.so and libTransmogrifier_d.so both exist. >> >> The problem is that the current project appears to be linking against the >> static library without the _d suffix and complains: >> >> /usr/bin/ld: cannot find -lContinuumTransfunctioner >> >> How can I direct cmake to link against shared object with debug postfix (_d) >> >> Thanks >> >> - Olumide >> >> >> >> >> -- >> >> 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 volker.enderlein at ifm-chemnitz.de Wed Apr 12 07:56:47 2017 From: volker.enderlein at ifm-chemnitz.de (Volker Enderlein) Date: Wed, 12 Apr 2017 13:56:47 +0200 Subject: [CMake] Directing cmake to link against shared object with debug postfix (_d) In-Reply-To: <4c94bc7c-7639-14e1-fc40-86359a428e2f@web.de> References: <9e6be8b6-a7f6-a79f-e55d-971da295689d@web.de> <4c94bc7c-7639-14e1-fc40-86359a428e2f@web.de> Message-ID: <7de12dc7-cf02-c58b-a040-b5479cb3620d@ifm-chemnitz.de> Am 12/04/2017 um 13:28 schrieb Olumide: > set(Libraries > ContinuumTransfunctioner${CMAKE_DEBUG_POSTFIX} > Transmogrifier${CMAKE_DEBUG_POSTFIX} > ) Hi, you could add the configuration for a single library dependency. target_link_libraries(your_target debug ContinuumTransfunctioner${CMAKE_DEBUG_POSTFIX} optimized ContinuumTransfunctioner debug Transmogrifier${CMAKE_DEBUG_POSTFIX} optimized Transmogrifier ) you could also put that into a variable and reference that later set(Libraries debug ContinuumTransfunctioner${CMAKE_DEBUG_POSTFIX} optimized ContinuumTransfunctioner debug Transmogrifier${CMAKE_DEBUG_POSTFIX} optimized Transmogrifier ) target_link_libraries(your_target ${Libraries}) Hope that helps, Cheers, Volker From 50295 at web.de Wed Apr 12 10:49:05 2017 From: 50295 at web.de (Olumide) Date: Wed, 12 Apr 2017 15:49:05 +0100 Subject: [CMake] Directing cmake to link against shared object with debug postfix (_d) In-Reply-To: <7de12dc7-cf02-c58b-a040-b5479cb3620d@ifm-chemnitz.de> References: <9e6be8b6-a7f6-a79f-e55d-971da295689d@web.de> <4c94bc7c-7639-14e1-fc40-86359a428e2f@web.de> <7de12dc7-cf02-c58b-a040-b5479cb3620d@ifm-chemnitz.de> Message-ID: <147083f9-2bbe-dddb-1bb3-e785aabaa222@web.de> Thanks Volker. I wonder if its possible to do go with the Robert's original suggestion: set(Libraries ContinuumTransfunctioner${CMAKE_DEBUG_POSTFIX} Transmogrifier${CMAKE_DEBUG_POSTFIX} ) But set on debug build set CMAKE_DEBUG_POSTFIX. For example: ## Does not work if (CMAKE_BUILD_TYPE STREQUAL "Debug") SET(CMAKE_DEBUG_POSTFIX "_d") endif if (CMAKE_BUILD_TYPE STREQUAL "Release") SET(CMAKE_DEBUG_POSTFIX "") endif Regards, - Olumide On 12/04/2017 12:56, Volker Enderlein wrote: > Am 12/04/2017 um 13:28 schrieb Olumide: >> set(Libraries >> ContinuumTransfunctioner${CMAKE_DEBUG_POSTFIX} >> Transmogrifier${CMAKE_DEBUG_POSTFIX} >> ) > Hi, > > you could add the configuration for a single library dependency. > > target_link_libraries(your_target > > debug ContinuumTransfunctioner${CMAKE_DEBUG_POSTFIX} > > optimized ContinuumTransfunctioner > > debug Transmogrifier${CMAKE_DEBUG_POSTFIX} > > optimized Transmogrifier > > ) > > you could also put that into a variable and reference that later > > set(Libraries > > debug ContinuumTransfunctioner${CMAKE_DEBUG_POSTFIX} > > optimized ContinuumTransfunctioner > > debug Transmogrifier${CMAKE_DEBUG_POSTFIX} > > optimized Transmogrifier > > ) > > target_link_libraries(your_target ${Libraries}) > > > Hope that helps, Cheers, Volker > > From nilsgladitz at gmail.com Wed Apr 12 10:56:29 2017 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Wed, 12 Apr 2017 16:56:29 +0200 Subject: [CMake] Directing cmake to link against shared object with debug postfix (_d) In-Reply-To: <147083f9-2bbe-dddb-1bb3-e785aabaa222@web.de> References: <9e6be8b6-a7f6-a79f-e55d-971da295689d@web.de> <4c94bc7c-7639-14e1-fc40-86359a428e2f@web.de> <7de12dc7-cf02-c58b-a040-b5479cb3620d@ifm-chemnitz.de> <147083f9-2bbe-dddb-1bb3-e785aabaa222@web.de> Message-ID: <10c9ccac-70be-1a22-3d02-81842c178919@gmail.com> On 04/12/2017 04:49 PM, Olumide wrote: > set(Libraries > ContinuumTransfunctioner${CMAKE_DEBUG_POSTFIX} > Transmogrifier${CMAKE_DEBUG_POSTFIX} > ) Perhaps try with generator expressions: set(Libraries ContinuumTransfunctioner$<$:d> Transmogrifier$<$:d> ) Maybe alternatively create a find module and populate imported targets with the required information: https://cmake.org/cmake/help/latest/manual/cmake-developer.7.html#find-modules Or assuming ContinuumTransfunctioner and Transmogrifier are created by an independent CMake project under your control look into target exports and package configuration files: https://cmake.org/cmake/help/latest/manual/cmake-packages.7.html#creating-packages Nils From 50295 at web.de Wed Apr 12 11:48:25 2017 From: 50295 at web.de (Olumide) Date: Wed, 12 Apr 2017 16:48:25 +0100 Subject: [CMake] Directing cmake to link against shared object with debug postfix (_d) In-Reply-To: <10c9ccac-70be-1a22-3d02-81842c178919@gmail.com> References: <9e6be8b6-a7f6-a79f-e55d-971da295689d@web.de> <4c94bc7c-7639-14e1-fc40-86359a428e2f@web.de> <7de12dc7-cf02-c58b-a040-b5479cb3620d@ifm-chemnitz.de> <147083f9-2bbe-dddb-1bb3-e785aabaa222@web.de> <10c9ccac-70be-1a22-3d02-81842c178919@gmail.com> Message-ID: <0b68e978-3f5f-f5ad-02cf-fb65d65e2a6b@web.de> Thanks Nils. BTW, shouldn't that be ContinuumTransfunctioner$<$:_d> Transmogrifier$<$:_d> Thanks, - Olumide On 12/04/2017 15:56, Nils Gladitz wrote: > On 04/12/2017 04:49 PM, Olumide wrote: > >> set(Libraries >> ContinuumTransfunctioner${CMAKE_DEBUG_POSTFIX} >> Transmogrifier${CMAKE_DEBUG_POSTFIX} >> ) > > Perhaps try with generator expressions: > > set(Libraries > ContinuumTransfunctioner$<$:d> > Transmogrifier$<$:d> > ) > > Maybe alternatively create a find module and populate imported targets > with the required information: > https://cmake.org/cmake/help/latest/manual/cmake-developer.7.html#find-modules > > > Or assuming ContinuumTransfunctioner and Transmogrifier are created by > an independent CMake project under your control look into target exports > and package configuration files: > https://cmake.org/cmake/help/latest/manual/cmake-packages.7.html#creating-packages > > > Nils From nilsgladitz at gmail.com Wed Apr 12 11:49:40 2017 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Wed, 12 Apr 2017 17:49:40 +0200 Subject: [CMake] Directing cmake to link against shared object with debug postfix (_d) In-Reply-To: <0b68e978-3f5f-f5ad-02cf-fb65d65e2a6b@web.de> References: <9e6be8b6-a7f6-a79f-e55d-971da295689d@web.de> <4c94bc7c-7639-14e1-fc40-86359a428e2f@web.de> <7de12dc7-cf02-c58b-a040-b5479cb3620d@ifm-chemnitz.de> <147083f9-2bbe-dddb-1bb3-e785aabaa222@web.de> <10c9ccac-70be-1a22-3d02-81842c178919@gmail.com> <0b68e978-3f5f-f5ad-02cf-fb65d65e2a6b@web.de> Message-ID: <2be2679f-1fe1-7e85-9126-1d38d3b56daf@gmail.com> On 12.04.2017 17:48, Olumide wrote: > Thanks Nils. > > BTW, shouldn't that be > ContinuumTransfunctioner$<$:_d> > Transmogrifier$<$:_d> Ah right given your specific case, yes. Nils From mikelojkovic at gmail.com Wed Apr 12 20:35:53 2017 From: mikelojkovic at gmail.com (mike lojkovic) Date: Wed, 12 Apr 2017 19:35:53 -0500 Subject: [CMake] Saving clang output to file when cmake is used with CLion Message-ID: I have a script I'm using to figure out which headers should be in my precompiled header. It requires the clang -H flag passed to work. I'm able to get the output on the console without issue, but can't figure out how to just pass clang's output to a file for my script to analyze. redirecting the console output to a file with ">" won't work since I'm compiling from CLion. Is there a way to do this from within a CMakeLists.txt? I'm thinking something like tee would work, but can't find a variable to chain to tee. From dan at su-root.co.uk Thu Apr 13 05:45:30 2017 From: dan at su-root.co.uk (Dan Liew) Date: Thu, 13 Apr 2017 10:45:30 +0100 Subject: [CMake] Saving clang output to file when cmake is used with CLion In-Reply-To: References: Message-ID: Hi, On 13 April 2017 at 01:35, mike lojkovic wrote: > I have a script I'm using to figure out which headers should be in my > precompiled header. It requires the clang -H flag passed to work. I'm > able to get the output on the console without issue, but can't figure > out how to just pass clang's output to a file for my script to > analyze. redirecting the console output to a file with ">" won't work > since I'm compiling from CLion. Is there a way to do this from within > a CMakeLists.txt? I'm thinking something like tee would work, but > can't find a variable to chain to tee. I have two ideas for this 1. Write a wrapper script for clang and tell CMake to use that as the compiler. Something like this would do it ``` #!/bin/bash : ${STDOUT_DEST?"STDOUT_DEST is not set"} : ${STDERR_DEST?"STDERR_DEST is not set"} CLANG_BIN="$(which clang)" { ${CLANG_BIN} "$@" 2>&1 1>&3 3>&- | tee -i ${STDERR_DEST}; } 3>&1 1>&2 | tee -i ${STDOUT_DEST} ``` this wrapper script logs the standard output and standard error to separate files (overwriting existing files). The file names are set by environment variables. You'll probably need to modify this script to suit your needs. then configure cmake to use this as the compiler ``` CC=/path/to/clang_wrapper cmake /path/to/source_dir ``` If you have C++ code you'll need to write a similar wrapper for `clang++`. 2. Use the compilation database [1] which will record all the clang invocations and then write a script to read the JSON file and re-run the commands with the `-H` flag added and capture the output and do whatever you need to do with it. [1] https://clang.llvm.org/docs/JSONCompilationDatabase.html HTH, Dan. From brad.king at kitware.com Thu Apr 13 06:52:51 2017 From: brad.king at kitware.com (Brad King) Date: Thu, 13 Apr 2017 06:52:51 -0400 Subject: [CMake] Link Fortran executable with C library using CommandLineTools C compiler on Mac OSX In-Reply-To: <23FA066C-A0CF-4A87-B0D5-85C874C0D074@inria.fr> References: <23FA066C-A0CF-4A87-B0D5-85C874C0D074@inria.fr> Message-ID: <3246b2e9-c1f4-979b-6495-1d5df7f5a53a@kitware.com> On 04/11/2017 05:31 AM, Algiane Froehly wrote: > if I remove the -lto_library library that is added by the > CMAKE_C_IMPLICIT_LINK_LIBRARIES variable. See here: * https://gitlab.kitware.com/cmake/cmake/merge_requests/658 * https://gitlab.kitware.com/cmake/cmake/issues/16766 It is fixed in CMake 3.8.0. -Brad From pawel.veselov at gmail.com Fri Apr 14 00:05:05 2017 From: pawel.veselov at gmail.com (Pawel Veselov) Date: Thu, 13 Apr 2017 21:05:05 -0700 Subject: [CMake] CMake uses semi-colon as path separator on Linux Message-ID: Hello. I really can't understand what's going on. Trying to compile my project for android, setting all kinds of things to get it done. I've tried 3.8.0, 3.7.2 and 3.6.2, with the same result. The below extracts are from running 3.6.2 Running with --debug and --trace, I see: /usr/share/cmake/Modules/FindPkgConfig.cmake(91): _pkgconfig_set(JSONC_CFLAGS ${_pkgconfig_invoke_result} ) /usr/share/cmake/Modules/FindPkgConfig.cmake(64): set(JSONC_CFLAGS -I/tmp/arm-23/include/json-c;-I/tmp/arm-23/include CACHE INTERNAL ) I ran strace, and I can see pkg-config returning paths normally, just spaces. Running make on the generated makefiles: /tmp/arm-23/bin/arm-linux-androideabi-gcc -g -ggdb -O0 --std=c99 -isystem/home/vps/ws/EF/DMClient/android_src/http-parser -isystem/usr/include -isystem/home/vps/ws/EF/DMClient/android_src/wslay/lib/includes -I/tmp/arm-23/include/json-c;-I/tmp/arm-23/include -isystem /tmp/arm-23/include -isystem /tmp/arm-23/include/libxml2 -o CMakeFiles/dmclient.dir/config.c.o -c /home/vps/ws/EF/DMClient/config.c The semicolons are in the ./CMakeFiles/node_editor.dir/flags.make The CMakeLists.txt has this line: pkg_check_modules(JSONC REQUIRED json-c openssl) At this point, I'm running CMake without any fancy command, the compiler location and such are derived from environment variables. I tried using the NDK flags (with 3.8, and using toolchain), but then realized this reproduces even without them (and on 3.6) Any idea what drags in those semicolons? Thank you. From nilsgladitz at gmail.com Fri Apr 14 02:24:13 2017 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 14 Apr 2017 08:24:13 +0200 Subject: [CMake] CMake uses semi-colon as path separator on Linux In-Reply-To: References: Message-ID: <6151fd83-c7d0-d9ba-2e22-ce4e730d760c@gmail.com> On 14.04.2017 06:05, Pawel Veselov wrote: > Hello. > > I really can't understand what's going on. Trying to compile my project > for android, setting all kinds of things to get it done. I've tried 3.8.0, > 3.7.2 and 3.6.2, with the same result. The below extracts are from running > 3.6.2 > > Running with --debug and --trace, I see: > > /usr/share/cmake/Modules/FindPkgConfig.cmake(91): > _pkgconfig_set(JSONC_CFLAGS ${_pkgconfig_invoke_result} ) > /usr/share/cmake/Modules/FindPkgConfig.cmake(64): set(JSONC_CFLAGS > -I/tmp/arm-23/include/json-c;-I/tmp/arm-23/include CACHE INTERNAL ) > > I ran strace, and I can see pkg-config returning paths normally, just spaces. > > Running make on the generated makefiles: > > /tmp/arm-23/bin/arm-linux-androideabi-gcc -g -ggdb -O0 --std=c99 > -isystem/home/vps/ws/EF/DMClient/android_src/http-parser > -isystem/usr/include > -isystem/home/vps/ws/EF/DMClient/android_src/wslay/lib/includes > -I/tmp/arm-23/include/json-c;-I/tmp/arm-23/include -isystem > /tmp/arm-23/include -isystem /tmp/arm-23/include/libxml2 -o > CMakeFiles/dmclient.dir/config.c.o -c > /home/vps/ws/EF/DMClient/config.c > > The semicolons are in the ./CMakeFiles/node_editor.dir/flags.make > > The CMakeLists.txt has this line: > pkg_check_modules(JSONC REQUIRED json-c openssl) > > At this point, I'm running CMake without any fancy command, the compiler > location and such are derived from environment variables. > > I tried using the NDK flags (with 3.8, and using toolchain), but then > realized this reproduces even without them (and on 3.6) > > Any idea what drags in those semicolons? CMake uses semicolons to separate list elements: https://cmake.org/cmake/help/latest/manual/cmake-language.7.html#lists Some CMake commands / variables / properties expect ";"-separated lists (e.g. target_compile_options(), COMPILE_OPTIONS) and some expect strings with whitespace separated arguments (e.g. CMAKE_C_FLAGS, COMPILE_FLAGS). Presumably you are feeding the list to something that expects the latter. Nils From algiane.froehly at inria.fr Fri Apr 14 05:27:05 2017 From: algiane.froehly at inria.fr (Algiane Froehly) Date: Fri, 14 Apr 2017 11:27:05 +0200 Subject: [CMake] Link Fortran executable with C library using CommandLineTools C compiler on Mac OSX In-Reply-To: <3246b2e9-c1f4-979b-6495-1d5df7f5a53a@kitware.com> References: <23FA066C-A0CF-4A87-B0D5-85C874C0D074@inria.fr> <3246b2e9-c1f4-979b-6495-1d5df7f5a53a@kitware.com> Message-ID: <2C882791-3A0B-41D8-B98A-43A69BCF6601@inria.fr> Hi, I haven?t seen this posts, it works perfectly now. Thank you for your help. Regards, Algiane > Le 13 avr. 2017 ? 12:52, Brad King a ?crit : > > On 04/11/2017 05:31 AM, Algiane Froehly wrote: >> if I remove the -lto_library library that is added by the >> CMAKE_C_IMPLICIT_LINK_LIBRARIES variable. > > See here: > > * https://gitlab.kitware.com/cmake/cmake/merge_requests/658 > * https://gitlab.kitware.com/cmake/cmake/issues/16766 > > It is fixed in CMake 3.8.0. > > -Brad > From thomas at junovagen.se Fri Apr 14 11:58:04 2017 From: thomas at junovagen.se (Thomas Nilefalk) Date: Fri, 14 Apr 2017 17:58:04 +0200 Subject: [CMake] CMAKE_SIZEOF_VOID_P question Message-ID: <1492185484.26594.0@send.one.com> I'm developing a library on and for a multitude of platforms and would like to provide both 32 and 64-bit versions for all platforms this is relevant for. I'm currently on Ubuntu 64bit with CMake 3.5.2 and use the "-m32" compiler switch to do the 32-bit compile. I'm trying to understand why GNUInstallDirs are not setting CMAKE_INSTALL_LIBDIR to what I think it should. While doing that I discovered that CMAKE_SIZEOF_VOID_P is not set as I thought it would either. According to the documentation CMAKE_SIZEOF_VOID_P it is determined by running the compiler. However it seems that it is not using pertinent flags from the configuration, in particular CMAKE_C_FLAGS and CMAKE_CXX_FLAGS. Having a CMakeLists.txt containing: > cmake_minimum_required(VERSION 2.8.5) > project(X C) > try_run(run_result_var compile_result_var /tmp /tmp/size.c) > message(STATUS "Sizeof=" ${run_result_var}) > message(STATUS "CMAKE_SIZEOF_VOID_P=" ${CMAKE_SIZEOF_VOID_P}) and size.c with: > int main(int argc, char **argv) { > return sizeof(void *); > } With no flags I get: > -- Sizeof=8 > -- CMAKE_SIZEOF_VOID_P=8 And with CMAKE_C_FLAGS set to "-m32" I get: > -- Sizeof=4 > -- CMAKE_SIZEOF_VOID_P=8 If this is by design, then I think the documentation is unclear, if not plain wrong: > This is set to the size of a pointer on the target machine, and is > determined by a try compile. > If a 64-bit size is found, then the library search path is modified > to look for 64-bit libraries first. Or am I missing something? /Thomas From chuck.atkins at kitware.com Fri Apr 14 15:27:06 2017 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Fri, 14 Apr 2017 15:27:06 -0400 Subject: [CMake] CMAKE_SIZEOF_VOID_P question In-Reply-To: <1492185484.26594.0@send.one.com> References: <1492185484.26594.0@send.one.com> Message-ID: Hi Thomas, According to the documentation CMAKE_SIZEOF_VOID_P it is determined by > running the compiler. However it seems that it is not using pertinent flags > from the configuration, in particular CMAKE_C_FLAGS and CMAKE_CXX_FLAGS. > It is but the results from type size checking get saved in cache variables so when run a second time, even though specifying extra CMAKE_CXX_FLAGS, the CMAKE_SIZEOF_VOID_P variable already exists in cache so it's not checked again. If you clear your build directory before each invocation of CMake then you should see it switch between 4 and 8 as expected. ---------- Chuck Atkins Staff R&D Engineer, Scientific Computing Kitware, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas at junovagen.se Fri Apr 14 16:33:13 2017 From: thomas at junovagen.se (Thomas Nilefalk) Date: Fri, 14 Apr 2017 22:33:13 +0200 Subject: [CMake] CMAKE_SIZEOF_VOID_P question In-Reply-To: References: <1492185484.26594.0@send.one.com> Message-ID: <351b636b-617e-e125-d482-820ae7c3ee40@junovagen.se> Den 2017-04-14 kl. 21:27, skrev Chuck Atkins: > Hi Thomas, > > According to the documentation CMAKE_SIZEOF_VOID_P it is > determined by running the compiler. However it seems that it is > not using pertinent flags from the configuration, in particular > CMAKE_C_FLAGS and CMAKE_CXX_FLAGS. > > > It is but the results from type size checking get saved in cache > variables so when run a second time, even though specifying extra > CMAKE_CXX_FLAGS, the CMAKE_SIZEOF_VOID_P variable already exists in > cache so it's not checked again. If you clear your build directory > before each invocation of CMake then you should see it switch between > 4 and 8 as expected. > Right, it does. Thanks. The inconsistencies of when something changes and when it doesn't, bit me again... Next question is then why doesn't GNUInstallDirs set CMAKE_INSTALL_LIBDIR as I expect on Ubuntu for the example I gave? I am expecting to see either lib64/lib (for 64/32 bit) or a triplet for (32-bit). Now it's always 'lib'. /Thomas > ---------- > Chuck Atkins > Staff R&D Engineer, Scientific Computing > Kitware, Inc. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ghisvail at gmail.com Sat Apr 15 12:21:46 2017 From: ghisvail at gmail.com (Ghislain Vaillant) Date: Sat, 15 Apr 2017 17:21:46 +0100 Subject: [CMake] CMAKE_SIZEOF_VOID_P question Message-ID: <1492273306.4727.60.camel@gmail.com> > Next question is then why doesn't GNUInstallDirs set > CMAKE_INSTALL_LIBDIR as I expect on Ubuntu for the example I gave? > > I am expecting to see either lib64/lib (for 64/32 bit) or a triplet for > (32-bit). Now it's always 'lib'. Debian / Ubuntu injects this additional triplet for multiarch support [1]. As far as you are concerned, you can safely ignore this detail. [1] https://wiki.debian.org/Multiarch Ghis From ol.rakhimov at gmail.com Sat Apr 15 21:41:42 2017 From: ol.rakhimov at gmail.com (Olzhas Rakhimov) Date: Sat, 15 Apr 2017 18:41:42 -0700 Subject: [CMake] Configuration retrieval for external tools Message-ID: Hello, I need an advice how to get 'project configurations' from CMake for another tool to use (cppdep in particular). The issue is described there: https://github.com/rakhimov/cppdep/issues/17 The information needed for analysis: 1. The directory of 'internal project (s)' source files (header/implementation) 2. Each 'internal' and 'external' project names 3. include search directories (to find headers and dependencies among projects) The best I could think of so far is to parse the CMakeCache.txt. Is there a better way? I'd appreciate feedback and references. Thanks, Olzhas -------------- next part -------------- An HTML attachment was scrubbed... URL: From tiagomacarios at gmail.com Sat Apr 15 22:45:38 2017 From: tiagomacarios at gmail.com (Tiago Macarios) Date: Sat, 15 Apr 2017 19:45:38 -0700 Subject: [CMake] Setting properties to interface Message-ID: Hi, Given a template-only library exposed throw an interface is it possible to set the necessary CXX_STANDARD necessary to use the library? The code below would be what I am trying to do. add_library(a_lib INTERFACE) set_property(TARGET a_lib PROPERTY CXX_STANDARD 11 PROPERTY CXX_STANDARD_REQUIRED ON ) target_compile_definitions(a_lib INTERFACE SOME_DEF ) Unfortunately, this does not work and fails with: INTERFACE_LIBRARY targets may only have whitelisted properties. The property "CXX_STANDARD_REQUIRED" is not allowed. Any ideas? Tiago -------------- next part -------------- An HTML attachment was scrubbed... URL: From tiagomacarios at gmail.com Sat Apr 15 22:48:16 2017 From: tiagomacarios at gmail.com (Tiago Macarios) Date: Sat, 15 Apr 2017 19:48:16 -0700 Subject: [CMake] CXX_STANDARD use latest Message-ID: Hi, One can require a specific CXX_STANDARD to be used, but is it possible to set a minimum and let CMake use the latest as long as it satisfies the minimum? Example code: set_property(TARGET a_lib PROPERTY CXX_STANDARD_MIN 11 PROPERTY CXX_STANDARD_REQUIRED ON PROPERTY CXX_STANDARD_LATEST ON ) Tiago -------------- next part -------------- An HTML attachment was scrubbed... URL: From Robert.Bielik at dirac.com Sun Apr 16 02:19:49 2017 From: Robert.Bielik at dirac.com (Robert Bielik) Date: Sun, 16 Apr 2017 06:19:49 +0000 Subject: [CMake] New Visual Studio project types Message-ID: <14558606b78c4ed9aacf44e5ae5f51fa@hosted3-mb02.itm.host> Hi all, With the "new" Cross-platform project types in VS2015+ (https://blogs.msdn.microsoft.com/vcblog/2016/03/30/visual-c-for-linux-development/), it's almost ridiculously easy and fun to develop X-platform on f.i. the raspberry pi. I have a CMake based console app which I'd like to use with the X-platform tools above, is this in the works for the CMake VS generator ? Any other ideas on how to cram in an existing CMake project with the VC linux dev stuff ? Regards /Robert From Robert.Bielik at dirac.com Sun Apr 16 02:31:59 2017 From: Robert.Bielik at dirac.com (Robert Bielik) Date: Sun, 16 Apr 2017 06:31:59 +0000 Subject: [CMake] New Visual Studio project types In-Reply-To: <14558606b78c4ed9aacf44e5ae5f51fa@hosted3-mb02.itm.host> References: <14558606b78c4ed9aacf44e5ae5f51fa@hosted3-mb02.itm.host> Message-ID: <0508750cc1874d39a43b0c41da74a84b@hosted3-mb02.itm.host> Ideally, I would like to: 1. Develop in Visual Studio 2. Cross-compile on the Windows Linux subsystem 3. Run/debug the code on a Raspberry Pi Maybe too much to ask for ? Regards /R > -----Original Message----- > From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Robert > Bielik > Sent: den 16 april 2017 08:20 > To: Cmake at cmake.org > Subject: [CMake] New Visual Studio project types > > Hi all, > > With the "new" Cross-platform project types in VS2015+ > (https://blogs.msdn.microsoft.com/vcblog/2016/03/30/visual-c-for-linux- > development/), it's almost ridiculously easy and fun to develop X-platform > on f.i. the raspberry pi. > > I have a CMake based console app which I'd like to use with the X-platform > tools above, is this in the works for the CMake VS generator ? Any other > ideas on how to cram in an existing CMake project with the VC linux dev stuff > ? > > Regards > /Robert > -- > > 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 craig.scott at crascit.com Sun Apr 16 04:40:15 2017 From: craig.scott at crascit.com (Craig Scott) Date: Sun, 16 Apr 2017 18:40:15 +1000 Subject: [CMake] CXX_STANDARD use latest In-Reply-To: References: Message-ID: Not sure if it lines up exactly with what you want, but the latest CMake release (3.8.0) allows you to specify the minimum language standard via compiler features: https://cmake.org/cmake/help/latest/manual/cmake-compile-features.7.html#requiring-language-standards On Sun, Apr 16, 2017 at 12:48 PM, Tiago Macarios wrote: > Hi, > > One can require a specific CXX_STANDARD to be used, but is it possible to > set a minimum and let CMake use the latest as long as it satisfies the > minimum? > > Example code: > > set_property(TARGET a_lib > PROPERTY CXX_STANDARD_MIN 11 > PROPERTY CXX_STANDARD_REQUIRED ON > PROPERTY CXX_STANDARD_LATEST ON > ) > > Tiago > > -- > > 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 > -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig.scott at crascit.com Sun Apr 16 04:51:01 2017 From: craig.scott at crascit.com (Craig Scott) Date: Sun, 16 Apr 2017 18:51:01 +1000 Subject: [CMake] Setting properties to interface In-Reply-To: References: Message-ID: As per my other email just now, you should be able to achieve what you want with the new CMake 3.8.0 release: add_library(a_lib INTERFACE) target_compile_features(a_lib INTERFACE cxx_std_11) I did a quick test with the above just now and it seems to work as expected. You may, however, still want to set the CXX_EXTENSIONS target property (or set it project wide with CMAKE_CXX_EXTENSIONS) to control whether or not compiler extensions are enabled too. On Sun, Apr 16, 2017 at 12:45 PM, Tiago Macarios wrote: > Hi, > > Given a template-only library exposed throw an interface is it possible to > set the necessary CXX_STANDARD necessary to use the library? The code below > would be what I am trying to do. > > add_library(a_lib INTERFACE) > > set_property(TARGET a_lib > PROPERTY CXX_STANDARD 11 > PROPERTY CXX_STANDARD_REQUIRED ON > ) > > target_compile_definitions(a_lib INTERFACE > SOME_DEF > ) > > > Unfortunately, this does not work and fails with: > > INTERFACE_LIBRARY targets may only have whitelisted properties. > The property "CXX_STANDARD_REQUIRED" is not allowed. > > Any ideas? > > Tiago > > -- > > 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 > -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From post at hendrik-sattler.de Sun Apr 16 06:03:42 2017 From: post at hendrik-sattler.de (Hendrik Sattler) Date: Sun, 16 Apr 2017 12:03:42 +0200 Subject: [CMake] New Visual Studio project types In-Reply-To: <14558606b78c4ed9aacf44e5ae5f51fa@hosted3-mb02.itm.host> References: <14558606b78c4ed9aacf44e5ae5f51fa@hosted3-mb02.itm.host> Message-ID: This is not cross-platform: "Today Visual Studio only supports building remotely on the Linux target machine." Am 16. April 2017 08:19:49 MESZ schrieb Robert Bielik : >Hi all, > >With the "new" Cross-platform project types in VS2015+ >(https://blogs.msdn.microsoft.com/vcblog/2016/03/30/visual-c-for-linux-development/), >it's almost ridiculously easy and fun to develop X-platform on f.i. the >raspberry pi. > >I have a CMake based console app which I'd like to use with the >X-platform tools above, is this in the works for the CMake VS generator >? Any other ideas on how to cram in an existing CMake project with the >VC linux dev stuff ? > >Regards >/Robert -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. From Robert.Bielik at dirac.com Sun Apr 16 06:30:49 2017 From: Robert.Bielik at dirac.com (Robert Bielik) Date: Sun, 16 Apr 2017 10:30:49 +0000 Subject: [CMake] New Visual Studio project types In-Reply-To: References: <14558606b78c4ed9aacf44e5ae5f51fa@hosted3-mb02.itm.host> Message-ID: <8cdf944459554759ab08e9085e2bdce3@hosted3-mb02.itm.host> Still, it is supported by visual studio, to build remotely, on Linux. I would like to take advantage of that with my current cmake projects, which I cannot do today. > -----Original Message----- > From: Hendrik Sattler [mailto:post at hendrik-sattler.de] > Sent: den 16 april 2017 12:04 > To: cmake at cmake.org; Robert Bielik ; > Cmake at cmake.org > Subject: Re: [CMake] New Visual Studio project types > > This is not cross-platform: > "Today Visual Studio only supports building remotely on the Linux target > machine." > > > Am 16. April 2017 08:19:49 MESZ schrieb Robert Bielik > : > >Hi all, > > > >With the "new" Cross-platform project types in VS2015+ > >(https://blogs.msdn.microsoft.com/vcblog/2016/03/30/visual-c-for-linux- > >development/), it's almost ridiculously easy and fun to develop > >X-platform on f.i. the raspberry pi. > > > >I have a CMake based console app which I'd like to use with the > >X-platform tools above, is this in the works for the CMake VS generator > >? Any other ideas on how to cram in an existing CMake project with the > >VC linux dev stuff ? > > > >Regards > >/Robert > > -- > Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail > gesendet. From thomas at junovagen.se Sun Apr 16 08:47:20 2017 From: thomas at junovagen.se (Thomas Nilefalk) Date: Sun, 16 Apr 2017 14:47:20 +0200 Subject: [CMake] CMAKE_SIZEOF_VOID_P question In-Reply-To: <1492273306.4727.60.camel@gmail.com> References: <1492273306.4727.60.camel@gmail.com> Message-ID: <58F367D8.9010407@junovagen.se> Ghislain Vaillant skrev: >> Next question is then why doesn't GNUInstallDirs set >> CMAKE_INSTALL_LIBDIR as I expect on Ubuntu for the example I gave? >> >> I am expecting to see either lib64/lib (for 64/32 bit) or a triplet for >> (32-bit). Now it's always 'lib'. > > Debian / Ubuntu injects this additional triplet for multiarch support > [1]. As far as you are concerned, you can safely ignore this detail. > > [1] https://wiki.debian.org/Multiarch > > Ghis I'm not sure I understand what you mean by "ignore" or exactly what I should ignore. All I want is that CMake installs libraries in a place that the linker will find them depending on the target architecture. With "target architecture" I mean either a 32-bit compile and link or a 64-bit compile and link. For all 64bit unixen that I know, you can also compile for 32bit architectures (with GCC-compatible compilers) and run them on the same OS. Do you mean I should ignore the whole "where goes my library" issue, or just fact that the triplet may or may not be used? To enable a 32bit compiled application to find the 32bit version of my library it should install in a place where the linker looks for those: > gcc -m32 -Xlinker --verbose 2>/dev/null | grep SEARCH | sed > 's/SEARCH_DIR("=\?\([^"]\+\)"); */\1\n/g' | grep -vE '^$' > /usr/i386-linux-gnu/lib32 > /usr/x86_64-linux-gnu/lib32 > /usr/local/lib/i386-linux-gnu > /usr/local/lib32 > /lib/i386-linux-gnu > /lib32 > /usr/lib/i386-linux-gnu > /usr/lib32 > /usr/local/lib > /lib > /usr/lib and dito for a 64bit version: > gcc -m64 -Xlinker --verbose 2>/dev/null | grep SEARCH | sed > 's/SEARCH_DIR("=\?\([^"]\+\)"); */\1\n/g' | grep -vE '^$' > /usr/x86_64-linux-gnu/lib64 > /usr/local/lib/x86_64-linux-gnu > /usr/local/lib64 > /lib/x86_64-linux-gnu > /lib64 > /usr/lib/x86_64-linux-gnu > /usr/lib64 > /usr/local/lib > /lib > /usr/lib As we can see the triplets are there, for sure. And since I want the two versions to exist side-by-side on the same system, I was hoping that GNUInstallDirs did something intelligent with its knowledge of the CMAKE_SIZEOF_VOID_P. And it turns out it does on some systems. E.g on WSL with Ubuntu 14.04 and a native (64-bit) compile CMAKE_INSTALL_LIBDIR is set to "lib/x86_64-linux-gnu" and with "-m32" (32bit) it is set to "lib". But on Ubuntu 16.10 it seems to generate "lib" for both cases. Is this a bug with GNUInstallDirs? /Thomas From tiagomacarios at gmail.com Sun Apr 16 15:04:33 2017 From: tiagomacarios at gmail.com (Tiago Macarios) Date: Sun, 16 Apr 2017 12:04:33 -0700 Subject: [CMake] Setting properties to interface In-Reply-To: References: Message-ID: Thanks Craig! That works. Just to confirm, there is no way to disable extensions for a single interface? On Sun, Apr 16, 2017 at 1:51 AM, Craig Scott wrote: > As per my other email just now, you should be able to achieve what you > want with the new CMake 3.8.0 release: > > add_library(a_lib INTERFACE) > target_compile_features(a_lib INTERFACE cxx_std_11) > > I did a quick test with the above just now and it seems to work as > expected. You may, however, still want to set the CXX_EXTENSIONS target > property (or set it project wide with CMAKE_CXX_EXTENSIONS) to control > whether or not compiler extensions are enabled too. > > > > On Sun, Apr 16, 2017 at 12:45 PM, Tiago Macarios > wrote: > >> Hi, >> >> Given a template-only library exposed throw an interface is it possible >> to set the necessary CXX_STANDARD necessary to use the library? The code >> below would be what I am trying to do. >> >> add_library(a_lib INTERFACE) >> >> set_property(TARGET a_lib >> PROPERTY CXX_STANDARD 11 >> PROPERTY CXX_STANDARD_REQUIRED ON >> ) >> >> target_compile_definitions(a_lib INTERFACE >> SOME_DEF >> ) >> >> >> Unfortunately, this does not work and fails with: >> >> INTERFACE_LIBRARY targets may only have whitelisted properties. >> The property "CXX_STANDARD_REQUIRED" is not allowed. >> >> Any ideas? >> >> Tiago >> >> -- >> >> 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 >> > > > > -- > Craig Scott > Melbourne, Australia > https://crascit.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig.scott at crascit.com Sun Apr 16 17:29:29 2017 From: craig.scott at crascit.com (Craig Scott) Date: Mon, 17 Apr 2017 07:29:29 +1000 Subject: [CMake] Setting properties to interface In-Reply-To: References: Message-ID: On Mon, Apr 17, 2017 at 5:04 AM, Tiago Macarios wrote: > Thanks Craig! That works. Just to confirm, there is no way to disable > extensions for a single interface? > Not that I'm aware of. > > On Sun, Apr 16, 2017 at 1:51 AM, Craig Scott > wrote: > >> As per my other email just now, you should be able to achieve what you >> want with the new CMake 3.8.0 release: >> >> add_library(a_lib INTERFACE) >> target_compile_features(a_lib INTERFACE cxx_std_11) >> >> I did a quick test with the above just now and it seems to work as >> expected. You may, however, still want to set the CXX_EXTENSIONS target >> property (or set it project wide with CMAKE_CXX_EXTENSIONS) to control >> whether or not compiler extensions are enabled too. >> >> >> >> On Sun, Apr 16, 2017 at 12:45 PM, Tiago Macarios > > wrote: >> >>> Hi, >>> >>> Given a template-only library exposed throw an interface is it possible >>> to set the necessary CXX_STANDARD necessary to use the library? The code >>> below would be what I am trying to do. >>> >>> add_library(a_lib INTERFACE) >>> >>> set_property(TARGET a_lib >>> PROPERTY CXX_STANDARD 11 >>> PROPERTY CXX_STANDARD_REQUIRED ON >>> ) >>> >>> target_compile_definitions(a_lib INTERFACE >>> SOME_DEF >>> ) >>> >>> >>> Unfortunately, this does not work and fails with: >>> >>> INTERFACE_LIBRARY targets may only have whitelisted properties. >>> The property "CXX_STANDARD_REQUIRED" is not allowed. >>> >>> Any ideas? >>> >>> Tiago >>> >>> -- >>> >>> 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 >>> >> >> >> >> -- >> Craig Scott >> Melbourne, Australia >> https://crascit.com >> > > -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From oliverzabel at gmx.de Mon Apr 17 09:06:49 2017 From: oliverzabel at gmx.de (Zabel, Oliver) Date: Mon, 17 Apr 2017 15:06:49 +0200 Subject: [CMake] Predownload Message-ID: <0M9OMc-1csuIc1ocw-00Cgnc@mail.gmx.com> Hi, i?m developing Software for embedded Systems and my applications Need to run on different target platforms. Until now we are build our Code with make but i?d like to Switch to cmake. ATM we?re putting our Compiler toolchains in our VCS to be able to produce the same binarys even after years. Until now, there is only one toolchain include in a Project as svn-external/git submodule. But i want to use toolchain-files with cmake. Now here is my idea and i?d like to know whether this is possible with cmake. I have my Project root and in this Folder i?d like to have different toolchain files for different Compilers. I?d like to exclude the Compilers as external. Now i?d like to build the cmake Cache by calling cmake with the required toolchain file. Is it now somehow possible, to download the required toolchain before the Cache is buidl up? If this would be possible, i could dynamicly choose which toolchain i want to have ? would be great for Compiler / unit Tests as well. Perhaps someone has a better idea to do this or even i using such a System and give me a hint? Thanks a lot! Best regards, Oliver -------------- next part -------------- An HTML attachment was scrubbed... URL: From jim at dishaw.org Mon Apr 17 09:41:29 2017 From: jim at dishaw.org (James Dishaw) Date: Mon, 17 Apr 2017 09:41:29 -0400 Subject: [CMake] System is unknown to cmake message Message-ID: <0fa201d2b780$53250e40$f96f2ac0$@dishaw.org> I am one of the developers for PLPlot and I have been trying different build configurations to check where it does and does not work. When I tried building on Windows 10 using MSYS2, I get the "System is unknown to cmake" message. The cmake identifies the system as "MINGW64_NT-10.0" I managed to get cmake to generate a working Makefile with the following command line cmake -G "Unix Makefiles" -DCMAKE_INSTALL_PREFIX=/opt/plplot -DPLD_wingdi=ON -DPLD_wingcc=ON -DWIN32=1 -DMINGW=1 -DMINGWLIBPATH=/d/msys64/usr/lib/w32api ../plplot/ &> cmake.log I have attached the cache file per the instructions in the message. Please let me know if you need me to try anything. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: CMakeCache.txt URL: From MillerHenry at JohnDeere.com Mon Apr 17 11:47:36 2017 From: MillerHenry at JohnDeere.com (Miller Henry) Date: Mon, 17 Apr 2017 15:47:36 +0000 Subject: [CMake] Predownload In-Reply-To: <0M9OMc-1csuIc1ocw-00Cgnc@mail.gmx.com> References: <0M9OMc-1csuIc1ocw-00Cgnc@mail.gmx.com> Message-ID: <35F6921410093E4CA40D524BD5C18D4C30F60713@EDXMB89.jdnet.deere.com> Instead of trying to do this with the toolchain somehow in cmake I think you might want to look into a meta build system that handles the toolchain and all other dependencies. I listed all I know of a couple months ago in this thread. https://cmake.org/pipermail/cmake/2017-March/065229.html From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Zabel, Oliver Sent: Monday, April 17, 2017 8:07 AM To: cmake at cmake.org Subject: [CMake] Predownload Hi, i?m developing Software for embedded Systems and my applications Need to run on different target platforms. Until now we are build our Code with make but i?d like to Switch to cmake. ATM we?re putting our Compiler toolchains in our VCS to be able to produce the same binarys even after years. Until now, there is only one toolchain include in a Project as svn-external/git submodule. But i want to use toolchain-files with cmake. Now here is my idea and i?d like to know whether this is possible with cmake. I have my Project root and in this Folder i?d like to have different toolchain files for different Compilers. I?d like to exclude the Compilers as external. Now i?d like to build the cmake Cache by calling cmake with the required toolchain file. Is it now somehow possible, to download the required toolchain before the Cache is buidl up? If this would be possible, i could dynamicly choose which toolchain i want to have ? would be great for Compiler / unit Tests as well. Perhaps someone has a better idea to do this or even i using such a System and give me a hint? Thanks a lot! Best regards, Oliver -------------- next part -------------- An HTML attachment was scrubbed... URL: From florent.castelli at gmail.com Mon Apr 17 18:03:36 2017 From: florent.castelli at gmail.com (Florent Castelli) Date: Tue, 18 Apr 2017 00:03:36 +0200 Subject: [CMake] Predownload In-Reply-To: References: <0M9OMc-1csuIc1ocw-00Cgnc@mail.gmx.com> Message-ID: It is possible. Nothing prevents you from calling execute_process to download as extract your toolchain file when it is run. You probably want to check the destination folder for a pre existing download though. Then, you proceed on configuring Cmake to use it as usual. /Florent On Apr 17, 2017 14:11, "Zabel, Oliver" wrote: Hi, i?m developing Software for embedded Systems and my applications Need to run on different target platforms. Until now we are build our Code with make but i?d like to Switch to cmake. ATM we?re putting our Compiler toolchains in our VCS to be able to produce the same binarys even after years. Until now, there is only one toolchain include in a Project as svn-external/git submodule. But i want to use toolchain-files with cmake. Now here is my idea and i?d like to know whether this is possible with cmake. I have my Project root and in this Folder i?d like to have different toolchain files for different Compilers. I?d like to exclude the Compilers as external. Now i?d like to build the cmake Cache by calling cmake with the required toolchain file. Is it now somehow possible, to download the required toolchain before the Cache is buidl up? If this would be possible, i could dynamicly choose which toolchain i want to have ? would be great for Compiler / unit Tests as well. Perhaps someone has a better idea to do this or even i using such a System and give me a hint? Thanks a lot! Best regards, Oliver -- 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 craig.scott at crascit.com Mon Apr 17 18:16:26 2017 From: craig.scott at crascit.com (Craig Scott) Date: Tue, 18 Apr 2017 08:16:26 +1000 Subject: [CMake] Predownload In-Reply-To: References: <0M9OMc-1csuIc1ocw-00Cgnc@mail.gmx.com> Message-ID: One option may be a superbuild arrangement (based on ExternalProject, online searches should give you details). The only thing the top level would do is setup the sub builds, including downloading and selecting which toolchain(s) to use for each sub build. On Tue, Apr 18, 2017 at 8:03 AM, Florent Castelli < florent.castelli at gmail.com> wrote: > It is possible. > > Nothing prevents you from calling execute_process to download as extract > your toolchain file when it is run. You probably want to check the > destination folder for a pre existing download though. > If you use file(DOWNLOAD...) for downloading the toolchain files and you specify an EXPECTED_HASH, this will also conveniently take care of only downloading the file if it isn't already present. Shouldn't need to resort to execute_process() to do the download. Then, you proceed on configuring Cmake to use it as usual. > > /Florent > > On Apr 17, 2017 14:11, "Zabel, Oliver" wrote: > > Hi, > > > > i?m developing Software for embedded Systems and my applications Need to > run on different target platforms. Until now we are build our Code with > make but i?d like to Switch to cmake. ATM we?re putting our Compiler > toolchains in our VCS to be able to produce the same binarys even after > years. Until now, there is only one toolchain include in a Project as > svn-external/git submodule. But i want to use toolchain-files with cmake. > > > > Now here is my idea and i?d like to know whether this is possible with > cmake. > > I have my Project root and in this Folder i?d like to have different > toolchain files for different Compilers. I?d like to exclude the Compilers > as external. > > Now i?d like to build the cmake Cache by calling cmake with the required > toolchain file. Is it now somehow possible, to download the required > toolchain before the Cache is buidl up? If this would be possible, i could > dynamicly choose which toolchain i want to have ? would be great for > Compiler / unit Tests as well. > > > > Perhaps someone has a better idea to do this or even i using such a System > and give me a hint? > > > > Thanks a lot! > > > > Best regards, > > Oliver > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensou > rce/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > > > > -- > > 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 > -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig.scott at crascit.com Mon Apr 17 18:18:30 2017 From: craig.scott at crascit.com (Craig Scott) Date: Tue, 18 Apr 2017 08:18:30 +1000 Subject: [CMake] Predownload In-Reply-To: References: <0M9OMc-1csuIc1ocw-00Cgnc@mail.gmx.com> Message-ID: Actually, ExternalProject could even be used to download and unpack the toolchain files in a superbuild arrangement too. Probably makes more sense now that I think about it, since it provides unpacking as well, not just downloading and has a much richer set of download methods. On Tue, Apr 18, 2017 at 8:16 AM, Craig Scott wrote: > One option may be a superbuild arrangement (based on ExternalProject, > online searches should give you details). The only thing the top level > would do is setup the sub builds, including downloading and selecting which > toolchain(s) to use for each sub build. > > > On Tue, Apr 18, 2017 at 8:03 AM, Florent Castelli < > florent.castelli at gmail.com> wrote: > >> It is possible. >> >> Nothing prevents you from calling execute_process to download as extract >> your toolchain file when it is run. You probably want to check the >> destination folder for a pre existing download though. >> > > > If you use file(DOWNLOAD...) for downloading the toolchain files and you > specify an EXPECTED_HASH, this will also conveniently take care of only > downloading the file if it isn't already present. Shouldn't need to resort > to execute_process() to do the download. > > > > Then, you proceed on configuring Cmake to use it as usual. >> >> /Florent >> >> On Apr 17, 2017 14:11, "Zabel, Oliver" wrote: >> >> Hi, >> >> >> >> i?m developing Software for embedded Systems and my applications Need to >> run on different target platforms. Until now we are build our Code with >> make but i?d like to Switch to cmake. ATM we?re putting our Compiler >> toolchains in our VCS to be able to produce the same binarys even after >> years. Until now, there is only one toolchain include in a Project as >> svn-external/git submodule. But i want to use toolchain-files with cmake. >> >> >> >> Now here is my idea and i?d like to know whether this is possible with >> cmake. >> >> I have my Project root and in this Folder i?d like to have different >> toolchain files for different Compilers. I?d like to exclude the Compilers >> as external. >> >> Now i?d like to build the cmake Cache by calling cmake with the required >> toolchain file. Is it now somehow possible, to download the required >> toolchain before the Cache is buidl up? If this would be possible, i could >> dynamicly choose which toolchain i want to have ? would be great for >> Compiler / unit Tests as well. >> >> >> >> Perhaps someone has a better idea to do this or even i using such a >> System and give me a hint? >> >> >> >> Thanks a lot! >> >> >> >> Best regards, >> >> Oliver >> >> -- >> >> 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 >> > > > > -- > Craig Scott > Melbourne, Australia > https://crascit.com > -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From florent.castelli at gmail.com Mon Apr 17 18:21:27 2017 From: florent.castelli at gmail.com (Florent Castelli) Date: Tue, 18 Apr 2017 00:21:27 +0200 Subject: [CMake] Predownload In-Reply-To: References: <0M9OMc-1csuIc1ocw-00Cgnc@mail.gmx.com> Message-ID: Don't you need the toolchain to be configured (Aka project() called) before ExternalProject? You wouldn't be able to update it after the download. /Florent On Apr 17, 2017 11:18 PM, "Craig Scott" wrote: > Actually, ExternalProject could even be used to download and unpack the > toolchain files in a superbuild arrangement too. Probably makes more sense > now that I think about it, since it provides unpacking as well, not just > downloading and has a much richer set of download methods. > > On Tue, Apr 18, 2017 at 8:16 AM, Craig Scott > wrote: > >> One option may be a superbuild arrangement (based on ExternalProject, >> online searches should give you details). The only thing the top level >> would do is setup the sub builds, including downloading and selecting which >> toolchain(s) to use for each sub build. >> >> >> On Tue, Apr 18, 2017 at 8:03 AM, Florent Castelli < >> florent.castelli at gmail.com> wrote: >> >>> It is possible. >>> >>> Nothing prevents you from calling execute_process to download as extract >>> your toolchain file when it is run. You probably want to check the >>> destination folder for a pre existing download though. >>> >> >> >> If you use file(DOWNLOAD...) for downloading the toolchain files and you >> specify an EXPECTED_HASH, this will also conveniently take care of only >> downloading the file if it isn't already present. Shouldn't need to resort >> to execute_process() to do the download. >> >> >> >> Then, you proceed on configuring Cmake to use it as usual. >>> >>> /Florent >>> >>> On Apr 17, 2017 14:11, "Zabel, Oliver" wrote: >>> >>> Hi, >>> >>> >>> >>> i?m developing Software for embedded Systems and my applications Need to >>> run on different target platforms. Until now we are build our Code with >>> make but i?d like to Switch to cmake. ATM we?re putting our Compiler >>> toolchains in our VCS to be able to produce the same binarys even after >>> years. Until now, there is only one toolchain include in a Project as >>> svn-external/git submodule. But i want to use toolchain-files with cmake. >>> >>> >>> >>> Now here is my idea and i?d like to know whether this is possible with >>> cmake. >>> >>> I have my Project root and in this Folder i?d like to have different >>> toolchain files for different Compilers. I?d like to exclude the Compilers >>> as external. >>> >>> Now i?d like to build the cmake Cache by calling cmake with the required >>> toolchain file. Is it now somehow possible, to download the required >>> toolchain before the Cache is buidl up? If this would be possible, i could >>> dynamicly choose which toolchain i want to have ? would be great for >>> Compiler / unit Tests as well. >>> >>> >>> >>> Perhaps someone has a better idea to do this or even i using such a >>> System and give me a hint? >>> >>> >>> >>> Thanks a lot! >>> >>> >>> >>> Best regards, >>> >>> Oliver >>> >>> -- >>> >>> 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 >>> >> >> >> >> -- >> Craig Scott >> Melbourne, Australia >> https://crascit.com >> > > > > -- > Craig Scott > Melbourne, Australia > https://crascit.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig.scott at crascit.com Mon Apr 17 18:23:55 2017 From: craig.scott at crascit.com (Craig Scott) Date: Tue, 18 Apr 2017 08:23:55 +1000 Subject: [CMake] Predownload In-Reply-To: References: <0M9OMc-1csuIc1ocw-00Cgnc@mail.gmx.com> Message-ID: The top level build doesn't actually need to build anything itself. It would just become a sequence of ExternalProject_Add() calls with some simple logic for selecting which things to turn on/off, etc. The first ExternalProject_Add() would download the toolchain files. The subsequent ExternalProject_Add() calls could then use those toolchain files in their configure steps. You just need to ensure you create the dependencies between the ExternalProject targets to ensure the toolchain downloads happen before the other ExternalProject targets that need them. On Tue, Apr 18, 2017 at 8:21 AM, Florent Castelli < florent.castelli at gmail.com> wrote: > Don't you need the toolchain to be configured (Aka project() called) > before ExternalProject? You wouldn't be able to update it after the > download. > > /Florent > > On Apr 17, 2017 11:18 PM, "Craig Scott" wrote: > >> Actually, ExternalProject could even be used to download and unpack the >> toolchain files in a superbuild arrangement too. Probably makes more sense >> now that I think about it, since it provides unpacking as well, not just >> downloading and has a much richer set of download methods. >> >> On Tue, Apr 18, 2017 at 8:16 AM, Craig Scott >> wrote: >> >>> One option may be a superbuild arrangement (based on ExternalProject, >>> online searches should give you details). The only thing the top level >>> would do is setup the sub builds, including downloading and selecting which >>> toolchain(s) to use for each sub build. >>> >>> >>> On Tue, Apr 18, 2017 at 8:03 AM, Florent Castelli < >>> florent.castelli at gmail.com> wrote: >>> >>>> It is possible. >>>> >>>> Nothing prevents you from calling execute_process to download as >>>> extract your toolchain file when it is run. You probably want to check the >>>> destination folder for a pre existing download though. >>>> >>> >>> >>> If you use file(DOWNLOAD...) for downloading the toolchain files and you >>> specify an EXPECTED_HASH, this will also conveniently take care of only >>> downloading the file if it isn't already present. Shouldn't need to resort >>> to execute_process() to do the download. >>> >>> >>> >>> Then, you proceed on configuring Cmake to use it as usual. >>>> >>>> /Florent >>>> >>>> On Apr 17, 2017 14:11, "Zabel, Oliver" wrote: >>>> >>>> Hi, >>>> >>>> >>>> >>>> i?m developing Software for embedded Systems and my applications Need >>>> to run on different target platforms. Until now we are build our Code with >>>> make but i?d like to Switch to cmake. ATM we?re putting our Compiler >>>> toolchains in our VCS to be able to produce the same binarys even after >>>> years. Until now, there is only one toolchain include in a Project as >>>> svn-external/git submodule. But i want to use toolchain-files with cmake. >>>> >>>> >>>> >>>> Now here is my idea and i?d like to know whether this is possible with >>>> cmake. >>>> >>>> I have my Project root and in this Folder i?d like to have different >>>> toolchain files for different Compilers. I?d like to exclude the Compilers >>>> as external. >>>> >>>> Now i?d like to build the cmake Cache by calling cmake with the >>>> required toolchain file. Is it now somehow possible, to download the >>>> required toolchain before the Cache is buidl up? If this would be possible, >>>> i could dynamicly choose which toolchain i want to have ? would be great >>>> for Compiler / unit Tests as well. >>>> >>>> >>>> >>>> Perhaps someone has a better idea to do this or even i using such a >>>> System and give me a hint? >>>> >>>> >>>> >>>> Thanks a lot! >>>> >>>> >>>> >>>> Best regards, >>>> >>>> Oliver >>>> >>>> -- >>>> >>>> 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 >>>> >>> >>> >>> >>> -- >>> Craig Scott >>> Melbourne, Australia >>> https://crascit.com >>> >> >> >> >> -- >> Craig Scott >> Melbourne, Australia >> https://crascit.com >> > -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From oliverzabel at gmx.de Tue Apr 18 01:24:55 2017 From: oliverzabel at gmx.de (Zabel, Oliver) Date: Tue, 18 Apr 2017 07:24:55 +0200 Subject: [CMake] Predownload In-Reply-To: References: <0M9OMc-1csuIc1ocw-00Cgnc@mail.gmx.com> , Message-ID: An HTML attachment was scrubbed... URL: From eric.noulard at gmail.com Tue Apr 18 10:30:06 2017 From: eric.noulard at gmail.com (Eric Noulard) Date: Tue, 18 Apr 2017 16:30:06 +0200 Subject: [CMake] Question about transitive deps and static libs. Message-ID: I have a question concerning the transitive linking of dependence and static libs. I'm working a on prokect where some shared lib are linked to static lib (do not ask me why). So I do: set(CMAKE_POSITION_INDEPENDENT_CODE True) then I have a bunch of libraries (either static or shared) which depends on each other. I use PRIVATE and PUBLIC specification with target_link_librairies. Now I expected that the transitive link properties would be fullfilled simply i.e. that when some target LIB1 is PRIVATEly link against say pthread. Then if a another lib LIB2 is linked against LIB1 then then "pthread" wouldn't be dragged into the link interface of LIB2. It seems that this is not as simple as I thought and as soon as LIB1 is static then LIB2 gets the dependency (be it PRIVATE or PUBLIC)... Find attached a small example. Is this a bug, a feature or something I didn't catch? -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: privpubdeps.tgz Type: application/x-gzip Size: 554 bytes Desc: not available URL: From eric.noulard at gmail.com Tue Apr 18 11:44:00 2017 From: eric.noulard at gmail.com (Eric Noulard) Date: Tue, 18 Apr 2017 17:44:00 +0200 Subject: [CMake] Question about transitive deps and static libs. In-Reply-To: References: Message-ID: Answering to myself. This mail by Craig explains a lot: https://cmake.org/pipermail/cmake/2016-May/063400.html Sorry for the noise. I guess I have my answer in there. I'll try to propose a documentation update based on Craig's explanation because, https://cmake.org/cmake/help/v3.8/manual/cmake-buildsystem.7.html#transitive-usage-requirements does not contains clues on specific treatment for static libs. 2017-04-18 16:30 GMT+02:00 Eric Noulard : > I have a question concerning the transitive linking of dependence and > static libs. > > I'm working a on prokect where some shared lib are linked to static lib > (do not ask me why). > So I do: > > set(CMAKE_POSITION_INDEPENDENT_CODE True) > > then I have a bunch of libraries (either static or shared) which depends > on each other. > I use PRIVATE and PUBLIC specification with target_link_librairies. > > Now I expected that the transitive link properties would be fullfilled > simply i.e. that > when some target LIB1 is PRIVATEly link against say pthread. Then if a > another > lib LIB2 is linked against LIB1 then then "pthread" wouldn't be dragged > into the link > interface of LIB2. > > It seems that this is not as simple as I thought and as soon as LIB1 is > static > then LIB2 gets the dependency (be it PRIVATE or PUBLIC)... > > Find attached a small example. > > Is this a bug, a feature or something I didn't catch? > > > -- > Eric > -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From konstantin at podsvirov.pro Tue Apr 18 12:52:44 2017 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Tue, 18 Apr 2017 19:52:44 +0300 Subject: [CMake] Packaging issues In-Reply-To: <90901491237516@web44j.yandex.ru> References: <7c2e6f72-4a77-c7ac-46c4-f2f71fd46fbf@ifm-chemnitz.de> <39448ffa-1cab-f8ce-b6f2-47ba2e5881c5@ifm-chemnitz.de> <90901491237516@web44j.yandex.ru> Message-ID: <1274801492534364@web34g.yandex.ru> The CPackIFW module learned the new hint CPACK_IFW_ROOT variable for finding the QtIFW tool suite installed in a non-standard place. https://cmake.org/cmake/help/git-master/module/CPackIFW.html#variable:CPACK_IFW_ROOT This feature available in 'master' branch and will be released with CMake 3.9.0. 03.04.2017, 19:44, "Konstantin Podsvirov" : > Hello Volker! > > 03.04.2017, 18:50, "Volker Enderlein" : >> ?Am 03/04/2017 um 12:30 schrieb Volker Enderlein: >>> ??Hi, >>> >>> ??I'm facing problems using the packaging with CPACK. >>> >>> ??I try to build three different packages, a MSI (via WIX), an IFW, and >>> ??a ZIP package. >>> >>> ??According to the documentation I set the following variables in my >>> ??CMakeLists.txt (and a few more which are required): >>> >>> ??set(CPACK_WIX_ROOT "C:/Temp/WiX-3.10/binaries") >>> >>> ??set(QTIFWDIR "${GLOBAL}/Qt/Tools/QtInstallerFramework/2.0/bin") > > As wrote in the documentation: > > https://cmake.org/cmake/help/latest/module/CPackIFW.html#overview > > QTIFWDIR (like QTDIR) - it's QtIFW installation path (without "/bin"). > > You can set it's as your environment variable and use for all your projects. > >>> ??set(CPACK_GENERATOR "WIX;IFW;ZIP") >>> >>> ??After creating the build dir and running from there >>> >>> ??cmake -G "Visual Studio 14 2015 Win64" ..\TestProject >>> >>> ??the files CMakeCache.txt, CPackConfig.cmake, CPackSourceConfig.cmake, >>> ??and CPackProperties.cmake are generated. >>> >>> ??When running `cpack -C Release` to build all three installers at once, >>> ??the first one (WIX) is built, but the second one (QtIFW) fails with >>> ??the messages >>> >>> ??CPack Error: Cannot find QtIFW compiler "binarycreator": likely it is >>> ??not installed, or not in your PATH >>> ??CPack Error: Cannot initialize the generator IFW >>> >>> ??I inspected the CMakeCache.txt file but found the following entries >>> ??properly defined: >>> >>> ??//QtIFW binarycreator command line client >>> ??CPACK_IFW_BINARYCREATOR_EXECUTABLE:FILEPATH=N:/Global/Qt/Tools/QtInstallerFramework/2.0/bin/binarycreator.exe >>> >>> ??//QtIFW devtool command line client >>> ??CPACK_IFW_DEVTOOL_EXECUTABLE:FILEPATH=N:/Global/Qt/Tools/QtInstallerFramework/2.0/bin/devtool.exe >>> >>> ??//QtIFW installer executable base >>> ??CPACK_IFW_INSTALLERBASE_EXECUTABLE:FILEPATH=N:/Global/Qt/Tools/QtInstallerFramework/2.0/bin/installerbase.exe >>> >>> ??//QtIFW repogen command line client >>> ??CPACK_IFW_REPOGEN_EXECUTABLE:FILEPATH=N:/Global/Qt/Tools/QtInstallerFramework/2.0/bin/repogen.exe >>> >>> ??//Enable to build 7-Zip source packages >>> ??CPACK_SOURCE_7Z:BOOL=ON >>> >>> ??//Enable to build ZIP source packages >>> ??CPACK_SOURCE_ZIP:BOOL=ON >>> >>> ??//Path to a program. >>> ??CPACK_WIX_CANDLE_EXECUTABLE:FILEPATH=C:/Temp/WiX-3.10/binaries/candle.exe >>> >>> ??//Path to a program. >>> ??CPACK_WIX_LIGHT_EXECUTABLE:FILEPATH=C:/Temp/WiX-3.10/binaries/light.exe >>> >>> ??But when I checked the CPack*Config.cmake files none of the entries >>> ??above are referenced. After running the `cmake -G "Visual Studio 14 >>> ??2015 Win64" ..\TestProject` a second time everything is fine; the >>> ??entries are referenced in CPack*Config.cmake files and all three >>> ??installers can be built. >>> >>> ??So I really get stuck at this point. >>> >>> ??Any ideas what could be the issue and how to avoid it? >>> >>> ??Cheers Volker >> >> ?A close follow up. >> >> ?I finally figured out what didn't work. >> >> ?The setting of the QTIFWDIR variable is not saved to the >> ?CPack*Config.cmake files. But the CMAKE_WIX_ROOT variable is. Those >> ?variables seem to be evaluated at runtime by CPack. Therefore the WIX >> ?build run successfully but the IFW build complained about a the path. >> ?Adding the variable with its current setting made everything run as >> ?expected. >> >> ?Cheers Volker >> >> ?-- >> >> ?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 > > Good luck with creating your installers! > > -- > Regards, > Konstantin Podsvirov (CPackIFW author) > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake -- Regards, Konstantin Podsvirov (CPackIFW author) From volker.enderlein at ifm-chemnitz.de Tue Apr 18 13:36:31 2017 From: volker.enderlein at ifm-chemnitz.de (Volker Enderlein) Date: Tue, 18 Apr 2017 19:36:31 +0200 Subject: [CMake] Packaging issues In-Reply-To: <1274801492534364@web34g.yandex.ru> References: <7c2e6f72-4a77-c7ac-46c4-f2f71fd46fbf@ifm-chemnitz.de> <39448ffa-1cab-f8ce-b6f2-47ba2e5881c5@ifm-chemnitz.de> <90901491237516@web44j.yandex.ru> <1274801492534364@web34g.yandex.ru> Message-ID: <40464058-9b73-32cd-f938-44702f3c6302@ifm-chemnitz.de> Hello Konstantin, Thanks again for your excellent support and your continuous development of the CPack IFW module. Cheers, Volker Am 18.04.2017 um 18:52 schrieb Konstantin Podsvirov: > The CPackIFW module learned the new hint CPACK_IFW_ROOT variable for finding the QtIFW tool suite installed in a non-standard place. > > https://cmake.org/cmake/help/git-master/module/CPackIFW.html#variable:CPACK_IFW_ROOT > > This feature available in 'master' branch and will be released with CMake 3.9.0. > > 03.04.2017, 19:44, "Konstantin Podsvirov" : >> Hello Volker! >> >> 03.04.2017, 18:50, "Volker Enderlein" : >>> Am 03/04/2017 um 12:30 schrieb Volker Enderlein: >>>> Hi, >>>> >>>> I'm facing problems using the packaging with CPACK. >>>> >>>> I try to build three different packages, a MSI (via WIX), an IFW, and >>>> a ZIP package. >>>> >>>> According to the documentation I set the following variables in my >>>> CMakeLists.txt (and a few more which are required): >>>> >>>> set(CPACK_WIX_ROOT "C:/Temp/WiX-3.10/binaries") >>>> >>>> set(QTIFWDIR "${GLOBAL}/Qt/Tools/QtInstallerFramework/2.0/bin") >> >> As wrote in the documentation: >> >> https://cmake.org/cmake/help/latest/module/CPackIFW.html#overview >> >> QTIFWDIR (like QTDIR) - it's QtIFW installation path (without "/bin"). >> >> You can set it's as your environment variable and use for all your projects. >> >>>> set(CPACK_GENERATOR "WIX;IFW;ZIP") >>>> >>>> After creating the build dir and running from there >>>> >>>> cmake -G "Visual Studio 14 2015 Win64" ..\TestProject >>>> >>>> the files CMakeCache.txt, CPackConfig.cmake, CPackSourceConfig.cmake, >>>> and CPackProperties.cmake are generated. >>>> >>>> When running `cpack -C Release` to build all three installers at once, >>>> the first one (WIX) is built, but the second one (QtIFW) fails with >>>> the messages >>>> >>>> CPack Error: Cannot find QtIFW compiler "binarycreator": likely it is >>>> not installed, or not in your PATH >>>> CPack Error: Cannot initialize the generator IFW >>>> >>>> I inspected the CMakeCache.txt file but found the following entries >>>> properly defined: >>>> >>>> //QtIFW binarycreator command line client >>>> CPACK_IFW_BINARYCREATOR_EXECUTABLE:FILEPATH=N:/Global/Qt/Tools/QtInstallerFramework/2.0/bin/binarycreator.exe >>>> >>>> //QtIFW devtool command line client >>>> CPACK_IFW_DEVTOOL_EXECUTABLE:FILEPATH=N:/Global/Qt/Tools/QtInstallerFramework/2.0/bin/devtool.exe >>>> >>>> //QtIFW installer executable base >>>> CPACK_IFW_INSTALLERBASE_EXECUTABLE:FILEPATH=N:/Global/Qt/Tools/QtInstallerFramework/2.0/bin/installerbase.exe >>>> >>>> //QtIFW repogen command line client >>>> CPACK_IFW_REPOGEN_EXECUTABLE:FILEPATH=N:/Global/Qt/Tools/QtInstallerFramework/2.0/bin/repogen.exe >>>> >>>> //Enable to build 7-Zip source packages >>>> CPACK_SOURCE_7Z:BOOL=ON >>>> >>>> //Enable to build ZIP source packages >>>> CPACK_SOURCE_ZIP:BOOL=ON >>>> >>>> //Path to a program. >>>> CPACK_WIX_CANDLE_EXECUTABLE:FILEPATH=C:/Temp/WiX-3.10/binaries/candle.exe >>>> >>>> //Path to a program. >>>> CPACK_WIX_LIGHT_EXECUTABLE:FILEPATH=C:/Temp/WiX-3.10/binaries/light.exe >>>> >>>> But when I checked the CPack*Config.cmake files none of the entries >>>> above are referenced. After running the `cmake -G "Visual Studio 14 >>>> 2015 Win64" ..\TestProject` a second time everything is fine; the >>>> entries are referenced in CPack*Config.cmake files and all three >>>> installers can be built. >>>> >>>> So I really get stuck at this point. >>>> >>>> Any ideas what could be the issue and how to avoid it? >>>> >>>> Cheers Volker >>> >>> A close follow up. >>> >>> I finally figured out what didn't work. >>> >>> The setting of the QTIFWDIR variable is not saved to the >>> CPack*Config.cmake files. But the CMAKE_WIX_ROOT variable is. Those >>> variables seem to be evaluated at runtime by CPack. Therefore the WIX >>> build run successfully but the IFW build complained about a the path. >>> Adding the variable with its current setting made everything run as >>> expected. >>> >>> Cheers Volker >>> >>> -- >>> >>> 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 >> >> Good luck with creating your installers! >> >> -- >> Regards, >> Konstantin Podsvirov (CPackIFW author) >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake > > -- > Regards, > Konstantin Podsvirov (CPackIFW author) > From r14 at thinhorn.com Tue Apr 18 15:13:19 2017 From: r14 at thinhorn.com (R. Sage) Date: Tue, 18 Apr 2017 12:13:19 -0700 Subject: [CMake] How does one create a nonfatal error in cmake_install.cmake? Message-ID: Under CMake 2.8.7, I am trying to produce an install error similarly to how I would use SEND_ERROR in a normal CMakeLIsts.txt and I successfully insert message(SEND_ERROR...) into the cmake_install.cmake and it produces a message, but unfortunately upon hitting the message(SEND_ERROR ...), it stops install execution immediately. I have also tested under CMake 3.5.1 and I get the same results as the target system (2.8.7). Below is a complete example that reproduces the issue. The behavior is that 'make install' terminates immediately after the SEND_ERROR message, before issuing any other messages (the example uses messages as the install steps). I edited the cmake_install.cmake to experiment with different message types and each type either returns status 0 (success) or aborts immediately without continuing. Lacking a nonfatal error, I guess I'll have to separate out the custom installation to be run manually outside of the CMake-controlled 'make install'. Thanks, Randy Sage ---- Example CMakeLists.txt ---- cmake_minimum_required (VERSION 2.8.7) project (INSTALL_ERROR_DEMO) install(CODE "execute_process ( COMMAND \"touch\" \"/dev/null/cannot/exist\" ERROR_VARIABLE _err RESULT_VARIABLE _res ) if (NOT \${_res} EQUAL \"0\") message( SEND_ERROR \"err: \${_err}, res: \${_res}\") message( INFO \" Proceeding with any remaining steps, but 'make install' will fail\") endif ()" COMPONENT compname ) install(CODE "message( INFO \" Hypothetical later install step\")" COMPONENT compname ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig.scott at crascit.com Tue Apr 18 18:20:34 2017 From: craig.scott at crascit.com (Craig Scott) Date: Wed, 19 Apr 2017 08:20:34 +1000 Subject: [CMake] Predownload In-Reply-To: References: <0M9OMc-1csuIc1ocw-00Cgnc@mail.gmx.com> Message-ID: On Tue, Apr 18, 2017 at 3:24 PM, Zabel, Oliver wrote: > Hi, thanks a lot for your input. I will take a look at the SuperProject > (with ExternalProject_Add() call) constellation as well as the meta build > tools. I'm quite new to this stuff, so please allow me my question: does > this even make sense what i'm trying or are there some "patterns" that > handles this stuff that i'm not aware of? > If it works in your situation, then it makes sense. ;) I'm not aware of any particular common pattern for what you're trying to do, so you may just have to experiment a bit. Not sure if it is relevant or if it will just be a distraction for you, but you may find Ruslo's polly project to be an interesting resource for toolchains. https://github.com/ruslo/polly > > *Gesendet:* Dienstag, 18. April 2017 um 00:23 Uhr > *Von:* "Craig Scott" > *An:* "Florent Castelli" > *Cc:* CMake , "Zabel, Oliver" > *Betreff:* Re: [CMake] Predownload > The top level build doesn't actually need to build anything itself. It > would just become a sequence of ExternalProject_Add() calls with some > simple logic for selecting which things to turn on/off, etc. The first > ExternalProject_Add() would download the toolchain files. The subsequent > ExternalProject_Add() calls could then use those toolchain files in their > configure steps. You just need to ensure you create the dependencies > between the ExternalProject targets to ensure the toolchain downloads > happen before the other ExternalProject targets that need them. > > > On Tue, Apr 18, 2017 at 8:21 AM, Florent Castelli < > florent.castelli at gmail.com> wrote: >> >> Don't you need the toolchain to be configured (Aka project() called) >> before ExternalProject? You wouldn't be able to update it after the >> download. >> >> /Florent >> >> On Apr 17, 2017 11:18 PM, "Craig Scott" wrote: >>> >>> Actually, ExternalProject could even be used to download and unpack the >>> toolchain files in a superbuild arrangement too. Probably makes more sense >>> now that I think about it, since it provides unpacking as well, not just >>> downloading and has a much richer set of download methods. >>> >>> On Tue, Apr 18, 2017 at 8:16 AM, Craig Scott >>> wrote: >>>> >>>> One option may be a superbuild arrangement (based on ExternalProject, >>>> online searches should give you details). The only thing the top level >>>> would do is setup the sub builds, including downloading and selecting which >>>> toolchain(s) to use for each sub build. >>>> >>>> >>>> On Tue, Apr 18, 2017 at 8:03 AM, Florent Castelli < >>>> florent.castelli at gmail.com> wrote: >>>>> >>>>> It is possible. >>>>> >>>>> Nothing prevents you from calling execute_process to download as >>>>> extract your toolchain file when it is run. You probably want to check the >>>>> destination folder for a pre existing download though. >>>>> >>>> >>>> >>>> If you use file(DOWNLOAD...) for downloading the toolchain files and >>>> you specify an EXPECTED_HASH, this will also conveniently take care of only >>>> downloading the file if it isn't already present. Shouldn't need to resort >>>> to execute_process() to do the download. >>>> >>>> >>>> >>>> >>>>> Then, you proceed on configuring Cmake to use it as usual. >>>>> >>>>> /Florent >>>>> >>>>> On Apr 17, 2017 14:11, "Zabel, Oliver" wrote: >>>>> >>>>> Hi, >>>>> >>>>> >>>>> >>>>> i?m developing Software for embedded Systems and my applications Need >>>>> to run on different target platforms. Until now we are build our Code with >>>>> make but i?d like to Switch to cmake. ATM we?re putting our Compiler >>>>> toolchains in our VCS to be able to produce the same binarys even after >>>>> years. Until now, there is only one toolchain include in a Project as >>>>> svn-external/git submodule. But i want to use toolchain-files with cmake. >>>>> >>>>> >>>>> >>>>> Now here is my idea and i?d like to know whether this is possible with >>>>> cmake. >>>>> >>>>> I have my Project root and in this Folder i?d like to have different >>>>> toolchain files for different Compilers. I?d like to exclude the Compilers >>>>> as external. >>>>> >>>>> Now i?d like to build the cmake Cache by calling cmake with the >>>>> required toolchain file. Is it now somehow possible, to download the >>>>> required toolchain before the Cache is buidl up? If this would be possible, >>>>> i could dynamicly choose which toolchain i want to have ? would be great >>>>> for Compiler / unit Tests as well. >>>>> >>>>> >>>>> >>>>> Perhaps someone has a better idea to do this or even i using such a >>>>> System and give me a hint? >>>>> >>>>> >>>>> >>>>> Thanks a lot! >>>>> >>>>> >>>>> >>>>> Best regards, >>>>> >>>>> Oliver >>>>> >>>>> -- >>>>> >>>>> 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 >>>> >>>> >>>> >>>> -- >>>> Craig Scott >>>> Melbourne, Australia >>>> https://crascit.com >>>> >>> >>> >>> -- >>> Craig Scott >>> Melbourne, Australia >>> https://crascit.com >>> >> > > -- > Craig Scott > Melbourne, Australia > https://crascit.com > -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcdailey.lists at gmail.com Tue Apr 18 22:45:46 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Tue, 18 Apr 2017 21:45:46 -0500 Subject: [CMake] Need code review of my android toolchain file Message-ID: I'm trying to follow best practices where I can, but the trouble is I'm not aware of any. So I want to post my android.toolchain.cmake file here, with the hope that I can get some pointers. The main thing I want to understand is when it is appropriate to require cache variables be set via command line argument (-D) or via the toolchain file itself. Here is what is in my toolchain right now: set(CMAKE_SYSTEM_NAME Android) set(CMAKE_SYSTEM_VERSION 15) # API level set(CMAKE_ANDROID_ARCH_ABI armeabi-v7a) set(CMAKE_ANDROID_STL_TYPE c++_static) set(CMAKE_ANDROID_NDK_TOOLCHAIN_VERSION clang) string(REGEX REPLACE "\\\\" "/" ndk_path "$ENV{ANDROID_NDK}") set(CMAKE_ANDROID_NDK ${ndk_path}) unset(ndk_path) My idea here is to provide a different toolchain file per specific NDK configuration. For example, I need to build my native libraries for both x86 and ARM platforms, so I would use 2 CMAKE_BINARY_DIR, each configured using a different toolchain: x86 would use "android.toolchain.x86.cmake" ARM would use "android.toolchain.arm.cmake" Something like that. Is this best practice? What other advice would you offer? Thanks in advance. From petr.kmoch at gmail.com Wed Apr 19 02:41:47 2017 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Wed, 19 Apr 2017 08:41:47 +0200 Subject: [CMake] Question about transitive deps and static libs. In-Reply-To: References: Message-ID: Hi, I will offer an alternative phrasing based on what makes me personally understand this best. It might potentially be useful for the documentation update you're planning. `target_link_libraries(A B)` specifies that the code in A needs B to be added to the produced binary when the binary is *linked*. However, static libraries are not produced by linking, but by an archiver or librarian tool. Therefore, B needs to be present for the actual linking step when this happens further down the chain (when linking an executable or shared library), regardless of the "privacy" of B in A. Petr On 18 April 2017 at 17:44, Eric Noulard wrote: > Answering to myself. > > This mail by Craig explains a lot: > https://cmake.org/pipermail/cmake/2016-May/063400.html > > Sorry for the noise. I guess I have my answer in there. > I'll try to propose a documentation update based on Craig's explanation > because, > https://cmake.org/cmake/help/v3.8/manual/cmake-buildsystem. > 7.html#transitive-usage-requirements > > does not contains clues on specific treatment for static libs. > > > > > 2017-04-18 16:30 GMT+02:00 Eric Noulard : > >> I have a question concerning the transitive linking of dependence and >> static libs. >> >> I'm working a on prokect where some shared lib are linked to static lib >> (do not ask me why). >> So I do: >> >> set(CMAKE_POSITION_INDEPENDENT_CODE True) >> >> then I have a bunch of libraries (either static or shared) which depends >> on each other. >> I use PRIVATE and PUBLIC specification with target_link_librairies. >> >> Now I expected that the transitive link properties would be fullfilled >> simply i.e. that >> when some target LIB1 is PRIVATEly link against say pthread. Then if a >> another >> lib LIB2 is linked against LIB1 then then "pthread" wouldn't be dragged >> into the link >> interface of LIB2. >> >> It seems that this is not as simple as I thought and as soon as LIB1 is >> static >> then LIB2 gets the dependency (be it PRIVATE or PUBLIC)... >> >> Find attached a small example. >> >> Is this a bug, a feature or something I didn't catch? >> >> >> -- >> Eric >> > > > > -- > Eric > > -- > > 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 singapuram.sanjay at gmail.com Thu Apr 20 11:56:54 2017 From: singapuram.sanjay at gmail.com (Sanjay Srivallabh Singapuram) Date: Thu, 20 Apr 2017 15:56:54 +0000 Subject: [CMake] Prevent libraries from linking twice during LLVM build Message-ID: Hello, I'm proposing a patch to the Polly/LLVM project that involves linking libPolly.a or libPolly.so to NVPTX back-end libraries. I'm currently using, target_link_libraries(Polly LLVMNVPTXCodeGen LLVMNVPTXInfo LLVMNVPTXDesc LLVMNVPTXAsmPrinter ) The opt binary links to both Polly and NVPTX back-end libraries, therefore including the back-end libraries twice which causes problems. Can linking the libraries as an INTERFACE to Polly solve the problem ? target_link_libraries(Polly INTERFACE LLVMNVPTXCodeGen LLVMNVPTXInfo LLVMNVPTXDesc LLVMNVPTXAsmPrinter ) Thank You, Sanjay -------------- next part -------------- An HTML attachment was scrubbed... URL: From cmake at meinersbur.de Thu Apr 20 13:47:04 2017 From: cmake at meinersbur.de (Michael Kruse) Date: Thu, 20 Apr 2017 19:47:04 +0200 Subject: [CMake] Prevent libraries from linking twice during LLVM build In-Reply-To: References: Message-ID: The cmake mailing list may not have sufficient context, so let me add some details. Polly is an extension library for LLVM. Both can be configured in multiple configurations: LLVM can be - A bunch of libLLVM*.a files - A bunch of libLLVM*.so files - A single libLLVM.so file Polly can be - LLVMPolly.so to be loaded dynamically into the LLVM host application using an LD_PRELOAD-like mechanism (e.g. clang or opt) - Linked directly into the LLVM host application (target_link_library) - as dynamic library libPolly.so - as static library libPolly.a and it should work with all combinations of these. The issue is not all host applications always have all LLVM components linked into it. In the example below, there is the Julia compiler which does not have the NVPTX backend in it, but it is required by (some configuration of) Polly. Hence if we have an LLVMPolly.so we don't know whether the host program has the LLVMNVPTX* libraries in it. If we do not depend on these libraries, the linker will complain about missing symbols if the host doesn't have these either. If we do depend on these libraries, and the host has them as well, we risk having the same library multiple times in the address space (e.g. LLVMNVPTX* is statically linked into libLLVM.so, but LLVMPolly.so contains them as well). This is a problem, because for instance, static initializers (".ctors") register some command-line options. It is an error if two libraries (or two copies of the same library) register the same command-line option twice. This is not really a cmake-specific question, and the solution I proposed to Sanjay to require the host application to have all required components already linked into it. We can do this for clang, opt (and bugpoint), but the Julia compiler guys do not like to depend on the NVPTX backend, which they usually do not use. Michael 2017-04-20 17:56 GMT+02:00 Sanjay Srivallabh Singapuram : > Hello, > > I'm proposing a patch to the Polly/LLVM project that involves linking > libPolly.a or libPolly.so to NVPTX back-end libraries. I'm currently using, > target_link_libraries(Polly > LLVMNVPTXCodeGen > LLVMNVPTXInfo > LLVMNVPTXDesc > LLVMNVPTXAsmPrinter > ) > > The opt binary links to both Polly and NVPTX back-end libraries, therefore > including the back-end libraries twice which causes problems. Can linking > the libraries as an INTERFACE to Polly solve the problem ? > > target_link_libraries(Polly INTERFACE > LLVMNVPTXCodeGen > LLVMNVPTXInfo > LLVMNVPTXDesc > LLVMNVPTXAsmPrinter > ) > > Thank You, > Sanjay From alex_chen at filemaker.com Thu Apr 20 18:57:52 2017 From: alex_chen at filemaker.com (Alex Chen) Date: Thu, 20 Apr 2017 15:57:52 -0700 Subject: [CMake] How to set C++ standard? Message-ID: <8D413141-C584-43A3-A286-49E9CB93A795@filemaker.com> I tried to set the compiler flag ?std=c++14 via cmake command line on Linux with ?DCMAKE_CXX_STANDARD=14.? The message from ?make? shows?? -std=c++11 ?std=gnu++14 If I do not set that flag, I get -std=c++11.? This seem to imply the CMAKE_CXX_STANDARD flag sets gnu++ instead of c++.? How do I set the flag ?std=c++14 then? Alex Chen -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig.scott at crascit.com Thu Apr 20 19:41:50 2017 From: craig.scott at crascit.com (Craig Scott) Date: Fri, 21 Apr 2017 09:41:50 +1000 Subject: [CMake] How to set C++ standard? In-Reply-To: <8D413141-C584-43A3-A286-49E9CB93A795@filemaker.com> References: <8D413141-C584-43A3-A286-49E9CB93A795@filemaker.com> Message-ID: You generally shouldn't set CMAKE_CXX_STANDARD on its own, you should also be explicitly setting CMAKE_CXX_STANDARD_REQUIRED and CMAKE_CXX_EXTENSIONS to ensure you are getting the behaviour you want. These would also typically be set by the project's own CMakeLists.txt file rather than being passed on the cmake command line as cache variables. You may find the following article helpful: https://crascit.com/2015/03/28/enabling-cxx11-in-cmake/ On Fri, Apr 21, 2017 at 8:57 AM, Alex Chen wrote: > I tried to set the compiler flag ?std=c++14 via cmake command line on > Linux with ?DCMAKE_CXX_STANDARD=14. The message from ?make? shows *-std=c++11 > ?std=gnu++14* > > If I do not set that flag, I get *-std=c++11. *This seem to imply the > CMAKE_CXX_STANDARD flag sets *gnu++* instead of *c++. *How do I set the > flag ?std=c++14 then? > > > > Alex Chen > > -- > > 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 > -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From kris.f.thielemans at gmail.com Thu Apr 20 20:03:01 2017 From: kris.f.thielemans at gmail.com (Kris Thielemans) Date: Fri, 21 Apr 2017 01:03:01 +0100 Subject: [CMake] dependency on external libraries (and Visual Studio) Message-ID: <00c301d2ba32$a4ee7db0$eecb7910$@gmail.com> Hi I have a project with a shared library that depends on some external static libraries. Those are CMake imported targets. It appears that my shared library does not get rebuild when the external libraries are updated. (It would need to be relinked). Is this expected? A bit more info on my set-up: CMake 3.8.0 Visual Studio Community 2015 Some content of my CMakeLists.txt (the external libraries are set in $(STIR_LIBRARIES}). Full project is on https://github.com/CCPPETMR/SIRF/ # static library depending on external add_library(cstir cstir_p.cpp) target_link_libraries(cstir ${STIR_LIBRARIES}) # shared library depending on external (probably not necessary as depends on cstir already) add_library(mstir SHARED mstir.c) target_link_libraries(mstir cstir ${STIR_LIBRARIES}) When checking the Visual Studio project, mstir has a "Reference" to cstir, but neither of them refers to any of the externals. Thanks Kris -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex_chen at filemaker.com Thu Apr 20 20:39:26 2017 From: alex_chen at filemaker.com (Alex Chen) Date: Thu, 20 Apr 2017 17:39:26 -0700 Subject: [CMake] How to set C++ standard? In-Reply-To: References: <8D413141-C584-43A3-A286-49E9CB93A795@filemaker.com> Message-ID: <808CD89E-ACBD-4429-8984-CAF205F61C75@filemaker.com> Thanks.? I find the problem in the source code where it uses CPP_STANDARD as suffix in ?std=c++, therefore I should set CPP_STANDARD instead of the other one. Alex Chen From: Craig Scott Date: Thursday, April 20, 2017 at 4:41 PM To: Alex Chen Cc: CMake Subject: Re: [CMake] How to set C++ standard? You generally shouldn't set CMAKE_CXX_STANDARD on its own, you should also be explicitly setting CMAKE_CXX_STANDARD_REQUIRED and CMAKE_CXX_EXTENSIONS to ensure you are getting the behaviour you want. These would also typically be set by the project's own CMakeLists.txt file rather than being passed on the cmake command line as cache variables. You may find the following article helpful: https://crascit.com/2015/03/28/enabling-cxx11-in-cmake/ On Fri, Apr 21, 2017 at 8:57 AM, Alex Chen wrote: I tried to set the compiler flag ?std=c++14 via cmake command line on Linux with ?DCMAKE_CXX_STANDARD=14. The message from ?make? shows -std=c++11 ?std=gnu++14 If I do not set that flag, I get -std=c++11. This seem to imply the CMAKE_CXX_STANDARD flag sets gnu++ instead of c++. How do I set the flag ?std=c++14 then? Alex Chen -- 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 -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex_chen at filemaker.com Thu Apr 20 21:06:19 2017 From: alex_chen at filemaker.com (Alex Chen) Date: Thu, 20 Apr 2017 18:06:19 -0700 Subject: [CMake] Overriding the include path, library path of OpenSSL, Zlib and libcurl Message-ID: <31918E16-09E5-4920-B25C-CBAF60D37FB6@filemaker.com> The source code I want to compile on Linux uses ?FindOpenSSL?, ?FindZLIB?, and ?FindCURL? to resolve the paths of these libraries. However, I have newer version of these libraries in different locations.? How to I override these to use my paths? I am able to use OPENSSL_ROOT_DIR, from FindOpenSSL module, and ZLIB_ROOT, from FindZLIB module, to override the paths.? But I cannot find anything in FindCURL module to override the path of libcurl. Alex Chen -------------- next part -------------- An HTML attachment was scrubbed... URL: From mellery451 at gmail.com Thu Apr 20 23:13:17 2017 From: mellery451 at gmail.com (Michael Ellery) Date: Thu, 20 Apr 2017 20:13:17 -0700 Subject: [CMake] Overriding the include path, library path of OpenSSL, Zlib and libcurl In-Reply-To: <31918E16-09E5-4920-B25C-CBAF60D37FB6@filemaker.com> References: <31918E16-09E5-4920-B25C-CBAF60D37FB6@filemaker.com> Message-ID: It doesn?t look like that find module directly supports HINTS or PATHS, so you can try setting CMAKE_LIBRARY_PATH and CMAKE_INCLUDE_PATH (https://cmake.org/cmake/help/v3.7/variable/CMAKE_LIBRARY_PATH.html) before calling the curl finder. I think you can add to those variables whatever paths are appropriate to search for CURL on your systems. -Mike > On Apr 20, 2017, at 6:06 PM, Alex Chen wrote: > > The source code I want to compile on Linux uses ?FindOpenSSL?, ?FindZLIB?, and ?FindCURL? to resolve the paths of these libraries. > However, I have newer version of these libraries in different locations. How to I override these to use my paths? > I am able to use OPENSSL_ROOT_DIR, from FindOpenSSL module, and ZLIB_ROOT, from FindZLIB module, to override the paths. > But I cannot find anything in FindCURL module to override the path of libcurl. > > > Alex Chen > -- > > 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 singapuram.sanjay at gmail.com Fri Apr 21 03:37:49 2017 From: singapuram.sanjay at gmail.com (Sanjay Srivallabh Singapuram) Date: Fri, 21 Apr 2017 07:37:49 +0000 Subject: [CMake] Prevent libraries from linking twice during LLVM build In-Reply-To: References: Message-ID: Thanks a lot for the context Michael ! On Thu, 20 Apr 2017 at 22:03 Michael Kruse wrote: > The cmake mailing list may not have sufficient context, so let me add > some details. > > Polly is an extension library for LLVM. Both can be configured in > multiple configurations: > > LLVM can be > - A bunch of libLLVM*.a files > - A bunch of libLLVM*.so files > - A single libLLVM.so > > Polly can be > - LLVMPolly.so to be loaded dynamically into the LLVM host application > using an LD_PRELOAD-like mechanism (e.g. clang or opt) > - Linked directly into the LLVM host application (target_link_library) > - as dynamic library libPolly.so > - as static library libPolly.a > > and it should work with all combinations of these. > > The issue is not all host applications always have all LLVM components > linked into it. In the example below, there is the Julia compiler > which does not have the the NVPTX backend in it, but it is required by > (some configuration of) Polly. > > Hence if we have an LLVMPolly.so we don't know whether the host > program has the LLVMNVPTX* libraries in it. If we do not depend on > these libraries, the linker will complain about missing symbols if the > host doesn't have these either. If we do depend on these libraries, > and the host has them as well, we risk having the same library > multiple times in the address space (e.g. LLVMNVPTX* is statically > linked into libLLVM.so, but LLVMPolly.so contains them as well). > > This is not really a cmake-specific question, and the solution I > proposed to Sanjay to require the host application to have all > required components already linked into it. We can do this for clang, > opt (and bugpoint), but the Julia compiler guys do not like to depend > of the NVPTX backend, which they usually do not use. > > Michael > > > > 2017-04-20 17:56 GMT+02:00 Sanjay Srivallabh Singapuram > : > > Hello, > > > > I'm proposing a patch to the Polly/LLVM project that involves linking > > libPolly.a or libPolly.so to NVPTX back-end libraries. I'm currently > using, > > target_link_libraries(Polly > > LLVMNVPTXCodeGen > > LLVMNVPTXInfo > > LLVMNVPTXDesc > > LLVMNVPTXAsmPrinter > > ) > > > > The opt binary links to both Polly and NVPTX back-end libraries, > therefore > > including the back-end libraries twice which causes problems. Can linking > > the libraries as an INTERFACE to Polly solve the problem ? > > > > target_link_libraries(Polly INTERFACE > > LLVMNVPTXCodeGen > > LLVMNVPTXInfo > > LLVMNVPTXDesc > > LLVMNVPTXAsmPrinter > > ) > > > > Thank You, > > Sanjay > > > > -- > Tardyzentrismus verboten! > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aishwaryaselvaraj1708 at gmail.com Fri Apr 21 09:40:59 2017 From: aishwaryaselvaraj1708 at gmail.com (aishwarya selvaraj) Date: Fri, 21 Apr 2017 19:10:59 +0530 Subject: [CMake] fftw library in cmake Message-ID: Hi all , Below is my CMakelist.txt. I'm getting an error as mentioned below . I'm not to rectify it . Could anyone help me out here please ? ?CMAKE_MINIMUM_REQUIRED(VERSION 2.8) PROJECT(PROSE) ? ExternalProject_Add(project_fftw #GIT_REPOSITORY https://github.com/FFTW/fftw3 URL "http://www.fftw.org/fftw-3.3.2.tar.gz" PREFIX ${CMAKE_CURRENT_BINARY_DIR}/fftw CONFIGURE_COMMAND "" #--Build step----------------- BUILD_COMMAND "" #--Install step--------------- UPDATE_COMMAND "" # Skip annoying updates for every build INSTALL_COMMAND "" ) ?include_directories(${CMAKE_CURRENT_BINARY_DIR}/fftw/src/project_fftw/api) ExternalProject_Get_Property(project_fftw install_dir) add_library(fftw STATIC IMPORTED) add_dependencies(fftw project_fftw) ?ADD_EXECUTABLE(prose ${PROJECT_SOURCE_DIR}/src/prose.cpp) TARGET_LINK_LIBRARIES(prose fftw ) ERROR: Scanning dependencies of target prose [100%] Building CXX object CMakeFiles/prose.dir/src/prose.cpp.o make[2]: *** No rule to make target `fftw-NOTFOUND', needed by `prose'. Stop. make[1]: *** [CMakeFiles/prose.dir/all] Error 2 make: *** [all] Error 2 Where Am I going wrong ? -- Regards, Aishwarya Selvaraj -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcdailey.lists at gmail.com Fri Apr 21 09:45:24 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Fri, 21 Apr 2017 08:45:24 -0500 Subject: [CMake] Need code review of my android toolchain file In-Reply-To: References: Message-ID: I guess the only feedback I really would like is if the path normalization I'm doing for CMAKE_ANDROID_NDK is necessary (converting backslashes to forward slashes). Will CMake translate the backslashes properly? Sometimes I use CMAKE_ANDROID_NDK in custom commands and custom targets to build absolute paths to items in the NDK. On Tue, Apr 18, 2017 at 9:45 PM, Robert Dailey wrote: > I'm trying to follow best practices where I can, but the trouble is > I'm not aware of any. So I want to post my android.toolchain.cmake > file here, with the hope that I can get some pointers. > > The main thing I want to understand is when it is appropriate to > require cache variables be set via command line argument (-D) or via > the toolchain file itself. Here is what is in my toolchain right now: > > > set(CMAKE_SYSTEM_NAME Android) > set(CMAKE_SYSTEM_VERSION 15) # API level > set(CMAKE_ANDROID_ARCH_ABI armeabi-v7a) > set(CMAKE_ANDROID_STL_TYPE c++_static) > set(CMAKE_ANDROID_NDK_TOOLCHAIN_VERSION clang) > > string(REGEX REPLACE "\\\\" "/" ndk_path "$ENV{ANDROID_NDK}") > set(CMAKE_ANDROID_NDK ${ndk_path}) > > unset(ndk_path) > > > > My idea here is to provide a different toolchain file per specific NDK > configuration. For example, I need to build my native libraries for > both x86 and ARM platforms, so I would use 2 CMAKE_BINARY_DIR, each > configured using a different toolchain: > > x86 would use "android.toolchain.x86.cmake" > ARM would use "android.toolchain.arm.cmake" > > Something like that. Is this best practice? What other advice would you offer? > > Thanks in advance. From nilsgladitz at gmail.com Fri Apr 21 09:49:52 2017 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 21 Apr 2017 15:49:52 +0200 Subject: [CMake] fftw library in cmake In-Reply-To: References: Message-ID: <66181503-dc20-9b37-a727-91b086ff99e6@gmail.com> On 04/21/2017 03:40 PM, aishwarya selvaraj wrote: > add_library(fftw STATIC IMPORTED) [...] > TARGET_LINK_LIBRARIES(prose fftw ) [...] > make[2]: *** No rule to make target `fftw-NOTFOUND', needed by > `prose'. Stop. You are creating an IMPORTED target "fftw" but you aren't populating its IMPORTED_LOCATION [1] (or IMPORTED_LOCATION_ [2]) target property. Without it CMake does not know what on disk library file to link to. You can set target properties with set_property() or set_target_properties(). Nils [1] https://cmake.org/cmake/help/latest/prop_tgt/IMPORTED_LOCATION.html [2] https://cmake.org/cmake/help/latest/prop_tgt/IMPORTED_LOCATION_CONFIG.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From aishwaryaselvaraj1708 at gmail.com Fri Apr 21 09:51:34 2017 From: aishwaryaselvaraj1708 at gmail.com (aishwarya selvaraj) Date: Fri, 21 Apr 2017 19:21:34 +0530 Subject: [CMake] fftw library in cmake In-Reply-To: <66181503-dc20-9b37-a727-91b086ff99e6@gmail.com> References: <66181503-dc20-9b37-a727-91b086ff99e6@gmail.com> Message-ID: Thanks Nils for the input . On Fri, Apr 21, 2017 at 7:19 PM, Nils Gladitz wrote: > On 04/21/2017 03:40 PM, aishwarya selvaraj wrote: > > add_library(fftw STATIC IMPORTED) > > [...] > > TARGET_LINK_LIBRARIES(prose fftw ) > > [...] > > make[2]: *** No rule to make target `fftw-NOTFOUND', needed by `prose'. > Stop. > > > You are creating an IMPORTED target "fftw" but you aren't populating its > IMPORTED_LOCATION [1] (or IMPORTED_LOCATION_ [2]) target property. > Without it CMake does not know what on disk library file to link to. > > You can set target properties with set_property() or > set_target_properties(). > > Nils > > [1] https://cmake.org/cmake/help/latest/prop_tgt/IMPORTED_LOCATION.html > [2] https://cmake.org/cmake/help/latest/prop_tgt/IMPORTED_ > LOCATION_CONFIG.html > -- Regards, Aishwarya Selvaraj -------------- next part -------------- An HTML attachment was scrubbed... URL: From volker.enderlein at ifm-chemnitz.de Fri Apr 21 10:09:12 2017 From: volker.enderlein at ifm-chemnitz.de (Volker Enderlein) Date: Fri, 21 Apr 2017 16:09:12 +0200 Subject: [CMake] Need code review of my android toolchain file In-Reply-To: References: Message-ID: <4922e8ea-82c8-7522-536a-611ab1fec337@ifm-chemnitz.de> Hi Robert, I would use file(TO_NATIVE_PATH "${_dir}" _dir) and file(TO_CMAKE_PATH "${_dir}" _dir) hope that helps, Cheers, Volker Am 21/04/2017 um 15:45 schrieb Robert Dailey: > I guess the only feedback I really would like is if the path > normalization I'm doing for CMAKE_ANDROID_NDK is necessary (converting > backslashes to forward slashes). Will CMake translate the backslashes > properly? > > Sometimes I use CMAKE_ANDROID_NDK in custom commands and custom > targets to build absolute paths to items in the NDK. > > On Tue, Apr 18, 2017 at 9:45 PM, Robert Dailey wrote: >> I'm trying to follow best practices where I can, but the trouble is >> I'm not aware of any. So I want to post my android.toolchain.cmake >> file here, with the hope that I can get some pointers. >> >> The main thing I want to understand is when it is appropriate to >> require cache variables be set via command line argument (-D) or via >> the toolchain file itself. Here is what is in my toolchain right now: >> >> >> set(CMAKE_SYSTEM_NAME Android) >> set(CMAKE_SYSTEM_VERSION 15) # API level >> set(CMAKE_ANDROID_ARCH_ABI armeabi-v7a) >> set(CMAKE_ANDROID_STL_TYPE c++_static) >> set(CMAKE_ANDROID_NDK_TOOLCHAIN_VERSION clang) >> >> string(REGEX REPLACE "\\\\" "/" ndk_path "$ENV{ANDROID_NDK}") >> set(CMAKE_ANDROID_NDK ${ndk_path}) >> >> unset(ndk_path) >> >> >> >> My idea here is to provide a different toolchain file per specific NDK >> configuration. For example, I need to build my native libraries for >> both x86 and ARM platforms, so I would use 2 CMAKE_BINARY_DIR, each >> configured using a different toolchain: >> >> x86 would use "android.toolchain.x86.cmake" >> ARM would use "android.toolchain.arm.cmake" >> >> Something like that. Is this best practice? What other advice would you offer? >> >> Thanks in advance. -- Volker Enderlein Institut f?r Mechatronik e.V. Phone: +49 (0)371 531 19651 Reichenhainer Strasse 88 Fax: +49 (0)371 531 19699 D-09126 Chemnitz Mail: volker.enderlein at ifm-chemnitz.de www.ifm-chemnitz.de Vorstand: Prof. Dr.-Ing. Welf-Guntram Drossel (Vorsitz) Dipl.-Ing. Heiko Freudenberg (Gesch?ftsf?hrer) Amtsgericht Chemnitz VR 713 Ust.-IdNr. DE 159285348 From alex_chen at filemaker.com Fri Apr 21 13:28:08 2017 From: alex_chen at filemaker.com (Alex Chen) Date: Fri, 21 Apr 2017 10:28:08 -0700 Subject: [CMake] Overriding the include path, library path of OpenSSL, Zlib and libcurl In-Reply-To: References: <31918E16-09E5-4920-B25C-CBAF60D37FB6@filemaker.com> Message-ID: <49F4E43B-163E-408F-B2C5-FB36FA68CA4F@filemaker.com> Thanks for the help.? I will try that. Alex Chen From: Michael Ellery Date: Thursday, April 20, 2017 at 8:13 PM To: Alex Chen Cc: CMake Subject: Re: [CMake] Overriding the include path, library path of OpenSSL, Zlib and libcurl It doesn?t look like that find module directly supports HINTS or PATHS, so you can try setting CMAKE_LIBRARY_PATH and CMAKE_INCLUDE_PATH (https://cmake.org/cmake/help/v3.7/variable/CMAKE_LIBRARY_PATH.html) before calling the curl finder. I think you can add to those variables whatever paths are appropriate to search for CURL on your systems. -Mike On Apr 20, 2017, at 6:06 PM, Alex Chen wrote: The source code I want to compile on Linux uses ?FindOpenSSL?, ?FindZLIB?, and ?FindCURL? to resolve the paths of these libraries. However, I have newer version of these libraries in different locations. How to I override these to use my paths? I am able to use OPENSSL_ROOT_DIR, from FindOpenSSL module, and ZLIB_ROOT, from FindZLIB module, to override the paths. But I cannot find anything in FindCURL module to override the path of libcurl. Alex Chen -- 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 ope-devel at gmx.de Fri Apr 21 13:29:37 2017 From: ope-devel at gmx.de (Olaf Peter) Date: Fri, 21 Apr 2017 19:29:37 +0200 Subject: [CMake] add_custom_command on test input files Message-ID: Hello, for my project I have a sub dir with test case which feeds the tests '*.input' and allows to check to output '*.expected'. For documentation purpose, I have a python script which generates a TestMatrix.rst file. Using CMake I have: dir structure: $root/{src,include,utils,test} test/CMakeLists.txt project(test LANGUAGES CXX) ... set(TEST_MATRIX_GENERATOR ${CMAKE_CURRENT_SOURCE_DIR}/../utils/gen_test_matrix.py) set(TEST_MATRIX_GENERATOR_TARGET ${CMAKE_CURRENT_SOURCE_DIR}/test_matrix.rst) file(GLOB_RECURSE TEST_CASE_FILES LIST_DIRECTORIES true "${CMAKE_CURRENT_SOURCE_DIR}/test_case/" "*.expected" ) add_custom_command( TARGET ${PROJECT_NAME} POST_BUILD COMMAND ${TEST_MATRIX_GENERATOR} ${CMAKE_CURRENT_SOURCE_DIR} > ${TEST_MATRIX_GENERATOR_TARGET} DEPENDS ${TEST_MATRIX_GENERATOR} ${TEST_CASE_FILES} BYPRODUCT ${TEST_MATRIX_GENERATOR_TARGET} COMMENT "Generate TestCase Matrix (RST)" ) set_source_files_properties( ${TEST_MATRIX_GENERATOR_TARGET} PROPERTIES GENERATED TRUE ) but I assume, this isn't clever since it doesn't depend on the test_case dirs/files as I've seen so far. Changes in these file doesn't trigger the generation process, removing the ${TEST_MATRIX_GENERATOR_TARGET} doesn't recreate it. How to get it working/generating on each changes (additions) of the files/dirs in test_case? Thanks, Olaf From alex_chen at filemaker.com Fri Apr 21 13:58:29 2017 From: alex_chen at filemaker.com (Alex Chen) Date: Fri, 21 Apr 2017 10:58:29 -0700 Subject: [CMake] Overriding the include path, library path of OpenSSL, Zlib and libcurl In-Reply-To: <49F4E43B-163E-408F-B2C5-FB36FA68CA4F@filemaker.com> References: <31918E16-09E5-4920-B25C-CBAF60D37FB6@filemaker.com> <49F4E43B-163E-408F-B2C5-FB36FA68CA4F@filemaker.com> Message-ID: <4F3E147B-8C29-4095-95CF-852739230D85@filemaker.com> Although cmake uses the path I supplied for OpenSSL and Zlib, I do not see the ?I flag being used in compiling the code. (I set VERBOSE=1 to make to see what it does.) When I run ?ldd? against the resulting .so files, reference to libssl.so or libcrypto.so is empty, i.e ?libssl.so => not found?, but libz.so still links to /lib64/libz.so. (It seems to ignore the fact it does find a new path of zlib.) How to I set the linker flag, i.e. ?L and ?Wl,-rpath=$myLibPath ? Alex Chen From: CMake on behalf of Alex Chen Date: Friday, April 21, 2017 at 10:28 AM To: CMake Subject: Re: [CMake] Overriding the include path, library path of OpenSSL, Zlib and libcurl Thanks for the help. I will try that. Alex Chen From: Michael Ellery Date: Thursday, April 20, 2017 at 8:13 PM To: Alex Chen Cc: CMake Subject: Re: [CMake] Overriding the include path, library path of OpenSSL, Zlib and libcurl It doesn?t look like that find module directly supports HINTS or PATHS, so you can try setting CMAKE_LIBRARY_PATH and CMAKE_INCLUDE_PATH (https://cmake.org/cmake/help/v3.7/variable/CMAKE_LIBRARY_PATH.html) before calling the curl finder. I think you can add to those variables whatever paths are appropriate to search for CURL on your systems. -Mike On Apr 20, 2017, at 6:06 PM, Alex Chen wrote: The source code I want to compile on Linux uses ?FindOpenSSL?, ?FindZLIB?, and ?FindCURL? to resolve the paths of these libraries. However, I have newer version of these libraries in different locations. How to I override these to use my paths? I am able to use OPENSSL_ROOT_DIR, from FindOpenSSL module, and ZLIB_ROOT, from FindZLIB module, to override the paths. But I cannot find anything in FindCURL module to override the path of libcurl. Alex Chen -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake -------------- next part -------------- An HTML attachment was scrubbed... URL: From mellery451 at gmail.com Fri Apr 21 14:03:56 2017 From: mellery451 at gmail.com (Michael Ellery) Date: Fri, 21 Apr 2017 11:03:56 -0700 Subject: [CMake] Overriding the include path, library path of OpenSSL, Zlib and libcurl In-Reply-To: <4F3E147B-8C29-4095-95CF-852739230D85@filemaker.com> References: <31918E16-09E5-4920-B25C-CBAF60D37FB6@filemaker.com> <49F4E43B-163E-408F-B2C5-FB36FA68CA4F@filemaker.com> <4F3E147B-8C29-4095-95CF-852739230D85@filemaker.com> Message-ID: <072AC783-CD83-42BE-87EC-13D96545F4EA@gmail.com> after find_package is invoked, several variables will be set. You use these to augment your compiler and linker information, e.g.: target_include_directories(mytarget $ZLIB_INCLUDE_DIRS) target_link_libraries(mytarget $ZLIB_LIBRARIES) ?and so on for other modules you find (OpenSSL, for example). You can also choose to add the include paths ?globally? using include_directories(), but it?s usually considered best practice to modify individual target properties where possible. -Mike .. > On Apr 21, 2017, at 10:58 AM, Alex Chen wrote: > > Although cmake uses the path I supplied for OpenSSL and Zlib, I do not see the ?I flag being used in compiling the code. (I set VERBOSE=1 to make to see what it does.) > When I run ?ldd? against the resulting .so files, reference to libssl.so or libcrypto.so is empty, i.e ?libssl.so => not found?, but libz.so still links to /lib64/libz.so. (It seems to ignore the fact it does find a new path of zlib.) > > How to I set the linker flag, i.e. ?L and ?Wl,-rpath=$myLibPath ? > > Alex Chen > > From: CMake on behalf of Alex Chen > Date: Friday, April 21, 2017 at 10:28 AM > To: CMake > Subject: Re: [CMake] Overriding the include path, library path of OpenSSL, Zlib and libcurl > > Thanks for the help. I will try that. > > Alex Chen > > From: Michael Ellery > Date: Thursday, April 20, 2017 at 8:13 PM > To: Alex Chen > Cc: CMake > Subject: Re: [CMake] Overriding the include path, library path of OpenSSL, Zlib and libcurl > > It doesn?t look like that find module directly supports HINTS or PATHS, so you can try setting CMAKE_LIBRARY_PATH and CMAKE_INCLUDE_PATH (https://cmake.org/cmake/help/v3.7/variable/CMAKE_LIBRARY_PATH.html) before calling the curl finder. I think you can add to those variables whatever paths are appropriate to search for CURL on your systems. > > -Mike > >> On Apr 20, 2017, at 6:06 PM, Alex Chen wrote: >> The source code I want to compile on Linux uses ?FindOpenSSL?, ?FindZLIB?, and ?FindCURL? to resolve the paths of these libraries. >> However, I have newer version of these libraries in different locations. How to I override these to use my paths? >> I am able to use OPENSSL_ROOT_DIR, from FindOpenSSL module, and ZLIB_ROOT, from FindZLIB module, to override the paths. >> But I cannot find anything in FindCURL module to override the path of libcurl. >> >> >> Alex Chen >> -- >> 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_FAQKitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake From rcdailey.lists at gmail.com Fri Apr 21 17:48:22 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Fri, 21 Apr 2017 16:48:22 -0500 Subject: [CMake] Trouble with FindPNG module Message-ID: I'm running CMake 3.8.0 on Ubuntu 14. I invoke the following: find_package(PNG REQUIRED) Which gives me the output in CMake: Could NOT find PNG (missing: PNG_LIBRARY) (found version "1.2.50") The CMakeCache.txt file has these variables set: PNG_LIBRARY_DEBUG:FILEPATH=PNG_LIBRARY_DEBUG-NOTFOUND PNG_LIBRARY_RELEASE:FILEPATH=PNG_LIBRARY_RELEASE-NOTFOUND PNG_PNG_INCLUDE_DIR:PATH=/usr/include So it found the headers, but not the libs. Why did it not find the libs? Note that my version of Ubuntu is 64-bit, and I've installed the 32-bit libs like so: $ sudo apt-get install libpng12-dev:i386 Would the find module be confused because it is trying to find the 64-bit library? What's the issue? From tgnottingham at gmail.com Sat Apr 22 21:16:41 2017 From: tgnottingham at gmail.com (Tyson Nottingham) Date: Sat, 22 Apr 2017 18:16:41 -0700 Subject: [CMake] check_c_source_compiles caching pitfalls Message-ID: The result of check_c_source_compiles and similar commands (check_c_source_runs, check_cxx_source_compiles, etc.) is cached by the variable name passed in. This caching makes those commands and ones that depend on them easy to misuse. For example, set(potential_flags -Wall -badflag) foreach(flag ${potential_flags}) check_cxx_compiler_flag(${flag} has_flag) if(has_flag) set(flags "${flags} ${flag}") endif(has_flag) endforeach(flag) Since the variable name "has_flag" is used on every loop iteration, the result of check_cxx_compiler_flag is the same on every iteration (because it uses check_cxx_source_compiles internally, which caches by variable name). Supposing -Wall is a valid flag, flags will be "-Wall -badflag", even if -badflag isn't valid. The obvious workaround is to use different variable names for each check. For example: set(potential_flags -Wall -badflag) set(flag_test_counter 0) foreach(flag ${potential_flags}) math(EXPR flag_test_counter "${flag_test_counter} + 1") set(flag_test "flag_test_${flag_test_counter}") check_cxx_compiler_flag(${flag} ${flag_test}) if(${flag_test}) set(flags "${flags} ${flag}") endif(${flag_test}) endforeach(flag) But there is still a problem with this. If I run this once, flags will be "-Wall". If I change potential_flags to "-Wall -Werror" (supposing -Werror is valid) and run it again, flags will still be "-Wall" because of the caching. The test on -Werror will use the results for the test on -badflag. This problem can just as easily occur in simpler situations. check_cxx_compiler_flag(-Wall has_flag) if(has_flag) message("yep") endif(has_flag) If I run this once, change -Wall to -badflag, and run it again, I'll still enter the if block. The obvious workaround is to delete the build files after changing potential_flags. However, all of this seems pretty error prone. I'm new to CMake, so I may be missing something obvious. Is there an obvious non-error-prone solution to this? In future versions, can these commands take arguments that say not to use the cached result (or something along those lines)? At the very least, the documentation for the commands and those that depend on them could mention these pitfalls. -------------- next part -------------- An HTML attachment was scrubbed... URL: From irwin at beluga.phys.uvic.ca Sat Apr 22 21:48:56 2017 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Sat, 22 Apr 2017 18:48:56 -0700 (PDT) Subject: [CMake] check_c_source_compiles caching pitfalls In-Reply-To: References: Message-ID: On 2017-04-22 18:16-0700 Tyson Nottingham wrote: > The result of check_c_source_compiles and similar commands > (check_c_source_runs, check_cxx_source_compiles, etc.) is cached by the > variable name passed in. This caching makes those commands and ones that > depend on them easy to misuse. To deal with cached variables that you want to reuse this way try the unset command within the loop. 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 post at hendrik-sattler.de Sun Apr 23 03:05:20 2017 From: post at hendrik-sattler.de (Hendrik Sattler) Date: Sun, 23 Apr 2017 09:05:20 +0200 Subject: [CMake] check_c_source_compiles caching pitfalls In-Reply-To: References: Message-ID: Am 23. April 2017 03:16:41 MESZ schrieb Tyson Nottingham : >The result of check_c_source_compiles and similar commands >(check_c_source_runs, check_cxx_source_compiles, etc.) is cached by the >variable name passed in. This caching makes those commands and ones >that >depend on them easy to misuse. > >For example, > >set(potential_flags -Wall -badflag) > >foreach(flag ${potential_flags}) > check_cxx_compiler_flag(${flag} has_flag) > if(has_flag) > set(flags "${flags} ${flag}") > endif(has_flag) >endforeach(flag) Try to use variables with a better naming. This will also solve your problem: has_flag_${flag} >Since the variable name "has_flag" is used on every loop iteration, the >result of check_cxx_compiler_flag is the same on every iteration >(because >it uses check_cxx_source_compiles internally, which caches by variable >name). Supposing -Wall is a valid flag, flags will be "-Wall -badflag", >even if -badflag isn't valid. Ask yourself WHY this is done! Rerunning cmake in a build tree should not repeat all those expensive tests. >The obvious workaround is to use different variable names for each >check. >For example: > >set(potential_flags -Wall -badflag) >set(flag_test_counter 0) > >foreach(flag ${potential_flags}) > math(EXPR flag_test_counter "${flag_test_counter} + 1") > set(flag_test "flag_test_${flag_test_counter}") > check_cxx_compiler_flag(${flag} ${flag_test}) > if(${flag_test}) > set(flags "${flags} ${flag}") > endif(${flag_test}) >endforeach(flag) > >But there is still a problem with this. If I run this once, flags will >be >"-Wall". If I change potential_flags to "-Wall -Werror" (supposing >-Werror >is valid) and run it again, flags will still be "-Wall" because of the >caching. The test on -Werror will use the results for the test on >-badflag. > >This problem can just as easily occur in simpler situations. > >check_cxx_compiler_flag(-Wall has_flag) > >if(has_flag) > message("yep") >endif(has_flag) > >If I run this once, change -Wall to -badflag, and run it again, I'll >still >enter the if block. > >The obvious workaround is to delete the build files after changing >potential_flags. > >However, all of this seems pretty error prone. I'm new to CMake, so I >may >be missing something obvious. Is there an obvious non-error-prone >solution >to this? In future versions, can these commands take arguments that say >not >to use the cached result (or something along those lines)? At the very >least, the documentation for the commands and those that depend on them >could mention these pitfalls. -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. From Robert.Bielik at dirac.com Mon Apr 24 07:28:21 2017 From: Robert.Bielik at dirac.com (Robert Bielik) Date: Mon, 24 Apr 2017 11:28:21 +0000 Subject: [CMake] Problem with Ninja on Windows Message-ID: <0eca1f12e8be4dab95e2c3e82543cfc5@hosted3-mb02.itm.host> Hi all, I've come to a problem with Ninja on Windows, but only when building for MSVC amd64 toolchain. With x86, it works OK. The error I get is: CMake Error: Error required internal CMake variable not set, cmake may be not be built correctly. Missing variable is: CMAKE_ASM_NASM_COMPILE_OBJECT It is boringssl (from the gRPC project) that needs NASM. But I find it odd that the x86 generator works, but not the amd64 one ? Any ideas what I should look for ? Regards /Robert From Robert.Bielik at dirac.com Mon Apr 24 07:35:58 2017 From: Robert.Bielik at dirac.com (Robert Bielik) Date: Mon, 24 Apr 2017 11:35:58 +0000 Subject: [CMake] Problem with Ninja on Windows In-Reply-To: <0eca1f12e8be4dab95e2c3e82543cfc5@hosted3-mb02.itm.host> References: <0eca1f12e8be4dab95e2c3e82543cfc5@hosted3-mb02.itm.host> Message-ID: <2f211b9622834fb0893b693edd0ce1db@hosted3-mb02.itm.host> I've found the culprit, in boringssl/crypto CMakeLists.txt there is: enable_language(ASM_NASM) If I remove this (since I don't use asm), it works on both x86 and amd64 (!) > -----Original Message----- > From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Robert > Bielik > Sent: den 24 april 2017 13:28 > To: Cmake at cmake.org > Subject: [CMake] Problem with Ninja on Windows > > Hi all, > > I've come to a problem with Ninja on Windows, but only when building for > MSVC amd64 toolchain. With x86, it works OK. The error I get is: > > CMake Error: Error required internal CMake variable not set, cmake may be > not be built correctly. > Missing variable is: > CMAKE_ASM_NASM_COMPILE_OBJECT > > It is boringssl (from the gRPC project) that needs NASM. But I find it odd that > the x86 generator works, but not the amd64 one ? > > Any ideas what I should look for ? > > Regards > /Robert > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake From rcdailey.lists at gmail.com Mon Apr 24 10:54:18 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Mon, 24 Apr 2017 09:54:18 -0500 Subject: [CMake] Trouble with FindPNG module In-Reply-To: References: Message-ID: Sorry to bump; any info on this? I'm completely blocked :-( On Fri, Apr 21, 2017 at 4:48 PM, Robert Dailey wrote: > I'm running CMake 3.8.0 on Ubuntu 14. I invoke the following: > > find_package(PNG REQUIRED) > > Which gives me the output in CMake: > > Could NOT find PNG (missing: PNG_LIBRARY) (found version "1.2.50") > > The CMakeCache.txt file has these variables set: > > PNG_LIBRARY_DEBUG:FILEPATH=PNG_LIBRARY_DEBUG-NOTFOUND > PNG_LIBRARY_RELEASE:FILEPATH=PNG_LIBRARY_RELEASE-NOTFOUND > PNG_PNG_INCLUDE_DIR:PATH=/usr/include > > So it found the headers, but not the libs. Why did it not find the > libs? Note that my version of Ubuntu is 64-bit, and I've installed the > 32-bit libs like so: > > $ sudo apt-get install libpng12-dev:i386 > > Would the find module be confused because it is trying to find the > 64-bit library? What's the issue? From ben.boeckel at kitware.com Mon Apr 24 11:02:27 2017 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 24 Apr 2017 11:02:27 -0400 Subject: [CMake] [cmake-developers] Trouble with FindPNG module In-Reply-To: References: Message-ID: <20170424150227.GA18124@megas.kitware.com> On Mon, Apr 24, 2017 at 09:54:18 -0500, Robert Dailey wrote: > On Fri, Apr 21, 2017 at 4:48 PM, Robert Dailey wrote: > > I'm running CMake 3.8.0 on Ubuntu 14. I invoke the following: > > > > find_package(PNG REQUIRED) > > > > Which gives me the output in CMake: > > > > Could NOT find PNG (missing: PNG_LIBRARY) (found version "1.2.50") > > > > The CMakeCache.txt file has these variables set: > > > > PNG_LIBRARY_DEBUG:FILEPATH=PNG_LIBRARY_DEBUG-NOTFOUND > > PNG_LIBRARY_RELEASE:FILEPATH=PNG_LIBRARY_RELEASE-NOTFOUND > > PNG_PNG_INCLUDE_DIR:PATH=/usr/include > > > > So it found the headers, but not the libs. Why did it not find the > > libs? Note that my version of Ubuntu is 64-bit, and I've installed the > > 32-bit libs like so: > > > > $ sudo apt-get install libpng12-dev:i386 What compiler are you using (what does CMake say it is?)? Does an `strace` of CMake configuring the project show anything interesting? `cmake --trace-expand`? --Ben From afuller at teradici.com Mon Apr 24 11:16:39 2017 From: afuller at teradici.com (Andrew Fuller) Date: Mon, 24 Apr 2017 15:16:39 +0000 Subject: [CMake] Trouble with FindPNG module In-Reply-To: References: , Message-ID: Where did the library get installed on your system? What's the value of CMAKE__LIBRARY_ARCHITECTURE? Since you're on a 64-bit system, I'd expect CMake to be looking for 64-bit libraries unless you've told it otherwise. ________________________________ From: CMake on behalf of Robert Dailey Sent: April 24, 2017 7:54:18 AM To: CMake; CMake Developers Subject: Re: [CMake] Trouble with FindPNG module Sorry to bump; any info on this? I'm completely blocked :-( On Fri, Apr 21, 2017 at 4:48 PM, Robert Dailey wrote: > I'm running CMake 3.8.0 on Ubuntu 14. I invoke the following: > > find_package(PNG REQUIRED) > > Which gives me the output in CMake: > > Could NOT find PNG (missing: PNG_LIBRARY) (found version "1.2.50") > > The CMakeCache.txt file has these variables set: > > PNG_LIBRARY_DEBUG:FILEPATH=PNG_LIBRARY_DEBUG-NOTFOUND > PNG_LIBRARY_RELEASE:FILEPATH=PNG_LIBRARY_RELEASE-NOTFOUND > PNG_PNG_INCLUDE_DIR:PATH=/usr/include > > So it found the headers, but not the libs. Why did it not find the > libs? Note that my version of Ubuntu is 64-bit, and I've installed the > 32-bit libs like so: > > $ sudo apt-get install libpng12-dev:i386 > > Would the find module be confused because it is trying to find the > 64-bit library? What's the issue? -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcdailey.lists at gmail.com Mon Apr 24 13:20:27 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Mon, 24 Apr 2017 12:20:27 -0500 Subject: [CMake] [cmake-developers] Trouble with FindPNG module In-Reply-To: <20170424150227.GA18124@megas.kitware.com> References: <20170424150227.GA18124@megas.kitware.com> Message-ID: On Mon, Apr 24, 2017 at 10:02 AM, Ben Boeckel wrote: > On Mon, Apr 24, 2017 at 09:54:18 -0500, Robert Dailey wrote: >> On Fri, Apr 21, 2017 at 4:48 PM, Robert Dailey wrote: >> > I'm running CMake 3.8.0 on Ubuntu 14. I invoke the following: >> > >> > find_package(PNG REQUIRED) >> > >> > Which gives me the output in CMake: >> > >> > Could NOT find PNG (missing: PNG_LIBRARY) (found version "1.2.50") >> > >> > The CMakeCache.txt file has these variables set: >> > >> > PNG_LIBRARY_DEBUG:FILEPATH=PNG_LIBRARY_DEBUG-NOTFOUND >> > PNG_LIBRARY_RELEASE:FILEPATH=PNG_LIBRARY_RELEASE-NOTFOUND >> > PNG_PNG_INCLUDE_DIR:PATH=/usr/include >> > >> > So it found the headers, but not the libs. Why did it not find the >> > libs? Note that my version of Ubuntu is 64-bit, and I've installed the >> > 32-bit libs like so: >> > >> > $ sudo apt-get install libpng12-dev:i386 > > What compiler are you using (what does CMake say it is?)? Does an > `strace` of CMake configuring the project show anything interesting? > `cmake --trace-expand`? It's using Gcc 4.9 because I told it to via toolchain file: -- The C compiler identification is GNU 4.9.4 -- The CXX compiler identification is GNU 4.9.4 -- Check for working C compiler: /usr/bin/gcc-4.9 -- Check for working C compiler: /usr/bin/gcc-4.9 -- 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/g++-4.9 -- Check for working CXX compiler: /usr/bin/g++-4.9 -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done Via the following toolchain file contents: set( CMAKE_SYSTEM_NAME Linux ) set( CMAKE_SYSTEM_VERSION 1 ) set( CMAKE_SYSTEM_PROCESSOR "i686" ) set( CMAKE_C_COMPILER gcc-4.9 ) set( CMAKE_CXX_COMPILER g++-4.9 ) set( CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -m32" ) set( CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -m32" ) I'm not sure how to use strace. I tried following instructions I found on the [CMake Performance Tips][1] page, but this isn't working. My generate command has a lot of options, so I use a helper shell script to generate. strace seems to not work well when using a shell script. Trace also doesn't show much useful. Could you give exact command line I can run to get the info you need? Where possible, I install everything via apt-get for the 4.9 toolchain. For libpng this was not an option as far as I could tell, so I'm not sure what implications that has on find_package() behavior. From rcdailey.lists at gmail.com Mon Apr 24 13:22:53 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Mon, 24 Apr 2017 12:22:53 -0500 Subject: [CMake] Trouble with FindPNG module In-Reply-To: References: Message-ID: The output is: x86_64-linux-gnu How can I tell CMake to look for 32-bit libraries? I would like to force this from my toolchain file (which I posted a few minutes ago) On Mon, Apr 24, 2017 at 10:16 AM, Andrew Fuller wrote: > Where did the library get installed on your system? What's the value of > CMAKE__LIBRARY_ARCHITECTURE? > > > Since you're on a 64-bit system, I'd expect CMake to be looking for 64-bit > libraries unless you've told it otherwise. > > ________________________________ > From: CMake on behalf of Robert Dailey > > Sent: April 24, 2017 7:54:18 AM > To: CMake; CMake Developers > Subject: Re: [CMake] Trouble with FindPNG module > > Sorry to bump; any info on this? I'm completely blocked :-( > > On Fri, Apr 21, 2017 at 4:48 PM, Robert Dailey > wrote: >> I'm running CMake 3.8.0 on Ubuntu 14. I invoke the following: >> >> find_package(PNG REQUIRED) >> >> Which gives me the output in CMake: >> >> Could NOT find PNG (missing: PNG_LIBRARY) (found version "1.2.50") >> >> The CMakeCache.txt file has these variables set: >> >> PNG_LIBRARY_DEBUG:FILEPATH=PNG_LIBRARY_DEBUG-NOTFOUND >> PNG_LIBRARY_RELEASE:FILEPATH=PNG_LIBRARY_RELEASE-NOTFOUND >> PNG_PNG_INCLUDE_DIR:PATH=/usr/include >> >> So it found the headers, but not the libs. Why did it not find the >> libs? Note that my version of Ubuntu is 64-bit, and I've installed the >> 32-bit libs like so: >> >> $ sudo apt-get install libpng12-dev:i386 >> >> Would the find module be confused because it is trying to find the >> 64-bit library? What's the issue? > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake From rcdailey.lists at gmail.com Mon Apr 24 13:35:15 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Mon, 24 Apr 2017 12:35:15 -0500 Subject: [CMake] Trouble with FindPNG module In-Reply-To: References: Message-ID: Interestingly, the changes to my toolchain made below work: set( CMAKE_SYSTEM_NAME Linux ) set( CMAKE_SYSTEM_VERSION 1 ) set( CMAKE_SYSTEM_PROCESSOR i386 ) set( CMAKE_C_COMPILER gcc-4.9 ) set( CMAKE_CXX_COMPILER g++-4.9 ) set( CMAKE_C_COMPILER_ARG1 -m32 ) set( CMAKE_CXX_COMPILER_ARG1 -m32 ) The only change here is that I'm using CMAKE_C_COMPILER_ARG1 and CMAKE_CXX_COMPILER_ARG1. These are not documented anywhere. I only found out about them from a post from Bill Hoffman (which I have lost the URL to). Is this the correct toolchain? At least find_package() is properly finding 32-bit libraries now, so I am happy. Should CMAKE_SYSTEM_PROCESSOR be i386 or i686? On Mon, Apr 24, 2017 at 12:22 PM, Robert Dailey wrote: > The output is: > > x86_64-linux-gnu > > How can I tell CMake to look for 32-bit libraries? I would like to > force this from my toolchain file (which I posted a few minutes ago) > > On Mon, Apr 24, 2017 at 10:16 AM, Andrew Fuller wrote: >> Where did the library get installed on your system? What's the value of >> CMAKE__LIBRARY_ARCHITECTURE? >> >> >> Since you're on a 64-bit system, I'd expect CMake to be looking for 64-bit >> libraries unless you've told it otherwise. >> >> ________________________________ >> From: CMake on behalf of Robert Dailey >> >> Sent: April 24, 2017 7:54:18 AM >> To: CMake; CMake Developers >> Subject: Re: [CMake] Trouble with FindPNG module >> >> Sorry to bump; any info on this? I'm completely blocked :-( >> >> On Fri, Apr 21, 2017 at 4:48 PM, Robert Dailey >> wrote: >>> I'm running CMake 3.8.0 on Ubuntu 14. I invoke the following: >>> >>> find_package(PNG REQUIRED) >>> >>> Which gives me the output in CMake: >>> >>> Could NOT find PNG (missing: PNG_LIBRARY) (found version "1.2.50") >>> >>> The CMakeCache.txt file has these variables set: >>> >>> PNG_LIBRARY_DEBUG:FILEPATH=PNG_LIBRARY_DEBUG-NOTFOUND >>> PNG_LIBRARY_RELEASE:FILEPATH=PNG_LIBRARY_RELEASE-NOTFOUND >>> PNG_PNG_INCLUDE_DIR:PATH=/usr/include >>> >>> So it found the headers, but not the libs. Why did it not find the >>> libs? Note that my version of Ubuntu is 64-bit, and I've installed the >>> 32-bit libs like so: >>> >>> $ sudo apt-get install libpng12-dev:i386 >>> >>> Would the find module be confused because it is trying to find the >>> 64-bit library? What's the issue? >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake From afuller at teradici.com Mon Apr 24 13:35:23 2017 From: afuller at teradici.com (Andrew Fuller) Date: Mon, 24 Apr 2017 17:35:23 +0000 Subject: [CMake] Trouble with FindPNG module In-Reply-To: References: , Message-ID: Try adding this to your toolchain file: set( CMAKE_C_LIBRARY_ARCHITECTURE "i386-linux-gnu" ) set( CMAKE_CXX_LIBRARY_ARCHITECTURE "i386-linux-gnu" ) ________________________________ From: rcdailey at gmail.com on behalf of Robert Dailey Sent: April 24, 2017 10:22:53 AM To: Andrew Fuller Cc: CMake Subject: Re: [CMake] Trouble with FindPNG module The output is: x86_64-linux-gnu How can I tell CMake to look for 32-bit libraries? I would like to force this from my toolchain file (which I posted a few minutes ago) On Mon, Apr 24, 2017 at 10:16 AM, Andrew Fuller wrote: > Where did the library get installed on your system? What's the value of > CMAKE__LIBRARY_ARCHITECTURE? > > > Since you're on a 64-bit system, I'd expect CMake to be looking for 64-bit > libraries unless you've told it otherwise. > > ________________________________ > From: CMake on behalf of Robert Dailey > > Sent: April 24, 2017 7:54:18 AM > To: CMake; CMake Developers > Subject: Re: [CMake] Trouble with FindPNG module > > Sorry to bump; any info on this? I'm completely blocked :-( > > On Fri, Apr 21, 2017 at 4:48 PM, Robert Dailey > wrote: >> I'm running CMake 3.8.0 on Ubuntu 14. I invoke the following: >> >> find_package(PNG REQUIRED) >> >> Which gives me the output in CMake: >> >> Could NOT find PNG (missing: PNG_LIBRARY) (found version "1.2.50") >> >> The CMakeCache.txt file has these variables set: >> >> PNG_LIBRARY_DEBUG:FILEPATH=PNG_LIBRARY_DEBUG-NOTFOUND >> PNG_LIBRARY_RELEASE:FILEPATH=PNG_LIBRARY_RELEASE-NOTFOUND >> PNG_PNG_INCLUDE_DIR:PATH=/usr/include >> >> So it found the headers, but not the libs. Why did it not find the >> libs? Note that my version of Ubuntu is 64-bit, and I've installed the >> 32-bit libs like so: >> >> $ sudo apt-get install libpng12-dev:i386 >> >> Would the find module be confused because it is trying to find the >> 64-bit library? What's the issue? > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Mon Apr 24 13:42:17 2017 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 24 Apr 2017 13:42:17 -0400 Subject: [CMake] [cmake-developers] Trouble with FindPNG module In-Reply-To: References: <20170424150227.GA18124@megas.kitware.com> Message-ID: <20170424174217.GA8585@megas.kitware.com> On Mon, Apr 24, 2017 at 12:20:27 -0500, Robert Dailey wrote: > -- The C compiler identification is GNU 4.9.4 > -- The CXX compiler identification is GNU 4.9.4 > -- Check for working C compiler: /usr/bin/gcc-4.9 > -- Check for working C compiler: /usr/bin/gcc-4.9 -- 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/g++-4.9 > -- Check for working CXX compiler: /usr/bin/g++-4.9 -- works > -- Detecting CXX compiler ABI info > -- Detecting CXX compiler ABI info - done > -- Detecting CXX compile features > -- Detecting CXX compile features - done Does the information in the CMakeFiles/$cmake_version directory contain anything indicating that it's detecting the compiler as 64-bit? > I'm not sure how to use strace. I tried following instructions I found > on the [CMake Performance Tips][1] page, but this isn't working. My > generate command has a lot of options, so I use a helper shell script > to generate. strace seems to not work well when using a shell script. > Trace also doesn't show much useful. Could you give exact command line > I can run to get the info you need? Sorry, it's such a common tool I use, I forget others are new to it :) . Here's how I'd use it to debug this: strace -s 10000 -e file -o cmake.strace.log $cmake_command If your cmake command is a script that later launches CMake, you can give strace `-f` to have it also trace any child processes made by the command. In the resulting log file, you'll see syscalls CMake is making. searching for the png header/library searching area shouldn't be too hard. Is it looking in anything resembling the right paths? --Ben From fancypantsorama at gmail.com Mon Apr 24 15:56:14 2017 From: fancypantsorama at gmail.com (Chris Russo) Date: Mon, 24 Apr 2017 15:56:14 -0400 Subject: [CMake] Building with cmake 3.6.2 need 3.7.2 or newer!! In-Reply-To: References: Message-ID: <2eba94ec-cd45-d94b-aa61-a7fe0b75e176@gmail.com> Greetings- Well this should be simple right? I have Windows 10 64 bit. Visual Studio Community 2015. It shows that my version on a certain build is cmake 3.6.2. I have tried to download the latest and greatest set the path and no luck. where is, which, find, search looking all over the file system I cannot find cmake 3.6.2 at all. I am trying to figure out what application actually installed cmake 3.6.2 and I cannot figure it out. I haven't looked into regedit.exe because I just thought I should reach out to the experts on this issue. So the real question here is. Maybe I don't really care about where cmake 3.6.2 lives. I would just like to upgrade to 3.7.2 or later. Set the path as the installer does and use Git Bash shell to invoke cmake 3.7.2 or greater. Could you please tell me my simplest option. I hope my cmake isn't on your system. If you know what I mean. LOL!! Thanks in advance. Any help would be greatly appreciated. If you want to see where is, or which from Git Bash Shell I will be mre than happy to provide it. Regards- Chris Russo From fancypantsorama at gmail.com Mon Apr 24 15:57:48 2017 From: fancypantsorama at gmail.com (Chris Russo) Date: Mon, 24 Apr 2017 15:57:48 -0400 Subject: [CMake] Building with cmake 3.6.2 need 3.7.2 or newer!! In-Reply-To: <2eba94ec-cd45-d94b-aa61-a7fe0b75e176@gmail.com> References: <2eba94ec-cd45-d94b-aa61-a7fe0b75e176@gmail.com> Message-ID: <71281832-5fd3-85e0-5c10-3f70058f9c85@gmail.com> On 4/24/2017 3:56 PM, Chris Russo wrote: > Greetings- > > Well this should be simple right? I have Windows 10 64 bit. Visual > Studio Community 2015. It shows that my version on a certain build is > cmake 3.6.2. I have tried to download the latest and greatest set the > path and no luck. > > where is, which, find, search looking all over the file system I > cannot find cmake 3.6.2 at all. I am trying to figure out what > application actually installed cmake 3.6.2 and I cannot figure it out. > I haven't looked into regedit.exe because I just thought I should > reach out to the experts on this issue. > > > So the real question here is. Maybe I don't really care about where > cmake 3.6.2 lives. I would just like to upgrade to 3.7.2 or later. Set > the path as the installer does and use Git Bash shell to invoke cmake > 3.7.2 or greater. > > Could you please tell me my simplest option. I hope my cmake isn't on > your system. If you know what I mean. LOL!! > > Thanks in advance. Any help would be greatly appreciated. If you want > to see where is, or which from Git Bash Shell I will be mre than happy > to provide it. > > > Regards- > > > Chris Russo > > > From steffen.dettmer at gmail.com Wed Apr 26 04:12:32 2017 From: steffen.dettmer at gmail.com (Steffen Dettmer) Date: Wed, 26 Apr 2017 10:12:32 +0200 Subject: [CMake] CMAKE_BUILD_TYPE does not work in CMAKE_TOOLCHAIN_FILE - how to proceed? Message-ID: Hi, I'm new to cmake and we started using it to build proprietary embedded projects with a proprietary toolchain. We love the new build system's performance and its simplicity! Compared with what we were used to have, it is just superior in every aspect we met, really great! We hopefully based our approach correctly based on examples found in the web, stackoverflow answers, tutorials and of course the cmake documentation. For each embedded system toolchain (i.e. device, major lib versions etc) we wrote a CMAKE_TOOLCHAIN_FILE, which sets CMAKE_C_COMPILER, CMAKE_C_FLAGS and so on. We needed to use the force (CACHE STRING "" FORCE). What is left open is to select debug or release binaries. I googled a lot, but unfortunately did not find a solution, so I hope you please can point me into the right direction. I think a (non-working) example illustrates pretty clear what I would like to archive. Having in ToolchainFile.cmake: if(CMAKE_BUILD_TYPE MATCHES DEBUG) set(XYZ_LDPATH "${XYZ_LDPATH} -L${XYZ_PATH}/linux-arm-g++/Debug/") elseif(CMAKE_BUILD_TYPE MATCHES Release) set(XYZ_LDPATH "${XYZ_LDPATH} -L${XYZ_PATH}/linux-arm-g++/Release/") else(CMAKE_BUILD_TYPE MATCHES DEBUG) message(FATAL_ERROR "unknown CMAKE_BUILD_TYPE=\"${CMAKE_BUILD_TYPE}\"") endif(CMAKE_BUILD_TYPE MATCHES DEBUG) # ... set(CMAKE_EXE_LINKER_FLAGS_INIT "${CMAKE_EXE_LINKER_FLAGS_INIT} ${XYZ_LDPATH}") set(CMAKE_SHARED_LINKER_FLAGS_INIT "${CMAKE_SHARED_LINKER_FLAGS_INIT} ${XYZ_LDPATH}") This unfortunately does not work, because the Toolchain file is included / executed multiple times and at least one inclusions have CMAKE_BUILD_TYPE empty. --trace shows that some CMake own file overwrites it. Do you have any hint how to do this correctly? Some workaround? Should we somehow save the value in an own variable and use this own variable if set (if this is possible at all)? Or are we supposed to have a different toolchain file for Debug and Release (would double the number of files)? We could also consider adding an own "-DXYZ_CMAKE_BUILD_TYPE=Debug" variable, would this be suited? What would be the best and "most standard" way to handle Debug and Release libraries in an own toolchain? Thank you for your time reading this! Best regards, Steffen From eric.noulard at gmail.com Wed Apr 26 06:45:35 2017 From: eric.noulard at gmail.com (Eric Noulard) Date: Wed, 26 Apr 2017 12:45:35 +0200 Subject: [CMake] CTest: Running test depending on a commit/change Message-ID: Is there any way to ask ctest run the set of tests impacted by a commit/change ? Or may be asking ctest to run only the tests that were built no later than say 3 min. ago. The use case is simple. I do some modification in my code call the build tool (ninja in my case) and I want ctest to only run the freshly rebuilt tests. Ideally all the tests depending on the freshly rebuilt items. Let's says for simplification that all my test are binaries built in the changed source tree. In fact ninja already knows how to rebuilt those binaries and it does it well. How may I teach ctest to run those? -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.weir at wesio.co.uk Thu Apr 27 08:42:42 2017 From: james.weir at wesio.co.uk (Wesio) Date: Thu, 27 Apr 2017 05:42:42 -0700 (MST) Subject: [CMake] iOS IPA Creation Xcode 8.3.x Message-ID: <1493296962483-7595423.post@n2.nabble.com> We extensively use CMake in one of our projects and have been successfully using add_executable with MACOSX_BUNDLE to produce iOS .app artefacts and then using a custom target to run (via xcrun) PackageApplication to transform the .app to a .ipa. Unfortunately with Xcode 8.3.x PackageApplication has now been removed in favour of xcodebuild and -exportArchive, however issuing the new commands causes a rebuild in a different folder which given the size of our project is very slow. Is there a correct way to produce the xcarchive using cmake (and subsequently the .ipa) or do I need to persevere trying to get this to work using custom targets? Thanks :) -- View this message in context: http://cmake.3232098.n2.nabble.com/iOS-IPA-Creation-Xcode-8-3-x-tp7595423.html Sent from the CMake mailing list archive at Nabble.com. From alex_chen at filemaker.com Thu Apr 27 20:14:07 2017 From: alex_chen at filemaker.com (Alex Chen) Date: Thu, 27 Apr 2017 17:14:07 -0700 Subject: [CMake] How to set libcurl library path and the library name? Message-ID: Hi, ??? I am trying to build AWS CPP SDK for the iOS from downloaded source. The compilation seems to go well but it fails at link time.? My CMake invocation is /Applications/CMake.app/Contents/bin/cmake -Wno-dev -DBUILD_ONLY=s3;s3-encryption -DCMAKE_OSX_SYSROOT=/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS10.3.sdk -DCMAKE_OSX_ARCHITECTURES=arm64 -DCMAKE_SYSTEM_NAME=Darwin -DCMAKE_SHARED_LINKER_FLAGS=-framework Foundation -framework Security -DCMAKE_EXE_LINKER_FLAGS=-framework Foundation -framework Security -DCMAKE_PREFIX_PATH=/Volumes/Workspace/Prebuilt/Release-iphoneos/libcurl -DCMAKE_BUILD_TYPE=Release -DCMAKE_CXX_FLAGS=-O3 -DCMAKE_INSTALL_PREFIX=/Volumes/Workspace/AWS/CppSDK/1.0.101/iPhoneOS/arm64/Release -DBUILD_SHARED_LIBS=off -DCPP_STANDARD=14 -DCURL_INCLUDE_DIR=/Volumes/Workspace/Prebuilt/Release-iphoneos/libcurl/include64 -DCURL_LIBRARIES=libcurl_7.51 -DSTATIC_LINKING=1 -DTARGET_ARCH=Apple /Volumes/Workspace/FMSOURCE/Shared/AWS/CppSDK/aws-sdk-cpp-1.0.101 The output from CMake looks like it finds the include path of libcurl but no the library. -- Found Git: /usr/bin/git (found version "2.11.0 (Apple Git-81)") -- Building AWS libraries as static objects fatal: Not a git repository (or any parent up to mount point /Volumes/Workspace) Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set). -- Building project version: 1.0.101 -- The CXX compiler identification is AppleClang 8.1.0.8020042 -- Check for working CXX compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ -- Check for working CXX compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done -- Found ZLIB: /usr/lib/libz.dylib (found version "1.2.8") -- Zlib include directory: /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS10.3.sdk/usr/include -- Zlib library: /usr/lib/libz.dylib -- Encryption: CommonCrypto -- Http client: Curl -- Found CURL: /usr/lib/libcurl.dylib (found version "7.51.0") -- Curl include directory: /Volumes/Workspace/FMSOURCE/Shared/Prebuilt/Release-iphoneos/libcurl/include64 -- Curl library: /usr/lib/libcurl.dylib -- Considering s3 -- Considering s3-encryption -- The C compiler identification is AppleClang 8.1.0.8020042 -- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Detecting C compile features -- Detecting C compile features - done -- Updating version info to 1.0.101 -- Custom memory management disabled -- Configuring done -- Generating done The linking errors look like this: [ 92%] Linking CXX executable aws-cpp-sdk-s3-integration-tests ld: warning: ignoring file /usr/lib/libcurl.dylib, missing required architecture arm64 in file /usr/lib/libcurl.dylib (2 slices) Undefined symbols for architecture arm64: "_curl_easy_cleanup", referenced from: Aws::Http::CurlHandleContainer::~CurlHandleContainer() in libaws-cpp-sdk-core.a(CurlHandleContainer.cpp.o) "_curl_easy_getinfo", referenced from: Aws::Http::CurlHttpClient::MakeRequest(Aws::Http::HttpRequest&, Aws::Utils::RateLimits::RateLimiterInterface*, Aws::Utils::RateLimits::RateLimiterInterface*) const in libaws-cpp-sdk-core.a(CurlHttpClient.cpp.o) "_curl_easy_init", referenced from: Aws::Http::CurlHandleContainer::CheckAndGrowPool() in libaws-cpp-sdk-core.a(CurlHandleContainer.cpp.o) "_curl_easy_perform", referenced from: Aws::Http::CurlHttpClient::MakeRequest(Aws::Http::HttpRequest&, Aws::Utils::RateLimits::RateLimiterInterface*, Aws::Utils::RateLimits::RateLimiterInterface*) const in libaws-cpp-sdk-core.a(CurlHttpClient.cpp.o) "_curl_easy_reset", referenced from: Aws::Http::CurlHandleContainer::ReleaseCurlHandle(void*) in libaws-cpp-sdk-core.a(CurlHandleContainer.cpp.o) "_curl_easy_setopt", referenced from: SetOptCodeForHttpMethod(void*, Aws::Http::HttpRequest const&) in libaws-cpp-sdk-core.a(CurlHttpClient.cpp.o) Aws::Http::CurlHttpClient::MakeRequest(Aws::Http::HttpRequest&, Aws::Utils::RateLimits::RateLimiterInterface*, Aws::Utils::RateLimits::RateLimiterInterface*) const in libaws-cpp-sdk-core.a(CurlHttpClient.cpp.o) Aws::Http::CurlHandleContainer::CheckAndGrowPool() in libaws-cpp-sdk-core.a(CurlHandleContainer.cpp.o) Aws::Http::CurlHandleContainer::ReleaseCurlHandle(void*) in libaws-cpp-sdk-core.a(CurlHandleContainer.cpp.o) Aws::Http::CurlHandleContainer::SetDefaultOptionsOnHandle(void*) in libaws-cpp-sdk-core.a(CurlHandleContainer.cpp.o) "_curl_global_cleanup", referenced from: Aws::Http::CurlHttpClient::CleanupGlobalState() in libaws-cpp-sdk-core.a(CurlHttpClient.cpp.o) "_curl_global_init", referenced from: Aws::Http::CurlHttpClient::InitGlobalState() in libaws-cpp-sdk-core.a(CurlHttpClient.cpp.o) "_curl_slist_append", referenced from: Aws::Http::CurlHttpClient::MakeRequest(Aws::Http::HttpRequest&, Aws::Utils::RateLimits::RateLimiterInterface*, Aws::Utils::RateLimits::RateLimiterInterface*) const in libaws-cpp-sdk-core.a(CurlHttpClient.cpp.o) "_curl_slist_free_all", referenced from: Aws::Http::CurlHttpClient::MakeRequest(Aws::Http::HttpRequest&, Aws::Utils::RateLimits::RateLimiterInterface*, Aws::Utils::RateLimits::RateLimiterInterface*) const in libaws-cpp-sdk-core.a(CurlHttpClient.cpp.o) ld: symbol(s) not found for architecture arm64 clang: error: linker command failed with exit code 1 (use -v to see invocation) make[2]: *** [aws-cpp-sdk-s3-integration-tests/aws-cpp-sdk-s3-integration-tests] Error 1 make[1]: *** [aws-cpp-sdk-s3-integration-tests/CMakeFiles/aws-cpp-sdk-s3-integration-tests.dir/all] Error 2 make: *** [all] Error 2 Thanks for any help you can provide Alex Chen -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex_chen at filemaker.com Thu Apr 27 21:15:32 2017 From: alex_chen at filemaker.com (Alex Chen) Date: Thu, 27 Apr 2017 18:15:32 -0700 Subject: [CMake] How to set libcurl library path and the library name? Message-ID: <67FC18D7-1351-432A-8C61-E500BE455D61@filemaker.com> There is an error in the FindCURL document of Cmake 3.8 (or prior versions). It says CURL_INCLUDE_DIRS?? - where to find curl/curl.h, etc. CURL_LIBRARIES????? - List of libraries when using curl. CURL_FOUND????????? - True if curl found. CURL_VERSION_STRING - the version of curl found (since CMake 2.8.8) But in fact it is looking for CURL_INCLUDE_DIR, not CURL_INCLUDE_DIRS.? If I set ?DCURL_INCLUDE_DIRS, cmake cannot find libcurl?s header files. Alex Chen From: CMake on behalf of Alex Chen Date: Thursday, April 27, 2017 at 5:14 PM To: CMake Subject: [CMake] How to set libcurl library path and the library name? Hi, I am trying to build AWS CPP SDK for the iOS from downloaded source. The compilation seems to go well but it fails at link time. My CMake invocation is /Applications/CMake.app/Contents/bin/cmake -Wno-dev -DBUILD_ONLY=s3;s3-encryption -DCMAKE_OSX_SYSROOT=/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS10.3.sdk -DCMAKE_OSX_ARCHITECTURES=arm64 -DCMAKE_SYSTEM_NAME=Darwin -DCMAKE_SHARED_LINKER_FLAGS=-framework Foundation -framework Security -DCMAKE_EXE_LINKER_FLAGS=-framework Foundation -framework Security -DCMAKE_PREFIX_PATH=/Volumes/Workspace/Prebuilt/Release-iphoneos/libcurl -DCMAKE_BUILD_TYPE=Release -DCMAKE_CXX_FLAGS=-O3 -DCMAKE_INSTALL_PREFIX=/Volumes/Workspace/AWS/CppSDK/1.0.101/iPhoneOS/arm64/Release -DBUILD_SHARED_LIBS=off -DCPP_STANDARD=14 -DCURL_INCLUDE_DIR=/Volumes/Workspace/Prebuilt/Release-iphoneos/libcurl/include64 -DCURL_LIBRARIES=libcurl_7.51 -DSTATIC_LINKING=1 -DTARGET_ARCH=Apple /Volumes/Workspace/FMSOURCE/Shared/AWS/CppSDK/aws-sdk-cpp-1.0.101 The output from CMake looks like it finds the include path of libcurl but no the library. -- Found Git: /usr/bin/git (found version "2.11.0 (Apple Git-81)") -- Building AWS libraries as static objects fatal: Not a git repository (or any parent up to mount point /Volumes/Workspace) Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set). -- Building project version: 1.0.101 -- The CXX compiler identification is AppleClang 8.1.0.8020042 -- Check for working CXX compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ -- Check for working CXX compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done -- Found ZLIB: /usr/lib/libz.dylib (found version "1.2.8") -- Zlib include directory: /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS10.3.sdk/usr/include -- Zlib library: /usr/lib/libz.dylib -- Encryption: CommonCrypto -- Http client: Curl -- Found CURL: /usr/lib/libcurl.dylib (found version "7.51.0") -- Curl include directory: /Volumes/Workspace/FMSOURCE/Shared/Prebuilt/Release-iphoneos/libcurl/include64 -- Curl library: /usr/lib/libcurl.dylib -- Considering s3 -- Considering s3-encryption -- The C compiler identification is AppleClang 8.1.0.8020042 -- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Detecting C compile features -- Detecting C compile features - done -- Updating version info to 1.0.101 -- Custom memory management disabled -- Configuring done -- Generating done The linking errors look like this: [ 92%] Linking CXX executable aws-cpp-sdk-s3-integration-tests ld: warning: ignoring file /usr/lib/libcurl.dylib, missing required architecture arm64 in file /usr/lib/libcurl.dylib (2 slices) Undefined symbols for architecture arm64: "_curl_easy_cleanup", referenced from: Aws::Http::CurlHandleContainer::~CurlHandleContainer() in libaws-cpp-sdk-core.a(CurlHandleContainer.cpp.o) "_curl_easy_getinfo", referenced from: Aws::Http::CurlHttpClient::MakeRequest(Aws::Http::HttpRequest&, Aws::Utils::RateLimits::RateLimiterInterface*, Aws::Utils::RateLimits::RateLimiterInterface*) const in libaws-cpp-sdk-core.a(CurlHttpClient.cpp.o) "_curl_easy_init", referenced from: Aws::Http::CurlHandleContainer::CheckAndGrowPool() in libaws-cpp-sdk-core.a(CurlHandleContainer.cpp.o) "_curl_easy_perform", referenced from: Aws::Http::CurlHttpClient::MakeRequest(Aws::Http::HttpRequest&, Aws::Utils::RateLimits::RateLimiterInterface*, Aws::Utils::RateLimits::RateLimiterInterface*) const in libaws-cpp-sdk-core.a(CurlHttpClient.cpp.o) "_curl_easy_reset", referenced from: Aws::Http::CurlHandleContainer::ReleaseCurlHandle(void*) in libaws-cpp-sdk-core.a(CurlHandleContainer.cpp.o) "_curl_easy_setopt", referenced from: SetOptCodeForHttpMethod(void*, Aws::Http::HttpRequest const&) in libaws-cpp-sdk-core.a(CurlHttpClient.cpp.o) Aws::Http::CurlHttpClient::MakeRequest(Aws::Http::HttpRequest&, Aws::Utils::RateLimits::RateLimiterInterface*, Aws::Utils::RateLimits::RateLimiterInterface*) const in libaws-cpp-sdk-core.a(CurlHttpClient.cpp.o) Aws::Http::CurlHandleContainer::CheckAndGrowPool() in libaws-cpp-sdk-core.a(CurlHandleContainer.cpp.o) Aws::Http::CurlHandleContainer::ReleaseCurlHandle(void*) in libaws-cpp-sdk-core.a(CurlHandleContainer.cpp.o) Aws::Http::CurlHandleContainer::SetDefaultOptionsOnHandle(void*) in libaws-cpp-sdk-core.a(CurlHandleContainer.cpp.o) "_curl_global_cleanup", referenced from: Aws::Http::CurlHttpClient::CleanupGlobalState() in libaws-cpp-sdk-core.a(CurlHttpClient.cpp.o) "_curl_global_init", referenced from: Aws::Http::CurlHttpClient::InitGlobalState() in libaws-cpp-sdk-core.a(CurlHttpClient.cpp.o) "_curl_slist_append", referenced from: Aws::Http::CurlHttpClient::MakeRequest(Aws::Http::HttpRequest&, Aws::Utils::RateLimits::RateLimiterInterface*, Aws::Utils::RateLimits::RateLimiterInterface*) const in libaws-cpp-sdk-core.a(CurlHttpClient.cpp.o) "_curl_slist_free_all", referenced from: Aws::Http::CurlHttpClient::MakeRequest(Aws::Http::HttpRequest&, Aws::Utils::RateLimits::RateLimiterInterface*, Aws::Utils::RateLimits::RateLimiterInterface*) const in libaws-cpp-sdk-core.a(CurlHttpClient.cpp.o) ld: symbol(s) not found for architecture arm64 clang: error: linker command failed with exit code 1 (use -v to see invocation) make[2]: *** [aws-cpp-sdk-s3-integration-tests/aws-cpp-sdk-s3-integration-tests] Error 1 make[1]: *** [aws-cpp-sdk-s3-integration-tests/CMakeFiles/aws-cpp-sdk-s3-integration-tests.dir/all] Error 2 make: *** [all] Error 2 Thanks for any help you can provide Alex Chen -- 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 eike at sf-mail.de Fri Apr 28 01:25:32 2017 From: eike at sf-mail.de (Rolf Eike Beer) Date: Fri, 28 Apr 2017 07:25:32 +0200 Subject: [CMake] How to set libcurl library path and the library name? In-Reply-To: <67FC18D7-1351-432A-8C61-E500BE455D61@filemaker.com> References: <67FC18D7-1351-432A-8C61-E500BE455D61@filemaker.com> Message-ID: <16972987.JhR2gOaost@daneel.sf-tec.de> Alex Chen wrote: > There is an error in the FindCURL document of Cmake 3.8 (or prior versions). No. > It says > > CURL_INCLUDE_DIRS - where to find curl/curl.h, etc. Which is what it is _setting_. > But in fact it is looking for CURL_INCLUDE_DIR, not CURL_INCLUDE_DIRS. If I > set ?DCURL_INCLUDE_DIRS, cmake cannot find libcurl?s header files. This is correct, it is _looking_ for the singular form, and then putting it in the plural one, like basically all modules do. This has the reason that sometimes you need multiple include dirs, but you can't properly store that in one cache variable (you need to know which one was actually not found on next run). Eike -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part. URL: From lp.cordier at dynamixyz.com Thu Apr 27 04:43:50 2017 From: lp.cordier at dynamixyz.com (Louis-Paul CORDIER) Date: Thu, 27 Apr 2017 10:43:50 +0200 Subject: [CMake] DLL handling under CMake Message-ID: Hi, I'm using CMake for a while now for cross-platform project. In opposition to Linux, Windows does not have a library system management through a repository system. I would say that 99% of applications that have common libraries between them does not share the runtimes. Each time, the .dll files are duplicated for each application. We have to live with that, and to create proper CMakeLists.txt that can handle DLL integration. I think many of CMake users have the following pipeline on Windows: 1. Run CMake (this will execute some find_library to get the correct .lib files) 2. Compile the application 3. Run the INSTALL target 4. Copy the .dll files into the output binary folder. 5. Package the application with the DLL inside (e.g innosetup) Currently find_library does not search for runtime, but only for .lib. So even if a developer is using find_library, he/she has to implement some additional CMake code to retrieve the path to .dll files and copy them using the install or the file CMake commands. I added my current code for handling Qt library in my project at the end of this email. (I put a huge part of it if someone want to reuse it). You will notice that this code is handling the case where you are debugging using Visual Studio, to avoid the missing .DLL issue. This steps are tedious and I'm wondering if there is a mechanism that exists or that have to be imagined to make the DLL nightmare end. All the best Louis-Paul Cordier ... #Folder where compiled files for release/debug install will be placed set(G3_RELEASE_DIR "release") set(G3_DEBUG_DIR "debug") find_package(Qt5 ${QT5VC2015_VERSION} EXACT COMPONENTS Core OpenGL Concurrent REQUIRED) QT5_WRAP_UI(...) QT5_WRAP_CPP(...) target_include_directories(...) target_compile_definitions(...) #Add Qt libraries to the linker target_link_libraries(${PROJECT_NAME} ${Qt5Widgets_LIBRARIES} ${Qt5OpenGL_LIBRARIES} ${Qt5Concurrent_LIBRARIES} ) if( WIN32 ) SET(QT_DLL Qt5Core Qt5Gui Qt5Widgets Qt5OpenGL Qt5Concurrent ) foreach( _file ${QT_DLL} ) list( APPEND DLL_LIBRARIES "${QT5_DIR}/bin/${_file}.dll" ) list( APPEND DLL_LIBRARIES_D "${QT5_DIR}/bin/${_file}d.dll" ) endforeach( _file ${QT_DLL} ) #TODO: add the platform libraries. endif( WIN32 ) # I add other DLLs of other project's library by appending to DLL_LIBRARIES and DLL_LIBRARIES_D #Handle DLLs under Windows. if(WIN32) set(DLL_LIBRARIES_PATH "") set(DLL_LIBRARIES_D_PATH "") #Process Release libraries. foreach( _file ${DLL_LIBRARIES} ) # Convert path to CMake path to avoid escaping issues. file(TO_CMAKE_PATH ${_file} _file_cmake_path) #check file existance if(NOT EXISTS ${_file_cmake_path}) message(FATAL_ERROR "Missing dll file: ${_file_cmake_path}") endif(NOT EXISTS ${_file_cmake_path}) # Add the DLL to the installation process. install(FILES ${_file_cmake_path} DESTINATION ${G3_RELEASE_DIR} CONFIGURATIONS Release RelWithDebInfo MinSizeRel Release_CMT Release_Net) # Extract the folder path of the DLL. It allows to add the folder where the # DLLs are stored to the PATH environment of Visual Studio, in order to avoid # copying DLL after each builds. if(MSVC) get_filename_component(_dll_folder ${_file} DIRECTORY) list(APPEND DLL_LIBRARIES_PATH ${_dll_folder}) endif(MSVC) endforeach( _file ${DLL_LIBRARIES} ) #Process Debug libraries. foreach( _file ${DLL_LIBRARIES_D} ) # Convert path to CMake path to avoid escaping issues. file(TO_CMAKE_PATH ${_file} _file_cmake_path) #check file existance if(NOT EXISTS ${_file_cmake_path}) message(FATAL_ERROR "Missing dll file: ${_file_cmake_path}") endif(NOT EXISTS ${_file_cmake_path}) # Add the DLL to the installation process. install(FILES ${_file_cmake_path} DESTINATION ${G3_DEBUG_DIR} CONFIGURATIONS Debug) # Extract the folder path of the DLL. It allows to add the folder where the # DLLs are stored to the PATH environment of Visual Studio, in order to avoid # copying DLL after each builds. if(MSVC) get_filename_component(_dll_folder ${_file} DIRECTORY) list(APPEND DLL_LIBRARIES_PATH_D ${_dll_folder}) endif(MSVC) endforeach( _file ${DLL_LIBRARIES_D} ) if(MSVC) #Remove duplicate entries list(REMOVE_DUPLICATES DLL_LIBRARIES_PATH) list(REMOVE_DUPLICATES DLL_LIBRARIES_PATH_D) #Set architecture if(ARCH_X64) set(DLL_LIBRARIES_ARCH "x64") else(ARCH_X64) set(DLL_LIBRARIES_ARCH "Win32") endif(ARCH_X64) # The output file goes in the build dir. # @ONLY means only variables of the form @VAR@ will be substituted. # This method need DLL_LIBRARIES_ARCH, DLL_LIBRARIES_PATH and DLL_LIBRARIES_PATH_D # variables to be set. DONT FORGET TO RESTART VISUAL STUDIO if DLL paths changes, as # vcxproj.user files are loaded only once at Visual Studio startup. configure_file(project.vcxproj.user.in ${CMAKE_CURRENT_BINARY_DIR}/${PROJECT_NAME}.vcxproj.user @ONLY) endif(MSVC) endif(WIN32) ------------------- NOTE: For those who are wondering the content of project.vcxproj.user.in: PATH=@DLL_LIBRARIES_PATH@;%PATH% WindowsLocalDebugger PATH=@DLL_LIBRARIES_PATH@;%PATH% WindowsLocalDebugger PATH=@DLL_LIBRARIES_PATH@;%PATH% WindowsLocalDebugger PATH=@DLL_LIBRARIES_PATH_D@;%PATH% WindowsLocalDebugger -- From nilsgladitz at gmail.com Fri Apr 28 04:42:57 2017 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 28 Apr 2017 10:42:57 +0200 Subject: [CMake] DLL handling under CMake In-Reply-To: References: Message-ID: On 04/27/2017 10:43 AM, Louis-Paul CORDIER wrote: > I added my current code for handling Qt library in my project at the > end of this email. (I put a huge part of it if someone want to reuse > it). You will notice that this code is handling the case where you are > debugging using Visual Studio, to avoid the missing .DLL issue. FWIW in case of Qt5 you do not have to manually construct or guess DLL locations. You can retrieve the DLL locations from the imported targets (e.g. "Qt5::Widgets") that Qt5 provides by querying the LOCATION_ target properties (e.g. LOCATION_DEBUG or LOCATION_RELEASE). Nils From volo.zyko at gmail.com Fri Apr 28 04:44:01 2017 From: volo.zyko at gmail.com (Volo Zyko) Date: Fri, 28 Apr 2017 11:44:01 +0300 Subject: [CMake] Inconsistent parsing of bracket comments in command arguments Message-ID: Hi, I've encountered the following behavior. Code like 'set(FOO#[[bar]] 1)' is parsed fine by cmake, but for the code 'set(FOO #[[bar]]1)' cmake reports: Syntax Error in cmake code at column 13 Argument not separated from preceding token by whitespace. Is this by design or just an omission? As for me either separation should be required on both sides of bracket comment or it should allow to omit separation on both sides too. Volo Zyko From liusong at zerozero.cn Fri Apr 28 06:51:42 2017 From: liusong at zerozero.cn (=?gb2312?B?wfXLyQ==?=) Date: Fri, 28 Apr 2017 10:51:42 +0000 Subject: [CMake] About multiple toolchains support in big project Message-ID: Hi CMake experts, I want to use CMake build system for large projects, which will uses different toolchains. Let?s take one simple example: There are two project, one is using the arm cross toolchain, another one is using the dsp toolchain. cmake_projects/ ??? CMakeLists.txt ??? arm_project ? ??? CMakeLists.txt ??? arm_project2 ? ??? CMakeLists.txt ??? dsp_project ? ??? CMakeLists.txt ??? dsp_project2 ??? CMakeLists.txt Inside the cmake_projects/CMakeLists.txt: add_subdirectory(arm_project) add_subdirectory(arm_project2) add_subdirectory(dsp_project) add_subdirectory(dsp_project2) Then, I want to build it: mkdir build cd build && cmake -DCMAKE_TOOLCHAIN_FILE= ../ You know that the CMAKE_TOOLCHAIN_FILE needs to be specified along with cmake command line, so in above example what?s the should be ? Yes, there might be another solution: cmake_projects/ ??? CMakeLists.txt ??? arm ? ??? CMakeLists.txt ??? dsp ? ??? CMakeLists.txt ??? arm_project ? ??? CMakeLists.txt ??? arm_project2 ? ??? CMakeLists.txt ??? dsp_project ? ??? CMakeLists.txt ??? dsp_project2 ??? CMakeLists.txt so that inside arm/CMakeLists.txt add_subdirectory(arm_project) add_subdirectory(arm_project2) and inside dsp/CMakeLists.txt add_subdirectory(dsp_project) add_subdirectory(dsp_project2) Then, build it with mkdir build_arm cd build_arm && cmake -DCMAKE_TOOLCHAIN_FILE= ../arm mkdir build_dsp cd build_dsp && cmake -DCMAKE_TOOLCHAIN_FILE= ../dsp But this way I need to sperate the arm and dsp build folder structure, but logically I need to keep the build folder structure as same as source code. Or, let developer don?t be aware of the toolchain difference it?s just choosing the right one? But if it?s supporting specifying the CMAKE_TOOLCHAIN_FILE inside the CMakeLists.txt, it might solving this problem. Any suggestions or ideas ? Thanks in advanced. Thanks, Song -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.jackson at bluequartz.net Sat Apr 29 10:00:37 2017 From: mike.jackson at bluequartz.net (Michael Jackson) Date: Sat, 29 Apr 2017 10:00:37 -0400 Subject: [CMake] DLL handling under CMake In-Reply-To: References: Message-ID: <59049C85.6070804@bluequartz.net> Our project uses some custom cmake functions to gather the DLLs from 3rd party libs (HDF5, TBB, Qt) and create custom targets to copy them to the build directory and create install rules to copy them to the package when it is created. Yes, they were tedious to write and get correct but they seem to work. The Qt version was the easiest after we moved to Qt 5 since it is straight forward to get the locations. The HDF5 folks recently updated their config file to have the same type of information. TBB is odd, but relatively easy to guess the correct pattern. I had a discussion about this topic yesterday and my pain point is that a lot of the "Find**" modules really _need_ to also define the DLL location instead of just where the link libs are at. From my little world on Windows all the .dll files seem to be in a bin directory. So I think that for each "Find***" those should define a few additional items: FOO_IS_SHARED FOO_BINARY_DIR assuming of course that the proper FooConfig.cmake is not available. -- Mike Jackson PS:: http://www.github.com/bluequartzsoftware/cmp has our custom scripts. It is mainly Qt focused but may have some gems in there that you find valuable. Louis-Paul CORDIER wrote: > Hi, > > I'm using CMake for a while now for cross-platform project. > > In opposition to Linux, Windows does not have a library system > management through a repository system. I would say that 99% of > applications that have common libraries between them does not share the > runtimes. Each time, the .dll files are duplicated for each application. > We have to live with that, and to create proper CMakeLists.txt that can > handle DLL integration. > > I think many of CMake users have the following pipeline on Windows: > > 1. Run CMake (this will execute some find_library to get the correct > .lib files) > 2. Compile the application > 3. Run the INSTALL target > 4. Copy the .dll files into the output binary folder. > 5. Package the application with the DLL inside (e.g innosetup) > > Currently find_library does not search for runtime, but only for .lib. > So even if a developer is using find_library, he/she has to implement > some additional CMake code to retrieve the path to .dll files and copy > them using the install or the file CMake commands. I added my current > code for handling Qt library in my project at the end of this email. (I > put a huge part of it if someone want to reuse it). You will notice that > this code is handling the case where you are debugging using Visual > Studio, to avoid the missing .DLL issue. > > This steps are tedious and I'm wondering if there is a mechanism that > exists or that have to be imagined to make the DLL nightmare end. > > All the best > > Louis-Paul Cordier > > > ... > > #Folder where compiled files for release/debug install will be placed > set(G3_RELEASE_DIR "release") > set(G3_DEBUG_DIR "debug") > > find_package(Qt5 ${QT5VC2015_VERSION} EXACT COMPONENTS Core OpenGL > Concurrent REQUIRED) > > QT5_WRAP_UI(...) > QT5_WRAP_CPP(...) > target_include_directories(...) > target_compile_definitions(...) > > #Add Qt libraries to the linker > target_link_libraries(${PROJECT_NAME} > ${Qt5Widgets_LIBRARIES} > ${Qt5OpenGL_LIBRARIES} > ${Qt5Concurrent_LIBRARIES} > ) > > if( WIN32 ) > SET(QT_DLL > Qt5Core > Qt5Gui > Qt5Widgets > Qt5OpenGL > Qt5Concurrent > ) > > foreach( _file ${QT_DLL} ) > list( APPEND DLL_LIBRARIES "${QT5_DIR}/bin/${_file}.dll" ) > list( APPEND DLL_LIBRARIES_D "${QT5_DIR}/bin/${_file}d.dll" ) > endforeach( _file ${QT_DLL} ) > > #TODO: add the platform libraries. > > endif( WIN32 ) > > # I add other DLLs of other project's library by appending to > DLL_LIBRARIES and DLL_LIBRARIES_D > > #Handle DLLs under Windows. > if(WIN32) > > set(DLL_LIBRARIES_PATH "") > set(DLL_LIBRARIES_D_PATH "") > > #Process Release libraries. > foreach( _file ${DLL_LIBRARIES} ) > > # Convert path to CMake path to avoid escaping issues. > file(TO_CMAKE_PATH ${_file} _file_cmake_path) > > #check file existance > if(NOT EXISTS ${_file_cmake_path}) > message(FATAL_ERROR "Missing dll file: ${_file_cmake_path}") > endif(NOT EXISTS ${_file_cmake_path}) > > # Add the DLL to the installation process. > install(FILES ${_file_cmake_path} > DESTINATION ${G3_RELEASE_DIR} > CONFIGURATIONS Release RelWithDebInfo MinSizeRel Release_CMT Release_Net) > > # Extract the folder path of the DLL. It allows to add the folder where the > # DLLs are stored to the PATH environment of Visual Studio, in order to > avoid > # copying DLL after each builds. > if(MSVC) > get_filename_component(_dll_folder ${_file} DIRECTORY) > list(APPEND DLL_LIBRARIES_PATH ${_dll_folder}) > endif(MSVC) > > endforeach( _file ${DLL_LIBRARIES} ) > > #Process Debug libraries. > foreach( _file ${DLL_LIBRARIES_D} ) > > # Convert path to CMake path to avoid escaping issues. > file(TO_CMAKE_PATH ${_file} _file_cmake_path) > > #check file existance > if(NOT EXISTS ${_file_cmake_path}) > message(FATAL_ERROR "Missing dll file: ${_file_cmake_path}") > endif(NOT EXISTS ${_file_cmake_path}) > > # Add the DLL to the installation process. > install(FILES ${_file_cmake_path} > DESTINATION ${G3_DEBUG_DIR} > CONFIGURATIONS Debug) > > # Extract the folder path of the DLL. It allows to add the folder where the > # DLLs are stored to the PATH environment of Visual Studio, in order to > avoid > # copying DLL after each builds. > if(MSVC) > get_filename_component(_dll_folder ${_file} DIRECTORY) > list(APPEND DLL_LIBRARIES_PATH_D ${_dll_folder}) > endif(MSVC) > > endforeach( _file ${DLL_LIBRARIES_D} ) > > if(MSVC) > #Remove duplicate entries > list(REMOVE_DUPLICATES DLL_LIBRARIES_PATH) > list(REMOVE_DUPLICATES DLL_LIBRARIES_PATH_D) > > #Set architecture > if(ARCH_X64) > set(DLL_LIBRARIES_ARCH "x64") > else(ARCH_X64) > set(DLL_LIBRARIES_ARCH "Win32") > endif(ARCH_X64) > > # The output file goes in the build dir. > # @ONLY means only variables of the form @VAR@ will be substituted. > # This method need DLL_LIBRARIES_ARCH, DLL_LIBRARIES_PATH and > DLL_LIBRARIES_PATH_D > # variables to be set. DONT FORGET TO RESTART VISUAL STUDIO if DLL paths > changes, as > # vcxproj.user files are loaded only once at Visual Studio startup. > > configure_file(project.vcxproj.user.in > ${CMAKE_CURRENT_BINARY_DIR}/${PROJECT_NAME}.vcxproj.user @ONLY) > endif(MSVC) > > endif(WIN32) > > ------------------- > > NOTE: > > For those who are wondering the content of project.vcxproj.user.in: > > > xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> > Condition="'$(Configuration)|$(Platform)'=='Release|@DLL_LIBRARIES_ARCH@'"> > PATH=@DLL_LIBRARIES_PATH@;%PATH% > > WindowsLocalDebugger > > > Condition="'$(Configuration)|$(Platform)'=='RelWithDebInfo|@DLL_LIBRARIES_ARCH@'"> > > PATH=@DLL_LIBRARIES_PATH@;%PATH% > > WindowsLocalDebugger > > > Condition="'$(Configuration)|$(Platform)'=='MinSizeRel|@DLL_LIBRARIES_ARCH@'"> > > PATH=@DLL_LIBRARIES_PATH@;%PATH% > > WindowsLocalDebugger > > > Condition="'$(Configuration)|$(Platform)'=='Debug|@DLL_LIBRARIES_ARCH@'"> > PATH=@DLL_LIBRARIES_PATH_D@;%PATH% > > WindowsLocalDebugger > > > > > > From post at hendrik-sattler.de Sat Apr 29 16:10:02 2017 From: post at hendrik-sattler.de (Hendrik Sattler) Date: Sat, 29 Apr 2017 22:10:02 +0200 Subject: [CMake] DLL handling under CMake In-Reply-To: References: Message-ID: <2114FB31-FF89-4461-8713-75FAA7179E4E@hendrik-sattler.de> Am 27. April 2017 10:43:50 MESZ schrieb Louis-Paul CORDIER : >This steps are tedious and I'm wondering if there is a mechanism that >exists or that have to be imagined to make the DLL nightmare end. I use BundleUtilities to achieve the copying of DLL files to the installation directory. The main problem for this is to enumerate the needed directories. I use the same for copying DLL files to the output directory to ease debugging. The advantage is the inspection of the exe for really needed DLL files. This AUTOMATICALLY handles the case debug vs. release. HS -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.