From borucki.andrzej at gmail.com Sat Dec 1 03:32:10 2018 From: borucki.andrzej at gmail.com (Andy) Date: Sat, 1 Dec 2018 09:32:10 +0100 Subject: [CMake] New version forces rebuild all? Message-ID: I have cmake project, I usuall call "cmake ." followed by make. Now I have installed cmake 3.12.3 (was impossible install by apt-get) I have following problem: If I change one *.cpp file, in most cases make rebuilds all *.cpp files, not related to this file. Sometimes is ok. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamesbigler at gmail.com Mon Dec 3 19:42:56 2018 From: jamesbigler at gmail.com (James Bigler) Date: Mon, 3 Dec 2018 17:42:56 -0700 Subject: [CMake] Build and run an external project Message-ID: I have an external project that I would like to compile using their build system, and be able to set the VS_COMMAND to the result of the project so I can run it. add_custom_target(${cmake_target} COMMAND make mytarget ${BUILD_ARGS} COMMAND ${CMAKE_COMMAND} -E copy_if_different ${PATH_TO_EXTERNAL}/mytarget.exe ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/$ WORKING_DIRECTORY ${PATH_TO_EXTERNAL} ) set_property( TARGET ${cmake_target} PROPERTY VS_DEBUGGER_COMMAND "${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/$/mytarget.exe" ) The VS_DEBUGGER_COMMAND works for targets such as add_executable, but not for add_custom_target. Is there a way to get what I want? Note that this is part of a larger CMake project that builds most of the other stuff using CMake, but I have a few external projects that I would like as part of the main solution. Thanks, James -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.noulard at gmail.com Mon Dec 3 23:55:04 2018 From: eric.noulard at gmail.com (Eric Noulard) Date: Tue, 4 Dec 2018 05:55:04 +0100 Subject: [CMake] Build and run an external project In-Reply-To: References: Message-ID: Did you check whether if https://cmake.org/cmake/help/latest/command/include_external_msproject.html wouldn't be better in your case? Le mar. 4 d?c. 2018 01:43, James Bigler a ?crit : > I have an external project that I would like to compile using their build > system, and be able to set the VS_COMMAND to the result of the project so I > can run it. > > add_custom_target(${cmake_target} > COMMAND make mytarget ${BUILD_ARGS} > COMMAND ${CMAKE_COMMAND} -E copy_if_different > ${PATH_TO_EXTERNAL}/mytarget.exe ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/$ > WORKING_DIRECTORY ${PATH_TO_EXTERNAL} > ) > set_property( TARGET ${cmake_target} PROPERTY VS_DEBUGGER_COMMAND > "${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/$/mytarget.exe" ) > > The VS_DEBUGGER_COMMAND works for targets such as add_executable, but not > for add_custom_target. > > Is there a way to get what I want? > > Note that this is part of a larger CMake project that builds most of the > other stuff using CMake, but I have a few external projects that I would > like as part of the main solution. > > Thanks, > James > -- > > 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: > https://cmake.org/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamesbigler at gmail.com Tue Dec 4 00:10:55 2018 From: jamesbigler at gmail.com (James Bigler) Date: Mon, 3 Dec 2018 22:10:55 -0700 Subject: [CMake] Build and run an external project In-Reply-To: References: Message-ID: Unfortunately I don't think your suggestion will work. I need to invoke a custom executable to build my project and not a msproject. I also need to copy the executable into the build directory. On Mon, Dec 3, 2018 at 9:55 PM Eric Noulard wrote: > Did you check whether if > https://cmake.org/cmake/help/latest/command/include_external_msproject.html > > wouldn't be better in your case? > > > Le mar. 4 d?c. 2018 01:43, James Bigler a ?crit : > >> I have an external project that I would like to compile using their build >> system, and be able to set the VS_COMMAND to the result of the project so I >> can run it. >> >> add_custom_target(${cmake_target} >> COMMAND make mytarget ${BUILD_ARGS} >> COMMAND ${CMAKE_COMMAND} -E copy_if_different >> ${PATH_TO_EXTERNAL}/mytarget.exe ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/$ >> WORKING_DIRECTORY ${PATH_TO_EXTERNAL} >> ) >> set_property( TARGET ${cmake_target} PROPERTY VS_DEBUGGER_COMMAND >> "${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/$/mytarget.exe" ) >> >> The VS_DEBUGGER_COMMAND works for targets such as add_executable, but not >> for add_custom_target. >> >> Is there a way to get what I want? >> >> Note that this is part of a larger CMake project that builds most of the >> other stuff using CMake, but I have a few external projects that I would >> like as part of the main solution. >> >> Thanks, >> James >> -- >> >> 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: >> https://cmake.org/mailman/listinfo/cmake >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sancelot at numalliance.com Tue Dec 4 02:13:00 2018 From: sancelot at numalliance.com (=?UTF-8?Q?St=c3=a9phane_Ancelot?=) Date: Tue, 4 Dec 2018 08:13:00 +0100 Subject: [CMake] linked dependencies in exported cmake package Message-ID: <0912c43c-d1e3-96b5-6661-88a9da4976ad@numalliance.com> Hi, I made an exported package for a library that needs linking qt5. find_package() works to find my library , however, I don't know how to handle the linking of external libs needed by this package. I suppose that must be managed inside the exported package, by which way ? Regards, S.Ancelot From sergey.nikulov at gmail.com Tue Dec 4 02:44:09 2018 From: sergey.nikulov at gmail.com (Sergei Nikulov) Date: Tue, 4 Dec 2018 10:44:09 +0300 Subject: [CMake] linked dependencies in exported cmake package In-Reply-To: <0912c43c-d1e3-96b5-6661-88a9da4976ad@numalliance.com> References: <0912c43c-d1e3-96b5-6661-88a9da4976ad@numalliance.com> Message-ID: ??, 4 ???. 2018 ?. ? 10:13, St?phane Ancelot : > > Hi, > > I made an exported package for a library that needs linking qt5. > > find_package() works to find my library , however, I don't know how to > handle the linking of external libs needed by this package. > > I suppose that must be managed inside the exported package, by which way ? I use the following way set_target_properties( PROPERTIES INTERFACE_LINK_LIBRARIES ) Ref here https://cmake.org/cmake/help/latest/prop_tgt/INTERFACE_LINK_LIBRARIES.html > Regards, > > S.Ancelot > > -- > > 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: > https://cmake.org/mailman/listinfo/cmake -- Best Regards, Sergei Nikulov From eric.noulard at gmail.com Tue Dec 4 02:53:48 2018 From: eric.noulard at gmail.com (Eric Noulard) Date: Tue, 4 Dec 2018 08:53:48 +0100 Subject: [CMake] Build and run an external project In-Reply-To: References: Message-ID: Le mar. 4 d?c. 2018 ? 06:11, James Bigler a ?crit : > Unfortunately I don't think your suggestion will work. > > I need to invoke a custom executable to build my project and not a > msproject. I also need to copy the executable into the build directory. > Sorry I miss the fact that you moved the executable around and was not a "regular" compile. I've read your message too fast, obviously, sorry. I'm not much a Visual Studio user and it has been a long time since I need to compile something on windows. You basically require that an executable not built by VS appears as a "runnable/debuggable" target in VS? Are you able to do that from VS "manually" ? Again I'm no VS/Windows specialist so others may have more valuable remark on that. -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From Torsten at Robitzki.de Tue Dec 4 02:56:07 2018 From: Torsten at Robitzki.de (Torsten Robitzki) Date: Tue, 4 Dec 2018 08:56:07 +0100 Subject: [CMake] dependencies of cross compiliations In-Reply-To: References: <7D02012F-99E4-44DA-96E3-C6D0D1955FD3@Robitzki.de> Message-ID: <8F791FB5-4DA3-4353-A04E-3D809ED9976C@Robitzki.de> > Am 27.11.2018 um 19:55 schrieb Eric Noulard : > > However from my point of view and my cross-compiling experience when you cross-compile you have: > > 1) the host compiler which is used to compile "host tools" > 2) the target compiler (may be several of them) to "cross-compile" > > My assumption are: > a) when you cross-compile your build is a "whole" and you shouldn't have to setup some superbuild > structure for building host tools ht_exe and another for target1 tool t1t_exe and another one for target2 tool t2t_exe. > > b) what you want is to build: > ht_exe for the host > possibly use ht_exe during the build to generate some [source] file > t1t_exe for the [cross]target1 > t2t_exe for the [cross]target2 > > c) you seldomly compile the same source for the host AND the target, but it may happen. In case, you are doing unit tests, it?s normal to have the same code running in a test on the host platform and in the final binary on the target. I think, having more than 1 target platform becomes more and more normal as it becomes more usual to have multiple microcontrollers in a project. Previously, I have encoded this in the build type. So instead of just having Debug and Release, I had HOST_Debug, HOST_Release NRF51_Debug, NRF51_Release, STM8_Debug, STM8_Release and so on. It doesn?t annoy me very much, that I have to run CMake 3 times to get all the binaries for a release build. The problem that I have, are dependencies between this builds. If I write a tool that (for example) generates source files for one of the target platforms, the build for the host platform must run before the build for that target platform. And when I make changes to that tool, I want the build to regenerate the generated source files. Keeping track of this dependencies to solve this kind of ordering issues and to allow minimum rebuilds, is the main purpose of any build system. To solve this with CMake, I think we need a way to define the dependencies between build types (in the example above, from the generator from the host build to the generated source file in one of the target builds) and CMake needs to know the build directory for all build types (not only the current). > The wish-season is coming up, so that's sort of what I would like to > have. Now it's your turn. No bikeshedding please, only deliveries ;) How about ``add_dependencies()`` allowing me to define dependencies between different build types? :-) best regards, Torsten -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From eric.noulard at gmail.com Tue Dec 4 06:01:30 2018 From: eric.noulard at gmail.com (Eric Noulard) Date: Tue, 4 Dec 2018 12:01:30 +0100 Subject: [CMake] New version forces rebuild all? In-Reply-To: References: Message-ID: Le mar. 4 d?c. 2018 ? 11:44, Andy a ?crit : > Problem are still. > Alone make also give me problems. > Do you have stripped down project example? > Ninja is replacement od cmake or make? > ninja (https://ninja-build.org/) is make replacement for which there is a CMake generator. https://cmake.org/cmake/help/v3.13/generator/Ninja.html > How work with ninja? > 1) install ninja (on debian the package is called ninja-build) 2) cmake -G Ninja 3) ninja this would rule out generator specific issue. -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From afritzsche at nvidia.com Tue Dec 4 11:20:31 2018 From: afritzsche at nvidia.com (Albrecht Fritzsche) Date: Tue, 4 Dec 2018 16:20:31 +0000 Subject: [CMake] Failing to set VS_DEBUGGER_* on target added via add_custom_target. Message-ID: Hi, I - being new to CMake - somehow fail to set VS_DEBUGGER_* property values on a project added via add_custom_target(). The settings of those property values seem to be lost and not written to any .vcxproj file. Doing the same to a target added via add_executable() works on the other hand as expected, ie the debug property values show up correctly in the corresponding .vcxproj. (This is all tried with Visual Studio 2015.) What is the proposed way to achieve the settings of the property values on a project added via add_custom_target()? What am I doing wrong? _Details_ I have the helloWorld.cpp and CMakeLists.txt next to a subdirectory ext, containing both the test01.cpp and test01.exe. Ie CMakeLists.txt helloWorld.cpp ext/ test01.cpp test01.exe The CMake code in a nutshell: add_executable(helloWorld helloWorld.cpp) set(test_name "test01") set(test_target "${test_name}_build") add_custom_target(${test_target} #COMMAND ${CMAKE_COMMAND} -E env "PATH=${BUILD_DRIVER_NVMAKE_DIRECTORY};$ENV{PATH}" nvmake ... COMMAND ${CMAKE_COMMAND} -E copy_if_different "${CMAKE_SOURCE_DIR}/ext/${test_name}.exe" "${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/$" SOURCES "${CMAKE_SOURCE_DIR}/ext/${test_name}.cpp" ) set_property( TARGET ${test_target} PROPERTY FOLDER "nvmake tests" ) # from the following two set_property() calls only the first one has an effect in the generated .vcxproj files set_property( TARGET helloWorld PROPERTY VS_DEBUGGER_COMMAND "foo.exe" ) set_property( TARGET ${test_target} PROPERTY VS_DEBUGGER_COMMAND "foo.exe" ) I understand that using imported targets might be an even more appropriate solution for the problem at hand. But with imported targets, eg via add_executable(${test_target} IMPORTED), I fail to add those in a way that they show up as projects in Visual Studio. What is the recommended way for this approach? Thanks for any hints, Ali PS The custom target ends up as a project of configuration type Utility - is there a way to change it to type Executable? ----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ----------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamesbigler at gmail.com Tue Dec 4 12:32:12 2018 From: jamesbigler at gmail.com (James Bigler) Date: Tue, 4 Dec 2018 10:32:12 -0700 Subject: [CMake] Build and run an external project In-Reply-To: References: Message-ID: Yes, I'm able to do it manually using the custom target I created with add_custom_target, by editing the debug properties to get a runnable object. I was hoping that the VS_DEBUGGER_COMMAND used for add_executable would also work with the add_custom_target, but alas they don't. On Tue, Dec 4, 2018 at 12:54 AM Eric Noulard wrote: > > > Le mar. 4 d?c. 2018 ? 06:11, James Bigler a > ?crit : > >> Unfortunately I don't think your suggestion will work. >> >> I need to invoke a custom executable to build my project and not a >> msproject. I also need to copy the executable into the build directory. >> > > Sorry I miss the fact that you moved the executable around and was not a > "regular" compile. > I've read your message too fast, obviously, sorry. > > I'm not much a Visual Studio user and it has been a long time since I need > to compile something on windows. > > You basically require that an executable not built by VS appears as a > "runnable/debuggable" target in VS? > Are you able to do that from VS "manually" ? > > Again I'm no VS/Windows specialist so others may have more valuable remark > on that. > > -- > Eric > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kim.walisch at gmail.com Wed Dec 5 07:40:04 2018 From: kim.walisch at gmail.com (Kim Walisch) Date: Wed, 5 Dec 2018 13:40:04 +0100 Subject: [CMake] target_compile_features() uses incorrect C++ version Message-ID: Hi, I have realized that my C++ primesieve project ( https://github.com/kimwalisch/primesieve) is compiled using -std=gnu++11 with GCC 7.3 and CMake 3.10 (on Ubuntu 18.10 x64) even though the default C++ version used by GCC 7.3 is C++14 as checked below: $ g++ -dM -E -x c++ /dev/null | grep -F __cplusplus #define __cplusplus 201402L Note that I have not set CXX_STANDARD manually in my CMakeLists.txt so I was expecting that my project would be compiled either with -std=gnu++14 or without any C++ version flag. I spent some time investigating where the -std=gnu++11 flag comes from and I found that it is related to the use of target_compile_features(): target_compile_features(primesieve PRIVATE cxx_auto_type) This code tells the compiler that my program uses features from C++11 and that the compiler should enable C++11 if the default C++ version of the compiler is e.g. C++98. I would however expect that if the default C++ version of the compiler is > C++11 CMake would not add -std=gnu++11 to the compiler flags. For me this is a CMake bug. Thanks, Kim Walisch -------------- next part -------------- An HTML attachment was scrubbed... URL: From dbahadir at benocs.com Wed Dec 5 08:17:59 2018 From: dbahadir at benocs.com (Deniz Bahadir) Date: Wed, 5 Dec 2018 14:17:59 +0100 Subject: [CMake] target_compile_features() uses incorrect C++ version In-Reply-To: References: Message-ID: Am 05.12.18 um 13:40 schrieb Kim Walisch: > Hi, > > I have realized that my C++ primesieve project > (https://github.com/kimwalisch/primesieve) is > compiled using -std=gnu++11 with GCC 7.3 and CMake 3.10 (on Ubuntu 18.10 > x64) even > though the default C++ version used by GCC 7.3 is C++14 as checked below: > > $ g++ -dM -E -x c++? /dev/null | grep -F __cplusplus > #define __cplusplus 201402L > > Note that I have not set?CXX_STANDARD manually in my CMakeLists.txt so I > was expecting > that my project would be compiled either with -std=gnu++14 or without > any C++ version flag. > I spent some time investigating where the -std=gnu++11 flag comes from > and I found that it is > related to the use of?target_compile_features(): > > target_compile_features(primesieve PRIVATE cxx_auto_type) > > This code tells the compiler that my program uses features from C++11 > and that the compiler > should enable C++11 if the default C++ version of the compiler is e.g. > C++98. I would > however expect that if the default C++ version of the compiler is > > C++11 CMake would not > add -std=gnu++11 to the compiler flags. > > For me this is a CMake bug. > > Thanks, > Kim Walisch > Hi Kim, this does indeed sound like some unwanted behavior. I recommend you open an issue in CMake's issue-tracker (https://gitlab.kitware.com/cmake/cmake/issues) and copy your email-content there. Best regards, Deniz Bahadir From deniz.bahadir at benocs.com Wed Dec 5 08:49:15 2018 From: deniz.bahadir at benocs.com (Deniz Bahadir) Date: Wed, 5 Dec 2018 14:49:15 +0100 Subject: [CMake] target_compile_features() uses incorrect C++ version In-Reply-To: References: Message-ID: <6f7fb749-0399-b78d-41df-f48c0133a87d@benocs.com> Am 05.12.18 um 14:37 schrieb Kim Walisch: > OK thanks, I have created a new issue at: > https://gitlab.kitware.com/cmake/cmake/issues/18686 > > Greetings, > Kim Thanks, great. Best regards, Deniz PS: Next time better answer to the mailing-list. ;-) This is probably interesting for others that read your first email on the list, too. > > On Wed, Dec 5, 2018 at 2:26 PM Deniz Bahadir > wrote: > > Am 05.12.18 um 13:40 schrieb Kim Walisch: > > Hi, > > > > I have realized that my C++ primesieve project > > (https://github.com/kimwalisch/primesieve) is > > compiled using -std=gnu++11 with GCC 7.3 and CMake 3.10 (on > Ubuntu 18.10 > > x64) even > > though the default C++ version used by GCC 7.3 is C++14 as > checked below: > > > > $ g++ -dM -E -x c++? /dev/null | grep -F __cplusplus > > #define __cplusplus 201402L > > > > Note that I have not set?CXX_STANDARD manually in my > CMakeLists.txt so I > > was expecting > > that my project would be compiled either with -std=gnu++14 or > without > > any C++ version flag. > > I spent some time investigating where the -std=gnu++11 flag comes > from > > and I found that it is > > related to the use of?target_compile_features(): > > > > target_compile_features(primesieve PRIVATE cxx_auto_type) > > > > This code tells the compiler that my program uses features from > C++11 > > and that the compiler > > should enable C++11 if the default C++ version of the compiler is > e.g. > > C++98. I would > > however expect that if the default C++ version of the compiler is > > > C++11 CMake would not > > add -std=gnu++11 to the compiler flags. > > > > For me this is a CMake bug. > > > > Thanks, > > Kim Walisch > > > > Hi Kim, > > this does indeed sound like some unwanted behavior. > > I recommend you open an issue in CMake's issue-tracker > (https://gitlab.kitware.com/cmake/cmake/issues) and copy your > email-content there. > > Best regards, > Deniz Bahadir > > -- > > 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: > https://cmake.org/mailman/listinfo/cmake > -- BENOCS GmbH Dipl.-Inform. Deniz Bahadir Reuchlinstr. 10 D 10553 Berlin Germany Phone: +49 - 30 / 577 0004-22 Email: deniz.bahadir at benocs.com www.benocs.com Board of Management: Stephan Schr?der, Dr.-Ing. Ingmar Poese Commercial Register: Amtsgericht Bonn HRB 19378 From afritzsche at nvidia.com Wed Dec 5 12:16:06 2018 From: afritzsche at nvidia.com (Albrecht Fritzsche) Date: Wed, 5 Dec 2018 17:16:06 +0000 Subject: [CMake] Imported targets fail to be added to the FOLDER property. Message-ID: Hi, is there a way to add an imported target to the IDE similar to the way eg executable targets are added? In the following code the last line seems to have no effect, ie when opening the generated Visual Studio solution neither the helloWorld.cpp nor the folder "tests" is shown set_property(GLOBAL PROPERTY USE_FOLDERS ON) set(target_name Hello) add_executable(${target_name} IMPORTED) set_property(TARGET ${target_name} PROPERTY IMPORTED_LOCATION "${CMAKE_SOURCE_DIR}/helloWorld.cpp") set_property(TARGET ${target_name} PROPERTY FOLDER "tests") Any idea how I can add this imported target to some folder of the IDE? Thanks, Ali ----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ----------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From borucki.andrzej at gmail.com Wed Dec 5 16:19:19 2018 From: borucki.andrzej at gmail.com (Andy) Date: Wed, 5 Dec 2018 22:19:19 +0100 Subject: [CMake] New version forces rebuild all? Message-ID: (previously I send this mail not to mail list, but user) Maybe my cmake files are bad? I have created test project https://gitlab.com/andrzejbor/test_rebuild_all after commit is rebuild whole project what I might change? I don't want moving all but .git to one directory src/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From cristian.adam at gmail.com Wed Dec 5 17:54:24 2018 From: cristian.adam at gmail.com (Cristian Adam) Date: Wed, 5 Dec 2018 23:54:24 +0100 Subject: [CMake] New version forces rebuild all? In-Reply-To: References: Message-ID: On Wed, Dec 5, 2018 at 10:19 PM Andy wrote: > (previously I send this mail not to mail list, but user) > Maybe my cmake files are bad? > I have created test project > https://gitlab.com/andrzejbor/test_rebuild_all > after commit is rebuild whole project > what I might change? > I don't want moving all but .git to one directory src/ > > The problem is that you add the GIT variables as compile time defines, which means that after every commit you will have different compile command lines, which trigger recompilation of whole project because you have used add_definitions. You should instead write those GIT variables in a file, like this: file(WRITE ${CMAKE_BINARY_DIR}/git_version.h.in " #define GIT_SHA1 \"@GIT_SHA@\" #define GIT_TAG \"@GIT_TAG@\" #define GIT_LOCAL_CHANGES \"@GIT_LOCAL_CHANGES@\"" ) configure_file(${CMAKE_BINARY_DIR}/git_version.h.in ${CMAKE_BINARY_DIR}/git_version.h @ONLY) Make sure you have ${CURRENT_BINARY_DIR} as part of your target's include directories. And then somewhere in your code do an #include "git_version.h". Cheers, Cristian. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Torsten at Robitzki.de Thu Dec 6 01:05:24 2018 From: Torsten at Robitzki.de (Torsten Robitzki) Date: Thu, 6 Dec 2018 07:05:24 +0100 Subject: [CMake] What is --build-two-config good for Message-ID: <155635BC-9214-4E40-8789-E7866BD47223@Robitzki.de> Hello, can someone of you tell me, what the purpose of the CTest ?build-two-config command line option is? The documentation says, that it is part of the CTest Build and Test Mode and that it will cause CTest to run CMake twice. I?ve checked the code and yes, it does exactly this. But why? What could be the reason to run CMake twice, when running CMake in a test from CTest? Best regards, Torsten -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From borucki.andrzej at gmail.com Thu Dec 6 03:50:53 2018 From: borucki.andrzej at gmail.com (Andy) Date: Thu, 6 Dec 2018 09:50:53 +0100 Subject: [CMake] How force cmake debug/release Message-ID: In cmake I have: if (${CMAKE_BUILD_TYPE} STREQUAL Release) message(WARNING "Release") endif() if (${CMAKE_BUILD_TYPE} STREQUAL Debug) message(WARNING "Debug") endif() (how write something like elseif?) If I call "cmake ." it write: "Warning:Debug" Debug is default and I must call "cmake . -DCMAKE_BUILD_TYPE=Release" for release? -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.chevrier at gmail.com Thu Dec 6 03:58:28 2018 From: marc.chevrier at gmail.com (Marc CHEVRIER) Date: Thu, 6 Dec 2018 09:58:28 +0100 Subject: [CMake] How force cmake debug/release In-Reply-To: References: Message-ID: <8f2ef920-dd10-47f8-b496-f3548c729ae7@Spark> Have a look at the documentation : https://cmake.org/cmake/help/v3.13/ Le 6 d?c. 2018 ? 09:51 +0100, Andy , a ?crit : > In cmake I have: > if (${CMAKE_BUILD_TYPE} STREQUAL Release) > ? message(WARNING "Release") > endif() > > if (${CMAKE_BUILD_TYPE} STREQUAL Debug) > ? message(WARNING "Debug") > endif() > > (how write something like elseif?) > > If I call "cmake ." it write: "Warning:Debug" > Debug is default and I must call "cmake . -DCMAKE_BUILD_TYPE=Release" > for release? > -- > > 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: > https://cmake.org/mailman/listinfo/cmake -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.bell.ia at gmail.com Thu Dec 6 09:26:12 2018 From: andrew.bell.ia at gmail.com (Andrew Bell) Date: Thu, 6 Dec 2018 09:26:12 -0500 Subject: [CMake] Export Linker Script Message-ID: I have a linker script that I'd like to export for dependent projects to use as if it were an actual library. I'm having trouble figuring out how to do this. With a linker script named "libmylib.so" I've tried: set(LIBNAME mylib) add_library(mylib INTERFACE) install(TARGETS mylib EXPORT MyExport ARCHIVE DESTINATION ${LIB_INSTALL_DIR}) install(FILES libmylib.so ${LIB_INSTALL_DIR}) This will install the script properly, but attempting to use the linker script in the dependent project fails: target_link_libraries(myapp mylib) doesn't add mylib to the link line with the proper directory location (no -L option for the library location). Any help appreciated, -- Andrew Bell andrew.bell.ia at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Thu Dec 6 09:26:49 2018 From: robert.maynard at kitware.com (Robert Maynard) Date: Thu, 6 Dec 2018 09:26:49 -0500 Subject: [CMake] What is --build-two-config good for In-Reply-To: <155635BC-9214-4E40-8789-E7866BD47223@Robitzki.de> References: <155635BC-9214-4E40-8789-E7866BD47223@Robitzki.de> Message-ID: It is possible to have CMake projects where an initial configuration of the project is insufficient for it to be in a valid state. This is generally caused by a project which evaluates variables before they exist and saved into the cache. By running CMake a second time for these projects the evaluation works 'as intended' at the build is the correct state. On Thu, Dec 6, 2018 at 1:05 AM Torsten Robitzki wrote: > Hello, > can someone of you tell me, what the purpose of the CTest > ?build-two-config command line option is? The documentation says, that it > is part of the CTest Build and Test Mode and that it will cause CTest to > run CMake twice. I?ve checked the code and yes, it does exactly this. > > But why? What could be the reason to run CMake twice, when running CMake > in a test from CTest? > > Best regards, > > Torsten > -- > > 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: > https://cmake.org/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Torsten at Robitzki.de Thu Dec 6 11:45:39 2018 From: Torsten at Robitzki.de (Torsten at Robitzki.de) Date: Thu, 6 Dec 2018 17:45:39 +0100 Subject: [CMake] What is --build-two-config good for In-Reply-To: References: <155635BC-9214-4E40-8789-E7866BD47223@Robitzki.de> Message-ID: <8CC543C1-7D9D-42D2-8A3E-985A81BC9CF0@Robitzki.de> Hi Robert, > Am 06.12.2018 um 15:26 schrieb Robert Maynard : > > It is possible to have CMake projects where an initial configuration of the project is insufficient for it to be in a valid state. This is generally caused by a project which evaluates variables before they exist and saved into the cache. By running CMake a second time for these projects the evaluation works ?as intended' at the build is the correct state. thanks for the explanation! regards, Torsten -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From Torsten at Robitzki.de Thu Dec 6 12:03:25 2018 From: Torsten at Robitzki.de (Torsten Robitzki) Date: Thu, 6 Dec 2018 18:03:25 +0100 Subject: [CMake] extending clean for Ninja Message-ID: Hi, we have some source file generators, that take a known list of input files and generate an ?relatively? unknown list of output files. The exact list of output files depend on the content of the input files. The ?usual? way to solve this seams to have an add_custom_target() call, and listing all output files as BYPRODUCTS, because then Ninja would know the output files as being targets and would delete them when asked to clean the project. Assumed all output files would be in the same directory and that it would be safe to delete the entire directory, I though, I could add the directory name as BYPRODUCTS. Unfortunately this hack doesn?t work, because the OS function that Ninja uses to remove files does not delete not empty directories. If I could use the very same generator to produce the list of output files, I could then add this list as BYPRODUCTS option to `add_custom_target()`. One problem still would remain: if I change one of the input files, so that the list of output files change, cmake would have to re-run. Does someone of you have an idea, how to force cmake to re-run, if a certain list of files changed? Is there an easier way to archive what I want (to delete the output files when Ninja -t clean is called)? Best regards, Torsten -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From jjwilke at sandia.gov Thu Dec 6 13:55:55 2018 From: jjwilke at sandia.gov (Wilke, Jeremiah J) Date: Thu, 6 Dec 2018 18:55:55 +0000 Subject: [CMake] Supporting imported targets with and without namespaces Message-ID: <8F9AEAC5-6F3D-4511-93C3-C55AEA5D7FC3@sandia.gov> We are cleaning up the cmake in our project. Targets are not currently exported with namespaces, but ideally should be. However, we have enough users based on the old cmake that we don?t want to require people to use the namespaced target (for a while). I couldn?t find recommendations on this in documentation or list archives. 1. Even when the exported target is namespace::imported_lib, this still seems to work: target_link_libraries(myLib imported_lib) which I did not understand. 2. AFAIK, you cannot ALIAS an imported target in the config file: add_library(imported_lib ALIAS namespace::imported_lib) so that both the namespace and non-namespaced versions are valid 3. It did work to use the following in the config file: add_library(imported_lib INTERFACE) target_link_libraries(imported_lib INTERFACE namespace::imported_lib) but this just feels like the wrong way to do it Any help would be greatly appreciated. Thanks, Jeremy -------------- next part -------------- An HTML attachment was scrubbed... URL: From Simon.Richter at hogyros.de Fri Dec 7 07:10:29 2018 From: Simon.Richter at hogyros.de (Simon Richter) Date: Fri, 7 Dec 2018 13:10:29 +0100 Subject: [CMake] How force cmake debug/release In-Reply-To: References: Message-ID: <0dd12b38-30fb-0e0b-4e69-828d54cd4944@hogyros.de> Hi, On 06.12.18 09:50, Andy wrote: > If I call "cmake ." it write: "Warning:Debug" > Debug is default and I must call "cmake . -DCMAKE_BUILD_TYPE=Release" > for release? That depends on the generator used. Some generators require the build type at configuration time, some at build time. For example, the Visual Studio generator should generate files containing both Debug and Release configurations, and neither of your code blocks should be run. Ideally, you should never do anything directly that depends on the build type, but only prepare things. So rather than if ("${CMAKE_BUILD_TYPE}" STREQUAL "Release") set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -O3") endif() you'd use set(CMAKE_CXX_FLAGS_RELEASE "${CMAKE_CXX_FLAGS_RELEASE} -O3") so generators that handle multiple build types at the same time can work. Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From ocroquette at free.fr Sat Dec 8 05:43:35 2018 From: ocroquette at free.fr (Olivier Croquette) Date: Sat, 8 Dec 2018 11:43:35 +0100 Subject: [CMake] Concurrency issues with copy_if_different In-Reply-To: References: <8a36e982-f9c2-2f8a-078e-9a961faf1673@free.fr> Message-ID: <7c7cf8b5-485b-6e16-643a-e8a31ee0584d@free.fr> On 2018-7-12 15:16, J. Caleb Wherry wrote: >> in one of our projects, we use copy_if_different to copy some DLLs >> required by the runtime. It's called as post-build action. The problem >> is that several targets want to copy the same DLLs, and when using >> parallelized builds, the different "cmake -E copy_if_different" can >> conflict, leading the whole build to fail. >> >> I see two options to fix this: >> >> 1. don't use copy_if_different, but a custom tool that can deal with the >> concurrency >> >> 2. instead of adding post-build actions to different targets, fill up a >> list containing all the files required, and add a single post-build >> action to a single target that copies all the required files in one go >> >> What do you think? > Had the same problem and went with #2 Hi Caleb, could you give some more details how you did this? Filling up the list is easy, but I am not sure how to define the final action that will copy all the DLLs, and make sure it happens only once. Did you define a new custom target for that? From mateusz at loskot.net Sat Dec 8 16:07:15 2018 From: mateusz at loskot.net (Mateusz Loskot) Date: Sat, 8 Dec 2018 22:07:15 +0100 Subject: [CMake] [MSVC] Setting warning level on target feels like long-time bug Message-ID: Hi, I define a target for a library, and set warning level for MSVC compiler: target_compile_options(mylib PRIVATE $<$:-W4>) Although this works well, the compiler throws this warning: cl : Command line warning D9025: overriding '/W3' with '/W4' I want to get rid of this warning, so I fix it this way if(MSVC) string(REGEX REPLACE "/W3" "" CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS}) string(REGEX REPLACE "-W3" "" CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS}) endif() target_compile_options(mylib PRIVATE $<$:-W4>) This works like charm, but leaves me with sour feeling that something is not right here.The REGEX REPLACE clean-up has become such a habit, it's almost canonical thing I do in all my CMake-based projects. Shouldn't CMake drop the default when target_compile_options is called? Is this behaviour by design, for MSVC? Could anyone help me to understand if this is actually a bug or am I misunderstanding anything? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net From mateusz at loskot.net Sat Dec 8 19:47:12 2018 From: mateusz at loskot.net (Mateusz Loskot) Date: Sun, 9 Dec 2018 01:47:12 +0100 Subject: [CMake] Can CXX_CLANG_TIDY use .clang-tidy file? Message-ID: Hi, Am I correct clang-tidy run via CXX_CLANG_TIDY ignores .clang-tidy configuration file? I've tried number of ways to help it find the file, i.e. copied the file to binary directories from where it seems run via usr/local/bin/cmake -E __run_co_compile --tidy=/usr/bin/clang-tidy-7 Best regards, -- Mateusz Loskot, http://mateusz.loskot.net From calebwherry at gmail.com Sat Dec 8 20:01:21 2018 From: calebwherry at gmail.com (J. Caleb Wherry) Date: Sat, 8 Dec 2018 20:01:21 -0500 Subject: [CMake] Concurrency issues with copy_if_different In-Reply-To: <7c7cf8b5-485b-6e16-643a-e8a31ee0584d@free.fr> References: <8a36e982-f9c2-2f8a-078e-9a961faf1673@free.fr> <7c7cf8b5-485b-6e16-643a-e8a31ee0584d@free.fr> Message-ID: Our case is pretty simplified in that almost every executable uses the dependent DLLs/SOs I need copied. For C# apps it is log4net, NDesk.Options, etc. For native apps it?s fmpeg shared libraries. So when I create the list at configure time, I immediately just use CMake to copy the files the where I want them in the build tree. This guarantees that they are copied the one time when CMake is run instead of at build time. A few things that make this work for us: * These libraries are checked into our repo so they aren?t changed by automatically pulling new binaries or anything like that. * We only have a handful of these dependent 3rd party libs, like 7. * Couldn?t think of a better way to do it. If you did want to move it to build time instead of configure time, you?d just have to make a custom target that every other target depends on. In some systems this isn?t easy but if you write wrappers around creating targets then you can do extra book keeping when a target is create. In this case, you just add another depends on the custom target that copies the dependent libs. -Caleb On Sat, Dec 8, 2018 at 7:14 PM Olivier Croquette wrote: > On 2018-7-12 15:16, J. Caleb Wherry wrote: > >> in one of our projects, we use copy_if_different to copy some DLLs > >> required by the runtime. It's called as post-build action. The problem > >> is that several targets want to copy the same DLLs, and when using > >> parallelized builds, the different "cmake -E copy_if_different" can > >> conflict, leading the whole build to fail. > >> > >> I see two options to fix this: > >> > >> 1. don't use copy_if_different, but a custom tool that can deal with the > >> concurrency > >> > >> 2. instead of adding post-build actions to different targets, fill up a > >> list containing all the files required, and add a single post-build > >> action to a single target that copies all the required files in one go > >> > >> What do you think? > > Had the same problem and went with #2 > > Hi Caleb, > > could you give some more details how you did this? Filling up the list > is easy, but I am not sure how to define the final action that will copy > all the DLLs, and make sure it happens only once. Did you define a new > custom target for that? > > > -- Sent from my iPhone SE -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig.scott at crascit.com Sun Dec 9 06:14:22 2018 From: craig.scott at crascit.com (Craig Scott) Date: Sun, 9 Dec 2018 22:14:22 +1100 Subject: [CMake] [MSVC] Setting warning level on target feels like long-time bug In-Reply-To: References: Message-ID: >From what I understand from a very limited quick search just now, it seems that /W3 is the default warning level for Visual Studio (according to the Microsoft docs ), but CMake explicitly adds it as a default compiler flag in CMAKE__FLAGS_INIT. This makes me wonder if it has always been the default, otherwise it isn't clear why it was deemed necessary to add it. More to the point, unless there's a reason not to, perhaps we could consider removing it from the default flags CMake sets. I think this would largely address the situation you're describing and shouldn't actually change the behavior of existing projects. I've CC'ed the developer's list and suggest that follow-up discussion should occur there. On Sun, Dec 9, 2018 at 8:07 AM Mateusz Loskot wrote: > Hi, > > I define a target for a library, and set warning level for MSVC compiler: > > target_compile_options(mylib PRIVATE $<$:-W4>) > > Although this works well, the compiler throws this warning: > > cl : Command line warning D9025: overriding '/W3' with '/W4' > > I want to get rid of this warning, so I fix it this way > > if(MSVC) > string(REGEX REPLACE "/W3" "" CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS}) > string(REGEX REPLACE "-W3" "" CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS}) > endif() > > target_compile_options(mylib PRIVATE $<$:-W4>) > > This works like charm, but leaves me with sour feeling that > something is not right here.The REGEX REPLACE clean-up > has become such a habit, it's almost canonical thing I do in > all my CMake-based projects. > > Shouldn't CMake drop the default when target_compile_options is called? > Is this behaviour by design, for MSVC? > Could anyone help me to understand if this is actually a bug > or am I misunderstanding anything? > > Best regards, > -- > Mateusz Loskot, http://mateusz.loskot.net > -- > > 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: > https://cmake.org/mailman/listinfo/cmake > -- Craig Scott Melbourne, Australia https://crascit.com New book released: Professional CMake: A Practical Guide -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig.scott at crascit.com Sun Dec 9 06:23:59 2018 From: craig.scott at crascit.com (Craig Scott) Date: Sun, 9 Dec 2018 22:23:59 +1100 Subject: [CMake] dependencies of cross compiliations In-Reply-To: <8F791FB5-4DA3-4353-A04E-3D809ED9976C@Robitzki.de> References: <7D02012F-99E4-44DA-96E3-C6D0D1955FD3@Robitzki.de> <8F791FB5-4DA3-4353-A04E-3D809ED9976C@Robitzki.de> Message-ID: On Tue, Dec 4, 2018 at 6:56 PM Torsten Robitzki wrote: > > Am 27.11.2018 um 19:55 schrieb Eric Noulard : > > > > However from my point of view and my cross-compiling experience when you > cross-compile you have: > > > > 1) the host compiler which is used to compile "host tools" > > 2) the target compiler (may be several of them) to "cross-compile" > > > > My assumption are: > > a) when you cross-compile your build is a "whole" and you shouldn't > have to setup some superbuild > > structure for building host tools ht_exe and another for target1 tool > t1t_exe and another one for target2 tool t2t_exe. > > > > b) what you want is to build: > > ht_exe for the host > > possibly use ht_exe during the build to generate some [source] file > > t1t_exe for the [cross]target1 > > t2t_exe for the [cross]target2 > > > > c) you seldomly compile the same source for the host AND the target, > but it may happen. > > In case, you are doing unit tests, it?s normal to have the same code > running in a test on the host platform and in the final binary on the > target. > > I think, having more than 1 target platform becomes more and more normal > as it becomes more usual to have multiple microcontrollers in a project. > > Previously, I have encoded this in the build type. So instead of just > having Debug and Release, I had HOST_Debug, HOST_Release NRF51_Debug, > NRF51_Release, STM8_Debug, STM8_Release and so on. It doesn?t annoy me very > much, that I have to run CMake 3 times to get all the binaries for a > release build. The problem that I have, are dependencies between this > builds. If I write a tool that (for example) generates source files for one > of the target platforms, the build for the host platform must run before > the build for that target platform. And when I make changes to that tool, I > want the build to regenerate the generated source files. > > Keeping track of this dependencies to solve this kind of ordering issues > and to allow minimum rebuilds, is the main purpose of any build system. To > solve this with CMake, I think we need a way to define the dependencies > between build types (in the example above, from the generator from the host > build to the generated source file in one of the target builds) and CMake > needs to know the build directory for all build types (not only the > current). > Perhaps a superbuild would be the cleanest approach here? The host tools would be one subproject and the cross-compile builds would depend on the host tools' build. You could then choose to build everything via the top level superbuild or just work on one of the subprojects if that's all you needed once the initial tools build had been done. You could even set up as many different sub-projects for the different architectures as needed. Packaging would require a little more work, but it shouldn't be prohibitively so. Another alternative is the approach described in this stackoverflow article which performs the host tools build off to the side in a secondary build during configure. This works well when the host tools don't change much (we use it extensively at work with very large, complex hierarchical projects). It wouldn't help though if you need to build more than one cross-compiled architecture. > > The wish-season is coming up, so that's sort of what I would like to > > have. Now it's your turn. No bikeshedding please, only deliveries ;) > > How about ``add_dependencies()`` allowing me to define dependencies > between different build types? :-) > A superbuild would already give you the equivalent capability. -- Craig Scott Melbourne, Australia https://crascit.com New book released: Professional CMake: A Practical Guide -------------- next part -------------- An HTML attachment was scrubbed... URL: From mateusz at loskot.net Sun Dec 9 07:31:39 2018 From: mateusz at loskot.net (Mateusz Loskot) Date: Sun, 9 Dec 2018 13:31:39 +0100 Subject: [CMake] [MSVC] Setting warning level on target feels like long-time bug In-Reply-To: References: Message-ID: On Sun, 9 Dec 2018 at 12:14, Craig Scott wrote: > > From what I understand from a very limited quick search just now, > it seems that /W3 is the default warning level for Visual Studio Yes, it is the default level indeed. > but CMake explicitly adds it as a default compiler flag in CMAKE__FLAGS_INIT. > This makes me wonder if it has always been the default, otherwise it isn't clear why it was deemed necessary to add it. Yes, I'd suspect it was added as 'just in case' too eagerly. > More to the point, unless there's a reason not to, perhaps we could consider removing it from the default flags CMake sets. > I think this would largely address the situation you're describing and shouldn't actually change the behavior of existing projects. Yes, it should be removed. Unless I'm missing an important reason behind the explicit -W3. No, "This has been the default since CMake began" [1], is not enough rationale to keep it. In the old times of manual editing of CMAKE_CXX_FLAGS, it was not a huge deal - in fact, fiddling with CMAKE_CXX_FLAGS was quite canonical way of doing things.. But with the advent of target_compile_options, the string call requirement is just unacceptable. [1] https://gitlab.kitware.com/cmake/cmake/issues/18317 > I've CC'ed the developer's list and suggest that follow-up discussion should occur there. FYI, I've just subscribed to the developer's list. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net From marc.chevrier at gmail.com Sun Dec 9 08:09:28 2018 From: marc.chevrier at gmail.com (Marc CHEVRIER) Date: Sun, 9 Dec 2018 14:09:28 +0100 Subject: [CMake] [MSVC] Setting warning level on target feels like long-time bug In-Reply-To: References: Message-ID: I think the discussion is shifting from the initial problem which was unwanted warning ??Command line warning D9025: overriding '/W3' with '/W4'??. Changing defaults is not a good idea from my point of view because relying on defaults can be problematic if Microsoft decide to change the default behaviour. Moreover, removing ?/W3? from defaults will remove the warning for this flag but the problem remains for all other flags possibly overloaded. The real question is how to manage cleanly target specific flags overriding global or directory defaults? And the frustrating thing is that cl.exe do not allow to disable D9025 warning! :( Le 9 d?c. 2018 ? 13:32 +0100, Mateusz Loskot , a ?crit : > On Sun, 9 Dec 2018 at 12:14, Craig Scott wrote: > > > > From what I understand from a very limited quick search just now, > > it seems that /W3 is the default warning level for Visual Studio > > Yes, it is the default level indeed. > > > but CMake explicitly adds it as a default compiler flag in CMAKE__FLAGS_INIT. > > This makes me wonder if it has always been the default, otherwise it isn't clear why it was deemed necessary to add it. > > Yes, I'd suspect it was added as 'just in case' too eagerly. > > > More to the point, unless there's a reason not to, perhaps we could consider removing it from the default flags CMake sets. > > I think this would largely address the situation you're describing and shouldn't actually change the behavior of existing projects. > > Yes, it should be removed. > Unless I'm missing an important reason behind the explicit -W3. > > No, "This has been the default since CMake began" [1], is not enough > rationale to keep it. > > In the old times of manual editing of CMAKE_CXX_FLAGS, it was not a huge deal > - in fact, fiddling with CMAKE_CXX_FLAGS was quite canonical way of > doing things.. > But with the advent of target_compile_options, the string call > requirement is just unacceptable. > > [1] https://gitlab.kitware.com/cmake/cmake/issues/18317 > > > I've CC'ed the developer's list and suggest that follow-up discussion should occur there. > > FYI, I've just subscribed to the developer's list. > > Best regards, > -- > Mateusz Loskot, http://mateusz.loskot.net > -- > > 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: > https://cmake.org/mailman/listinfo/cmake -------------- next part -------------- An HTML attachment was scrubbed... URL: From mateusz at loskot.net Sun Dec 9 08:55:21 2018 From: mateusz at loskot.net (Mateusz Loskot) Date: Sun, 9 Dec 2018 14:55:21 +0100 Subject: [CMake] [MSVC] Setting warning level on target feels like long-time bug In-Reply-To: References: Message-ID: On Sun, 9 Dec 2018 at 14:09, Marc CHEVRIER wrote: > > I think the discussion is shifting from the initial problem which was unwanted warning ? Command line warning D9025: overriding '/W3' with '/W4' ?. I disagree with your opinion. Fixing just the warning would be a symptomatic treatment. > Changing defaults is not a good idea from my point of view because relying on defaults can be problematic if Microsoft decide to change the default behaviour. Although I think it is a long shot at something that is (highly) unlikely to change, YAGNI consideration, I understand CMake developers may be reluctant to change the long-time defaults. > The real question is how to manage cleanly target specific flags overriding global or directory defaults? >From end-user point of view (I have not checekd CMake implementation), I'd either do not explicitly set -W defaults or strip any -W option prior re-setting with (possibly) new value passed to target_compile_options. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net From mingw.android at gmail.com Sun Dec 9 10:02:38 2018 From: mingw.android at gmail.com (Ray Donnelly) Date: Sun, 9 Dec 2018 09:02:38 -0600 Subject: [CMake] [cmake-developers] [MSVC] Setting warning level on target feels like long-time bug In-Reply-To: References: Message-ID: Cmake is already full of do much hardcoded logic / flags and does new releases so frequently (maybe there's some correlation between these two) that adding this would hardly impact upon its quality or maintainability. So to that end, hardcoding the default per msvc version so that it's not added unnecessarily, triggering this warning would seem appropriate to me. Either that or disabling this warning with more hard coded flags would also be appropriate. The current status in not ideal. On Sun, Dec 9, 2018, 7:55 AM Mateusz Loskot On Sun, 9 Dec 2018 at 14:09, Marc CHEVRIER > wrote: > > > > I think the discussion is shifting from the initial problem which was > unwanted warning ? Command line warning D9025: overriding '/W3' with '/W4' > ?. > > I disagree with your opinion. > Fixing just the warning would be a symptomatic treatment. > > > Changing defaults is not a good idea from my point of view because > relying on defaults can be problematic if Microsoft decide to change the > default behaviour. > > Although I think it is a long shot at something that is (highly) > unlikely to change, YAGNI consideration, > I understand CMake developers may be reluctant to change the long-time > defaults. > > > The real question is how to manage cleanly target specific flags > overriding global or directory defaults? > > From end-user point of view (I have not checekd CMake implementation), > I'd either do not explicitly set -W defaults or strip any -W option > prior re-setting > with (possibly) new value passed to target_compile_options. > > Best regards, > -- > Mateusz Loskot, http://mateusz.loskot.net > -- > > 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: > https://cmake.org/mailman/listinfo/cmake-developers > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zbeekman at gmail.com Sun Dec 9 21:36:58 2018 From: zbeekman at gmail.com (Zaak Beekman) Date: Sun, 9 Dec 2018 21:36:58 -0500 Subject: [CMake] Correct way to specify multiple build configurations for single config generators? Message-ID: I have been reading the *excellent* book "Professional CMake". The author, Craig Scott, recommends the following best practices: - check the existence of `CMAKE_CONFIGURATION_TYPES` and only adding or pruning configurations if it's preset, *AFTER* your call to `project()` - do not set `CMAKE_CONFIGURATION_TYPES` and use the `STRINGS` property on `CMAKE_BUILD_TYPE` for single config generators - forcibly set the `CMAKE_BUILD_TYPE` cache variable if it is unset, otherwise check the passed `CMAKE_BUILD_TYPE` against allowable configs and throw an error if it differs - set `CMAKE__FLAGS_` and `CMAKE__LINKER_FLAGS_` variables as cache variables for newly defined configuration The problem I encounter is that, if I set `-DCMAKE_BUILD_TYPE:STRING=` to CMake on the command line, then CMake seems to initialize all of the `` cache variables to the empty string *BEFORE* I can set them. All other custom configurations get set to my specified default cache variable value. What is the best practice for setting the new configuration's default flags? I am aware of `CMAKE_USER_MAKE_RULES_OVERRIDE` and all of the `CMAKE__FLAGS__INIT` variable, but as far as I can tell, there is no access to knowing what compiler is being used, since the compilers have yet to be probed. Is it possible to use the `CMAKE_..._INIT` variables to set per-compiler flags some how? Any answers or pointers here would be most appreciated. FYI, Before being enlightened to some of the dangers or non-standard ways of what I was doing, I would typically set `CMAKE_CONFIGURATION_TYPES` *before* my call to `project()`. Something like this: ```cmake set ( CMAKE_CONFIGURATION_TYPES "Debug" "Release" "MinSizeRel" "RelWithDebInfo" "CodeCoverage" ) set ( CMAKE_BUILD_TYPE "Release" CACHE STRING "Select which configuration to build." ) set_property ( CACHE CMAKE_BUILD_TYPE PROPERTY STRINGS ${CMAKE_CONFIGURATION_TYPES} ) ``` I would then call `project()` so that the compilers would be probed and I could make specific flag choices based on the compiler being used, and set those as Cache variables. Something like this: ```cmake if ("${CMAKE_Fortran_COMPILER_ID}" MATCHES "GNU" ) set(gfortran_compiler true) set ( CMAKE_C_FLAGS_CODECOVERAGE "-fprofile-arcs -ftest-coverage -O0" CACHE STRING "Code coverage C compiler flags") set ( CMAKE_Fortran_FLAGS_CODECOVERAGE "-fprofile-arcs -ftest-coverage -O0" CACHE STRING "Code coverage Fortran compiler flags") ``` This seemed to work fine and specifying, e.g., `-DCMAKE_BUILD_TYPE:STRING=CodeCoverage`, the `CMAKE__FLAGS_CODECOVERAGE` cache variable would be set to the appropriate value. Thanks for taking the time to read my question. -Zaak -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.noulard at gmail.com Mon Dec 10 03:57:24 2018 From: eric.noulard at gmail.com (Eric Noulard) Date: Mon, 10 Dec 2018 09:57:24 +0100 Subject: [CMake] dependencies of cross compiliations In-Reply-To: References: <7D02012F-99E4-44DA-96E3-C6D0D1955FD3@Robitzki.de> <8F791FB5-4DA3-4353-A04E-3D809ED9976C@Robitzki.de> Message-ID: Le dim. 9 d?c. 2018 ? 12:24, Craig Scott a ?crit : > On Tue, Dec 4, 2018 at 6:56 PM Torsten Robitzki > wrote: > >> > Am 27.11.2018 um 19:55 schrieb Eric Noulard : >> > >> > My assumption are: >> > a) when you cross-compile your build is a "whole" and you shouldn't >> have to setup some superbuild >> > structure for building host tools ht_exe and another for target1 >> tool t1t_exe and another one for target2 tool t2t_exe. >> > >> > b) what you want is to build: >> > ht_exe for the host >> > possibly use ht_exe during the build to generate some [source] file >> > t1t_exe for the [cross]target1 >> > t2t_exe for the [cross]target2 >> > >> > c) you seldomly compile the same source for the host AND the target, >> but it may happen. >> >> In case, you are doing unit tests, it?s normal to have the same code >> running in a test on the host platform and in the final binary on the >> target. >> >> I think, having more than 1 target platform becomes more and more normal >> as it becomes more usual to have multiple microcontrollers in a project. >> > Yes that's why I thought it was worth going further than host + target, but host + tgt1 + tg2 + .... > >> Previously, I have encoded this in the build type. So instead of just >> having Debug and Release, I had HOST_Debug, HOST_Release NRF51_Debug, >> NRF51_Release, STM8_Debug, STM8_Release and so on. It doesn?t annoy me very >> much, that I have to run CMake 3 times to get all the binaries for a >> release build. The problem that I have, are dependencies between this >> builds. If I write a tool that (for example) generates source files for one >> of the target platforms, the build for the host platform must run before >> the build for that target platform. And when I make changes to that tool, I >> want the build to regenerate the generated source files. >> >> Keeping track of this dependencies to solve this kind of ordering issues >> and to allow minimum rebuilds, is the main purpose of any build system. To >> solve this with CMake, I think we need a way to define the dependencies >> between build types (in the example above, from the generator from the host >> build to the generated source file in one of the target builds) and CMake >> needs to know the build directory for all build types (not only the >> current). >> > > Perhaps a superbuild would be the cleanest approach here? The host tools > would be one subproject and the cross-compile builds would depend on the > host tools' build. You could then choose to build everything via the top > level superbuild or just work on one of the subprojects if that's all you > needed once the initial tools build had been done. You could even set up as > many different sub-projects for the different architectures as needed. > Packaging would require a little more work, but it shouldn't be > prohibitively so. > I guess the tough part is to find a [light] way to specify dependencies between host target build and the various target builds. > Another alternative is the approach described in this stackoverflow > article > > which performs the host tools build off to the side in a secondary build > during configure. This works well when the host tools don't change much (we > use it extensively at work with very large, complex hierarchical projects). > It wouldn't help though if you need to build more than one cross-compiled > architecture. > > > The wish-season is coming up, so that's sort of what I would like to >> > have. Now it's your turn. No bikeshedding please, only deliveries ;) >> >> How about ``add_dependencies()`` allowing me to define dependencies >> between different build types? :-) >> > > A superbuild would already give you the equivalent capability. > Not as easy as it seems right? I bet you know it well as you listed the dependencies shortcoming of adding dependencies for External_ProjectAdd in your book (?27.1.4). -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig.scott at crascit.com Mon Dec 10 05:22:31 2018 From: craig.scott at crascit.com (Craig Scott) Date: Mon, 10 Dec 2018 21:22:31 +1100 Subject: [CMake] dependencies of cross compiliations In-Reply-To: References: <7D02012F-99E4-44DA-96E3-C6D0D1955FD3@Robitzki.de> <8F791FB5-4DA3-4353-A04E-3D809ED9976C@Robitzki.de> Message-ID: On Mon, Dec 10, 2018 at 7:57 PM Eric Noulard wrote: > > Le dim. 9 d?c. 2018 ? 12:24, Craig Scott a > ?crit : > >> On Tue, Dec 4, 2018 at 6:56 PM Torsten Robitzki >> wrote: >> >>> > Am 27.11.2018 um 19:55 schrieb Eric Noulard : >>> > >>> > My assumption are: >>> > a) when you cross-compile your build is a "whole" and you shouldn't >>> have to setup some superbuild >>> > structure for building host tools ht_exe and another for target1 >>> tool t1t_exe and another one for target2 tool t2t_exe. >>> > >>> > b) what you want is to build: >>> > ht_exe for the host >>> > possibly use ht_exe during the build to generate some [source] >>> file >>> > t1t_exe for the [cross]target1 >>> > t2t_exe for the [cross]target2 >>> > >>> > c) you seldomly compile the same source for the host AND the target, >>> but it may happen. >>> >>> In case, you are doing unit tests, it?s normal to have the same code >>> running in a test on the host platform and in the final binary on the >>> target. >>> >>> I think, having more than 1 target platform becomes more and more normal >>> as it becomes more usual to have multiple microcontrollers in a project. >>> >> > Yes that's why I thought it was worth going further than host + target, > but host + tgt1 + tg2 + .... > > >> >>> Previously, I have encoded this in the build type. So instead of just >>> having Debug and Release, I had HOST_Debug, HOST_Release NRF51_Debug, >>> NRF51_Release, STM8_Debug, STM8_Release and so on. It doesn?t annoy me very >>> much, that I have to run CMake 3 times to get all the binaries for a >>> release build. The problem that I have, are dependencies between this >>> builds. If I write a tool that (for example) generates source files for one >>> of the target platforms, the build for the host platform must run before >>> the build for that target platform. And when I make changes to that tool, I >>> want the build to regenerate the generated source files. >>> >>> Keeping track of this dependencies to solve this kind of ordering issues >>> and to allow minimum rebuilds, is the main purpose of any build system. To >>> solve this with CMake, I think we need a way to define the dependencies >>> between build types (in the example above, from the generator from the host >>> build to the generated source file in one of the target builds) and CMake >>> needs to know the build directory for all build types (not only the >>> current). >>> >> >> Perhaps a superbuild would be the cleanest approach here? The host tools >> would be one subproject and the cross-compile builds would depend on the >> host tools' build. You could then choose to build everything via the top >> level superbuild or just work on one of the subprojects if that's all you >> needed once the initial tools build had been done. You could even set up as >> many different sub-projects for the different architectures as needed. >> Packaging would require a little more work, but it shouldn't be >> prohibitively so. >> > > I guess the tough part is to find a [light] way to specify dependencies > between host target build and the various target builds. > > >> Another alternative is the approach described in this stackoverflow >> article >> >> which performs the host tools build off to the side in a secondary build >> during configure. This works well when the host tools don't change much (we >> use it extensively at work with very large, complex hierarchical projects). >> It wouldn't help though if you need to build more than one cross-compiled >> architecture. >> >> > The wish-season is coming up, so that's sort of what I would like to >>> > have. Now it's your turn. No bikeshedding please, only deliveries ;) >>> >>> How about ``add_dependencies()`` allowing me to define dependencies >>> between different build types? :-) >>> >> >> A superbuild would already give you the equivalent capability. >> > > Not as easy as it seems right? > I bet you know it well as you listed the dependencies shortcoming of > adding dependencies for External_ProjectAdd in your book (?27.1.4). > For a strict superbuild arrangement, handling straight dependencies to get build order correct is not too bad. This is what I was thinking of with my earlier comment that super builds essentially give you the equivalent capability as just using add_dependencies(). You can also usually define CMAKE_PREFIX_PATH to pass sub-project install locations between the sub-projects and they each find what they need from the others without much further help. The top level superbuild is then really just specifying which sub-projects depend on which other ones. That does require a little bit of boilerplate, agreed, but not crazy amounts. Where it starts getting out of hand is when you want to have a main build that directly wants/needs to refer to targets from sub-projects brought in by ExternalProject. Then you have to go working out where everything is without much help from CMake and that can be a soul-destroying exercise for complex multi-platform projects. Packaging suffers from this if done from the top superbuild project, but the difficulty can sometimes be reduced by doing the packaging itself as another subproject and importing what it needs from the others (you can then use the various imported targets, etc. to locate things), but it's still not particularly clean. But yes, I'm agreeing with you, it isn't all that simple once you start considering the full software delivery process (i.e. going beyond more than just getting things to build). -- Craig Scott Melbourne, Australia https://crascit.com New book released: Professional CMake: A Practical Guide -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig.scott at crascit.com Mon Dec 10 06:34:34 2018 From: craig.scott at crascit.com (Craig Scott) Date: Mon, 10 Dec 2018 22:34:34 +1100 Subject: [CMake] Correct way to specify multiple build configurations for single config generators? In-Reply-To: References: Message-ID: On Mon, Dec 10, 2018 at 1:37 PM Zaak Beekman wrote: > I have been reading the *excellent* book "Professional CMake". The author, > Craig Scott, recommends the following best practices: > > - check the existence of `CMAKE_CONFIGURATION_TYPES` and only adding > or pruning configurations if it's preset, *AFTER* your call to `project()` > - do not set `CMAKE_CONFIGURATION_TYPES` and use the `STRINGS` > property on `CMAKE_BUILD_TYPE` for single config generators > - forcibly set the `CMAKE_BUILD_TYPE` cache variable if it is unset, > otherwise check the passed `CMAKE_BUILD_TYPE` against allowable configs and > throw an error if it differs > - set `CMAKE__FLAGS_` and > `CMAKE__LINKER_FLAGS_` variables as cache variables for > newly defined configuration > > The problem I encounter is that, if I set > `-DCMAKE_BUILD_TYPE:STRING=` to CMake on the command line, then > CMake seems to initialize all of the `` cache variables to the > empty string *BEFORE* I can set them. All other custom configurations get > set to my specified default cache variable value. > > What is the best practice for setting the new configuration's default > flags? > This is only going to be an issue for single-configuration generators. For multi-config generators, you don't set CMAKE_BUILD_TYPE and the flags you set as cache variables after the first project() call should be honoured. For single-config generators, you have a few choices: - Run CMake with CMAKE_BUILD_TYPE set to some other config first, then change it to the one you want after the first run. If the custom config is one that is only occasionally used and typically just one you switch to temporarily from time-to-time, then this may be okay for your situation. It's also easy enough to handle in a CI build, albeit slightly less efficient since you have to run CMake twice. It's a bit annoying, but it is at least easy. - Rather than setting the custom config's flags in the project, do it in a toolchain file instead (with the various ...__INIT variables). The flags are going to be toolchain-specific anyway, so you don't lose generality. You also gain the advantage that you can take that same toolchain file and apply it to other projects, so you get better reusability. This would be what I would use personally, but I'm comfortable with toolchain files. The main downside to this approach is that those new to CMake can feel a bit intimidated by toolchain files or see them as an unnecessary complication for a build that should just pick up the default compilers and work out of the box. It's a tradeoff, so I erred on the side of simplicity in the book and didn't make toolchains a recommendation for defining custom configs. If you and your users are happy with toolchain files though, I'd go this route. - You could set your custom config's cache variables (again I'd recommend setting the ...__INIT variables) before the first project() command, but you won't have the compiler ID or any other compiler information at that point. You also won't have any of the default configs' flags available to you, so you can't make your custom config an extension of an existing one (e.g. you can't start with flags from, say, RelWithDebInfo and add a few more to enable profiling like in the book's example). If your project only needs to consider one compiler and the flags are simple and well-defined, this is going to be the easiest for your developers, since it will work out-of-the-box with no extra effort on their part. - Instead of setting cache variables, you could append to regular non-cache ... variables after the project() command. This has the advantage of being simple, but your config-specific flags won't show in the cache and developers can't override them without editing the project. So as you can see from the above, there's no one perfect solution. The best choice really depends on your project and your users. > > I am aware of `CMAKE_USER_MAKE_RULES_OVERRIDE` and all of the > `CMAKE__FLAGS__INIT` variable, but as far as I > can tell, there is no access to knowing what compiler is being used, since > the compilers have yet to be probed. Is it possible to use the > `CMAKE_..._INIT` variables to set per-compiler flags some how? > Use a toolchain file where you are in control of which compiler is selected. Use different toolchain files for different compilers. > Any answers or pointers here would be most appreciated. > > FYI, Before being enlightened to some of the dangers or non-standard ways > of what I was doing, I would typically set `CMAKE_CONFIGURATION_TYPES` > *before* my call to `project()`. Something like this: > > ```cmake > set ( CMAKE_CONFIGURATION_TYPES "Debug" "Release" "MinSizeRel" > "RelWithDebInfo" "CodeCoverage" ) > set ( CMAKE_BUILD_TYPE "Release" > CACHE STRING "Select which configuration to build." ) > set_property ( CACHE CMAKE_BUILD_TYPE PROPERTY STRINGS > ${CMAKE_CONFIGURATION_TYPES} ) > ``` > > I would then call `project()` so that the compilers would be probed and I > could make specific flag choices based on the compiler being used, and set > those as Cache variables. Something like this: > > ```cmake > if ("${CMAKE_Fortran_COMPILER_ID}" MATCHES "GNU" ) > set(gfortran_compiler true) > set ( CMAKE_C_FLAGS_CODECOVERAGE "-fprofile-arcs -ftest-coverage -O0" > CACHE STRING "Code coverage C compiler flags") > set ( CMAKE_Fortran_FLAGS_CODECOVERAGE "-fprofile-arcs -ftest-coverage > -O0" > CACHE STRING "Code coverage Fortran compiler flags") > ``` > > This seemed to work fine and specifying, e.g., > `-DCMAKE_BUILD_TYPE:STRING=CodeCoverage`, the > `CMAKE__FLAGS_CODECOVERAGE` cache variable would be set to the > appropriate value. > This didn't work for me, it showed the same problem you described in your original issue. Perhaps you forgot to clear out a previous build first? It would only work after an initial run of CMake where you didn't set CMAKE_BUILD_TYPE or you set it to something else. -- Craig Scott Melbourne, Australia https://crascit.com New book released: Professional CMake: A Practical Guide -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Mon Dec 10 07:16:38 2018 From: brad.king at kitware.com (Brad King) Date: Mon, 10 Dec 2018 07:16:38 -0500 Subject: [CMake] [MSVC] Setting warning level on target feels like long-time bug In-Reply-To: References: Message-ID: <4c137c69-702d-5fe6-d01d-f1bb7ad51786@kitware.com> On 12/9/18 8:09 AM, Marc CHEVRIER wrote: > The real question is how to manage cleanly target specific flags > overriding global or directory defaults? All the optimization and warning flags currently handled by `CMAKE__FLAGS[_]` need to have abstractions introduced (e.g. target properties or something) and the defaults re-thought. Transition can be handled via a policy. -Brad From Felix.Ramold at kuka.com Mon Dec 10 07:30:13 2018 From: Felix.Ramold at kuka.com (Ramold, Felix) Date: Mon, 10 Dec 2018 12:30:13 +0000 Subject: [CMake] Testing our CMake Modules Message-ID: <4565d613bcd74c63853f891ba0b9ef13@DEAU1SVMAIL03.kuka.int.kuka.com> We created multiple additional functions for CMake. They became quite a lot, and we need to (unit) test them. There are simple ones, that are only variable bases like: function(join_list LIST GLUE) These can be tested with a custom CMake Script, that checks the results. For this we also wrote a set of assert-macros. This becomes way harder when the functions are target based: function(target_my_custom_property_set TARGET VALUE) We need a multiple CMakeLists.txt Files that need to be configured. Configuration must succeed or fail with specified messages. Also the result files must be checked. I wonder, is there an easier way? Is there a existing framework? How does Kitware test the shipped modules? Note: My original Stackoverflow question: https://stackoverflow.com/questions/51948060/testing-our-cmake-modules Thanks, Felix -------------- next part -------------- An HTML attachment was scrubbed... URL: From kai.wolf at gmail.com Mon Dec 10 07:47:08 2018 From: kai.wolf at gmail.com (Kai Wolf) Date: Mon, 10 Dec 2018 13:47:08 +0100 Subject: [CMake] Testing our CMake Modules In-Reply-To: <4565d613bcd74c63853f891ba0b9ef13@DEAU1SVMAIL03.kuka.int.kuka.com> References: <4565d613bcd74c63853f891ba0b9ef13@DEAU1SVMAIL03.kuka.int.kuka.com> Message-ID: They (Kitware) typically write custom .cmake files to test the function/macro under test coupled together with a CMakeLists.txt file and/or a small C/C++ implementation file. Look here [1] for some examples, for instance CMake/Tests/MacroTest. Greetings, Kai http://kai-wolf.me http://effective-cmake.com [1] https://github.com/Kitware/CMake/tree/master/Tests > Am 10.12.2018 um 13:30 schrieb Ramold, Felix : > > We created multiple additional functions for CMake. They became quite a lot, and we need to (unit) test them. > There are simple ones, that are only variable bases like: > function(join_list LIST GLUE) > These can be tested with a custom CMake Script, that checks the results. For this we also wrote a set of assert-macros. > This becomes way harder when the functions are target based: > function(target_my_custom_property_set TARGET VALUE) > We need a multiple CMakeLists.txt Files that need to be configured. Configuration must succeed or fail with specified messages. Also the result files must be checked. > I wonder, is there an easier way? Is there a existing framework? How does Kitware test the shipped modules? > Note: My original Stackoverflow question: https://stackoverflow.com/questions/51948060/testing-our-cmake-modules > > Thanks, > Felix > -- > > 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: > https://cmake.org/mailman/listinfo/cmake -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: Message signed with OpenPGP URL: From zbeekman at gmail.com Mon Dec 10 09:46:17 2018 From: zbeekman at gmail.com (Zaak Beekman) Date: Mon, 10 Dec 2018 09:46:17 -0500 Subject: [CMake] Correct way to specify multiple build configurations for single config generators? In-Reply-To: References: Message-ID: Hi Craig, et al, Craig, once again, thank you for writing such a great reference and learning book! I have a few responses inline below. On Mon, Dec 10, 2018 at 6:34 AM Craig Scott wrote: > This is only going to be an issue for single-configuration generators. For > multi-config generators, you don't set CMAKE_BUILD_TYPE and the flags you > set as cache variables after the first project() call should be honoured. > For single-config generators, you have a few choices: > > - Run CMake with CMAKE_BUILD_TYPE set to some other config first, then > change it to the one you want after the first run. If the custom config is > one that is only occasionally used and typically just one you switch to > temporarily from time-to-time, then this may be okay for your situation. > It's also easy enough to handle in a CI build, albeit slightly less > efficient since you have to run CMake twice. It's a bit annoying, but it is > at least easy. > > Come to think of it, this might be why my example below was working. During the CI process for that project we test the different configurations, so if the config is in question is *not* set first, then it's cache variables have a chance to initialize themselves before the build is switched to that config. > > - Rather than setting the custom config's flags in the project, do it > in a toolchain file instead (with the various ...__INIT variables). > The flags are going to be toolchain-specific anyway, so you don't lose > generality. You also gain the advantage that you can take that same > toolchain file and apply it to other projects, so you get better > reusability. This would be what I would use personally, but I'm comfortable > with toolchain files. The main downside to this approach is that those new > to CMake can feel a bit intimidated by toolchain files or see them as an > unnecessary complication for a build that should just pick up the default > compilers and work out of the box. It's a tradeoff, so I erred on the side > of simplicity in the book and didn't make toolchains a recommendation for > defining custom configs. If you and your users are happy with toolchain > files though, I'd go this route. > > Hhhmmm. Looks like I'm off to read about toolchain files. Fingers crossed its covered in your book! > > - You could set your custom config's cache variables (again I'd > recommend setting the ...__INIT variables) before the first > project() command, but you won't have the compiler ID or any other compiler > information at that point. You also won't have any of the default configs' > flags available to you, so you can't make your custom config an extension > of an existing one (e.g. you can't start with flags from, say, > RelWithDebInfo and add a few more to enable profiling like in the book's > example). If your project only needs to consider one compiler and the flags > are simple and well-defined, this is going to be the easiest for your > developers, since it will work out-of-the-box with no extra effort on their > part. > - Instead of setting cache variables, you could append to regular > non-cache ... variables after the project() command. This has the > advantage of being simple, but your config-specific flags won't show in the > cache and developers can't override them without editing the project. > > I find cache variables to be a large enough source of confusion as it is. In my experience users rarely use ccmake or cmake-gui. They tend to give up if they can't pass a few flags on the command line and achieve the desired results. And if they do, and see one value of the variable, yet the project seems to use a different value caused by shadowing the cache variable with a regular variable, this leads to extreme confusion. I am aware of `CMAKE_USER_MAKE_RULES_OVERRIDE` and all of the >> `CMAKE__FLAGS__INIT` variable, but as far as I >> can tell, there is no access to knowing what compiler is being used, since >> the compilers have yet to be probed. Is it possible to use the >> `CMAKE_..._INIT` variables to set per-compiler flags some how? >> > > Use a toolchain file where you are in control of which compiler is > selected. Use different toolchain files for different compilers. > I actually just seem to have had some success through the combination of `CMAKE_..._INIT` variables passed in `CMAKE_USER_MAKE_RULES_OVERRIDE` when used in combination with setting the corresponding CACHE variables in the CMakeLists.txt. Now, this may not be a robust solution because it relies on some interesting behavior of the `if()` statement used from the `CMAKE_USER_MAKE_RULES_OVERRIDE` file. In the file specified by `CMAKE_USER_MAKE_RULES_OVERRIDE` includes `if()` statements of the form `if("${CMAKE_C_COMPILER_ID}" STREQUAL "GNU")` then the following code block is never actually executed. However, if one uses `if(CMAKE_C_COMPILER_ID STREQUAL "GNU")` it seems that the evaluation of the `if()` statement is deferred until a point in which the value of `CMAKE_C_COMPILER` has already been set. It sounds like ToolChain files are probably a better solution here, however, It's nice that this quick and dirty trick seems to work (at least during my testing with 3.10 on Linux....). Does anyone have any insight into if this will be a robust and reliable approach? This didn't work for me, it showed the same problem you described in your > original issue. Perhaps you forgot to clear out a previous build first? It > would only work after an initial run of CMake where you didn't set > CMAKE_BUILD_TYPE or you set it to something else. > Yes, That is probably true. This config is normally just used under CI testing in which we loop through the build configs, starting with standard pre-defined ones. So the cache is probably set by a previous call with CMAKE_BUILD_TYPE set to Debug or something. Thanks for the swift response and the great book! -Zaak -------------- next part -------------- An HTML attachment was scrubbed... URL: From robb at datalogics.com Mon Dec 10 11:33:09 2018 From: robb at datalogics.com (Rob Boehne) Date: Mon, 10 Dec 2018 16:33:09 +0000 Subject: [CMake] [cmake-developers] [MSVC] Setting warning level on target feels like long-time bug In-Reply-To: References: Message-ID: <2FF0BBDB-0247-4228-8386-6B6E3A92621E@datalogics.com> I?m going to chime in here and say that IMO, it really isn?t the build system generator?s responsibility to set a warning level. CMake maintainers should consider these questions when deciding on what to do with this issue: *) Does CMake set the compiler?s warning flags on all platforms? *) How does setting the warning flag impact users? (as in this thread, and elsewhere) This is (to me anyway) not a question as to whether /w3 should be removed from the defaults, but whether the compiler?s default warning level should be silently overridden by using CMake. The advantages to keeping it, are (IMHO) 1) Users who rely on this won?t be surprised if they care about, but don?t specify warning level for MSVC ? and they use a version or configuration where /w3 is not the default. I can?t think of a second advantage of keeping this. I can think of quite a few reasons why keeping this behavior would be bad ? suppose the compiler implementation changes ? now CMake is responsible for keeping the same warnings on From: CMake on behalf of Ray Donnelly Date: Sunday, December 9, 2018 at 9:03 AM To: Mateusz Loskot Cc: CMake , "cmake at cmake.org" Subject: Re: [CMake] [cmake-developers] [MSVC] Setting warning level on target feels like long-time bug Cmake is already full of do much hardcoded logic / flags and does new releases so frequently (maybe there's some correlation between these two) that adding this would hardly impact upon its quality or maintainability. So to that end, hardcoding the default per msvc version so that it's not added unnecessarily, triggering this warning would seem appropriate to me. Either that or disabling this warning with more hard coded flags would also be appropriate. The current status in not ideal. On Sun, Dec 9, 2018, 7:55 AM Mateusz Loskot wrote: On Sun, 9 Dec 2018 at 14:09, Marc CHEVRIER > wrote: > > I think the discussion is shifting from the initial problem which was unwanted warning ? Command line warning D9025: overriding '/W3' with '/W4' ?. I disagree with your opinion. Fixing just the warning would be a symptomatic treatment. > Changing defaults is not a good idea from my point of view because relying on defaults can be problematic if Microsoft decide to change the default behaviour. Although I think it is a long shot at something that is (highly) unlikely to change, YAGNI consideration, I understand CMake developers may be reluctant to change the long-time defaults. > The real question is how to manage cleanly target specific flags overriding global or directory defaults? From end-user point of view (I have not checekd CMake implementation), I'd either do not explicitly set -W defaults or strip any -W option prior re-setting with (possibly) new value passed to target_compile_options. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net -- 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: https://cmake.org/mailman/listinfo/cmake-developers -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.hoffman at kitware.com Mon Dec 10 12:31:38 2018 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Mon, 10 Dec 2018 12:31:38 -0500 Subject: [CMake] Can CXX_CLANG_TIDY use .clang-tidy file? In-Reply-To: References: Message-ID: <155d0851-42d3-e1f7-b48a-df8185595fa0@kitware.com> On 12/8/2018 7:47 PM, Mateusz Loskot wrote: > Hi, > > Am I correct clang-tidy run via CXX_CLANG_TIDY > ignores .clang-tidy configuration file? > > I've tried number of ways to help it find the file, > i.e. copied the file to binary directories from where it seems run via > usr/local/bin/cmake -E __run_co_compile --tidy=/usr/bin/clang-tidy-7 I don't think anything was done to turn that off on purpose.? Can you run the command from the command line and get it to work?? If so, you should be able to get the same arguments to the clang tidy that CMake is running. -Bill From dmacq at instantiations.com Mon Dec 10 15:57:09 2018 From: dmacq at instantiations.com (Donald MacQueen [|]) Date: Mon, 10 Dec 2018 15:57:09 -0500 Subject: [CMake] CDash suggestions Message-ID: <096629aa-77a7-b228-ee92-4d9e4a083813@instantiations.com> I just installed CDash and I have a few suggestions about improving the documentation. Is this the place for it? -- Donald [|] A bad day in [] is better than a good day in {}. From wo-is-jo at web.de Tue Dec 11 07:06:39 2018 From: wo-is-jo at web.de (wo-is-jo at web.de) Date: Tue, 11 Dec 2018 13:06:39 +0100 Subject: [CMake] Re-configure depending on Python script output Message-ID: An HTML attachment was scrubbed... URL: From zack.galbreath at kitware.com Tue Dec 11 14:59:51 2018 From: zack.galbreath at kitware.com (Zack Galbreath) Date: Tue, 11 Dec 2018 14:59:51 -0500 Subject: [CMake] CDash suggestions In-Reply-To: <096629aa-77a7-b228-ee92-4d9e4a083813@instantiations.com> References: <096629aa-77a7-b228-ee92-4d9e4a083813@instantiations.com> Message-ID: On Mon, Dec 10, 2018 at 3:57 PM Donald MacQueen [|] < dmacq at instantiations.com> wrote: > I just installed CDash and I have a few suggestions about improving the > documentation. > > Is this the place for it? > Please feel free to file an issue on our GitHub repository. https://github.com/Kitware/CDash/issues -------------- next part -------------- An HTML attachment was scrubbed... URL: From attila.krasznahorkay at gmail.com Wed Dec 12 04:49:31 2018 From: attila.krasznahorkay at gmail.com (Attila Krasznahorkay) Date: Wed, 12 Dec 2018 10:49:31 +0100 Subject: [CMake] DEPFILE usage in add_custom_command(...) Message-ID: Dear All, I'm trying to use the DEPFILE argument of add_custom_command(...) to be able to tell Ninja exactly when it should re-run that custom command. But unfortunately I'm not able to get it to work as I'd like. :-( I'm running a custom command that processes a header file through a custom executable. (It's a long story, see https://gitlab.kitware.com/cmake/cmake/issues/18695 and https://gitlab.kitware.com/cmake/cmake/issues/16830 for some more details.) I run that custom executable using a script file that I generate during the CMake configuration. In that script file I generate a dependency file using: set( cmd "${cmd}${CMAKE_CXX_COMPILER} -I\"$\"" ) set( cmd "${cmd} -D$" ) if( CMAKE_OSX_SYSROOT ) set( cmd "${cmd} -isysroot ${CMAKE_OSX_SYSROOT}" ) endif() set( cmd "${cmd} -MM -MT ${rootmap_name} -MF ${dictname}.d ${ARG_HEADER}\n" ) This then results in a file like: /Users/krasznaa/ATLAS/sw/projects/volatile/externals/build_test/DictionaryPackage/CMakeFiles/DictionaryPackageDict.dsomap: \ /Users/krasznaa/ATLAS/sw/projects/volatile/externals/build_test/DictionaryPackage/CMakeFiles/DictionaryPackageDict.h \ /Users/krasznaa/ATLAS/sw/projects/volatile/externals/CMakeDictionaryTests/DictionaryPackage/DictionaryPackage/MyClass.h \ /Users/krasznaa/ATLAS/sw/projects/volatile/externals/CMakeDictionaryTests/DictionaryPackage/DictionaryPackage/HelperHeader.h \ /Users/krasznaa/ATLAS/sw/projects/volatile/externals/CMakeDictionaryTests/DictionaryPackage/DictionaryPackage/MyOtherClass.h \ /Users/krasznaa/ATLAS/sw/projects/volatile/externals/CMakeDictionaryTests/AthLinks/AthLinks/DataLink.h \ /Users/krasznaa/ATLAS/sw/projects/volatile/externals/CMakeDictionaryTests/AthLinks/AthLinks/ElementLink.h \ /Users/krasznaa/ATLAS/sw/projects/volatile/externals/CMakeDictionaryTests/AthLinks/AthLinks/ElementLinkVector.h \ /Users/krasznaa/ATLAS/sw/projects/volatile/externals/CMakeDictionaryTests/AthContainers/AthContainers/tools/AuxTypeVectorFactory.h Which looks correct to me. The generated Ninja file refers to this dependency file with: ############################################# # Custom command for DictionaryPackage/CMakeFiles/DictionaryPackageDict.dsomap build DictionaryPackage/CMakeFiles/DictionaryPackageDict.dsomap DictionaryPackage/CMakeFiles/DictionaryPackageDictReflexDict.cxx x86_64-mac1014-clang100-opt/lib/libDictionaryPackageDict_rdict.pcm: CUSTOM_COMMAND DictionaryPackage/CMakeFiles/DictionaryPackageDict.h /Users/krasznaa/ATLAS/sw/projects/volatile/externals/CMakeDictionaryTests/DictionaryPackage/DictionaryPackage/DictionaryPackageDict.h DictionaryPackage/CMakeFiles/selection.xml DictionaryPackage/CMakeFiles/DictionaryPackageDict.h /Users/krasznaa/ATLAS/sw/projects/volatile/externals/CMakeDictionaryTests/DictionaryPackage/DictionaryPackage/DictionaryPackageDict.h COMMAND = cd /Users/krasznaa/ATLAS/sw/projects/volatile/externals/build_test/DictionaryPackage/CMakeFiles && /Users/krasznaa/Software/CMake/3.11.4/bin/cmake -E make_directory /Users/krasznaa/ATLAS/sw/projects/volatile/externals/build_test/x86_64-mac1014-clang100-opt/lib && sh /Users/krasznaa/ATLAS/sw/projects/volatile/externals/build_test/DictionaryPackage/CMakeFiles/makeDictionaryPackageDictReflexDict.sh DESC = Generating DictionaryPackageDictReflexDict.cxx depfile = /Users/krasznaa/ATLAS/sw/projects/volatile/externals/build_test/DictionaryPackage/CMakeFiles/DictionaryPackageDictReflexDict.d restat = 1 Which again, looks correct to me. But... This setup results in Ninja *always* re-running this command on every re-build. Even when I didn't modify any of the files referenced in that dependency file. :-( Does anyone have an idea what I'm doing wrong? Unfortunately I didn't manage to find examples of using DEPFILE that would've helped me further than this... Any help would be very much appreciated. Cheers, Attila From mateusz at loskot.net Wed Dec 12 06:19:49 2018 From: mateusz at loskot.net (Mateusz Loskot) Date: Wed, 12 Dec 2018 12:19:49 +0100 Subject: [CMake] Can CXX_CLANG_TIDY use .clang-tidy file? In-Reply-To: <155d0851-42d3-e1f7-b48a-df8185595fa0@kitware.com> References: <155d0851-42d3-e1f7-b48a-df8185595fa0@kitware.com> Message-ID: On Mon, 10 Dec 2018 at 18:31, Bill Hoffman via CMake wrote: > On 12/8/2018 7:47 PM, Mateusz Loskot wrote: > > > > Am I correct clang-tidy run via CXX_CLANG_TIDY > > ignores .clang-tidy configuration file? > > > > I've tried number of ways to help it find the file, > > i.e. copied the file to binary directories from where it seems run via > > usr/local/bin/cmake -E __run_co_compile --tidy=/usr/bin/clang-tidy-7 > > I don't think anything was done to turn that off on purpose. Can you > run the command from the command line and get it to work? If so, you > should be able to get the same arguments to the clang tidy that CMake is > running. Bill, Thank you for the hint. It helped to discover it turns out to be a silly issue. My .clang-tidy listed checks that would issue no warnings for the target source files :) Since, apparently, clang-tidy via /usr/local/bin/cmake -E __run_co_compile --tidy=/usr/bin/clang-tidy-7 runs in quiet mode, while when run directly /usr/bin/clang-tidy-7, it outputs a brief summary even if no analysis warnings are issued. That left me with impression, .clang-tidy is not used. To summary, for records and others looking for similar answers, here is what works for me: 1. .clang-tidy is in source root directory 2. Top-level CMakeLists.txt ``` find_program(CLANG_TIDY NAMES clang-tidy-7 clang-tidy-6.0 clang-tidy-5.0 clang-tidy-4.0 clang-tidy ``` and ``` set_target_properties(test_headers_all_in_one PROPERTIES CXX_CLANG_TIDY ${CLANG_TIDY}) ``` Notice, since checks are specified in .clang-tidy configuration file, no arguments need to be specified to clang-tidy. 3. Build analysed target ``` $ cd project $ cmake -S . -B _build -DBoost_ARCHITECTURE=-x64 .. $ VERBOSE=1 cmake --build _build --target test_headers_all_in_one # alternative to the last command may be $ cd _build $ VERBOSE=1 make test_headers_all_in_one ``` Both, will run clang-tidy with checks read from .clang-tidy config, and output of any warnings. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net From dodungocorporation at gmail.com Wed Dec 12 08:01:24 2018 From: dodungocorporation at gmail.com (Ciccio Pasticcio) Date: Wed, 12 Dec 2018 14:01:24 +0100 Subject: [CMake] Dependency managment Message-ID: Hi all, we are trying to re-design the build system of an existing complex project using cmake. We have a source tree such this (it is only an example to help explaining the problem) . ??? libs ??? CMakeLists.txt ??? libA ? ??? CMakeLists.txt ? ??? include ? ? ??? libA.h ? ??? source ? ??? libA.cpp ??? libB ??? CMakeLists.txt ??? include ? ??? libB.h ??? source ??? libB.cpp The tree contains libraries and executables and many of them have some dependencies to be satisfied. We wrote a CMakeLists.txt file on top of the hyerarchy which repetitively uses the add_directory directive to build every project under it. This solution seems to work well until a project needs another one to be built; in other words, we did not find out how to deal with dependencies. Looking at the tree above, we can compile libA but we cannot compile libB without installing libA because the latter needs it. What's the right and easy way to make a target globally available or at least available for projects on the same level? Thanks, Gabriele -------------- next part -------------- An HTML attachment was scrubbed... URL: From attila.krasznahorkay at gmail.com Wed Dec 12 08:12:29 2018 From: attila.krasznahorkay at gmail.com (Attila Krasznahorkay) Date: Wed, 12 Dec 2018 14:12:29 +0100 Subject: [CMake] Dependency managment In-Reply-To: References: Message-ID: <8EEC9DCD-6DA9-417A-AFEC-FE97DCD31CED@gmail.com> Hi Gabriele, What do you mean exactly by "we can compile libA but we cannot compile libB without installing libA because the latter needs it"? o.O Are you trying to find libA in libs/libB/CMakeLists.txt with find_package(...)? "Normal" targets (libraries and executables) should be globally visible after you defined them. This is the default behaviour of CMake. So if you define libA correctly, you would just need to link libB against it (using target_link_libraries(...)) for the whole thing to work correctly. (libB waiting for libA to finish, and then using its headers and linking against its library file.) There are literally countless number of examples out there in the wild for doing this. Here is one example for instance: https://gitlab.com/atomki-nuclear-phys/cda That project also very generously uses add_subdirectory(...). And targets in the subdirectories depend on each other in not completely trivial ways. (Mind you, as long as you set everything up correctly, it doesn't even matter in which order you include the subdirectories. It's fine to first include one that depends on a library whose definition is only included later on.) Cheers, Attila > On 12 Dec 2018, at 14:01, Ciccio Pasticcio wrote: > > Hi all, > we are trying to re-design the build system of an existing complex project using cmake. > We have a source tree such this (it is only an example to help explaining the problem) > > . > ??? libs > ??? CMakeLists.txt > ??? libA > ? ??? CMakeLists.txt > ? ??? include > ? ? ??? libA.h > ? ??? source > ? ??? libA.cpp > ??? libB > ??? CMakeLists.txt > ??? include > ? ??? libB.h > ??? source > ??? libB.cpp > > The tree contains libraries and executables and many of them have some dependencies to be > satisfied. We wrote a CMakeLists.txt file on top of the hyerarchy which repetitively uses the > add_directory directive to build every project under it. This solution seems to work well > until a project needs another one to be built; in other words, we did not find out how to deal > with dependencies. Looking at the tree above, we can compile libA but we cannot compile libB without > installing libA because the latter needs it. What's the right and easy way to make a target globally > available or at least available for projects on the same level? > > Thanks, > Gabriele > -- > > 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: > https://cmake.org/mailman/listinfo/cmake From Luca.Beldi at twentyfouram.com Wed Dec 12 12:53:06 2018 From: Luca.Beldi at twentyfouram.com (Luca Beldi) Date: Wed, 12 Dec 2018 17:53:06 +0000 Subject: [CMake] FindBZip2 fails to set BZIP2_NEED_PREFIX if using x64 Message-ID: <641B65E58A04934CA96AFBC7BD48036E19593C3C@joi-exm03.justoneinbox.com> Hi Everyone, I posted a bug ticket (https://gitlab.kitware.com/cmake/cmake/issues/18701) but I?m not sure if this is a bug in CMake or I just missed something. Configuring a project that contains find_package(BZip2) cmake "Visual Studio 14 2015" ../ will correctly produce -- Looking for BZ2_bzCompressInit -- Looking for BZ2_bzCompressInit - found while cmake "Visual Studio 14 2015" -A x64 ../ will erroneously show -- Looking for BZ2_bzCompressInit -- Looking for BZ2_bzCompressInit - not found Using "NMake Makefiles" as generator will bear identical results for the 32 and 64 bit versions. Tested with CMake 3.13.1 Anyone experienced this before? Thanks, Luca Beldi This communication may contain privileged or confidential information. If you are not the intended recipient, you are hereby notified that you have received this message in error and that any review, dissemination, distribution or copying of this message is strictly prohibited. Any views or opinions presented are solely those of the author and do not necessarily represent those of TwentyFour Asset Management LLP or their affiliates. If you have received this communication in error, please notify us immediately by email, and delete the original message. We do not waive confidentiality by mis-transmission. This communication is directed in the UK to those persons who are Eligible Counterparties or Professional Clients (as defined by the Financial Conduct Authority). This is not an offer, or solicitation of any offer to buy or sell any security, investment or other product. TwentyFour Asset Management LLP treats all personal data in accordance with the Data Protection Act 1998 and is duly registered with the Information Commissioner?s Office as a Data Controller. Personal data is only retained and used by us as a means of communication and will not be released to any other parties. TwentyFour Asset Management LLP is a Limited Liability Partnership incorporated in England under Partnership No. OC335015 with its registered office at 8th Floor, The Monument Building, 11 Monument Street, London, EC3R 8AF and is authorised and regulated in the UK by the Financial Conduct Authority, FRN No.481888. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bjorn.blissing at vti.se Wed Dec 12 13:31:58 2018 From: bjorn.blissing at vti.se (=?iso-8859-1?Q?Bj=F6rn_Blissing?=) Date: Wed, 12 Dec 2018 18:31:58 +0000 Subject: [CMake] Changed behavior of CPACK_PACKAGE_VERSION generation? Message-ID: Hi, Today we discovered that our generated CPACK_PACKAGE_VERSION variables were broken. This is probably related to us updating to a newer version of CMake. Previously we generated this variable by setting the CPACK_PACKAGE_VERSION_MAJOR and CPACK_PACKAGE_VERSION_MINOR to fixed values, while CPACK_PACKAGE_VERSION_PATCH was set to variable name. This name was then replaced by running a custom target just before building. In this target the variable name got replaced with the current SVN revision number. This have worked the last years, but now the variable name just gets omitted when we run "generate" in CMake. A short example: ================ cmake_minimum_required(VERSION 2.8.9) project (hello) add_executable(hello helloworld.cpp) set(CPACK_PACKAGE_VERSION_MAJOR "1") set(CPACK_PACKAGE_VERSION_MINOR "0") set(CPACK_PACKAGE_VERSION_PATCH "REPLACEME") include(CPack) Would result in the following strings in CPackConfig.cmake: ----------------------------------------------------------- set(CPACK_PACKAGE_VERSION "1.0.REPLACEME") set(CPACK_PACKAGE_VERSION_MAJOR "1") set(CPACK_PACKAGE_VERSION_MINOR "0") set(CPACK_PACKAGE_VERSION_PATCH "REPLACEME") But with the CMake 3.12.2 this will be: --------------------------------------- set(CPACK_PACKAGE_VERSION "1.0") set(CPACK_PACKAGE_VERSION_MAJOR "1") set(CPACK_PACKAGE_VERSION_MINOR "0") set(CPACK_PACKAGE_VERSION_PATCH "REPLACEME") So our CPACK_PACKAGE_VERSION will omit the variable name, which in turn makes our custom target to fail. Our quick fix was to add the following line to our CMakeList.txt file: SET(CPACK_PACKAGE_VERSION "${CPACK_PACKAGE_VERSION_MAJOR}.${CPACK_PACKAGE_VERSION_MINOR}.${CPACK_PACKAGE_VERSION_PATCH}") My question is: Is this change of behavior intended? Are only numbers allowed to be part of the CPack version variable? Regards Bj?rn Blissing From robert.maynard at kitware.com Wed Dec 12 14:27:12 2018 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 12 Dec 2018 14:27:12 -0500 Subject: [CMake] [ANNOUNCE] cmake.org and gitlab.kitware.com downtime Message-ID: CMake Users, Kitware NY is moving into a new office building on Dec 15th. This involves moving the company's network infrastructure. As a result, there will be downtime for cmake.org, cmake.org/cmake/help/, open.cdash.org, and gitlab.kitware.com. We expect that these sites will be unavailable all day Dec. 15th while we physically move everything and complete the network cutover. There is a good chance of network connectivity being unstable for a few days afterwards while we troubleshoot and fix any issues. From robert.maynard at kitware.com Thu Dec 13 09:11:20 2018 From: robert.maynard at kitware.com (Robert Maynard) Date: Thu, 13 Dec 2018 09:11:20 -0500 Subject: [CMake] [ANNOUNCE] CMake 3.13.2 available for download Message-ID: We are pleased to announce that CMake 3.13.2 is now available for download. Please use the latest release from our download page: https://cmake.org/download/ * CMake 3.13.0 included a change to pass compiler implicit include directories to the "moc" tool for "AUTOMOC". This has been reverted due to regressing existing builds and will need further investigation before being re-introduced in a later release. Thanks for your support! ------------------------------------------------------------------------- Changes in 3.13.2 since 3.13.1: Anton Chernov (1): CUDA: Add CUDA 10 (Turing) detection Brad King (2): CUDA: Fix crash on linking to a CUDA target without CUDA enabled CMake 3.13.2 Nils Gladitz (1): CPack/External: Fix status messages of staging scripts Sebastian Holtermann (1): Autogen: Revert passing compiler implicit includes to moc From dschepler at scalable-networks.com Thu Dec 13 13:27:09 2018 From: dschepler at scalable-networks.com (Daniel Schepler) Date: Thu, 13 Dec 2018 18:27:09 +0000 Subject: [CMake] How to link in different prebuilt objects based on configuration Message-ID: We have a build here where a large portion of our product is in source code available to customers, but then there is a core which we only distribute as prebuilt "private objects". However, then when we test the customer-type build on Windows, we get an error like: --- CMake Error in CMakeLists.txt: Target "exata" has source files which vary by configuration. This is not supported by the "Visual Studio 15 2017 Win64" generator. Config "Debug": E:/EXata_7_0/qualnet_dev_13_Dec18/kernel/obj/exata-main-windows-x64-vc14d.obj Config "Release": E:/EXata_7_0/qualnet_dev_13_Dec18/kernel/obj/exata-main-windows-x64-vc14.obj --- (This object file is marked with source file property EXTERNAL_OBJECT=1.) Is this a limitation in Visual Studio projects, or a limitation in CMake? In either case, what workaround could allow this build to support generating Visual Studio projects? -- Daniel Schepler -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alain.Miniussi at oca.eu Fri Dec 14 04:44:58 2018 From: Alain.Miniussi at oca.eu (Alain Miniussi) Date: Fri, 14 Dec 2018 10:44:58 +0100 Subject: [CMake] Preventing add_custom_command from removing output Message-ID: <7c0049a0-419d-7550-0b55-a72b88d84b6e@oca.eu> Hi, I have a source file (version.cpp) I need to generate trough a script. What the script does is - generate a version.cpp.new file - if version.cpp does not exists or is different from version.cpp.new, copy version.cpp.new into version.cpp ------------------- add_custom_command(OUTPUT version.cpp always ? COMMAND ? bash -x ${CMAKE_SOURCE_DIR}/tools/dev/gen_version.sh ${CMAKE_CURRENT_BINARY_DIR}/version.cpp? ) set_source_files_properties(version.cpp PROPERTIES GENERATED TRUE) ----------------- the 'always' target is here to make sure the script is alway called (in case the version changed). Unfortunately, it seems that add_custom_command will delete its output before calling the command. As a result the version.cpp's dependancies are always bult. Is there a way to prevent that deletion ? Thanks -- ----- Alain Miniussi DSI, P?les Calcul et Genie Log. T?l. : +33492003009 (Mont-Gros) T?l. : +33483618544 (Sophia Antipolis) From paulwjeffries at gmail.com Fri Dec 14 11:48:32 2018 From: paulwjeffries at gmail.com (Paul Jeffries) Date: Fri, 14 Dec 2018 10:48:32 -0600 Subject: [CMake] Make errors when running ./bootstrap in Ubuntu 12.04 Message-ID: Dear list, I ultimately want to install a program called DosageConvertor that requires a version of cmake that is 3.2 or later. Therefore, I am trying to install a more recent version of cmake since the current version is 2.8.7. When I run ./bootstrap, I get a message that there were problems running make: 2 errors generated. make: *** [cmAddCustomCommandCommand.o] Error 1 (I have added the complete output below.) I searched and found no clear solution to this problem. I did see that std should be set to gnu++11, but my output has ?std=gnu++1y?. I specified the compiler because when I ran ./bootstrap by itself, I got an error message that there was no C++ compiler. Did I choose the wrong compiler? Am I missing a library? Any help would be appreciated. Paul paul at paul-VirtualBox:~/cmake-3.13.1$ CC=gcc ./bootstrap && make && sudo make install---------------------------------------------CMake 3.13.1, Copyright 2000-2018 Kitware, Inc. and ContributorsC compiler on this system is: gcc C++ compiler on this system is: clang++ -std=gnu++1y Makefile processor on this system is: makeclang++ has setenvclang++ has unsetenvclang++ does not have environ in stdlib.hclang++ has stl wstringclang++ has ---------------------------------------------clang++ -std=gnu++1y -I/home/paul/cmake-3.13.1/Bootstrap.cmk -I/home/paul/cmake-3.13.1/Source -I/home/paul/cmake- 3.13.1/Source/LexerParser -I/home/paul/cmake-3.13.1/Utilities -c /home/paul/cmake-3.13.1/Source/cmAddCustomCommandCommand.cxx -o cmAddCustomCommandCommand.o In file included from /home/paul/cmake-3.13.1/Source/cmAddCustomCommandCommand.cxx:9:In file included from /home/paul/cmake-3.13.1/Source/cmCustomCommand.h:9: /home/paul/cmake-3.13.1/Source/cmListFileCache.h:127:3: error: exception specification of explicitly defaulted move constructor does not match the cmListFileBacktrace(cmListFileBacktrace&&) // NOLINT(clang-tidy) ^ /home/paul/cmake-3.13.1/Source/cmListFileCache.h:130:24: error: exception specification of explicitly defaulted move assignment operator does not match the calculated one cmListFileBacktrace& operator=(cmListFileBacktrace&&) // NOLINT(clang-tidy) ^2 errors generated.make: *** [cmAddCustomCommandCommand.o] Error 1---------------------------------------------Error when bootstrapping CMake:Problem while running make---------------------------------------------Log of errors: /home/paul/cmake-3.13.1/Bootstrap.cmk/cmake_bootstrap.log---------------------------------------------paul at paul-VirtualBox:~/cmake-3.13.1$ -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.noulard at gmail.com Fri Dec 14 12:02:07 2018 From: eric.noulard at gmail.com (Eric Noulard) Date: Fri, 14 Dec 2018 18:02:07 +0100 Subject: [CMake] Make errors when running ./bootstrap in Ubuntu 12.04 In-Reply-To: References: Message-ID: Did you try to pick a pre-compiled version of CMake? https://cmake.org/download/ https://github.com/Kitware/CMake/releases/download/v3.13.2/cmake-3.13.2-Linux-x86_64.tar.gz CMake is statically linked so installing a binary should work. Le ven. 14 d?c. 2018 ? 17:48, Paul Jeffries a ?crit : > Dear list, > > I ultimately want to install a program called DosageConvertor that > requires a version of cmake that is 3.2 or later. Therefore, I am trying to > install a more recent version of cmake since the current version is 2.8.7. > > When I run ./bootstrap, I get a message that there were problems running > make: 2 errors generated. make: *** [cmAddCustomCommandCommand.o] Error 1 > (I have added the complete output below.) > > I searched and found no clear solution to this problem. I did see that std > should be set to gnu++11, but my output has ?std=gnu++1y?. > > I specified the compiler because when I ran ./bootstrap by itself, I got > an error message that there was no C++ compiler. Did I choose the wrong > compiler? Am I missing a library? > > Any help would be appreciated. > > Paul > > paul at paul-VirtualBox:~/cmake-3.13.1$ CC=gcc ./bootstrap && make && sudo make install---------------------------------------------CMake 3.13.1, Copyright 2000-2018 Kitware, Inc. and ContributorsC compiler on this system is: gcc C++ compiler on this system is: clang++ -std=gnu++1y Makefile processor on this system is: makeclang++ has setenvclang++ has unsetenvclang++ does not have environ in stdlib.hclang++ has stl wstringclang++ has ---------------------------------------------clang++ -std=gnu++1y -I/home/paul/cmake-3.13.1/Bootstrap.cmk -I/home/paul/cmake-3.13.1/Source -I/home/paul/cmake- 3.13.1/Source/LexerParser -I/home/paul/cmake-3.13.1/Utilities -c /home/paul/cmake-3.13.1/Source/cmAddCustomCommandCommand.cxx -o cmAddCustomCommandCommand.o In file included from /home/paul/cmake-3.13.1/Source/cmAddCustomCommandCommand.cxx:9:In file included from /home/paul/cmake-3.13.1/Source/cmCustomCommand.h:9: /home/paul/cmake-3.13.1/Source/cmListFileCache.h:127:3: error: exception specification of explicitly defaulted move constructor does not match the cmListFileBacktrace(cmListFileBacktrace&&) // NOLINT(clang-tidy) ^ /home/paul/cmake-3.13.1/Source/cmListFileCache.h:130:24: error: exception specification of explicitly defaulted move assignment operator does not match the calculated one cmListFileBacktrace& operator=(cmListFileBacktrace&&) // NOLINT(clang-tidy) ^2 errors generated.make: *** [cmAddCustomCommandCommand.o] Error 1---------------------------------------------Error when bootstrapping CMake:Problem while running make---------------------------------------------Log of errors: /home/paul/cmake-3.13.1/Bootstrap.cmk/cmake_bootstrap.log---------------------------------------------paul at paul-VirtualBox:~/cmake-3.13.1$ > > > > > -- > > 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: > https://cmake.org/mailman/listinfo/cmake > -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From juan.e.sanchez at gmail.com Fri Dec 14 12:41:01 2018 From: juan.e.sanchez at gmail.com (Juan E. Sanchez) Date: Fri, 14 Dec 2018 11:41:01 -0600 Subject: [CMake] Make errors when running ./bootstrap in Ubuntu 12.04 In-Reply-To: References: Message-ID: <3ef88a5f-3969-54da-cf51-9f9db71eef7b@gmail.com> The original poster is using Ubuntu 12.04, so a precompiled binary might not work if it targeted a newer system. Ubuntu 12.04 is obsolete and no longer supported by Canonical and is a huge risk for production systems. I would suggest the original poster try installing gnu gcc c++ instead of clang. Please see: https://askubuntu.com/questions/26498/how-to-choose-the-default-gcc-and-g-version Regards, Juan On 12/14/18 11:02 AM, Eric Noulard wrote: > Did you try to pick a pre-compiled version of CMake? > https://cmake.org/download/ > > https://github.com/Kitware/CMake/releases/download/v3.13.2/cmake-3.13.2-Linux-x86_64.tar.gz > CMake is statically linked so installing a binary should work. > > Le?ven. 14 d?c. 2018 ??17:48, Paul Jeffries > a ?crit?: > > Dear list, > > I ultimately want to install a program called DosageConvertor that > requires a version of cmake that is 3.2 or later. Therefore, I am > trying to install a more recent version of cmake since the current > version is 2.8.7. > > When I run ./bootstrap, I get a message that there were problems > running make: 2 errors generated. make: *** > [cmAddCustomCommandCommand.o] Error 1 (I have added the complete > output below.) > > I searched and found no clear solution to this problem. I did see > that std should be set to gnu++11, but my output has ?std=gnu++1y?. > > I specified the compiler because when I ran ./bootstrap by itself, I > got an error message that there was no C++ compiler. Did I choose > the wrong compiler? Am I missing a library? > > Any help would be appreciated. > > Paul > > |paul at paul-VirtualBox:~/cmake-3.13.1$ CC=gcc ./bootstrap && make && > sudo make install| > |---------------------------------------------| > |CMake 3.13.1, Copyright 2000-2018 Kitware, Inc. and Contributors| > |C compiler on this system is: gcc | > |C++ compiler on this system is: clang++ -std=gnu++1y | > |Makefile processor on this system is: make| > |clang++ has setenv| > |clang++ has unsetenv| > |clang++ does not have environ in stdlib.h| > |clang++ has stl wstring| > |clang++ has | > |---------------------------------------------| > |clang++ -std=gnu++1y -I/home/paul/cmake-3.13.1/Bootstrap.cmk > -I/home/paul/cmake-3.13.1/Source -I/home/paul/cmake- > 3.13.1/Source/LexerParser | > |-I/home/paul/cmake-3.13.1/Utilities -c > /home/paul/cmake-3.13.1/Source/cmAddCustomCommandCommand.cxx -o > cmAddCustomCommandCommand.o | > |In file included from > /home/paul/cmake-3.13.1/Source/cmAddCustomCommandCommand.cxx:9:| > |In file included from > /home/paul/cmake-3.13.1/Source/cmCustomCommand.h:9: | > |/home/paul/cmake-3.13.1/Source/cmListFileCache.h:127:3: error: > exception specification of explicitly defaulted move constructor > does not match the cmListFileBacktrace(cmListFileBacktrace&&) // > NOLINT(clang-tidy)| > |||^ /home/paul/cmake-3.13.1/Source/cmListFileCache.h:130:24: error: > exception specification of explicitly defaulted move assignment > operator does not match the calculated one cmListFileBacktrace& > operator=(cmListFileBacktrace&&) // NOLINT(clang-tidy)| > |||^| > |2 errors generated.| > |make: *** [cmAddCustomCommandCommand.o] Error 1| > |---------------------------------------------| > |Error when bootstrapping CMake:| > |Problem while running make| > |---------------------------------------------| > |Log of errors: > /home/paul/cmake-3.13.1/Bootstrap.cmk/cmake_bootstrap.log| > |---------------------------------------------| > |paul at paul-VirtualBox:~/cmake-3.13.1$ | > > > > > -- > > 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: > https://cmake.org/mailman/listinfo/cmake > > > > -- > Eric > From robert.maynard at kitware.com Fri Dec 14 15:27:54 2018 From: robert.maynard at kitware.com (Robert Maynard) Date: Fri, 14 Dec 2018 15:27:54 -0500 Subject: [CMake] Make errors when running ./bootstrap in Ubuntu 12.04 In-Reply-To: <3ef88a5f-3969-54da-cf51-9f9db71eef7b@gmail.com> References: <3ef88a5f-3969-54da-cf51-9f9db71eef7b@gmail.com> Message-ID: The precompiled binaries would be your best option as they are built with older platforms in mind. If you try to build from source you should set the CC and CXX environment flags, as your output is mismatched ( it is grabbing clang for C++, and gcc for C ). On Fri, Dec 14, 2018 at 12:41 PM Juan E. Sanchez wrote: > > The original poster is using Ubuntu 12.04, so a precompiled binary might > not work if it targeted a newer system. Ubuntu 12.04 is obsolete and no > longer supported by Canonical and is a huge risk for production systems. > > I would suggest the original poster try installing gnu gcc c++ instead > of clang. > > Please see: > https://askubuntu.com/questions/26498/how-to-choose-the-default-gcc-and-g-version > > Regards, > > Juan > > On 12/14/18 11:02 AM, Eric Noulard wrote: > > Did you try to pick a pre-compiled version of CMake? > > https://cmake.org/download/ > > > > https://github.com/Kitware/CMake/releases/download/v3.13.2/cmake-3.13.2-Linux-x86_64.tar.gz > > CMake is statically linked so installing a binary should work. > > > > Le ven. 14 d?c. 2018 ? 17:48, Paul Jeffries > > a ?crit : > > > > Dear list, > > > > I ultimately want to install a program called DosageConvertor that > > requires a version of cmake that is 3.2 or later. Therefore, I am > > trying to install a more recent version of cmake since the current > > version is 2.8.7. > > > > When I run ./bootstrap, I get a message that there were problems > > running make: 2 errors generated. make: *** > > [cmAddCustomCommandCommand.o] Error 1 (I have added the complete > > output below.) > > > > I searched and found no clear solution to this problem. I did see > > that std should be set to gnu++11, but my output has ?std=gnu++1y?. > > > > I specified the compiler because when I ran ./bootstrap by itself, I > > got an error message that there was no C++ compiler. Did I choose > > the wrong compiler? Am I missing a library? > > > > Any help would be appreciated. > > > > Paul > > > > |paul at paul-VirtualBox:~/cmake-3.13.1$ CC=gcc ./bootstrap && make && > > sudo make install| > > |---------------------------------------------| > > |CMake 3.13.1, Copyright 2000-2018 Kitware, Inc. and Contributors| > > |C compiler on this system is: gcc | > > |C++ compiler on this system is: clang++ -std=gnu++1y | > > |Makefile processor on this system is: make| > > |clang++ has setenv| > > |clang++ has unsetenv| > > |clang++ does not have environ in stdlib.h| > > |clang++ has stl wstring| > > |clang++ has | > > |---------------------------------------------| > > |clang++ -std=gnu++1y -I/home/paul/cmake-3.13.1/Bootstrap.cmk > > -I/home/paul/cmake-3.13.1/Source -I/home/paul/cmake- > > 3.13.1/Source/LexerParser | > > |-I/home/paul/cmake-3.13.1/Utilities -c > > /home/paul/cmake-3.13.1/Source/cmAddCustomCommandCommand.cxx -o > > cmAddCustomCommandCommand.o | > > |In file included from > > /home/paul/cmake-3.13.1/Source/cmAddCustomCommandCommand.cxx:9:| > > |In file included from > > /home/paul/cmake-3.13.1/Source/cmCustomCommand.h:9: | > > |/home/paul/cmake-3.13.1/Source/cmListFileCache.h:127:3: error: > > exception specification of explicitly defaulted move constructor > > does not match the cmListFileBacktrace(cmListFileBacktrace&&) // > > NOLINT(clang-tidy)| > > |||^ /home/paul/cmake-3.13.1/Source/cmListFileCache.h:130:24: error: > > exception specification of explicitly defaulted move assignment > > operator does not match the calculated one cmListFileBacktrace& > > operator=(cmListFileBacktrace&&) // NOLINT(clang-tidy)| > > |||^| > > |2 errors generated.| > > |make: *** [cmAddCustomCommandCommand.o] Error 1| > > |---------------------------------------------| > > |Error when bootstrapping CMake:| > > |Problem while running make| > > |---------------------------------------------| > > |Log of errors: > > /home/paul/cmake-3.13.1/Bootstrap.cmk/cmake_bootstrap.log| > > |---------------------------------------------| > > |paul at paul-VirtualBox:~/cmake-3.13.1$ | > > > > > > > > > > -- > > > > 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: > > https://cmake.org/mailman/listinfo/cmake > > > > > > > > -- > > 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: > https://cmake.org/mailman/listinfo/cmake From personwithhats2 at gmail.com Fri Dec 14 17:47:21 2018 From: personwithhats2 at gmail.com (Person Withhats) Date: Fri, 14 Dec 2018 14:47:21 -0800 Subject: [CMake] Tracking progress of CMake-ran TAR Message-ID: When tarting files from CMake (in order to use cross-platform work-ability and what not) it'd be great to have a progress bar of any sort. It's awkward to wait 30-60 minutes for file untarring with absolutely 0 information. I'm not aware of any way to do this through CMake directly, only alternative is e.g. python script that does the untar for me. Any suggestions? -------------- next part -------------- An HTML attachment was scrubbed... URL: From osmanzakir90 at hotmail.com Sat Dec 15 12:48:08 2018 From: osmanzakir90 at hotmail.com (Osman Zakir) Date: Sat, 15 Dec 2018 17:48:08 +0000 Subject: [CMake] Finding Boost (1.69.0)? Message-ID: Would the way for finding Boost that I saw before when I asked about doing it for version 1.68.0 also work for version 1.69.0? If so, I could just try to find the archive of older threads and search for that message. If not, please tell me here how to do it. Either way, any help would be appreciated. I'm currently trying to generate project files for Jinja2Cpp with CMake, using Boost version 1.69.0 this time, while using the -DBOOST_ROOT flag. But it keeps saying that one or more Boost modules wasn't found and that it's using the submodule that comes with the Jinja2Cpp source code. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Simon.Richter at hogyros.de Sat Dec 15 18:44:31 2018 From: Simon.Richter at hogyros.de (Simon Richter) Date: Sun, 16 Dec 2018 00:44:31 +0100 Subject: [CMake] Finding Boost (1.69.0)? In-Reply-To: References: Message-ID: Hi, On 15.12.18 18:48, Osman Zakir wrote: > Would the way for finding Boost that I saw before when I asked about > doing it for version 1.68.0 also work for version 1.69.0? Some versions of FindBoost.cmake only check a fixed list of versions. You can extend this list by passing in e.g. -DBoost_ADDITIONAL_VERSIONS=1.66;1.67;1.68;1.69 Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From dmacq at instantiations.com Sun Dec 16 14:41:05 2018 From: dmacq at instantiations.com (Donald MacQueen [|]) Date: Sun, 16 Dec 2018 14:41:05 -0500 Subject: [CMake] How to set CTEST_BUILD_NAME Message-ID: I want to do something like set(CTEST_BUILD_NAME {CMAKE_SYSTEM_NAME}_someLocalVariable) I tried putting this ^^ in CTestConfig.cmake with no luck. I searched the docs and the archives from 2014 to the present and nothing jumped out at me. 2) Is there a list of what can be set/used in CTestConfig.cmake? Thanks. -- Donald [|] A bad day in [] is better than a good day in {}. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus From craig.scott at crascit.com Sun Dec 16 15:22:21 2018 From: craig.scott at crascit.com (Craig Scott) Date: Mon, 17 Dec 2018 07:22:21 +1100 Subject: [CMake] How to set CTEST_BUILD_NAME In-Reply-To: References: Message-ID: On Mon, Dec 17, 2018 at 6:41 AM Donald MacQueen [|] < dmacq at instantiations.com> wrote: > I want to do something like set(CTEST_BUILD_NAME > {CMAKE_SYSTEM_NAME}_someLocalVariable) > > I tried putting this ^^ in CTestConfig.cmake with no luck. > > I searched the docs and the archives from 2014 to the present and > nothing jumped out at me. > > 2) Is there a list of what can be set/used in CTestConfig.cmake? > The variables are not all collected together conveniently, but the Dashboard Client section of the ctest command does list the supported variables associated with each command. It would seem like setting CTEST_BUILD_NAME should work based on those docs, so perhaps if you could point us as a minimal complete example which demonstrates your problem, that might give more clues as to what's happening for you. -- Craig Scott Melbourne, Australia https://crascit.com New book released: Professional CMake: A Practical Guide -------------- next part -------------- An HTML attachment was scrubbed... URL: From personwithhats2 at gmail.com Sun Dec 16 16:31:25 2018 From: personwithhats2 at gmail.com (Person Withhats) Date: Sun, 16 Dec 2018 13:31:25 -0800 Subject: [CMake] Tracking progress of CMake TAR Message-ID: When running tar via CMake (in order to use cross-platform work-ability and what not) it'd be great to have a progress bar of any sort. It's awkward to wait 30-60 minutes for file untarring with absolutely 0 information. I'm not aware of any way to do this through CMake directly, only alternative is e.g. python script that does the untar for me. Any suggestions? (sorry if this is reposted, can't remember if acc was approved before or after sending one time) -------------- next part -------------- An HTML attachment was scrubbed... URL: From xavier.besseron at uni.lu Sun Dec 16 18:15:48 2018 From: xavier.besseron at uni.lu (Xavier Besseron) Date: Mon, 17 Dec 2018 00:15:48 +0100 Subject: [CMake] How to set CTEST_BUILD_NAME In-Reply-To: References: Message-ID: Hi Donald, For my project, I do it this way. In my CMakeLists.txt, I first set the variable BUILDNAME in cache before calling `include(CTest)`. # define BUILDNAME, used to submit jobs to CDash set(BUILDNAME "Whatever you want" CACHE STRING "" FORCE) # This must be called after SITE and BUILDNAME variables are set include(CTest) I hope this will work for you. Best regards, Xavier On Sun, Dec 16, 2018 at 9:22 PM Craig Scott wrote: > > > On Mon, Dec 17, 2018 at 6:41 AM Donald MacQueen [|] < > dmacq at instantiations.com> wrote: > >> I want to do something like set(CTEST_BUILD_NAME >> {CMAKE_SYSTEM_NAME}_someLocalVariable) >> >> I tried putting this ^^ in CTestConfig.cmake with no luck. >> >> I searched the docs and the archives from 2014 to the present and >> nothing jumped out at me. >> >> 2) Is there a list of what can be set/used in CTestConfig.cmake? >> > > The variables are not all collected together conveniently, but the Dashboard > Client section > > of the ctest command does list the supported variables associated with each > command. It would seem like setting CTEST_BUILD_NAME should work based on > those docs, so perhaps if you could point us as a minimal complete example > which demonstrates your problem, that might give more clues as to what's > happening for you. > > > -- > Craig Scott > Melbourne, Australia > https://crascit.com > > New book released: Professional CMake: A Practical Guide > > -- > > 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: > https://cmake.org/mailman/listinfo/cmake > > > ----------------------------------------------------------------------------------- > > This e-mail can not be trusted due to SPF/DKIM validation failed. > > > ----------------------------------------------------------------------------------- > > -- Dr Xavier BESSERON Research Scientist FSTC, University of Luxembourg Campus Belval, Office MNO E04 0415-040 Phone: +352 46 66 44 5418 http://luxdem.uni.lu/team/xbesseron/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmacq at instantiations.com Sun Dec 16 18:45:18 2018 From: dmacq at instantiations.com (Donald MacQueen [|]) Date: Sun, 16 Dec 2018 18:45:18 -0500 Subject: [CMake] How to set CTEST_BUILD_NAME In-Reply-To: References: Message-ID: <1ee44cdc-38f4-a969-0984-ed5e6868c56f@instantiations.com> Hi Xavier, That worked like a charm! Thanks very much. Thanks too to Craig for the link. I had not seen that before. On 12/16/2018 6:15 PM, Xavier Besseron wrote: > Hi Donald, > For my project, I do it this way. > In my CMakeLists.txt, I first set the variable BUILDNAME in cache > before calling `include(CTest)`. > > #defineBUILDNAME,usedtosubmitjobstoCDash > > set(BUILDNAME"Whatever you want"CACHESTRING""FORCE) > > #ThismustbecalledafterSITEandBUILDNAMEvariablesareset > > include(CTest) > > I hope this will work for you. > Best regards, > Xavier > > On Sun, Dec 16, 2018 at 9:22 PM Craig Scott > wrote: > > > > On Mon, Dec 17, 2018 at 6:41 AM Donald MacQueen [|] > > wrote: > > I want to do something like set(CTEST_BUILD_NAME > {CMAKE_SYSTEM_NAME}_someLocalVariable) > > I tried putting this ^^ in CTestConfig.cmake with no luck. > > I searched the docs and the archives from 2014 to the present and > nothing jumped out at me. > > 2) Is there a list of what can be set/used in CTestConfig.cmake? > > > The variables are not all collected together conveniently, but the > Dashboard Client section > > of the ctest command does list the supported variables associated > with each command. It would seem like setting CTEST_BUILD_NAME > should work based on those docs, so perhaps if you could point us > as a minimal complete example which demonstrates your problem, > that might give more clues as to what's happening for you. > > > -- > Craig Scott > Melbourne, Australia > https://crascit.com > > New book released: Professional CMake: A Practical Guide > > > ----------------------------------------------------------------------------------- > > > > -- > Dr Xavier BESSERON > Research Scientist > FSTC, University of Luxembourg > Campus Belval, Office MNO E04 0415-040 > Phone: +352 46 66 44 5418 > http://luxdem.uni.lu/team/xbesseron/ > -- Donald [|] A bad day in [] is better than a good day in {}. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus -------------- next part -------------- An HTML attachment was scrubbed... URL: From kris.f.thielemans at gmail.com Sun Dec 16 19:24:05 2018 From: kris.f.thielemans at gmail.com (Kris Thielemans) Date: Mon, 17 Dec 2018 00:24:05 -0000 Subject: [CMake] dependencies on system include files Message-ID: <001401d4959e$d2333650$7699a2f0$@gmail.com> Hi all I've just had a problem caused by an upgrade of my system files (in this particular case: boost). Rebuilding our software didn't correctly rebuild those files that depend on the updated boost files. (I'm using CMake 3.9 with make on Ubuntu 16.04) Checking a bit more carefully it appears that the system .h files are not included in depend.make. I guess this is done to save some time checking all those dependencies as system files are supposed to be relatively stable, but if they're not, it creates trouble of course. Is there any way to change this behaviour? (ideally something like for one time only, check if dependent system include files are more recent then what was compiled, but that's a stretch of course). Thanks Kris -------------- next part -------------- An HTML attachment was scrubbed... URL: From Simon.Richter at hogyros.de Mon Dec 17 07:39:00 2018 From: Simon.Richter at hogyros.de (Simon Richter) Date: Mon, 17 Dec 2018 13:39:00 +0100 Subject: [CMake] dependencies on system include files In-Reply-To: <001401d4959e$d2333650$7699a2f0$@gmail.com> References: <001401d4959e$d2333650$7699a2f0$@gmail.com> Message-ID: <960c000b-f22a-37f1-f931-2850a6156a42@hogyros.de> Hi Kris, On 17.12.18 01:24, Kris Thielemans wrote: > Checking a bit more carefully it appears that the system .h files are > not included in depend.make. I guess this is done to save some time > checking all those dependencies as system files are supposed to be > relatively stable, but if they?re not, it creates trouble of course. > Is there any way to change this behaviour? (ideally something like for > one time only, check if dependent system include files are more recent > then what was compiled, but that?s a stretch of course). The problem is: that wouldn't help, as most package managers install files with timestamps from packages rather than their installation time. Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From ian.james.cullen at gmail.com Mon Dec 17 09:45:58 2018 From: ian.james.cullen at gmail.com (Ian Cullen) Date: Mon, 17 Dec 2018 14:45:58 +0000 Subject: [CMake] Tracking progress of CMake TAR In-Reply-To: References: Message-ID: Are you calling tar via a custom command?? tar itself looks to have a few options to print progress: https://www.gnu.org/software/tar/manual/html_section/tar_25.html Although none of the options seem to know the archive's size, so aren't able to print a completion percentage. On 16/12/2018 21:31, Person Withhats wrote: > When running tar via CMake (in order to use cross-platform > work-ability and what not) it'd be great to have a progress bar of any > sort. > > It's awkward to wait 30-60 minutes for file untarring with absolutely > 0 information. I'm not aware of any way to do this through CMake > directly, only alternative is e.g. python script that does the untar > for me. > > Any suggestions? (sorry if this is reposted, can't remember if acc was > approved before or after sending one time) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.noulard at gmail.com Mon Dec 17 10:16:34 2018 From: eric.noulard at gmail.com (Eric Noulard) Date: Mon, 17 Dec 2018 16:16:34 +0100 Subject: [CMake] Tracking progress of CMake TAR In-Reply-To: References: Message-ID: I guess he is using cmake -E tar may be using 'v' verbose option from tar should be enough. i.e. cmake -E tar xvz your-archive.tar.gz It should display file names as they come out of the archive. So unless your very big archive only contains relatively big files, the output should evolve quite often. Eric Le lun. 17 d?c. 2018 ? 15:46, Ian Cullen a ?crit : > Are you calling tar via a custom command? tar itself looks to have a few > options to print progress: > > https://www.gnu.org/software/tar/manual/html_section/tar_25.html > > Although none of the options seem to know the archive's size, so aren't > able to print a completion percentage. > > > On 16/12/2018 21:31, Person Withhats wrote: > > When running tar via CMake (in order to use cross-platform work-ability > and what not) it'd be great to have a progress bar of any sort. > > It's awkward to wait 30-60 minutes for file untarring with absolutely 0 > information. I'm not aware of any way to do this through CMake directly, > only alternative is e.g. python script that does the untar for me. > > Any suggestions? (sorry if this is reposted, can't remember if acc was > approved before or after sending one time) > > > -- > > 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: > https://cmake.org/mailman/listinfo/cmake > -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From dblaikie at gmail.com Mon Dec 17 10:37:09 2018 From: dblaikie at gmail.com (David Blaikie) Date: Mon, 17 Dec 2018 07:37:09 -0800 Subject: [CMake] dependencies on system include files In-Reply-To: <001401d4959e$d2333650$7699a2f0$@gmail.com> References: <001401d4959e$d2333650$7699a2f0$@gmail.com> Message-ID: If you're willing to run a different command or flag when rebuilding after upgrading system libraries, I would guess the thing to do would be to do a clean and rebuild, perhaps? On Sun, Dec 16, 2018, 4:24 PM Kris Thielemans Hi all > > > > I?ve just had a problem caused by an upgrade of my system files (in this > particular case: boost). Rebuilding our software didn?t correctly rebuild > those files that depend on the updated boost files. (I?m using CMake 3.9 > with make on Ubuntu 16.04) > > > > Checking a bit more carefully it appears that the system .h files are not > included in depend.make. I guess this is done to save some time checking > all those dependencies as system files are supposed to be relatively > stable, but if they?re not, it creates trouble of course. > > > > Is there any way to change this behaviour? (ideally something like for one > time only, check if dependent system include files are more recent then > what was compiled, but that?s a stretch of course). > > > > Thanks > > > > Kris > > > > > > > -- > > 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: > https://cmake.org/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From branch at arlut.utexas.edu Mon Dec 17 11:22:54 2018 From: branch at arlut.utexas.edu (Ed Branch) Date: Mon, 17 Dec 2018 10:22:54 -0600 Subject: [CMake] DEPFILE usage in add_custom_command(...) In-Reply-To: References: Message-ID: <05f826bf-4601-02b5-05c4-cb9bbbb96795@arlut.utexas.edu> The target name in the depfile does not match the target name on the ninja build line due to absolute vs relative path mismatch. Even though they refer to the same file, the target names must match exactly. From eric.noulard at gmail.com Mon Dec 17 11:53:23 2018 From: eric.noulard at gmail.com (Eric Noulard) Date: Mon, 17 Dec 2018 17:53:23 +0100 Subject: [CMake] Tracking progress of CMake TAR In-Reply-To: References: Message-ID: Le lun. 17 d?c. 2018 ? 17:17, Person Withhats a ?crit : > It's untarring around 1.5GB of SDK's, I don't think listing 1000's of > files is going to help. > Yes right. You need some "size extraction progress" not number of files progress. I'm not sure classical un-archive program do have the feature. I'm pretty sure that "working progress bar" is most of the time very difficult to implement: https://ux.stackexchange.com/questions/11881/progress-bars-why-are-they-never-useful I was hoping for some sort of progress bar or the like, > I'm pretty sure cmake -E tar does not have this feature. Genuine unix tar command does not have such feature and some people uses 'pv' (http://www.ivarch.com/programs/pv.shtml) for that very same purpose e.g. https://superuser.com/questions/168749/is-there-a-way-to-see-any-tar-progress-per-file I guess the issue is the same for other archive tool including zip: https://askubuntu.com/questions/909918/q-how-to-show-unzip-progress CMake is using libarchive for handling various archive files (including tar) libarchive seems to have some feature for progress display ( https://github.com/libarchive/libarchive/wiki/ManPageArchiveReadExtract3) but CMake code is not using it in any way. > and yes I'm using cmake -E tar .-. > > Any ideas? > Beside non-portable way no. > > On Mon, Dec 17, 2018 at 7:16 AM Eric Noulard > wrote: > >> I guess he is using >> >> cmake -E tar >> >> may be using 'v' verbose option from tar should be enough. >> >> i.e. >> cmake -E tar xvz your-archive.tar.gz >> >> It should display file names as they come out of the archive. >> So unless your very big archive only contains relatively big files, the >> output should evolve quite often. >> >> Eric >> >> >> Le lun. 17 d?c. 2018 ? 15:46, Ian Cullen a >> ?crit : >> >>> Are you calling tar via a custom command? tar itself looks to have a >>> few options to print progress: >>> >>> https://www.gnu.org/software/tar/manual/html_section/tar_25.html >>> >>> Although none of the options seem to know the archive's size, so aren't >>> able to print a completion percentage. >>> >>> >>> On 16/12/2018 21:31, Person Withhats wrote: >>> >>> When running tar via CMake (in order to use cross-platform work-ability >>> and what not) it'd be great to have a progress bar of any sort. >>> >>> It's awkward to wait 30-60 minutes for file untarring with absolutely 0 >>> information. I'm not aware of any way to do this through CMake directly, >>> only alternative is e.g. python script that does the untar for me. >>> >>> Any suggestions? (sorry if this is reposted, can't remember if acc was >>> approved before or after sending one time) >>> >>> >>> -- >>> >>> 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: >>> https://cmake.org/mailman/listinfo/cmake >>> >> >> >> -- >> 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: >> https://cmake.org/mailman/listinfo/cmake >> > -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.noulard at gmail.com Mon Dec 17 12:31:58 2018 From: eric.noulard at gmail.com (Eric Noulard) Date: Mon, 17 Dec 2018 18:31:58 +0100 Subject: [CMake] Tracking progress of CMake TAR In-Reply-To: References: Message-ID: Le lun. 17 d?c. 2018 ? 18:00, Person Withhats a ?crit : > I guess for now, anything that'll get it to work on Windows? That's the > primary platform for this. > If you give up on portability then replace cmake -E tar with an external program which has progress capability on Windows. It looks like 7-zip can do that: see: https://sevenzip.osdn.jp/chm/cmdline/switches/bs.htm or: https://sourceforge.net/p/sevenzip/discussion/45797/thread/d10225f7/ I don't work on Windows those day so I won't be able to try it out. Eric > > On Mon, Dec 17, 2018 at 8:53 AM Eric Noulard > wrote: > >> >> Le lun. 17 d?c. 2018 ? 17:17, Person Withhats >> a ?crit : >> >>> It's untarring around 1.5GB of SDK's, I don't think listing 1000's of >>> files is going to help. >>> >> >> Yes right. >> You need some "size extraction progress" not number of files progress. >> >> I'm not sure classical un-archive program do have the feature. >> >> I'm pretty sure that "working progress bar" is most of the time very >> difficult to implement: >> >> https://ux.stackexchange.com/questions/11881/progress-bars-why-are-they-never-useful >> >> I was hoping for some sort of progress bar or the like, >>> >> >> I'm pretty sure cmake -E tar does not have this feature. >> Genuine unix tar command does not have such feature and some people uses >> 'pv' (http://www.ivarch.com/programs/pv.shtml) >> for that very same purpose >> e.g. >> https://superuser.com/questions/168749/is-there-a-way-to-see-any-tar-progress-per-file >> >> I guess the issue is the same for other archive tool including zip: >> https://askubuntu.com/questions/909918/q-how-to-show-unzip-progress >> >> CMake is using libarchive for handling various archive files (including >> tar) libarchive seems to have >> some feature for progress display ( >> https://github.com/libarchive/libarchive/wiki/ManPageArchiveReadExtract3) >> but CMake code is not using it in any way. >> >> >>> and yes I'm using cmake -E tar .-. >>> >>> Any ideas? >>> >> >> Beside non-portable way no. >> >> >>> >>> On Mon, Dec 17, 2018 at 7:16 AM Eric Noulard >>> wrote: >>> >>>> I guess he is using >>>> >>>> cmake -E tar >>>> >>>> may be using 'v' verbose option from tar should be enough. >>>> >>>> i.e. >>>> cmake -E tar xvz your-archive.tar.gz >>>> >>>> It should display file names as they come out of the archive. >>>> So unless your very big archive only contains relatively big files, the >>>> output should evolve quite often. >>>> >>>> Eric >>>> >>>> >>>> Le lun. 17 d?c. 2018 ? 15:46, Ian Cullen >>>> a ?crit : >>>> >>>>> Are you calling tar via a custom command? tar itself looks to have a >>>>> few options to print progress: >>>>> >>>>> https://www.gnu.org/software/tar/manual/html_section/tar_25.html >>>>> >>>>> Although none of the options seem to know the archive's size, so >>>>> aren't able to print a completion percentage. >>>>> >>>>> >>>>> On 16/12/2018 21:31, Person Withhats wrote: >>>>> >>>>> When running tar via CMake (in order to use cross-platform >>>>> work-ability and what not) it'd be great to have a progress bar of any >>>>> sort. >>>>> >>>>> It's awkward to wait 30-60 minutes for file untarring with absolutely >>>>> 0 information. I'm not aware of any way to do this through CMake directly, >>>>> only alternative is e.g. python script that does the untar for me. >>>>> >>>>> Any suggestions? (sorry if this is reposted, can't remember if acc was >>>>> approved before or after sending one time) >>>>> >>>>> >>>>> -- >>>>> >>>>> 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: >>>>> https://cmake.org/mailman/listinfo/cmake >>>>> >>>> >>>> >>>> -- >>>> 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: >>>> https://cmake.org/mailman/listinfo/cmake >>>> >>> >> >> -- >> Eric >> > -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From mario at emmenlauer.de Mon Dec 17 15:35:27 2018 From: mario at emmenlauer.de (Mario Emmenlauer) Date: Mon, 17 Dec 2018 21:35:27 +0100 Subject: [CMake] Modern cmake advise for transitive library dependencies Message-ID: <64a351dc-3227-19bf-953b-d394f2645986@emmenlauer.de> Dear cmake team and user community, I'd kindly like to ask for advice on how to handle transitive dependencies cleanly with "modern" cmake. I'm often plagued by this problem: I have a library X that optionally depends on library A. When I build library Y that depends on X, how do I (cleanly) handle the optional dependency A? Assume "A" would be "Qt5Core". I can link X publicly against Qt5::Core. But when I import X into Y, then Y will complain about unknown target Qt5::Core, unless I do find_package(Qt5 COMPONENTS Core) in Y. But since Qt is optional in X, I would need to track somehow if Qt was enabled before. But what good is the public transitive dependency when I manually need to track it, to find the libraries again? Am I missing something? Can the dependency be automatically resolved, or can I query some variable if X was linking A? How to do this cleanly? Thanks a lot and all the best, Mario Emmenlauer From paul at mad-scientist.net Mon Dec 17 14:42:37 2018 From: paul at mad-scientist.net (Paul Smith) Date: Mon, 17 Dec 2018 14:42:37 -0500 Subject: [CMake] CMake 3.11.3: set properties on the command line? Message-ID: Hi all. I'm using cmake with a cross-compiler environment, but building third party packages that are configured with CMake. So when I invoke cmake for those packages I add this options to the command line: -DCMAKE_FIND_ROOT_PATH=/my/sysroot However, this is not working because it's finding 32bit libraries. For example if the package's CMakeLists.txt file contains this: find_package(ZLIB REQUIRED) then my link line ends up containing: /my/sysroot/usr/lib/libz.so which is the 32bit version and the link fails. The 64bit version DOES exist exactly as it should: $ ls -1 /my/sysroot/usr/lib*/libz.so* /my/sysroot/tools/usr/lib/libz.so /my/sysroot/tools/usr/lib64/libz.so and the link works if I do it by hand with the right path. I don't know why it's not automatically looking for lib64; I checked and CMake knows I want a 64bit build. For example I see this after running: CMakeFiles/3.11.3/CMakeCXXCompiler.cmake:set(CMAKE_CXX_SIZEOF_DATA_PTR "8") Actually I wish cmake would just add "-lz" to the command line and let the linker figure it all out rather than trying to second-guess things. Then it would "just work". In any event, if I edit the CMakeLists.txt in the package to set the global property FIND_LIBRARY_USE_LIB64_PATHS to ON, then it all works fine: set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_LIB64_PATHS ON) But I can't see any way to set that property from the command line, without editing the package's CMakeLists.txt file which I obviously don't want to do. Help for either (a) figuring out why cmake incorrectly chooses 32bit libraries or (b) setting the property without editing third-party CMakeLists.txt files would be much appreciated!! From brendan at heinonen.co Mon Dec 17 15:42:40 2018 From: brendan at heinonen.co (Brendan Heinonen) Date: Mon, 17 Dec 2018 15:42:40 -0500 Subject: [CMake] Using ninja with imported libraries not working (Windows) Message-ID: I've been struggling to use ninja-generator with imported libraries in CMake on Windows. The issue started when I moved some third-party code in the project to an external project using find_package. I have since reduced the issue to a minimally reproducible example: add_library(foo STATIC IMPORTED) set_property(TARGET foo PROPERTY IMPORTED_LOCATION E:/path/to/foo.lib) target_link_libraries(bar foo) This produces a Ninja error: ninja : error : 'E:/path/to/foo.lib', needed by 'bar', missing and no known rule to make it I should note that the path to the lib exists, and in fact, this config works on other generators, such as NMake and Unix Makefiles. The issue is "fixed" upon manually editing build.ninja and removing this from the bar link target: E$:/path/to/foo.lib What's the deal? Am I missing something? Any help would be appreciated. -- *Brendan Heinonen* -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig.scott at crascit.com Mon Dec 17 16:22:54 2018 From: craig.scott at crascit.com (Craig Scott) Date: Tue, 18 Dec 2018 08:22:54 +1100 Subject: [CMake] CMake 3.11.3: set properties on the command line? In-Reply-To: References: Message-ID: On Tue, Dec 18, 2018 at 7:42 AM Paul Smith wrote: > Hi all. > > I'm using cmake with a cross-compiler environment, but building third > party packages that are configured with CMake. So when I invoke cmake > for those packages I add this options to the command line: > > -DCMAKE_FIND_ROOT_PATH=/my/sysroot > > However, this is not working because it's finding 32bit libraries. For > example if the package's CMakeLists.txt file contains this: > > find_package(ZLIB REQUIRED) > > then my link line ends up containing: > > /my/sysroot/usr/lib/libz.so > > which is the 32bit version and the link fails. The 64bit version DOES > exist exactly as it should: > > $ ls -1 /my/sysroot/usr/lib*/libz.so* > /my/sysroot/tools/usr/lib/libz.so > /my/sysroot/tools/usr/lib64/libz.so > > and the link works if I do it by hand with the right path. I don't > know why it's not automatically looking for lib64; I checked and CMake > knows I want a 64bit build. For example I see this after running: > > CMakeFiles/3.11.3/CMakeCXXCompiler.cmake:set(CMAKE_CXX_SIZEOF_DATA_PTR > "8") > > Actually I wish cmake would just add "-lz" to the command line and let > the linker figure it all out rather than trying to second-guess things. > Then it would "just work". > > In any event, if I edit the CMakeLists.txt in the package to set the > global property FIND_LIBRARY_USE_LIB64_PATHS to ON, then it all works > fine: > > set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_LIB64_PATHS ON) > > But I can't see any way to set that property from the command line, > without editing the package's CMakeLists.txt file which I obviously > don't want to do. > > Help for either (a) figuring out why cmake incorrectly chooses 32bit > libraries or (b) setting the property without editing third-party > CMakeLists.txt files would be much appreciated!! > If you are setting your own sysroot, are you using a toolchain file? You could put your set_property() command in your toolchain file if you're using one. If you're not using a toolchain file and don't want to go that route, you could potentially inject the commands you want using the CMAKE_PROJECT__INCLUDE feature. It allows you to effectively include a file immediately after a project() command without having to actually edit the CMakeLists.txt that contains that project() command. Those techniques aside, it's interesting that you need to add this manual workaround at all. I suspect this code might be why it is being turned off for you, but without more detail about your build setup, it's hard to say. If you use a toolchain file and set CMAKE_SYSTEM_NAME to anything (even the same as the CMAKE_HOST_SYSTEM_NAME), CMAKE_CROSSCOMPILING will be TRUE, which I suspect would prevent the problem you're seeing. -- Craig Scott Melbourne, Australia https://crascit.com New book released: Professional CMake: A Practical Guide -------------- next part -------------- An HTML attachment was scrubbed... URL: From robb at datalogics.com Mon Dec 17 17:07:24 2018 From: robb at datalogics.com (Rob Boehne) Date: Mon, 17 Dec 2018 22:07:24 +0000 Subject: [CMake] AIX shared libraries Message-ID: <01940C49-A004-42B7-9B59-908AF90DE74F@datalogics.com> AIX supports two types of shared libraries, AIX-style, and System 5 (SYSV) compatibility libraries. CMake is currently set up to exclusively work with SYSV-style (read the ld man pages for -brtl). To do this I?m attempting to set the commands to override linking shared libraries. The default setup forces generating an exports list, which also gives me problems because I explicitly provide one (that is then overridden by the generated list, which comes out empty in my case). The set commands below almost work, one of the problems is that I can?t see any way to pass flags to commands like ?/bin/ar?. Under AIX, tools like ar, nm, etc. have a strict ?object file mode? that can be altered with the -X command line argument. I couldn?t find any place to pass -X64 or -X32 to /bin/ar, and setting CMAKE_AR with a space in it results in CMAKE_AR==?/bin/ar;-X64? which is not what I want. Adding double quotes fails because they aren?t escaped, so the command ends up being sent with argv[0]==?/bin/ar -X64? which fails. Escaping the space like you see below results in the same behavior. I don?t have any static archives in the project, but I?m pretty sure there would be problems with them. I want to create the output of the first command to look like the target filename but with a file extension of ?so? rather than ?a? but I don?t see any way to do that. elseif("${CMAKE_SYSTEM_NAME}" STREQUAL "AIX") if(${CMAKE_CXX_COMPILER_ID} STREQUAL "XL") if(CMAKE_SIZEOF_VOID_P MATCHES "8") set(CMAKE_AR /bin/ar\ -X64) else() set(CMAKE_AR /bin/ar\ -X32) endif() # override the broken commands cmake uses to build shared libs on AIX with XLC set(CMAKE_SHARED_LIBRARY_SUFFIX ".a") set(CMAKE_SHARED_LIBRARY_LINK_CXX_FLAGS "") set(CMAKE_SHARED_LINKER_FLAGS_INIT "") set(CMAKE_EXTRA_SHARED_LIBRARY_SUFFIXES ".so") set(CMAKE_SHARED_LIBRARY_CREATE_CXX_FLAGS "-bM:SRE -bnoentry") set(CMAKE_CXX_CREATE_SHARED_LIBRARY " -o /shr.so ; -cru /shr.so" ) [cid:image002.png at 01D3D0E3.DCFE6710] Rob Boehne Senior Software Architect | Datalogics, Inc. +1.312.853.8351 | robb at datalogics.com datalogics.com | blogs.datalogics.com Connect with us: Facebook | Twitter | LinkedIn | YouTube -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 124449 bytes Desc: image001.png URL: From kris.f.thielemans at gmail.com Tue Dec 18 03:32:41 2018 From: kris.f.thielemans at gmail.com (Kris Thielemans) Date: Tue, 18 Dec 2018 08:32:41 -0000 Subject: [CMake] dependencies on system include files In-Reply-To: References: <001401d4959e$d2333650$7699a2f0$@gmail.com> Message-ID: <004101d496ac$3e690bc0$bb3b2340$@gmail.com> Thanks David It seems that a rebuild is the only way. We?ll add that to our instructions then! Kris From: David Blaikie Sent: 17 December 2018 15:37 To: Kris Thielemans Cc: CMake Mail List Subject: Re: [CMake] dependencies on system include files If you're willing to run a different command or flag when rebuilding after upgrading system libraries, I would guess the thing to do would be to do a clean and rebuild, perhaps? On Sun, Dec 16, 2018, 4:24 PM Kris Thielemans wrote: Hi all I?ve just had a problem caused by an upgrade of my system files (in this particular case: boost). Rebuilding our software didn?t correctly rebuild those files that depend on the updated boost files. (I?m using CMake 3.9 with make on Ubuntu 16.04) Checking a bit more carefully it appears that the system .h files are not included in depend.make. I guess this is done to save some time checking all those dependencies as system files are supposed to be relatively stable, but if they?re not, it creates trouble of course. Is there any way to change this behaviour? (ideally something like for one time only, check if dependent system include files are more recent then what was compiled, but that?s a stretch of course). Thanks Kris -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.chevrier at gmail.com Tue Dec 18 04:36:39 2018 From: marc.chevrier at gmail.com (Marc CHEVRIER) Date: Tue, 18 Dec 2018 10:36:39 +0100 Subject: [CMake] AIX shared libraries In-Reply-To: <01940C49-A004-42B7-9B59-908AF90DE74F@datalogics.com> References: <01940C49-A004-42B7-9B59-908AF90DE74F@datalogics.com> Message-ID: Hi, To manage specific flags for ar command, you can rely on rules override (see variable CMAKE_USER_MAKE_RULES_OVERRIDE and CMAKE_USER_MAKE_RULES_OVERRIDE_). I have attached some example I used in the past to manage cleanly 32 and 64 bits builds on AIX. And to use these files, set variable CMAKE_USER_MAKE_RULES_OVERRIDE_CXX before the project command: ... set (CMAKE_USER_MAKE_RULES_OVERRIDE_CXX /to/path/${CMAKE_CXX_COMPILER_ID}-CXX-Override.cmake) ? project (?) To create an archive holding the shared object may be the most efficient is to create a script (bash or Make script is OK) to do both actions and override variable CMAKE_CXX_CREATE_SHARED_LIBRARY: set(CMAKE_CXX_CREATE_SHARED_LIBRARY ??????????????? ??/to/my/link/script ? -o /shr.so ) Le 17 d?c. 2018 ? 23:07 +0100, Rob Boehne , a ?crit : > AIX supports two types of shared libraries, AIX-style, and System 5 (SYSV) compatibility libraries.? CMake is currently set up to exclusively work with SYSV-style (read the ld man pages for -brtl). > To do this I?m attempting to set the commands to override linking shared libraries.? The default setup forces generating an exports list, which also gives me problems because I explicitly provide one (that is then overridden by the generated list, which comes out empty in my case).? The set commands below almost work, one of the problems is that I can?t see any way to pass flags to commands like ?/bin/ar?.? Under AIX, tools like ar, nm, etc. have a strict ?object file mode? that can be altered with the -X command line argument.? I couldn?t find any place to pass -X64 or -X32 to /bin/ar, and setting CMAKE_AR with a space in it results in CMAKE_AR==?/bin/ar;-X64? which is not what I want.? Adding double quotes fails because they aren?t escaped, so the command ends up being ?sent with argv[0]==?/bin/ar -X64? which fails.? Escaping the space like you see below results in the same behavior. ??I don?t have any static archives in the project, but I?m pretty sure there would be problems with them.?? I want to create the output of the first command to look like the target filename but with a file extension of ?so? rather than ?a? but I don?t see any way to do that. > > ??? elseif("${CMAKE_SYSTEM_NAME}" STREQUAL "AIX") > ??????? if(${CMAKE_CXX_COMPILER_ID} STREQUAL "XL") > ??????????? if(CMAKE_SIZEOF_VOID_P MATCHES "8") > ??????????????? set(CMAKE_AR /bin/ar\ -X64) > ??????????? else() > ??????????????? set(CMAKE_AR /bin/ar\ -X32) > ??????????? endif() > ??????????? # override the broken commands cmake uses to build shared libs on AIX with XLC > ??????????? set(CMAKE_SHARED_LIBRARY_SUFFIX ".a") > ??????????? set(CMAKE_SHARED_LIBRARY_LINK_CXX_FLAGS "") > ??????????? set(CMAKE_SHARED_LINKER_FLAGS_INIT "") > ??????????? set(CMAKE_EXTRA_SHARED_LIBRARY_SUFFIXES ".so") > ??????????? set(CMAKE_SHARED_LIBRARY_CREATE_CXX_FLAGS "-bM:SRE -bnoentry") > ??????????? set(CMAKE_CXX_CREATE_SHARED_LIBRARY > ??????????????? " ? -o /shr.so ; -cru /shr.so" > ???????????????? ) > > > > Rob Boehne > Senior Software Architect | Datalogics, Inc. > +1.312.853.8351?|?robb at datalogics.com > datalogics.com?|?blogs.datalogics.com > Connect with us:?Facebook?|?Twitter?|?LinkedIn?|?YouTube > > > -- > > 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: > https://cmake.org/mailman/listinfo/cmake -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: CDC7B71C5C07488EBC57ECC24B80DA5D.png Type: image/png Size: 124449 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: XL-CXX-RulesOverride.cmake Type: application/octet-stream Size: 407 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: XL-RulesOverride.cmake Type: application/octet-stream Size: 1560 bytes Desc: not available URL: From rleigh at codelibre.net Tue Dec 18 07:34:38 2018 From: rleigh at codelibre.net (Roger Leigh) Date: Tue, 18 Dec 2018 12:34:38 +0000 Subject: [CMake] dependencies on system include files In-Reply-To: References: <001401d4959e$d2333650$7699a2f0$@gmail.com> Message-ID: On 17/12/2018 15:37, David Blaikie wrote: > On Sun, Dec 16, 2018, 4:24 PM Kris Thielemans > wrote: > > I?ve just had a problem caused by an upgrade of my system files (in > this particular case: boost). Rebuilding our software didn?t > correctly rebuild those files that depend on the updated boost > files. (I?m using CMake 3.9 with make on Ubuntu 16.04)____ > > Checking a bit more carefully it appears that the system .h files > are not included in depend.make. I guess this is done to save some > time checking all those dependencies as system files are supposed to > be relatively stable, but if they?re not, it creates trouble of > course. > > Is there any way to change this behaviour? (ideally something like > for one time only, check if dependent system include files are more > recent then what was compiled, but that?s a stretch of course).____ > If you're willing to run a different command or flag when rebuilding > after upgrading system libraries, I would guess the thing to do would be > to do a clean and rebuild, perhaps? This is unfortunately insufficient. After upgrading any system libraries you will have to clean everything, including the CMake cache, and re-run CMake from a clean build tree, then rebuild everything. The reason for this is that the cache contains the results of find_library etc., and these may have changed as a result of the system upgrade. However, the cached values may be used despite this. It's safest to start from a clean slate. For example, if you upgraded boost from 1.6x to 1.69 Boost.Filesystem dropped its dependency upon Boost.System, which is no longer a library (it's header-only). This would result in a link failure. I've not specifically tested this case to see if it would cope, but there is plenty of stuff cached which could potentially cause problems, and the solution to drop the cache is simple. I wouldn't want to risk the integrity of the build due to the potential for subtle inconsistency between the cache and the system. After you've upgraded the system, it's essentially a different system. Regards, Roger From Alan.W.Irwin1234 at gmail.com Tue Dec 18 13:36:28 2018 From: Alan.W.Irwin1234 at gmail.com (Alan W. Irwin) Date: Tue, 18 Dec 2018 10:36:28 -0800 (PST) Subject: [CMake] Modern cmake advise for transitive library dependencies In-Reply-To: <64a351dc-3227-19bf-953b-d394f2645986@emmenlauer.de> References: <64a351dc-3227-19bf-953b-d394f2645986@emmenlauer.de> Message-ID: On 2018-12-17 21:35+0100 Mario Emmenlauer wrote: > > Dear cmake team and user community, > > I'd kindly like to ask for advice on how to handle transitive > dependencies cleanly with "modern" cmake. I'm often plagued by this > problem: I have a library X that optionally depends on library A. > When I build library Y that depends on X, how do I (cleanly) handle > the optional dependency A? > Assume "A" would be "Qt5Core". I can link X publicly against Qt5::Core. > But when I import X into Y, then Y will complain about unknown target > Qt5::Core, unless I do find_package(Qt5 COMPONENTS Core) in Y. But since > Qt is optional in X, I would need to track somehow if Qt was enabled > before. > > But what good is the public transitive dependency when I manually need > to track it, to find the libraries again? Am I missing something? > Can the dependency be automatically resolved, or can I query some > variable if X was linking A? > > How to do this cleanly? Hi Mario: One way to cleanly automate this is to configure the XConfig.cmake file (depending on whether X is linked with Qt5 or not) to optionally execute find_package(Qt5 ...) As a result, when the logic in XConfig.cmake is executed as a result of find_package(X ...) from Y, Qt5 should be found automatically when needed. Alan __________________________ Alan W. Irwin 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 robert.maynard at kitware.com Tue Dec 18 14:08:26 2018 From: robert.maynard at kitware.com (Robert Maynard) Date: Tue, 18 Dec 2018 14:08:26 -0500 Subject: [CMake] How to link in different prebuilt objects based on configuration In-Reply-To: References: Message-ID: As far as I know this is a limitation of the MSVC project files, and CMake errors out on that generator rather than try and build an invalid project. Have you tried do something where you have the Config and Release objects as separate targets that always exist, but selectively conditionally to them based on the Config setting? On Thu, Dec 13, 2018 at 2:16 PM Daniel Schepler wrote: > > We have a build here where a large portion of our product is in source code available to customers, but then there is a core which we only distribute as prebuilt "private objects". However, then when we test the customer-type build on Windows, we get an error like: > > --- > CMake Error in CMakeLists.txt: > Target "exata" has source files which vary by configuration. This is not > supported by the "Visual Studio 15 2017 Win64" generator. > > Config "Debug": > > E:/EXata_7_0/qualnet_dev_13_Dec18/kernel/obj/exata-main-windows-x64-vc14d.obj > > Config "Release": > > E:/EXata_7_0/qualnet_dev_13_Dec18/kernel/obj/exata-main-windows-x64-vc14.obj > --- > > (This object file is marked with source file property EXTERNAL_OBJECT=1.) > > Is this a limitation in Visual Studio projects, or a limitation in CMake? In either case, what workaround could allow this build to support generating Visual Studio projects? > -- > Daniel Schepler > -- > > 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: > https://cmake.org/mailman/listinfo/cmake From dschepler at scalable-networks.com Tue Dec 18 15:01:27 2018 From: dschepler at scalable-networks.com (Daniel Schepler) Date: Tue, 18 Dec 2018 20:01:27 +0000 Subject: [CMake] How to link in different prebuilt objects based on configuration In-Reply-To: References: , Message-ID: I did eventually find a solution where I set up an imported target with IMPORTED_LOCATION and IMPORTED_LOCATION_DEBUG properties pointing to the object files, and then linked in that target with target_link_libraries(). I admit I wasn't completely sure if adding .obj/.o files to the link lines in this way would be well supported, though it did seem to work OK in practice in the generators I tested to cover what our customers and build systems use (Visual Studio, NMake Makefiles [JOM], Unix Makefiles for the Linux build, and Ninja on Linux). -- Daniel ________________________________________ From: Robert Maynard [robert.maynard at kitware.com] Sent: Tuesday, December 18, 2018 11:08 AM To: Daniel Schepler Cc: CMake MailingList Subject: Re: [CMake] How to link in different prebuilt objects based on configuration As far as I know this is a limitation of the MSVC project files, and CMake errors out on that generator rather than try and build an invalid project. Have you tried do something where you have the Config and Release objects as separate targets that always exist, but selectively conditionally to them based on the Config setting? On Thu, Dec 13, 2018 at 2:16 PM Daniel Schepler wrote: > > We have a build here where a large portion of our product is in source code available to customers, but then there is a core which we only distribute as prebuilt "private objects". However, then when we test the customer-type build on Windows, we get an error like: > > --- > CMake Error in CMakeLists.txt: > Target "exata" has source files which vary by configuration. This is not > supported by the "Visual Studio 15 2017 Win64" generator. > > Config "Debug": > > E:/EXata_7_0/qualnet_dev_13_Dec18/kernel/obj/exata-main-windows-x64-vc14d.obj > > Config "Release": > > E:/EXata_7_0/qualnet_dev_13_Dec18/kernel/obj/exata-main-windows-x64-vc14.obj > --- > > (This object file is marked with source file property EXTERNAL_OBJECT=1.) > > Is this a limitation in Visual Studio projects, or a limitation in CMake? In either case, what workaround could allow this build to support generating Visual Studio projects? > -- > Daniel Schepler > -- > > 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: > https://cmake.org/mailman/listinfo/cmake From craig.scott at crascit.com Tue Dec 18 15:54:38 2018 From: craig.scott at crascit.com (Craig Scott) Date: Wed, 19 Dec 2018 07:54:38 +1100 Subject: [CMake] Modern cmake advise for transitive library dependencies In-Reply-To: References: <64a351dc-3227-19bf-953b-d394f2645986@emmenlauer.de> Message-ID: On Wed, Dec 19, 2018 at 5:36 AM Alan W. Irwin wrote: > On 2018-12-17 21:35+0100 Mario Emmenlauer wrote: > > > > > Dear cmake team and user community, > > > > I'd kindly like to ask for advice on how to handle transitive > > dependencies cleanly with "modern" cmake. I'm often plagued by this > > problem: I have a library X that optionally depends on library A. > > When I build library Y that depends on X, how do I (cleanly) handle > > the optional dependency A? > > Assume "A" would be "Qt5Core". I can link X publicly against Qt5::Core. > > But when I import X into Y, then Y will complain about unknown target > > Qt5::Core, unless I do find_package(Qt5 COMPONENTS Core) in Y. But since > > Qt is optional in X, I would need to track somehow if Qt was enabled > > before. > > > > But what good is the public transitive dependency when I manually need > > to track it, to find the libraries again? Am I missing something? > > Can the dependency be automatically resolved, or can I query some > > variable if X was linking A? > > > > How to do this cleanly? > > Hi Mario: > > One way to cleanly automate this is to configure the XConfig.cmake > file (depending on whether X is linked with Qt5 or not) to optionally > execute > > find_package(Qt5 ...) > > As a result, when the logic in XConfig.cmake is executed as a result of > > find_package(X ...) > > from Y, Qt5 should be found automatically when needed. > Your XConfig.cmake is responsible for also ensuring all targets it depends on are defined. This shouldn't be left up to consumers of X. The way this is normally done is pretty much as Alan suggests (it's also the way I handle cases analogous to yours in our projects at work). There's even a find_dependency() command intended for precisely this situation to make it a little easier, although I generally advise against using it for packages that support components due to the way a particular optimisation in its implementation affects later find_dependency() calls for the same package. -- Craig Scott Melbourne, Australia https://crascit.com New book released: Professional CMake: A Practical Guide -------------- next part -------------- An HTML attachment was scrubbed... URL: From mario at emmenlauer.de Tue Dec 18 16:31:38 2018 From: mario at emmenlauer.de (Mario Emmenlauer) Date: Tue, 18 Dec 2018 22:31:38 +0100 Subject: [CMake] Modern cmake advise for transitive library dependencies In-Reply-To: References: <64a351dc-3227-19bf-953b-d394f2645986@emmenlauer.de> Message-ID: <98dda4fc-2c73-3050-bd19-0121bc1dd8bd@emmenlauer.de> Dear Craig, Alan, thanks so much for this hint! I did not write the initial XConfig.cmake myself and so it slipped my attention. Now things are perfectly clear, I'll extend the XConfig.cmake.in and add the configuration steps there. All the best, Mario On 18.12.18 21:54, Craig Scott wrote: > > > On Wed, Dec 19, 2018 at 5:36 AM Alan W. Irwin > wrote: > > On 2018-12-17 21:35+0100 Mario Emmenlauer wrote: > > > > > Dear cmake team and user community, > > > > I'd kindly like to ask for advice on how to handle transitive > > dependencies cleanly with "modern" cmake. I'm often plagued by this > > problem: I have a library X that optionally depends on library A. > > When I build library Y that depends on X, how do I (cleanly) handle > > the optional dependency A? > > Assume "A" would be "Qt5Core". I can link X publicly against Qt5::Core. > > But when I import X into Y, then Y will complain about unknown target > > Qt5::Core, unless I do find_package(Qt5 COMPONENTS Core) in Y. But since > > Qt is optional in X, I would need to track somehow if Qt was enabled > > before. > > > > But what good is the public transitive dependency when I manually need > > to track it, to find the libraries again? Am I missing something? > > Can the dependency be automatically resolved, or can I query some > > variable if X was linking A? > > > > How to do this cleanly? > > Hi Mario: > > One way to cleanly automate this is to configure the XConfig.cmake > file (depending on whether X is linked with Qt5 or not) to optionally > execute > > find_package(Qt5 ...) > > As a result, when the logic in XConfig.cmake is executed as a result of > > find_package(X ...) > > from Y, Qt5 should be found automatically when needed. > > > > Your XConfig.cmake is responsible for also ensuring all targets it depends on > are defined. This shouldn't be left up to consumers of X. The way this is > normally done is pretty much as Alan suggests (it's also the way I handle cases > analogous to yours in our projects at work). There's even a find_dependency() > > command intended for precisely this situation to make it a little easier, > although I generally advise against using it for packages that support > components due to the way a particular optimisation in its implementation > affects later find_dependency() calls for the same package. > -- > Craig Scott > Melbourne, Australia > https://crascit.com > > New book released: Professional CMake: A Practical Guide > Viele Gruesse, Mario Emmenlauer -- BioDataAnalysis GmbH, Mario Emmenlauer Tel. Buero: +49-89-74677203 Balanstr. 43 mailto: memmenlauer * biodataanalysis.de D-81669 M?nchen http://www.biodataanalysis.de/ From rleigh at codelibre.net Wed Dec 19 11:35:26 2018 From: rleigh at codelibre.net (Roger Leigh) Date: Wed, 19 Dec 2018 16:35:26 +0000 Subject: [CMake] Modern cmake advise for transitive library dependencies In-Reply-To: References: <64a351dc-3227-19bf-953b-d394f2645986@emmenlauer.de> Message-ID: <90e0d75a-86ff-2399-584d-8ccd0c690846@codelibre.net> On 18/12/2018 20:54, Craig Scott wrote: > > Your XConfig.cmake is responsible for also ensuring all targets it > depends on are defined. This shouldn't be left up to consumers of X. The > way this is normally done is pretty much as Alan suggests (it's also the > way I handle cases analogous to yours in our projects at work). There's > even a find_dependency() > > command intended for precisely this situation to make it a little > easier, although I generally advise against using it for packages that > support components due to the way a particular optimisation in its > implementation affects later find_dependency() calls for the same package. Can't we drop this optimisation and fix find_dependency, making it properly usable? I've tested a few of the modules using components to see if they behave correctly with different sets of components, and I've not yet encountered any problems due to calling multiple times. In consequence, I wonder if we could simply drop the "optimisation" and have find_dependency do nothing more than be a thin wrapper around find_package. This would solve the problems and should not break backward compatibility. The only difference would be if the first find_package call succeeds and subsequent calls fail, which would alter the value of _FOUND. However, that's likely exactly what one should expect. Regards, Roger From leicao88124 at lanl.gov Wed Dec 19 18:31:15 2018 From: leicao88124 at lanl.gov (Cao, Lei) Date: Wed, 19 Dec 2018 23:31:15 +0000 Subject: [CMake] cmake cannot find source file (new to cmake) Message-ID: Hi, I tried to follow some examples and wrote some cmake files to build my code. But cmake is complaining that it cannot find a source file. Here is the code structure: Toplevel |----- CMakeLists.txt |----- src --------|------CMakeLists.txt | |------common---------------|-------CMakeLists.txt | |------dir1-----| |------- src1.h | |-----CMakeLists.txt |----bin |-----src2.c |-----src3.c Here is the CMakeLists.txt in toplevel: project(proj) add_subdirectory(src) Here is the CMakeLists.txt in src: project(proj) add_subdirectory(common) add_subdirectory(dir1) include_directories(common) set(src_files src1.h src2.c src3.c) add_executable(exec ${src_files}) CMakeLists.txt in common and dir1 are empty. When I ran "cmake .." in bin, cmake complained that it could not find source file src1.h in add_executable. What is wrong here? Thanks, Lei -------------- next part -------------- An HTML attachment was scrubbed... URL: From oleksii.vilchanskyi at gmail.com Thu Dec 20 05:11:38 2018 From: oleksii.vilchanskyi at gmail.com (Oleksii Vilchanskyi) Date: Thu, 20 Dec 2018 11:11:38 +0100 Subject: [CMake] cmake cannot find source file (new to cmake) In-Reply-To: References: Message-ID: <0cae1d68-6ee9-7d1a-6a4d-7497890c3372@gmail.com> > ? ? Toplevel > > ? ? ? ?|-----?CMakeLists.txt > > ? ? ? ?|-----?src?--------|------CMakeLists.txt > > ? ? ? ?|? ? ? ? ? ? ? ? ? ? ? > |------common---------------|-------CMakeLists.txt > > ? ? ? ?|? ? ? ? ? ? ? ? ? ? ? |------dir1-----|? ? ? ? ? ? ? ? ? > ?|------- src1.h > > ? ? ? ?|? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |-----CMakeLists.txt > > ? ? ? ?|----bin? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |-----src2.c > > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |-----src3.c It's quite hard to figure out what's going on here, but I assume src1.h is under src/common. Please post the output of 'tree' command next time, if you are on a Unix. > ? ? ? ? ? ? ? ? set(src_files src1.h src2.c src3.c) You don't have to add headers as target dependencies unless you program in an IDE (just fyi). > ? ? ?CMakeLists.txt in common and dir1 are empty. So, either partially move your CMake scripts into these subdirectories, or don't do `add_subdirectory()`. For example: src/CMakeLists.txt: add_executable(exec dir1/src1.c dir1/src2.c dir1/src3.c) target_include_directories(exec PRIVATE "${CMAKE_CURRENT_SOURCE_DIR}/common") -- Alex -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From romain.leguay at gmail.com Thu Dec 20 06:09:43 2018 From: romain.leguay at gmail.com (Romain LEGUAY) Date: Thu, 20 Dec 2018 12:09:43 +0100 Subject: [CMake] ExternalProject, Superbuild and rebuild on Windows Message-ID: Hello everyone, I'm trying to build VTK and ITK along my project. For now, I use the trick to add an option to build VTK and ITK only once using ExternalProject_Add for all my dependencies and also for my project. This works great on Unix system but with a VS solution, the dependencies are not rebuilt when I change CMAKE_BUILD_TYPE. Is it possible to know if CMAKE_BUILD_TYPE is changed? It will permit me to switch on the option to rebuild the dependencies. Anyone as other better ideas? Thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: From kai.wolf at gmail.com Thu Dec 20 06:44:04 2018 From: kai.wolf at gmail.com (Kai Wolf) Date: Thu, 20 Dec 2018 12:44:04 +0100 Subject: [CMake] ExternalProject, Superbuild and rebuild on Windows In-Reply-To: References: Message-ID: <9D6ACC5C-FA18-4A1D-87C2-203C8DA6B92E@gmail.com> The CMAKE_BUILD_TYPE variable only makes sense for single-configuration generators (such as Makefile or Ninja) and is not used for IDE type generators. You should rather look for CMAKE_CONFIGURATION_TYPES as well as CMAKE_CFG_INTDIR. Greetings, Kai http://kai-wolf.me http://effective-cmake.com > Am 20.12.2018 um 12:09 schrieb Romain LEGUAY : > > Hello everyone, > > I'm trying to build VTK and ITK along my project. > > For now, I use the trick to add an option to build VTK and ITK only once using ExternalProject_Add for all my dependencies and also for my project. > > This works great on Unix system but with a VS solution, the dependencies are not rebuilt when I change CMAKE_BUILD_TYPE. > > Is it possible to know if CMAKE_BUILD_TYPE is changed? It will permit me to switch on the option to rebuild the dependencies. > > Anyone as other better ideas? > > Thank you > -- > > 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: > https://cmake.org/mailman/listinfo/cmake -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: Message signed with OpenPGP URL: From romain.leguay at gmail.com Thu Dec 20 16:34:43 2018 From: romain.leguay at gmail.com (Romain LEGUAY) Date: Thu, 20 Dec 2018 22:34:43 +0100 Subject: [CMake] ExternalProject, Superbuild and rebuild on Windows In-Reply-To: <9D6ACC5C-FA18-4A1D-87C2-203C8DA6B92E@gmail.com> References: <9D6ACC5C-FA18-4A1D-87C2-203C8DA6B92E@gmail.com> Message-ID: Thank you for your answer, I didn't know the CMAKE_CFG_INTDIR variable. It was this variable I needed. Best regards, Romain Le jeu. 20 d?c. 2018 ? 12:44, Kai Wolf a ?crit : > The CMAKE_BUILD_TYPE variable only makes sense for single-configuration > generators (such as Makefile or Ninja) and is not used for IDE type > generators. > You should rather look for CMAKE_CONFIGURATION_TYPES as well as > CMAKE_CFG_INTDIR. > > Greetings, > > Kai > > http://kai-wolf.me > http://effective-cmake.com > > > > Am 20.12.2018 um 12:09 schrieb Romain LEGUAY : > > > > Hello everyone, > > > > I'm trying to build VTK and ITK along my project. > > > > For now, I use the trick to add an option to build VTK and ITK only once > using ExternalProject_Add for all my dependencies and also for my project. > > > > This works great on Unix system but with a VS solution, the dependencies > are not rebuilt when I change CMAKE_BUILD_TYPE. > > > > Is it possible to know if CMAKE_BUILD_TYPE is changed? It will permit me > to switch on the option to rebuild the dependencies. > > > > Anyone as other better ideas? > > > > Thank you > > -- > > > > 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: > > https://cmake.org/mailman/listinfo/cmake > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ax487 at gmx.de Thu Dec 20 17:14:17 2018 From: ax487 at gmx.de (Unknown) Date: Thu, 20 Dec 2018 23:14:17 +0100 Subject: [CMake] Get linker flags / include directories for a library target Message-ID: <965c52de901d462e84324b3748195ed4a36bf4e4.camel@gmx.de> Dear community, I have been wondering on multiple occasions about how to get the linker flags (i.e. all -llib -Ldir) and include flags (-Idir) for a library (i.e. a target added to the project using add_library) within a cmake. There are many cases in which the flags are required, noticeably generating a suitable pkg-config file or creating a wrappers around C/C++ libraries. I think that it should be possible to derive the flags from some of the target properties of the library, but I don't know exactly how. Could you give me a hand? ax487 From oleksii.vilchanskyi at gmail.com Thu Dec 20 17:56:32 2018 From: oleksii.vilchanskyi at gmail.com (Oleksii Vilchanskyi) Date: Thu, 20 Dec 2018 23:56:32 +0100 Subject: [CMake] Fwd: cmake cannot find source file (new to cmake) In-Reply-To: References: Message-ID: <52bbfeae-055e-702d-321c-243b9c3f4962@gmail.com> Forwarding to the list and replying to some parts. > I removed add_subdirectories and added path to each of the source > file according to your instruction and things worked! I just have a > quick question: why should I remove the add_subdirectories in the src > CMakeLists.txt? I thought add_subdirectories should tell cmake to look > for files in the directories? add_subdirectory() tells CMake that there's yet another listfile (CMakeLists.txt) in a subdirectory, which will be processed recursively until no further listfiles are found inside. Then the normal procedural flow continues. So it doesn't say anything about project files, just that new script code that might involve the project files needs to be processed. >>> Toplevel >>> >>> |----- CMakeLists.txt >>> >>> |----- src --------|------CMakeLists.txt >>> >>> | >>> |------common---------------|-------CMakeLists.txt >>> >>> | |------dir1-----| >>> |------- src1.h >>> >>> | |-----CMakeLists.txt >>> >>> |----bin |-----src2.c >>> >>> |-----src3.c >> >> It's quite hard to figure out what's going on here, but I assume src1.h >> is under src/common. Please post the output of 'tree' command next time, >> if you are on a Unix. >> >>> set(src_files src1.h src2.c src3.c) >> >> You don't have to add headers as target dependencies unless you program >> in an IDE (just fyi). >> >>> CMakeLists.txt in common and dir1 are empty. >> >> So, either partially move your CMake scripts into these subdirectories, >> or don't do `add_subdirectory()`. For example: >> >> src/CMakeLists.txt: >> add_executable(exec dir1/src1.c dir1/src2.c dir1/src3.c) >> target_include_directories(exec PRIVATE >> "${CMAKE_CURRENT_SOURCE_DIR}/common") -- Alex From dodungocorporation at gmail.com Fri Dec 21 03:29:52 2018 From: dodungocorporation at gmail.com (Ciccio Pasticcio) Date: Fri, 21 Dec 2018 09:29:52 +0100 Subject: [CMake] target_link_libraries not populating INCLUDE_DIRECTORIES? Message-ID: Hi all, considering the following CMakeLists.txt: PROJECT(lib_foo) ADD_LIBRARY(lib_foo SHARED ) TARGET_INCLUDE_DIRECTORIES(PRIVATE private/ PUBLIC inc/) FIND_PACKAGE(Boost 1.55 REQUIRED COMPONENTS chrono system) TARGET_LINK_LIBRARIES(lib_foo PRIVATE Boost::chrono Boost::system) GET_TARGET_PROPERTIES(tinc lib_foo INCLUDE_DIRECTORIES) MESSAGE(STATUS "Include dirs: ${tinc}") I would expect a message with my private/ and inc/ paths, plus the one that comes with the Boost libraries, instead I only get the directories specified in TARGET_INCLUDE_DIRECTORIES. The manpage of TARGET_LINK_LIBRARIES says: PRIVATE and PUBLIC items will populate the INCLUDE_DIRECTORIES property of . If I print Boost_INCLUDE_DIR I found the inclusion path. Am I missing something? Thanks, Gabriele -------------- next part -------------- An HTML attachment was scrubbed... URL: From kai.wolf at gmail.com Fri Dec 21 03:33:20 2018 From: kai.wolf at gmail.com (Kai Wolf) Date: Fri, 21 Dec 2018 09:33:20 +0100 Subject: [CMake] Get linker flags / include directories for a library target In-Reply-To: <965c52de901d462e84324b3748195ed4a36bf4e4.camel@gmx.de> References: <965c52de901d462e84324b3748195ed4a36bf4e4.camel@gmx.de> Message-ID: <4BF6D799-4941-4460-871C-9F18B80E88EB@gmail.com> You can ask a CMake build target for its properties using get_target_property(). For instance, to retrieve the linker flags for a given target foo, you?d write: get_target_prooperty(foo_linker_flags foo LINK_FLAGS) See [1] for a list of valid parameters. Greetings, Kai [1] https://cmake.org/cmake/help/latest/manual/cmake-properties.7.html#properties-on-targets http://kai-wolf.me http://effective-cmake.com > Am 20.12.2018 um 23:14 schrieb Unknown : > > Dear community, > > I have been wondering on multiple occasions about how to get the > linker flags (i.e. all -llib -Ldir) and include flags (-Idir) > for a library (i.e. a target added to the project using > add_library) within a cmake. > > There are many cases in which the flags are required, noticeably > generating a suitable pkg-config file or creating a wrappers around > C/C++ libraries. > > I think that it should be possible to derive the flags from > some of the target properties of the library, but I don't > know exactly how. > > Could you give me a hand? > > ax487 > > -- > > 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: > https://cmake.org/mailman/listinfo/cmake -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: Message signed with OpenPGP URL: From mateusz at loskot.net Fri Dec 21 03:50:01 2018 From: mateusz at loskot.net (Mateusz Loskot) Date: Fri, 21 Dec 2018 09:50:01 +0100 Subject: [CMake] target_link_libraries not populating INCLUDE_DIRECTORIES? In-Reply-To: References: Message-ID: On Fri, 21 Dec 2018, 09:30 Ciccio Pasticcio TARGET_INCLUDE_DIRECTORIES(PRIVATE private/ PUBLIC inc/) > ... > The manpage of TARGET_LINK_LIBRARIES says: > PRIVATE and PUBLIC items will populate the INCLUDE_DIRECTORIES property of . Yea, but are missing the actual from your call. Mateusz Loskot, mateusz at loskot.net (Sent from mobile) -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.chevrier at gmail.com Fri Dec 21 04:06:18 2018 From: marc.chevrier at gmail.com (Marc CHEVRIER) Date: Fri, 21 Dec 2018 10:06:18 +0100 Subject: [CMake] target_link_libraries not populating INCLUDE_DIRECTORIES? In-Reply-To: References: Message-ID: <68e9b31c-6377-426e-9b45-4bd0338ae0fc@Spark> Command target_link_libraries do not populate directly the properties of the target due to many constraints regarding the values given to the command (generator expressions, other targets, etc?). The full contents is taken into account at generation time not at the configuration time. This is why you cannot get full information using command get_target_property which is evaluated at configuration time. Le 21 d?c. 2018 ? 09:30 +0100, Ciccio Pasticcio , a ?crit : > Hi all, > > considering the following CMakeLists.txt: > > PROJECT(lib_foo) > ADD_LIBRARY(lib_foo SHARED ) > TARGET_INCLUDE_DIRECTORIES(PRIVATE private/ PUBLIC inc/) > FIND_PACKAGE(Boost 1.55 REQUIRED COMPONENTS chrono system) > TARGET_LINK_LIBRARIES(lib_foo PRIVATE Boost::chrono Boost::system) > GET_TARGET_PROPERTIES(tinc lib_foo INCLUDE_DIRECTORIES) > MESSAGE(STATUS "Include dirs: ${tinc}") > > I would expect a message with my private/ and inc/ paths, plus the one that comes with the Boost libraries, instead I only get the directories specified in TARGET_INCLUDE_DIRECTORIES. The manpage of TARGET_LINK_LIBRARIES says: > PRIVATE and PUBLIC items will populate the INCLUDE_DIRECTORIES property of . > > If I print Boost_INCLUDE_DIR I found the inclusion path. > > Am I missing something? > > Thanks, > Gabriele > -- > > 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: > https://cmake.org/mailman/listinfo/cmake -------------- next part -------------- An HTML attachment was scrubbed... URL: From djobet at tower-research.com Fri Dec 21 06:38:43 2018 From: djobet at tower-research.com (David Jobet) Date: Fri, 21 Dec 2018 11:38:43 +0000 Subject: [CMake] cmake -gsplit-dwarf dwp and install step Message-ID: Hello, in order to speed up our link step, I wanted to experiment with split dwarf. See http://www.productive-cpp.com/improving-cpp-builds-with-split-dwarf/ Adding the compilation flag is easy, but I'm stumbling on the installation step. In our current mode, we redirect the STRIP step to extract the symbols and strip the binary. With split dwarf, I want to use 'dwp' to collect all .dwo files and assemble a symbol file. No need to strip I guess since symbols are already put elsewhere. So I figure I would just use dwp as the strip command in my custom strip command. Problem is .dwo files are recorded in the .o files relative to the build directory and the strip command is executed on the installed directory. As a result, 'dwp' complains it cannot find the .dwo files. I don't want to add a POST_BUILD step on each our binaries (we have lots of binaries), and anyway I'd rather prefer to have the 'dwp' step executed at install time so it's executed only when we want to deliver. Is there a way to either - pass the build_dir to the strip command ? - define a custom step of the install process that would execute on the build dir previous to the install step itself ? (for the same reason I don't want to manually define a POST_BUILD step on each binaries, I don't want to manually define a custom INSTALL step that would precede the INSTALL step of all our binaries) - or another option ? With regards David From laasunde at hotmail.com Fri Dec 21 07:07:09 2018 From: laasunde at hotmail.com (Lars) Date: Fri, 21 Dec 2018 12:07:09 +0000 Subject: [CMake] set_property imported_location_release Message-ID: Hello, Trying to import an external library but having some issue with setting imported_location_release property. Basically I have config file which does this; add_library(foo STATIC IMPORTED) set_property(target foo APPEND PROPERTY interface_include_directories "$" "$") set_property(TARGET foo APPEND PROPERTY IMPORTED_LOCATION_RELEASE $<$:${foo_root}/lib/release/foo.a>) The imported target is used in a target_link_libraries method; target_link_libraries(an_application foo) Running CMake 3.6.1 does not produce any warnings. Running make I get a "target pattern contains no '%'" error message with a reference to a Build.make file. The Build.make contains the string " $<$:/tmp/prototype/foo/lib/release/foo.a". We did not expect to see the generator expression in the Build.make file. Does set_property support generator expression in this context? What are we doing wrong? Appreciate any help :-) king regards, Lars -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.chevrier at gmail.com Fri Dec 21 07:41:45 2018 From: marc.chevrier at gmail.com (Marc CHEVRIER) Date: Fri, 21 Dec 2018 13:41:45 +0100 Subject: [CMake] set_property imported_location_release In-Reply-To: References: Message-ID: <7275c374-4ad1-475a-80ec-d83d5fb0d8a5@Spark> Properties IMPORTED_LOCATION* do not support generator expressions. Generally speaking, if a property supports generator expression, it is explicitly specified in documentation. Le 21 d?c. 2018 ? 13:07 +0100, Lars , a ?crit : > Hello, > > Trying to import an external library but having some issue with setting imported_location_release property. > > Basically I have config file which does this; > add_library(foo STATIC IMPORTED) > set_property(target foo APPEND PROPERTY > ?? interface_include_directories > ??? "$" > ??? "$") > > set_property(TARGET foo APPEND PROPERTY > ? IMPORTED_LOCATION_RELEASE > ??? $<$:${foo_root}/lib/release/foo.a>) > > The imported target is used in a target_link_libraries method; > target_link_libraries(an_application foo) > > Running CMake 3.6.1?does not produce any warnings. Running make I get a "target pattern contains no '%'" error message with a reference to a Build.make file. > > The Build.make contains the string "?$<$:/tmp/prototype/foo/lib/release/foo.a".? We did not expect to see the generator expression in the Build.make file. > > Does set_property support generator expression in this context? What are we doing wrong? > > Appreciate any help :-) > > king regards, Lars > > -- > > 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: > https://cmake.org/mailman/listinfo/cmake -------------- next part -------------- An HTML attachment was scrubbed... URL: From ax487 at gmx.de Fri Dec 21 09:12:30 2018 From: ax487 at gmx.de (Unknown) Date: Fri, 21 Dec 2018 15:12:30 +0100 Subject: [CMake] Get linker flags / include directories for a library target In-Reply-To: <4BF6D799-4941-4460-871C-9F18B80E88EB@gmail.com> References: <965c52de901d462e84324b3748195ed4a36bf4e4.camel@gmx.de> <4BF6D799-4941-4460-871C-9F18B80E88EB@gmail.com> Message-ID: <8a711a8d20249114189f9ab89359e561c464c4e1.camel@gmx.de> Hello Kai, thanks for your suggestion. I tried the property, but I just got "foo_linker_flags-NOTFOUND" as a result (I am using cmake 3.13.1 btw). The same goes for LINK_OPTIONS, and INTERFACE_LINK_OPTIONS. I tried using the INTERFACE_LINK_LIBRARIES property instead. The resulting list contains things I can use, such as /usr/lib/libz.so However, I am using another cmake imported library. Therefore, the list contains some libbaz::libbaz dependency as well. In order to get the actual list of libraries, I would have to also resolve these names. But this has to be done somewhere during the generation of the Makefiles, so that functionality must exist somewhere in cmake. On Fri, 2018-12-21 at 09:33 +0100, Kai Wolf wrote: > You can ask a CMake build target for its properties using > get_target_property(). > For instance, to retrieve the linker flags for a given target foo, > you?d write: > > get_target_prooperty(foo_linker_flags foo LINK_FLAGS) > > See [1] for a list of valid parameters. > > Greetings, > > Kai > > [1] > https://cmake.org/cmake/help/latest/manual/cmake-properties.7.html#properties-on-targets > > http://kai-wolf.me > http://effective-cmake.com > > > Am 20.12.2018 um 23:14 schrieb Unknown : > > > > Dear community, > > > > I have been wondering on multiple occasions about how to get the > > linker flags (i.e. all -llib -Ldir) and include flags (-Idir) > > for a library (i.e. a target added to the project using > > add_library) within a cmake. > > > > There are many cases in which the flags are required, noticeably > > generating a suitable pkg-config file or creating a wrappers around > > C/C++ libraries. > > > > I think that it should be possible to derive the flags from > > some of the target properties of the library, but I don't > > know exactly how. > > > > Could you give me a hand? > > > > ax487 > > > > -- > > > > 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: > > https://cmake.org/mailman/listinfo/cmake From laasunde at hotmail.com Fri Dec 21 09:14:04 2018 From: laasunde at hotmail.com (Lars) Date: Fri, 21 Dec 2018 14:14:04 +0000 Subject: [CMake] set_property imported_location_release In-Reply-To: <7275c374-4ad1-475a-80ec-d83d5fb0d8a5@Spark> References: , <7275c374-4ad1-475a-80ec-d83d5fb0d8a5@Spark> Message-ID: Marc, Appreciate the quick and helpful response. In a config file that supports multiple platforms, do I need to create import_location_path variable and populate it depending on platform and 32/64 etc? Any other options? Thanks. Kind regards, Lars ________________________________ Fra: Marc CHEVRIER Sendt: fredag 21. desember 2018 13.41 Til: cmake at cmake.org; Lars Emne: Re: [CMake] set_property imported_location_release Properties IMPORTED_LOCATION* do not support generator expressions. Generally speaking, if a property supports generator expression, it is explicitly specified in documentation. Le 21 d?c. 2018 ? 13:07 +0100, Lars , a ?crit : Hello, Trying to import an external library but having some issue with setting imported_location_release property. Basically I have config file which does this; add_library(foo STATIC IMPORTED) set_property(target foo APPEND PROPERTY interface_include_directories "$" "$") set_property(TARGET foo APPEND PROPERTY IMPORTED_LOCATION_RELEASE $<$:${foo_root}/lib/release/foo.a>) The imported target is used in a target_link_libraries method; target_link_libraries(an_application foo) Running CMake 3.6.1 does not produce any warnings. Running make I get a "target pattern contains no '%'" error message with a reference to a Build.make file. The Build.make contains the string " $<$:/tmp/prototype/foo/lib/release/foo.a". We did not expect to see the generator expression in the Build.make file. Does set_property support generator expression in this context? What are we doing wrong? Appreciate any help :-) king regards, Lars -- 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: https://cmake.org/mailman/listinfo/cmake -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.chevrier at gmail.com Fri Dec 21 09:46:18 2018 From: marc.chevrier at gmail.com (Marc CHEVRIER) Date: Fri, 21 Dec 2018 15:46:18 +0100 Subject: [CMake] set_property imported_location_release In-Reply-To: References: <7275c374-4ad1-475a-80ec-d83d5fb0d8a5@Spark> Message-ID: Yes, the most efficient way is using conditional setting. For example: if (CMAKE_SIZEOF_VOID_P EQUAL 4) ? set(import_path /to/lib32) else() ? set(import_path /to/lib64) endif() set_property(TARGET foo PROPERTY IMPORT_LOCATION "${import_path}/lib.so") Le 21 d?c. 2018 ? 15:14 +0100, Lars , a ?crit : > Marc, > > Appreciate the quick and helpful response. > > In a config file that supports multiple platforms, do I need to create import_location_path variable and populate it depending on platform and 32/64 etc? Any other options? > > Thanks. > > Kind regards, Lars > > Fra: Marc CHEVRIER > Sendt: fredag 21. desember 2018 13.41 > Til: cmake at cmake.org; Lars > Emne: Re: [CMake] set_property imported_location_release > > Properties IMPORTED_LOCATION* do not support generator expressions. > > Generally speaking, if a property supports generator expression, it is explicitly specified in documentation. > Le 21 d?c. 2018 ? 13:07 +0100, Lars , a ?crit : > > Hello, > > > > Trying to import an external library but having some issue with setting imported_location_release property. > > > > Basically I have config file which does this; > > add_library(foo STATIC IMPORTED) > > set_property(target foo APPEND PROPERTY > > ?? interface_include_directories > > ??? "$" > > ??? "$") > > > > set_property(TARGET foo APPEND PROPERTY > > ? IMPORTED_LOCATION_RELEASE > > ??? $<$:${foo_root}/lib/release/foo.a>) > > > > The imported target is used in a target_link_libraries method; > > target_link_libraries(an_application foo) > > > > Running CMake 3.6.1?does not produce any warnings. Running make I get a "target pattern contains no '%'" error message with a reference to a Build.make file. > > > > The Build.make contains the string "?$<$:/tmp/prototype/foo/lib/release/foo.a".? We did not expect to see the generator expression in the Build.make file. > > > > Does set_property support generator expression in this context? What are we doing wrong? > > > > Appreciate any help :-) > > > > king regards, Lars > > > > -- > > > > 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: > > https://cmake.org/mailman/listinfo/cmake -------------- next part -------------- An HTML attachment was scrubbed... URL: From laasunde at hotmail.com Fri Dec 21 10:31:56 2018 From: laasunde at hotmail.com (Lars) Date: Fri, 21 Dec 2018 15:31:56 +0000 Subject: [CMake] set_property imported_location_release In-Reply-To: References: <7275c374-4ad1-475a-80ec-d83d5fb0d8a5@Spark> , Message-ID: That is what I thought. Thank you. ________________________________ Fra: Marc CHEVRIER Sendt: fredag 21. desember 2018 15.46.18 Til: cmake at cmake.org; Lars Emne: Re: Sv: [CMake] set_property imported_location_release Yes, the most efficient way is using conditional setting. For example: if (CMAKE_SIZEOF_VOID_P EQUAL 4) set(import_path /to/lib32) else() set(import_path /to/lib64) endif() set_property(TARGET foo PROPERTY IMPORT_LOCATION "${import_path}/lib.so") Le 21 d?c. 2018 ? 15:14 +0100, Lars , a ?crit : Marc, Appreciate the quick and helpful response. In a config file that supports multiple platforms, do I need to create import_location_path variable and populate it depending on platform and 32/64 etc? Any other options? Thanks. Kind regards, Lars ________________________________ Fra: Marc CHEVRIER Sendt: fredag 21. desember 2018 13.41 Til: cmake at cmake.org; Lars Emne: Re: [CMake] set_property imported_location_release Properties IMPORTED_LOCATION* do not support generator expressions. Generally speaking, if a property supports generator expression, it is explicitly specified in documentation. Le 21 d?c. 2018 ? 13:07 +0100, Lars , a ?crit : Hello, Trying to import an external library but having some issue with setting imported_location_release property. Basically I have config file which does this; add_library(foo STATIC IMPORTED) set_property(target foo APPEND PROPERTY interface_include_directories "$" "$") set_property(TARGET foo APPEND PROPERTY IMPORTED_LOCATION_RELEASE $<$:${foo_root}/lib/release/foo.a>) The imported target is used in a target_link_libraries method; target_link_libraries(an_application foo) Running CMake 3.6.1 does not produce any warnings. Running make I get a "target pattern contains no '%'" error message with a reference to a Build.make file. The Build.make contains the string " $<$:/tmp/prototype/foo/lib/release/foo.a". We did not expect to see the generator expression in the Build.make file. Does set_property support generator expression in this context? What are we doing wrong? Appreciate any help :-) king regards, Lars -- 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: https://cmake.org/mailman/listinfo/cmake -------------- next part -------------- An HTML attachment was scrubbed... URL: From personwithhats2 at gmail.com Fri Dec 21 20:30:17 2018 From: personwithhats2 at gmail.com (Person Withhats) Date: Fri, 21 Dec 2018 17:30:17 -0800 Subject: [CMake] Handling real-time output from execute_process Message-ID: Hey there! I'm running a script that downloads some files and untars them. This takes a while but it outputs progress. Unfortunately I can't get the output to show up in real-time with CMake GUI or CLI. Current workaround to see output live, loses it in log though...... execute_process(COMMAND "cmd" /c "start /wait download_sdks.exe" WORKING_DIRECTORY "${SCRIPT_DIR}" OUTPUT_VARIABLE OUT RESULT_VARIABLE RES) Exit code is always 0 no matter what I do or how I get this set up. I want to see the output as it's running (preferably in same cmake window) and for the GUI stop-button to properly stop the script instead of hanging until script ends by itself. Right now I can get the output at the end but after 1.5 hours of untarring/etc. I'd be worried if it wasn't just frozen...... This is for windows 10 ofc and the .exe file is PyInstalled. Works fine double-clicking (launches terminal/etc.) but Cmake....ugh...... tl;dr script runs and works fine as usual but I can't see output *while* it's running instead of after. -------------- next part -------------- An HTML attachment was scrubbed... URL: From frodak17 at gmail.com Fri Dec 21 22:26:19 2018 From: frodak17 at gmail.com (frodak17) Date: Fri, 21 Dec 2018 22:26:19 -0500 Subject: [CMake] Handling real-time output from execute_process In-Reply-To: References: Message-ID: On Fri, Dec 21, 2018 at 8:30 PM Person Withhats wrote: > Hey there! > > I'm running a script that downloads some files and untars them. This takes > a while but it outputs progress. Unfortunately I can't get the output to > show up in real-time with CMake GUI or CLI. > > Current workaround to see output live, loses it in log though...... > execute_process(COMMAND "cmd" /c "start /wait download_sdks.exe" > WORKING_DIRECTORY "${SCRIPT_DIR}" > OUTPUT_VARIABLE OUT > RESULT_VARIABLE RES) > > Exit code is always 0 no matter what I do or how I get this set up. I want > to see the output as it's running (preferably in same cmake window) and for > the GUI stop-button to properly stop the script instead of hanging until > script ends by itself. > > Right now I can get the output at the end but after 1.5 hours of > untarring/etc. I'd be worried if it wasn't just frozen...... > > This is for windows 10 ofc and the .exe file is PyInstalled. Works fine > double-clicking (launches terminal/etc.) but Cmake....ugh...... > > tl;dr script runs and works fine as usual but I can't see output *while* > it's running instead of after. > How about use OUTPUT_FILE instead. Then while CMake is running you can do a tail -f on the output file in a different window or just check the contents in notepad. I don?t know what happens if you don?t redirect standard output from CMake maybe it shows in terminal. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From personwithhats2 at gmail.com Fri Dec 21 23:16:43 2018 From: personwithhats2 at gmail.com (Person Withhats) Date: Fri, 21 Dec 2018 20:16:43 -0800 Subject: [CMake] Handling real-time output from execute_process In-Reply-To: References: Message-ID: 1) I want output in real time on a Windows system(no tail), and piping output to a file then reading it is a very poor solution. 'just check the contents in note pad'.... 2) This is a general-purpose solution and not something I'm making just for myself, hacky fixes are not an option. On Fri, Dec 21, 2018 at 7:26 PM frodak17 wrote: > > > On Fri, Dec 21, 2018 at 8:30 PM Person Withhats > wrote: > >> Hey there! >> >> I'm running a script that downloads some files and untars them. This >> takes a while but it outputs progress. Unfortunately I can't get the output >> to show up in real-time with CMake GUI or CLI. >> >> Current workaround to see output live, loses it in log though...... >> execute_process(COMMAND "cmd" /c "start /wait download_sdks.exe" >> WORKING_DIRECTORY "${SCRIPT_DIR}" >> OUTPUT_VARIABLE OUT >> RESULT_VARIABLE RES) >> >> Exit code is always 0 no matter what I do or how I get this set up. I >> want to see the output as it's running (preferably in same cmake window) >> and for the GUI stop-button to properly stop the script instead of hanging >> until script ends by itself. >> >> Right now I can get the output at the end but after 1.5 hours of >> untarring/etc. I'd be worried if it wasn't just frozen...... >> >> This is for windows 10 ofc and the .exe file is PyInstalled. Works fine >> double-clicking (launches terminal/etc.) but Cmake....ugh...... >> >> tl;dr script runs and works fine as usual but I can't see output *while* >> it's running instead of after. >> > > How about use OUTPUT_FILE instead. Then while CMake is running you can do > a tail -f on the output file in a different window or just check the > contents in notepad. I don?t know what happens if you don?t redirect > standard output from CMake maybe it shows in terminal. > >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From frodak17 at gmail.com Sat Dec 22 02:56:13 2018 From: frodak17 at gmail.com (frodak17) Date: Sat, 22 Dec 2018 02:56:13 -0500 Subject: [CMake] Handling real-time output from execute_process In-Reply-To: References: Message-ID: On Fri, Dec 21, 2018 at 11:16 PM Person Withhats wrote: > 1) I want output in real time on a Windows system(no tail), and piping > output to a file then reading it is a very poor solution. 'just check the > contents in note pad'.... > 2) This is a general-purpose solution and not something I'm making just > for myself, hacky fixes are not an option. > > By default the command runs in the same console as cmake. So if it is a typical executable that prints to standard output it will be shown with the rest of the cmake output. Also the executable output can be captured to a file or variable instead of being shown. What you can't do is capture it in a variable or file and display it at the same time. When you use '"cmd" /c "start /wait download_sdks.exe"' this spawns a new console window that cmake knows nothing about. This breaks the normal usage of execute_process() because "start /wait" creates an independent console to run download_sdks.exe. cmake has no influence over this second console. So while you can see its outputs you can't capture it in any way through cmake. You get a return value of 0 in this case because the errorlevel from the second console isn't passed back correctly to the first console and then back to cmake. A quick google search shows that this would work: COMMAND "cmd" /c "start /wait download_sdks.exe & exit ^!errorlevel^!" assuming that download_sdks.exe actually returns any error codes. You don't say why download_sdks.exe can't be run as a normal executable. Nor do you say why you aren't using "start /wait /b" to keep everything in the same console as cmake is running in. You said you want to see the output from the command but are clearly trying to capture the output in a variable instead but don't mention why. I guess it's hacky but the tool download_sdks.exe seems to be broken in terms of console output (as it has to be run in a cmd.exe shell and not just as a standalone executable) and you have to compensate for that. That leaves you with redirecting the output to a file. This saves it so your script can read this file contents and do whatever you originally intended by capturing OUT and you can monitor as the file gets updated. Of course Windows has options for monitoring a file, powershell comes with "Get-Content mylogfile.log -Wait". I would have thought most developers have Git for Windows installed and it does provide tail. Now if download_sdks.exe can be fixed to print to standard out without all these cmd.exe console redirections than you can simply spawn powershell, run download_sdks.exe , use a Tee-Object to log the data to a file and still see its output in the original cmake console. CMake can then read the log back in and do whatever processing you originally intended. Now the GUI does seem to lag behind console output when hitting the configure button (at least when I tested it because I never used it before). In this case you may want to spawn a separate console to see the output instead of waiting for the GUI to display it. I'm not sure it's reasonable to expect the GUI stop button to kill a process it doesn't know about. You just close the console window and the GUI recognizes that execute_process() was interrupted. Not sure why you wouldn't consider that as acceptable. So you would still need to capture output to a file to process it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From personwithhats2 at gmail.com Sat Dec 22 14:03:37 2018 From: personwithhats2 at gmail.com (Person Withhats) Date: Sat, 22 Dec 2018 11:03:37 -0800 Subject: [CMake] Handling real-time output from execute_process In-Reply-To: References: Message-ID: Oops, forgot to add mailing list. Also, here's some sample CMake output that shows some issues. 1) Carrige return doesn't replace previous line of output == tons of %'s 2) Perhaps cuz I'm forcing no buffer in CMake it causes the below extra 2 new lines on each line of output?? Should be condensed at least... What I'm using to unbuffer: class Unbuffered(object): def __init__(self, stream): self.stream = stream def write(self, data): self.stream.write(data) self.stream.flush() def writelines(self, datas): self.stream.writelines(datas) self.stream.flush() def __getattr__(self, attr): return getattr(self.stream, attr) sys.stdout = Unbuffered(sys.stdout) sys.stdout.buffer = Unbuffered(sys.stdout.buffer) Downloading/Extracting SDKs... Download URL: "XXXXXX" Downloading 779738578 Bytes 65536 [0.01%] 131072 [0.02%] 196608 [0.03%] 262144 [0.03%] On Fri, Dec 21, 2018 at 11:56 PM frodak17 wrote: > > > On Fri, Dec 21, 2018 at 11:16 PM Person Withhats < > personwithhats2 at gmail.com> wrote: > >> 1) I want output in real time on a Windows system(no tail), and piping >> output to a file then reading it is a very poor solution. 'just check the >> contents in note pad'.... >> 2) This is a general-purpose solution and not something I'm making just >> for myself, hacky fixes are not an option. >> >> > By default the command runs in the same console as cmake. > So if it is a typical executable that prints to standard output it will be > shown with the rest of the cmake output. > Also the executable output can be captured to a file or variable instead > of being shown. > What you can't do is capture it in a variable or file and display it at > the same time. > > When you use '"cmd" /c "start /wait download_sdks.exe"' this spawns a new > console window that cmake knows nothing about. > This breaks the normal usage of execute_process() because "start /wait" > creates an independent console to run download_sdks.exe. > cmake has no influence over this second console. So while you can see its > outputs you can't capture it in any way through cmake. > > You get a return value of 0 in this case because the errorlevel from the > second console isn't passed back correctly to the first console and then > back to cmake. > A quick google search shows that this would work: COMMAND "cmd" /c "start > /wait download_sdks.exe & exit ^!errorlevel^!" assuming that > download_sdks.exe actually returns any error codes. > > You don't say why download_sdks.exe can't be run as a normal executable. > Nor do you say why you aren't using "start /wait /b" to keep everything in > the same console as cmake is running in. > You said you want to see the output from the command but are clearly > trying to capture the output in a variable instead but don't mention why. > > I guess it's hacky but the tool download_sdks.exe seems to be broken in > terms of console output (as it has to be run in a cmd.exe shell and not > just as a standalone executable) and you have to compensate for that. > That leaves you with redirecting the output to a file. This saves it so > your script can read this file contents and do whatever you originally > intended by capturing OUT and you can monitor as the file gets updated. > > Of course Windows has options for monitoring a file, powershell comes with > "Get-Content mylogfile.log -Wait". I would have thought most developers > have Git for Windows installed and it does provide tail. > > Now if download_sdks.exe can be fixed to print to standard out without all > these cmd.exe console redirections than you can simply spawn powershell, > run download_sdks.exe , use a Tee-Object to log the data to a file and > still see its output in the original cmake console. CMake can then read the > log back in and do whatever processing you originally intended. > > Now the GUI does seem to lag behind console output when hitting the > configure button (at least when I tested it because I never used it > before). In this case you may want to spawn a separate console to see the > output instead of waiting for the GUI to display it. I'm not sure it's > reasonable to expect the GUI stop button to kill a process it doesn't know > about. You just close the console window and the GUI recognizes that > execute_process() was interrupted. Not sure why you wouldn't consider that > as acceptable. So you would still need to capture output to a file to > process it. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From personwithhats2 at gmail.com Sat Dec 22 14:03:53 2018 From: personwithhats2 at gmail.com (Person Withhats) Date: Sat, 22 Dec 2018 11:03:53 -0800 Subject: [CMake] Handling real-time output from execute_process In-Reply-To: References: Message-ID: Cmake GUI output* On Sat, Dec 22, 2018 at 11:03 AM Person Withhats wrote: > Oops, forgot to add mailing list. > > Also, here's some sample CMake output that shows some issues. > 1) Carrige return doesn't replace previous line of output == tons of %'s > 2) Perhaps cuz I'm forcing no buffer in CMake it causes the below extra 2 > new lines on each line of output?? Should be condensed at least... > > What I'm using to unbuffer: > class Unbuffered(object): > def __init__(self, stream): > self.stream = stream > def write(self, data): > self.stream.write(data) > self.stream.flush() > def writelines(self, datas): > self.stream.writelines(datas) > self.stream.flush() > def __getattr__(self, attr): > return getattr(self.stream, attr) > > sys.stdout = Unbuffered(sys.stdout) > sys.stdout.buffer = Unbuffered(sys.stdout.buffer) > > > > Downloading/Extracting SDKs... > > > > Download URL: "XXXXXX" > > > > Downloading 779738578 Bytes > > > > 65536 [0.01%] > > > > 131072 [0.02%] > > > > 196608 [0.03%] > > > > 262144 [0.03%] > > > > > On Fri, Dec 21, 2018 at 11:56 PM frodak17 wrote: > >> >> >> On Fri, Dec 21, 2018 at 11:16 PM Person Withhats < >> personwithhats2 at gmail.com> wrote: >> >>> 1) I want output in real time on a Windows system(no tail), and piping >>> output to a file then reading it is a very poor solution. 'just check the >>> contents in note pad'.... >>> 2) This is a general-purpose solution and not something I'm making just >>> for myself, hacky fixes are not an option. >>> >>> >> By default the command runs in the same console as cmake. >> So if it is a typical executable that prints to standard output it will >> be shown with the rest of the cmake output. >> Also the executable output can be captured to a file or variable instead >> of being shown. >> What you can't do is capture it in a variable or file and display it at >> the same time. >> >> When you use '"cmd" /c "start /wait download_sdks.exe"' this spawns a new >> console window that cmake knows nothing about. >> This breaks the normal usage of execute_process() because "start /wait" >> creates an independent console to run download_sdks.exe. >> cmake has no influence over this second console. So while you can see >> its outputs you can't capture it in any way through cmake. >> >> You get a return value of 0 in this case because the errorlevel from the >> second console isn't passed back correctly to the first console and then >> back to cmake. >> A quick google search shows that this would work: COMMAND "cmd" /c "start >> /wait download_sdks.exe & exit ^!errorlevel^!" assuming that >> download_sdks.exe actually returns any error codes. >> >> You don't say why download_sdks.exe can't be run as a normal executable. >> Nor do you say why you aren't using "start /wait /b" to keep everything >> in the same console as cmake is running in. >> You said you want to see the output from the command but are clearly >> trying to capture the output in a variable instead but don't mention why. >> >> I guess it's hacky but the tool download_sdks.exe seems to be broken in >> terms of console output (as it has to be run in a cmd.exe shell and not >> just as a standalone executable) and you have to compensate for that. >> That leaves you with redirecting the output to a file. This saves it so >> your script can read this file contents and do whatever you originally >> intended by capturing OUT and you can monitor as the file gets updated. >> >> Of course Windows has options for monitoring a file, powershell comes >> with "Get-Content mylogfile.log -Wait". I would have thought most >> developers have Git for Windows installed and it does provide tail. >> >> Now if download_sdks.exe can be fixed to print to standard out without >> all these cmd.exe console redirections than you can simply spawn >> powershell, run download_sdks.exe , use a Tee-Object to log the data to a >> file and still see its output in the original cmake console. CMake can then >> read the log back in and do whatever processing you originally intended. >> >> Now the GUI does seem to lag behind console output when hitting the >> configure button (at least when I tested it because I never used it >> before). In this case you may want to spawn a separate console to see the >> output instead of waiting for the GUI to display it. I'm not sure it's >> reasonable to expect the GUI stop button to kill a process it doesn't know >> about. You just close the console window and the GUI recognizes that >> execute_process() was interrupted. Not sure why you wouldn't consider that >> as acceptable. So you would still need to capture output to a file to >> process it. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From personwithhats2 at gmail.com Sat Dec 22 17:15:08 2018 From: personwithhats2 at gmail.com (Person Withhats) Date: Sat, 22 Dec 2018 14:15:08 -0800 Subject: [CMake] Handling real-time output from execute_process In-Reply-To: References: Message-ID: Fixed extra spaces, was due to buffer (had to strip line endings). I'mma make a new thread this mess is my fault. On Sat, Dec 22, 2018 at 11:03 AM Person Withhats wrote: > Oops, forgot to add mailing list. > > Also, here's some sample CMake output that shows some issues. > 1) Carrige return doesn't replace previous line of output == tons of %'s > 2) Perhaps cuz I'm forcing no buffer in CMake it causes the below extra 2 > new lines on each line of output?? Should be condensed at least... > > What I'm using to unbuffer: > class Unbuffered(object): > def __init__(self, stream): > self.stream = stream > def write(self, data): > self.stream.write(data) > self.stream.flush() > def writelines(self, datas): > self.stream.writelines(datas) > self.stream.flush() > def __getattr__(self, attr): > return getattr(self.stream, attr) > > sys.stdout = Unbuffered(sys.stdout) > sys.stdout.buffer = Unbuffered(sys.stdout.buffer) > > > > Downloading/Extracting SDKs... > > > > Download URL: "XXXXXX" > > > > Downloading 779738578 Bytes > > > > 65536 [0.01%] > > > > 131072 [0.02%] > > > > 196608 [0.03%] > > > > 262144 [0.03%] > > > > > On Fri, Dec 21, 2018 at 11:56 PM frodak17 wrote: > >> >> >> On Fri, Dec 21, 2018 at 11:16 PM Person Withhats < >> personwithhats2 at gmail.com> wrote: >> >>> 1) I want output in real time on a Windows system(no tail), and piping >>> output to a file then reading it is a very poor solution. 'just check the >>> contents in note pad'.... >>> 2) This is a general-purpose solution and not something I'm making just >>> for myself, hacky fixes are not an option. >>> >>> >> By default the command runs in the same console as cmake. >> So if it is a typical executable that prints to standard output it will >> be shown with the rest of the cmake output. >> Also the executable output can be captured to a file or variable instead >> of being shown. >> What you can't do is capture it in a variable or file and display it at >> the same time. >> >> When you use '"cmd" /c "start /wait download_sdks.exe"' this spawns a new >> console window that cmake knows nothing about. >> This breaks the normal usage of execute_process() because "start /wait" >> creates an independent console to run download_sdks.exe. >> cmake has no influence over this second console. So while you can see >> its outputs you can't capture it in any way through cmake. >> >> You get a return value of 0 in this case because the errorlevel from the >> second console isn't passed back correctly to the first console and then >> back to cmake. >> A quick google search shows that this would work: COMMAND "cmd" /c "start >> /wait download_sdks.exe & exit ^!errorlevel^!" assuming that >> download_sdks.exe actually returns any error codes. >> >> You don't say why download_sdks.exe can't be run as a normal executable. >> Nor do you say why you aren't using "start /wait /b" to keep everything >> in the same console as cmake is running in. >> You said you want to see the output from the command but are clearly >> trying to capture the output in a variable instead but don't mention why. >> >> I guess it's hacky but the tool download_sdks.exe seems to be broken in >> terms of console output (as it has to be run in a cmd.exe shell and not >> just as a standalone executable) and you have to compensate for that. >> That leaves you with redirecting the output to a file. This saves it so >> your script can read this file contents and do whatever you originally >> intended by capturing OUT and you can monitor as the file gets updated. >> >> Of course Windows has options for monitoring a file, powershell comes >> with "Get-Content mylogfile.log -Wait". I would have thought most >> developers have Git for Windows installed and it does provide tail. >> >> Now if download_sdks.exe can be fixed to print to standard out without >> all these cmd.exe console redirections than you can simply spawn >> powershell, run download_sdks.exe , use a Tee-Object to log the data to a >> file and still see its output in the original cmake console. CMake can then >> read the log back in and do whatever processing you originally intended. >> >> Now the GUI does seem to lag behind console output when hitting the >> configure button (at least when I tested it because I never used it >> before). In this case you may want to spawn a separate console to see the >> output instead of waiting for the GUI to display it. I'm not sure it's >> reasonable to expect the GUI stop button to kill a process it doesn't know >> about. You just close the console window and the GUI recognizes that >> execute_process() was interrupted. Not sure why you wouldn't consider that >> as acceptable. So you would still need to capture output to a file to >> process it. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From personwithhats2 at gmail.com Sat Dec 22 17:17:04 2018 From: personwithhats2 at gmail.com (Person Withhats) Date: Sat, 22 Dec 2018 14:17:04 -0800 Subject: [CMake] Carriage returns in CMake GUI + Stopping execute_process() Message-ID: 2 questions: 1) I'm printing download progress via carrige returns, but the CMake GUI does it like this. Anyway to get output to work properly? 21561344 [2.77%] 21626880 [2.77%] 21692416 [2.78%] 21757952 [2.79%] 21823488 [2.80%] 21889024 [2.81%] 21954560 [2.82%] 22020096 [2.82%] 22085632 [2.83%] 22151168 [2.84%] 2) Pressing 'Stop' does not halt processes spun up by execute_process, CMake waits until they finish before exiting.....very aggrevating! -------------- next part -------------- An HTML attachment was scrubbed... URL: From frodak17 at gmail.com Sat Dec 22 17:55:58 2018 From: frodak17 at gmail.com (frodak17) Date: Sat, 22 Dec 2018 17:55:58 -0500 Subject: [CMake] Carriage returns in CMake GUI + Stopping execute_process() In-Reply-To: References: Message-ID: On Sat, Dec 22, 2018 at 5:17 PM Person Withhats wrote: > > 2) Pressing 'Stop' does not halt processes spun up by execute_process, > CMake waits until they finish before exiting.....very aggrevating! > > Looks like this would require a code change how the GUI works and the internal way execute_process works. Now execute_process knows how to cancel a process due to time out, but it didn't seem to check for anything else. Essentially it looks like execute_process needs to be signaled by the button press to cancel the process in addition to checking for timeout. There are other internal interrupt flags that seem to be set when the GUI stop button is pressed. Anyways this is what I noticed in the code base. -------------- next part -------------- An HTML attachment was scrubbed... URL: From personwithhats2 at gmail.com Sat Dec 22 17:59:16 2018 From: personwithhats2 at gmail.com (Person Withhats) Date: Sat, 22 Dec 2018 14:59:16 -0800 Subject: [CMake] Carriage returns in CMake GUI + Stopping execute_process() In-Reply-To: References: Message-ID: Seems like a pretty big issue though, if people have to open task manager every time they rethink what they're doing in CMake and what not. Maybe someone has a workaround or something. And #1 might not be possible if CMake is monitoring a file instead of printing input to console & file......... On Sat, Dec 22, 2018 at 2:56 PM frodak17 wrote: > > > On Sat, Dec 22, 2018 at 5:17 PM Person Withhats > wrote: > >> >> 2) Pressing 'Stop' does not halt processes spun up by execute_process, >> CMake waits until they finish before exiting.....very aggrevating! >> >> > Looks like this would require a code change how the GUI works and the > internal way execute_process works. Now execute_process knows how to > cancel a process due to time out, but it didn't seem to check for anything > else. Essentially it looks like execute_process needs to be signaled by > the button press to cancel the process in addition to checking for > timeout. There are other internal interrupt flags that seem to be set when > the GUI stop button is pressed. Anyways this is what I noticed in the code > base. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ocroquette at free.fr Mon Dec 24 06:01:15 2018 From: ocroquette at free.fr (Olivier Croquette) Date: Mon, 24 Dec 2018 12:01:15 +0100 Subject: [CMake] Syntax to document cmake files, functions and macros Message-ID: Hello, I have quite a few .cmake files that I want to document. They define functions, macros, and variables, and I was wondering if there is any standard or tooling to help. Is there a complete specification of the syntax used in the CMake distribution itself? E.g.: add_executable( [WIN32] [MACOSX_BUNDLE] ?????????????? [EXCLUDE_FROM_ALL] ?????????????? [source1] [source2 ...]) add_definitions(-DFOO -DBAR ...) add_custom_target(Name [ALL] [command1 [args1...]] ????????????????? [COMMAND command2 [args2...] ...] ????????????????? [DEPENDS depend depend depend ... ] ????????????????? [BYPRODUCTS [files...]] ????????????????? [WORKING_DIRECTORY dir] ????????????????? [COMMENT comment] ????????????????? [VERBATIM] [USES_TERMINAL] ????????????????? [COMMAND_EXPAND_LISTS] ????????????????? [SOURCES src1 [src2...]]) It looks like the documentation is not completely consistent by the way, for instance, the first argument of add_executable is , and of add_custom_target is Name, although is same situation, isn't it? For functions and macros, I can reuse this syntax, is there anything similar for documenting a file, or variables? More generally, is there anything like Doxygen, Javadoc, both in terms of syntax and tooling to generate documents from source code? Olivier From oleksii.vilchanskyi at gmail.com Mon Dec 24 06:32:26 2018 From: oleksii.vilchanskyi at gmail.com (Oleksii Vilchanskyi) Date: Mon, 24 Dec 2018 12:32:26 +0100 Subject: [CMake] Syntax to document cmake files, functions and macros In-Reply-To: References: Message-ID: <1506c326-ebba-3f1d-32b3-7ac8f0100d4f@gmail.com> On 12/24/18 12:01 PM, Olivier Croquette wrote: > I have quite a few .cmake files that I want to document. They define > functions, macros, and variables, and I was wondering if there is any > standard or tooling to help. Yes, see [1]. You can find concrete examples at [2]. [1]: [2]: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From robert.maynard at kitware.com Mon Dec 24 10:46:56 2018 From: robert.maynard at kitware.com (Robert Maynard) Date: Mon, 24 Dec 2018 10:46:56 -0500 Subject: [CMake] Get linker flags / include directories for a library target In-Reply-To: <8a711a8d20249114189f9ab89359e561c464c4e1.camel@gmx.de> References: <965c52de901d462e84324b3748195ed4a36bf4e4.camel@gmx.de> <4BF6D799-4941-4460-871C-9F18B80E88EB@gmail.com> <8a711a8d20249114189f9ab89359e561c464c4e1.camel@gmx.de> Message-ID: That functionality exists in the C++ side of the code base and is run during the 'generate' stage ( CMakeLists are parsed during 'configure', than a 'generate' step is run ). To get access to how import targets and generator expressions are resolved you have two options. 1. You can try to use file(GENERATE but it doesn't support all the generator expressions currently 2. You use cmake-server (https://cmake.org/cmake/help/latest/manual/cmake-server.7.html) to query a build directory for all this information. On Fri, Dec 21, 2018 at 9:12 AM Unknown wrote: > > Hello Kai, > > thanks for your suggestion. I tried the property, > but I just got "foo_linker_flags-NOTFOUND" as a > result (I am using cmake 3.13.1 btw). The > same goes for > > LINK_OPTIONS, and > INTERFACE_LINK_OPTIONS. > > I tried using the INTERFACE_LINK_LIBRARIES property > instead. The resulting list contains things I can use, > such as /usr/lib/libz.so > > However, I am using another cmake imported library. > Therefore, the list contains some libbaz::libbaz > dependency as well. > > In order to get the actual list of libraries, I would > have to also resolve these names. > > But this has to be done somewhere during the > generation of the Makefiles, so that functionality > must exist somewhere in cmake. > > > On Fri, 2018-12-21 at 09:33 +0100, Kai Wolf wrote: > > You can ask a CMake build target for its properties using > > get_target_property(). > > For instance, to retrieve the linker flags for a given target foo, > > you?d write: > > > > get_target_prooperty(foo_linker_flags foo LINK_FLAGS) > > > > See [1] for a list of valid parameters. > > > > Greetings, > > > > Kai > > > > [1] > > https://cmake.org/cmake/help/latest/manual/cmake-properties.7.html#properties-on-targets > > > > http://kai-wolf.me > > http://effective-cmake.com > > > > > Am 20.12.2018 um 23:14 schrieb Unknown : > > > > > > Dear community, > > > > > > I have been wondering on multiple occasions about how to get the > > > linker flags (i.e. all -llib -Ldir) and include flags (-Idir) > > > for a library (i.e. a target added to the project using > > > add_library) within a cmake. > > > > > > There are many cases in which the flags are required, noticeably > > > generating a suitable pkg-config file or creating a wrappers around > > > C/C++ libraries. > > > > > > I think that it should be possible to derive the flags from > > > some of the target properties of the library, but I don't > > > know exactly how. > > > > > > Could you give me a hand? > > > > > > ax487 > > > > > > -- > > > > > > 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: > > > https://cmake.org/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: > https://cmake.org/mailman/listinfo/cmake From bo.schwarzstein at gmail.com Mon Dec 24 21:04:13 2018 From: bo.schwarzstein at gmail.com (Bo Zhou) Date: Tue, 25 Dec 2018 11:04:13 +0900 Subject: [CMake] Get linker flags / include directories for a library target In-Reply-To: <965c52de901d462e84324b3748195ed4a36bf4e4.camel@gmx.de> References: <965c52de901d462e84324b3748195ed4a36bf4e4.camel@gmx.de> Message-ID: All the flags/options in the CMake they could be considered as a list. So it's much more easier to handle it as this set(WIN_DEFINITIONS -DNOMINMAX) Remember the list is the object, so we could construct the new list for the specific target. Then to the specific target, just use the 3 commands. target_compile_options() target_include_directories() target_link_libraries() We use this method to organize the cross-platform with library and executable without any problem, and super easy to control and manage. Thanks. On Fri, Dec 21, 2018 at 7:19 AM Unknown wrote: > Dear community, > > I have been wondering on multiple occasions about how to get the > linker flags (i.e. all -llib -Ldir) and include flags (-Idir) > for a library (i.e. a target added to the project using > add_library) within a cmake. > > There are many cases in which the flags are required, noticeably > generating a suitable pkg-config file or creating a wrappers around > C/C++ libraries. > > I think that it should be possible to derive the flags from > some of the target properties of the library, but I don't > know exactly how. > > Could you give me a hand? > > ax487 > > -- > > 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: > https://cmake.org/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From soriposforums at gmail.com Tue Dec 25 15:40:24 2018 From: soriposforums at gmail.com (Sori Pos) Date: Tue, 25 Dec 2018 21:40:24 +0100 Subject: [CMake] While running CMake for building ReactOS on AWS EC2, the configure.sh (cmake) kills all SSH connections Message-ID: Hello everyone! I launched a clean AWS Instance (of type Amazon Linux AMI which is based on RedHat), and I am trying to build ReactOS by using the normal steps described in their documentation. I downloaded their "ReactOS Build Environment" and configured it correctly, then I did a "git checkout reactos". Then, after running "./RosBE.sh" then I tried to execute ./configure.sh from within the folder output-MinGW-i386/reactos The last lines of their "configure.sh" are these: echo Preparing reactos... cd reactos rm -f CMakeCache.txt host-tools/CMakeCache.txt cmake -G "$CMAKE_GENERATOR" -DENABLE_CCACHE:BOOL=0 -DCMAKE_TOOLCHAIN_FILE:FILEPATH=toolchain-gcc.cmake -DARCH:STRING=$ARCH -DNEW_STYLE_BUILD:BOOL=$USE_NEW_STYLE $EXTRA_ARGS $ROS_CMAKEOPTS "$REACTOS_SOURCE_DIR" echo Configure script complete! Enter directories and execute appropriate build commands \(ex: ninja, make, makex, etc...\). My console logs display this: bash-4.2$ ./configure.sh Creating directories in output-MinGW-i386 Preparing reactos... -- The C compiler identification is GNU 4.7.2 -- The CXX compiler identification is GNU 4.7.2 -- Check for working C compiler using: Ninja -- Check for working C compiler using: Ninja -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Detecting C compile features -- Detecting C compile features - done -- Check for working CXX compiler using: Ninja -- Check for working CXX compiler using: Ninja -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done -- Found Git: /usr/bin/git (found version "2.14.5") -- Build Type: Debug -- The ASM compiler identification is GNU -- Found assembler: /work/rosbe2.1.2/i386/bin/i686-w64-mingw32-gcc -- Selected localization: all -- fusion has no base address -- fusion_1_1 has no base address -- fusion_2_0 has no base address -- xolehlp has no base address -- Configuring done Connection to "xx.yy.zz.tt" closed by remote host. So the ReactOS script displays "Preparing reactos..." but then never gets to the point to display "Configure script complete! Enter directories and execute appropriate build commands". Basically this means that something happens inside the cmake call, which causes the AWS host to forcible close the connection. And, to make things even weirder, I have also discovered this while trying to trace the list of running processes from another ssh connection to the same host: This CMake bug forced the close of BOTH ssh connections (not only the one in which I was running "configure", but also the other ssh connection which was unrelated! ) Do you have any explanation as to what bug inside CMake is causing the amazon node to kill all ssh connections? Thanks, and sorry for the long rant, I was trying to be as detailed as possible. :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From soriposforums at gmail.com Thu Dec 27 03:30:04 2018 From: soriposforums at gmail.com (Sori Pos) Date: Thu, 27 Dec 2018 09:30:04 +0100 Subject: [CMake] While running CMake for building ReactOS on AWS EC2, the configure.sh (cmake) kills all SSH connections In-Reply-To: References: Message-ID: Sorry guys, I have found the cause of the problem after posting the same question in the ReactOS forums: https://reactos.org/forum/viewtopic.php?f=9&t=18137&p=135307 The problem was that my instance had only 1GB of RAM, and the ReactOS CMake configure step needs at least 2-4 GB of RAM, so this was causing the SSH connections to crash. (And the initial ReactOS build documentation did not specify that I need at least 2-4 GB of RAM, so I updated it to include this requirement.) I have tried it again on another instance with 4GB of RAM and it was executed successfully. Anyway, I found this behaviour of sshd to be really stupid... :( I mean, how can someone expect that the SSH connection was reset because of out-of-memory... On Tue, Dec 25, 2018 at 9:40 PM Sori Pos wrote: > Hello everyone! > > I launched a clean AWS Instance (of type Amazon Linux AMI which is based > on RedHat), and I am trying to build ReactOS by using the normal steps > described in their documentation. > > I downloaded their "ReactOS Build Environment" and configured it > correctly, then I did a "git checkout reactos". Then, after running "./RosBE.sh" > then I tried to execute ./configure.sh from within the folder > output-MinGW-i386/reactos > > The last lines of their "configure.sh" are these: > > echo Preparing reactos... > > cd reactos > > rm -f CMakeCache.txt host-tools/CMakeCache.txt > > > cmake -G "$CMAKE_GENERATOR" -DENABLE_CCACHE:BOOL=0 > -DCMAKE_TOOLCHAIN_FILE:FILEPATH=toolchain-gcc.cmake -DARCH:STRING=$ARCH > -DNEW_STYLE_BUILD:BOOL=$USE_NEW_STYLE $EXTRA_ARGS $ROS_CMAKEOPTS > "$REACTOS_SOURCE_DIR" > > > echo Configure script complete! Enter directories and execute appropriate > build commands \(ex: ninja, make, makex, etc...\). > > > > > My console logs display this: > > > bash-4.2$ ./configure.sh > > Creating directories in output-MinGW-i386 > > Preparing reactos... > > -- The C compiler identification is GNU 4.7.2 > > -- The CXX compiler identification is GNU 4.7.2 > > -- Check for working C compiler using: Ninja > > -- Check for working C compiler using: Ninja -- works > > -- Detecting C compiler ABI info > > -- Detecting C compiler ABI info - done > > -- Detecting C compile features > > -- Detecting C compile features - done > > -- Check for working CXX compiler using: Ninja > > -- Check for working CXX compiler using: Ninja -- works > > -- Detecting CXX compiler ABI info > > -- Detecting CXX compiler ABI info - done > > -- Detecting CXX compile features > > -- Detecting CXX compile features - done > > -- Found Git: /usr/bin/git (found version "2.14.5") > > -- Build Type: Debug > > -- The ASM compiler identification is GNU > > -- Found assembler: /work/rosbe2.1.2/i386/bin/i686-w64-mingw32-gcc > > -- Selected localization: all > > -- fusion has no base address > > -- fusion_1_1 has no base address > > -- fusion_2_0 has no base address > > -- xolehlp has no base address > > -- Configuring done > > Connection to "xx.yy.zz.tt" closed by remote host. > > > > > > So the ReactOS script displays "Preparing reactos..." but then never gets > to the point to display "Configure script complete! Enter directories and > execute appropriate build commands". > > > Basically this means that something happens inside the cmake call, which > causes the AWS host to forcible close the connection. > > > And, to make things even weirder, I have also discovered this while trying > to trace the list of running processes from another ssh connection to the > same host: This CMake bug forced the close of BOTH ssh connections (not > only the one in which I was running "configure", but also the other ssh > connection which was unrelated! ) > > > Do you have any explanation as to what bug inside CMake is causing the > amazon node to kill all ssh connections? > > > > Thanks, and sorry for the long rant, I was trying to be as detailed as > possible. :) > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chuck.atkins at kitware.com Thu Dec 27 17:04:35 2018 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Thu, 27 Dec 2018 17:04:35 -0500 Subject: [CMake] cmake cannot find source file (new to cmake) In-Reply-To: References: Message-ID: > > When I ran "cmake .." in bin, cmake complained that it could not find > source file src1.h in add_executable. What is wrong here? > Hi Lei, Alex hit several of these points, but to wrap it up together: A couple of things... - There's no need for a CMakeLists.txt in a directory if it's not actually going to do anything. i.e. if you're not adding targets or executing any other CMake code then just traversing the directories doesn't serve any particular purpose. - The list of source files that a target uses to build don't have to necessarily be full paths, they can be absolute or relative paths, but the relative paths need to be relative to where the target is created, i.e. the add_executable(...) call. So in your case, the target is "exec" in the "src" folder so all paths to source files, if relative paths and not absolute paths, need to be relative to the src directory. - include_directories is the older style CMake and will apply to all targets created after it. Use target_include_directories instead for the more modern target-centric approach of having commands only apply to the appropriate target instead of globally. - Rather than use a list of sources, you can also use the target_sources command to programmatically add source files to a target based on necessary logic. The same restriction applies though that the sources added need to be relative to the target location or an absolute path. - The preferred project layout for CMake is to really have out-of-source builds. So instead having bin as a sub-directory of your project, just eliminate that level entirely. You can certainly create your structure however you want but that's the suggested and preferred way of organising. Combining these things, you could have nested CMakeLists.txt in which the subdirectories are explicitly adding the sources: - Top Level: - CMakeLists.txt cmake_minimum_required(VERSION 3.8) project(proj) add_executable(exec) add_subdirectory(common) add_subdirectory(dir1) - common/ - src1.h - CMakeLists.txt target_include_directories(exec PRIVATE ${CMAKE_CURRENT_SOURCE_DIR}) target_sources(exec PRIVATE ${CMAKE_CURRENT_SOURCE_DIR}/src1.h) - dir1/ - src1.c - src2.c - CMakeLists.txt target_sources(exec PRIVATE ${CMAKE_CURRENT_SOURCE_DIR}/src1.c ${CMAKE_CURRENT_SOURCE_DIR}/src2.c ) Or a much simpler single file where no nested CMakeLists.txt are needed since they wouldn't be doing anything: - Top Level: - CMakeLists.txt cmake_minimum_required(VERSION 3.8) project(proj) add_executable(exec common/src1.h dir1/src1.c dir1/src2.c ) target_include_directories(exec common) - common/ - src1.h - dir1/ - src1.c - src2.c Both are valid, the first is overkill for this simple example but illustrates a way of doing things that can be helpful with much more complex projects. Either way, you also have a build directory completely detached and outside your source tree instead of a sub-directory. - Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From frelyn.sdiwc at gmail.com Fri Dec 28 01:52:27 2018 From: frelyn.sdiwc at gmail.com (Frelyn SDIWC) Date: Fri, 28 Dec 2018 14:52:27 +0800 Subject: [CMake] The Fourth International Conference on Electrical, Electronics, Computer Engineering and their Applications (EECEA2019) Message-ID: You are invited to participate in *The Fourth International Conference on Electrical, Electronics, Computer Engineering and their Applications (EECEA2019)* that will be held at *University of Perpetual Help System DALTA, Las Pi?as, Manila, Philippines* on *February 20-22, 2019*. The event will be held over three days, with presentations delivered by researchers from the international community, including presentations from keynote speakers and state-of-the-art lectures. The conference welcomes papers on the following (but not limited to) research topics: *-----Electronics Engineering-----* 3D Semiconductor Device Technology Adaptive Signal Processing Advanced Electromagnetics Artificial Intelligence Component Technology of MEMS Compound Semiconductor Physics and Devices Computer Engineering Device Electronics for I.C Electronics System-Level Based Design Electronics & Nano Electronics Electronics-Medical Electronics Epitaxy and Light-emitting Diodes Fiber Optics and Fiber Devices Giant Area Microelectronics Intelligent Transportation Systems Integrated Optics Medicine and Biology Applications Micro/Nano Systems and Networks Mixed Signal Circuits Mobile Computing Mobile Robotics Multimedia Services and Technologies Networks Design, Protocols and Management Optical Electronic Devices & Photonics Radio-Frequency Integrated Circuits Signal & Image Processing VLSI Testing and Design for Testability *-----Electrical Engineering-----* Software Specification Software Assurance Analysis of Power Quality and System Stability Assembly and Packaging Analog Circuits and Digital Circuits Antenna and Propagation Battery Management System Circuits and Electronics Computer Relaying Electric Energy Processing Electromagnetic and Photonics Electro-optical Phenomena of Semiconductors Integrated Optics and Electro-optics Devices Microwave Theory and Techniques Microwave and millimeter circuit and Antenna Modulation, Coding, and Channel Analysis Power Electronics Power IC Remote control and techniques of GPS Remote Control and Techniques of GPS Robotics and Atomization Engineering Signal Integrity Design for High-Speed Digital Systems Signal Processing Simulation of Propagation Smart Grid Solar Power Generation Techniques of Laser and Applications Of Electro-optics Wind Power Generation *-----Computer Engineering-----* Algorithms Artificial Intelligence Automated Software Engineering Bioinformatics and Scientific Computing Computer-aided Design Computer Animation Computer Architecture Computing Ethics Computer Modeling Computer Networks Computer Security Computer Simulation Database and Data Mining Data Compression Data Encryption Data Mining Digital Signal and Image Processing Digital System and Logic Design Expert Systems Image Processing Information Systems Internet and Web Applications Mobile Computing Network Security and Cryptography Multimedia Applications Multimedia Networking Mobile Wireless Networks Programming Languages Wireless Communication Wireless Sensor Network Important Dates Submission Date *Jan. 20, 2019* Notification of Acceptance *Feb. 3, 2019* Camera Ready Submission *Feb. 10, 2019* Registration Deadline *Feb. 10, 2019* Conference Dates *Feb. 20-22, 2019* For more inquiries, just visit* http://sdiwc.net/conferences/4th-international-conference-electrical-electronics-computer-engineering-applications/ * or email us at *eecea19 at sdiwc.net * -------------- next part -------------- An HTML attachment was scrubbed... URL: From ax487 at gmx.de Fri Dec 28 18:04:30 2018 From: ax487 at gmx.de (Unknown) Date: Sat, 29 Dec 2018 00:04:30 +0100 Subject: [CMake] Get linker flags / include directories for a library target In-Reply-To: References: <965c52de901d462e84324b3748195ed4a36bf4e4.camel@gmx.de> <4BF6D799-4941-4460-871C-9F18B80E88EB@gmail.com> <8a711a8d20249114189f9ab89359e561c464c4e1.camel@gmx.de> Message-ID: <8763e456344433bc0833c003ee92801ae47b5f8a.camel@gmx.de> I would like to thank all of you for your suggestions. I have gathered the following (correct me if I am wrong): - The LINK_FLAGS target property is used in cmake 2.x, the INTERFACE_LINK_LIBRARIES in cmake 3.x, the latter contains a ;-list of libraries. - The list may contain generator expressions, it is however possible to to use file(GENERATE ..) to obtain evaluate those. - In any case, the library list contains libraries having different formats (see [1]), full paths, (imported) targets, and plain names. - When Makefiles (or files for other build systems) are generated, the list is turned into -L/-l flags used by ld. This happens on the C++ side of things, the functionality is not exposed to cmake scripts. As for automatic generation of a pkg-config .pc file, there have been some inquiries ([2], [3], and [4]), the last one being rather recent. The answers point out that pkg-config files can be generated using configure_file(...), that cmake has its own (imported target) method for handling dependencies. I don't mean to be disrespectful or unappreciative of the work put into cmake (in fact I think it is a vast improvement over automake), but since there is no way to obtain the required information programatically, all users of my library have to either use cmake themselves, or use non-portable workarounds which are prone to break sooner than later. If I want to use an external tool (think setup.py) to build extensions (in-place or not), the same problem occurs. This is rather disappointing to be honest... ax487 [1] https://cmake.org/cmake/help/latest/command/target_link_libraries.html [2] https://cmake.org/pipermail/cmake/2006-August/010747.html [3] https://cmake.org/pipermail/cmake/2008-January/019533.html [4] https://cmake.org/pipermail/cmake/2018-March/067289.html On Mon, 2018-12-24 at 10:46 -0500, Robert Maynard wrote: > That functionality exists in the C++ side of the code base and is run > during the 'generate' stage ( CMakeLists are parsed during > 'configure', than a 'generate' step is run ). > > To get access to how import targets and generator expressions are > resolved you have two options. > 1. You can try to use file(GENERATE but it doesn't support all the > generator expressions currently > 2. You use cmake-server > (https://cmake.org/cmake/help/latest/manual/cmake-server.7.html) to > query a build directory for all this information. > > On Fri, Dec 21, 2018 at 9:12 AM Unknown wrote: > > Hello Kai, > > > > thanks for your suggestion. I tried the property, > > but I just got "foo_linker_flags-NOTFOUND" as a > > result (I am using cmake 3.13.1 btw). The > > same goes for > > > > LINK_OPTIONS, and > > INTERFACE_LINK_OPTIONS. > > > > I tried using the INTERFACE_LINK_LIBRARIES property > > instead. The resulting list contains things I can use, > > such as /usr/lib/libz.so > > > > However, I am using another cmake imported library. > > Therefore, the list contains some libbaz::libbaz > > dependency as well. > > > > In order to get the actual list of libraries, I would > > have to also resolve these names. > > > > But this has to be done somewhere during the > > generation of the Makefiles, so that functionality > > must exist somewhere in cmake. > > > > > > On Fri, 2018-12-21 at 09:33 +0100, Kai Wolf wrote: > > > You can ask a CMake build target for its properties using > > > get_target_property(). > > > For instance, to retrieve the linker flags for a given target > > > foo, > > > you?d write: > > > > > > get_target_prooperty(foo_linker_flags foo LINK_FLAGS) > > > > > > See [1] for a list of valid parameters. > > > > > > Greetings, > > > > > > Kai > > > > > > [1] > > > https://cmake.org/cmake/help/latest/manual/cmake-properties.7.html#properties-on-targets > > > > > > http://kai-wolf.me > > > http://effective-cmake.com > > > > > > > Am 20.12.2018 um 23:14 schrieb Unknown : > > > > > > > > Dear community, > > > > > > > > I have been wondering on multiple occasions about how to get > > > > the > > > > linker flags (i.e. all -llib -Ldir) and include flags (-Idir) > > > > for a library (i.e. a target added to the project using > > > > add_library) within a cmake. > > > > > > > > There are many cases in which the flags are required, > > > > noticeably > > > > generating a suitable pkg-config file or creating a wrappers > > > > around > > > > C/C++ libraries. > > > > > > > > I think that it should be possible to derive the flags from > > > > some of the target properties of the library, but I don't > > > > know exactly how. > > > > > > > > Could you give me a hand? > > > > > > > > ax487 > > > > > > > > -- > > > > > > > > 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: > > > > https://cmake.org/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: > > https://cmake.org/mailman/listinfo/cmake From dblaikie at gmail.com Sat Dec 29 02:19:08 2018 From: dblaikie at gmail.com (David Blaikie) Date: Sat, 29 Dec 2018 18:19:08 +1100 Subject: [CMake] cmake -gsplit-dwarf dwp and install step In-Reply-To: References: Message-ID: Hi there - I'm not a CMake person, but a Clang/LLVM developer who helped in the implementation of Split DWARF in Clang/LLVM, so I know a bit about DWOs and DWPs, etc & thought I'd offer a few extra details... On Fri, Dec 21, 2018 at 3:39 AM David Jobet wrote: > Hello, > > in order to speed up our link step, I wanted to experiment with split > dwarf. > See http://www.productive-cpp.com/improving-cpp-builds-with-split-dwarf/ > > Adding the compilation flag is easy, but I'm stumbling on the installation > step. > In our current mode, we redirect the STRIP step to extract the symbols > and strip the binary. > When you say "symbols" - do you mean only debug info? Or other things (like the ELF symbol table (.symtab section) - since they're no longer needed if no one's calling into the binary (I guess maybe a symbol table that contains the entry point - 'main' would be needed? - this is the part of ELF I don't understand too well)) > With split dwarf, I want to use 'dwp' to collect all .dwo files and > assemble a symbol file. No need to strip I guess since symbols are > already put elsewhere. > Actually there's probably still a desire to strip the executable - Split DWARF leaves some debug info in the .o/executable (& at least the GNU extension form of Split DWARF available in DWARFv4 leaves quiet a bit in the .o/executable, especially in an optimized build, unfortunately) that you can benefit from stripping out - along with the non-debug-related symbol table, if that's a thing you're stripping (see above). > So I figure I would just use dwp as the strip command in my custom > strip command. > > Problem is .dwo files are recorded in the .o files relative to the > build directory and the strip command is executed on the installed > directory. > I think this depends on your build system - and might be resolvable relative to the comp_dir in the debug info remaining in the .o file? Though I haven't looked/checked closely (but yeah, moving debug info around when using Split DWARF is a bit tricky) > As a result, 'dwp' complains it cannot find the .dwo files. > > I don't want to add a POST_BUILD step on each our binaries (we have > lots of binaries), and anyway I'd rather prefer to have the 'dwp' step > executed at install time so it's executed only when we want to > deliver. > > Is there a way to either > - pass the build_dir to the strip command ? > - define a custom step of the install process that would execute on > the build dir previous to the install step itself ? (for the same > reason I don't want to manually define a POST_BUILD step on each > binaries, I don't want to manually define a custom INSTALL step that > would precede the INSTALL step of all our binaries) > - or another option ? > > With regards > > David > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmacq at instantiations.com Sat Dec 29 09:01:30 2018 From: dmacq at instantiations.com (Donald MacQueen [|]) Date: Sat, 29 Dec 2018 09:01:30 -0500 Subject: [CMake] Accessing ${SITE} in CTestConfig.cmake Message-ID: My machine shows up as M6800 under Site in my remote dashboard. I want to use my local dashboard, so I did this in CTestConfigCTestConfig.cmake: IF (${SITE} STREQUAL "M6800") ??? set(CTEST_DROP_SITE "192.168.49.128") # <------------------------- local dashboard ELSE() ??? set(CTEST_DROP_SITE "192.168.10.150") ENDIF() I also tried IF (${CTEST_SITE} STREQUAL "M6800") with no luck. Any ideas? Thanks. -- Donald [|] A bad day in [] is better than a good day in {}. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus From frodak17 at gmail.com Sat Dec 29 16:06:13 2018 From: frodak17 at gmail.com (frodak17) Date: Sat, 29 Dec 2018 16:06:13 -0500 Subject: [CMake] Get linker flags / include directories for a library target In-Reply-To: <8763e456344433bc0833c003ee92801ae47b5f8a.camel@gmx.de> References: <965c52de901d462e84324b3748195ed4a36bf4e4.camel@gmx.de> <4BF6D799-4941-4460-871C-9F18B80E88EB@gmail.com> <8a711a8d20249114189f9ab89359e561c464c4e1.camel@gmx.de> <8763e456344433bc0833c003ee92801ae47b5f8a.camel@gmx.de> Message-ID: On Fri, Dec 28, 2018 at 6:04 PM Unknown wrote: > I would like to thank all of you for your suggestions. I have gathered > the following (correct me if I am wrong): > > - The LINK_FLAGS target property is used in cmake 2.x, the > INTERFACE_LINK_LIBRARIES in cmake 3.x, the latter contains a ;-list > of libraries. > - The list may contain generator expressions, it is however > possible to to use file(GENERATE ..) to obtain evaluate those. > - In any case, the library list contains libraries having different > formats (see [1]), full paths, (imported) targets, and plain names. > - When Makefiles (or files for other build systems) are generated, > the list is turned into -L/-l flags used by ld. This happens > on the C++ side of things, the functionality is not exposed > to cmake scripts. > > As for automatic generation of a pkg-config .pc file, there have > been some inquiries ([2], [3], and [4]), the last one being rather > recent. > > The answers point out that pkg-config files can be generated using > configure_file(...), that cmake has its own (imported target) method > for handling dependencies. > > I don't mean to be disrespectful or unappreciative of the work put > into cmake (in fact I think it is a vast improvement over automake), > but since there is no way to obtain the required information > programatically, all users of my library have to either use > cmake themselves, or use non-portable workarounds which are prone > to break sooner than later. > > If I want to use an external tool (think setup.py) to build > extensions (in-place or not), the same problem occurs. > > This is rather disappointing to be honest... > > ax487 > > > The answer to [2] was that the information required to automatically generate a .pc file was not available. https://linux.die.net/man/1/pkg-config https://people.freedesktop.org/~dbn/pkg-config-guide.html#writing I don't see how CMake could know which packages your library conflicts with or which versions of which libraries are required. For example a library target can link against an imported target but it won't know that only imported target version 1.0.0 is compatible as opposed to versions >= 1.5. It seems that you are trying to provide more than how to link against your library but also against everything your library wants to be linked against. For example the .pc file you want generated contains "Libs: -L${libdirbar} -L${libdirfoo} -lbar -lfoo". But that isn't the proper way of a .pc file should reference separate libraries it should use the Requires field. Also if your library is linking against an imported library `libbaz::libbaz` how is this library being provided to the people using your library? Are you trying to generate a .pc file for the imported library because it didn't provide one and incorporate the flags into library you are creating? I think that no one has volunteered to write a CMake package to create .pc files is because generating a .pc file is pretty simple. It's just a template and a configure_file() command. https://cmake.org/pipermail/cmake/2018-March/067293.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From kyle.edwards at kitware.com Mon Dec 31 10:08:48 2018 From: kyle.edwards at kitware.com (Kyle Edwards) Date: Mon, 31 Dec 2018 10:08:48 -0500 Subject: [CMake] Accessing ${SITE} in CTestConfig.cmake In-Reply-To: References: Message-ID: <1546268928.4676.6.camel@kitware.com> On Sat, 2018-12-29 at 09:01 -0500, Donald MacQueen [|] wrote: > My machine shows up as M6800 under Site in my remote dashboard. > > I want to use my local dashboard, so I did this in? > CTestConfigCTestConfig.cmake: > > IF (${SITE} STREQUAL "M6800") > ???? set(CTEST_DROP_SITE "192.168.49.128") # <----------------------- > --? > local dashboard > ELSE() > ???? set(CTEST_DROP_SITE "192.168.10.150") > ENDIF() > > I also tried IF (${CTEST_SITE} STREQUAL "M6800") with no luck. > > Any ideas? > > Thanks. > > --? > Donald [|] > A bad day in [] is better than a good day in {}. > > > --- > This email has been checked for viruses by Avast antivirus software. > https://www.avast.com/antivirus > Donald, Try this instead: if(CTEST_SITE STREQUAL "M6800") # ... See the documentation for the if() command to understand how to use it: https://cmake.org/cmake/help/latest/command/if.html Kyle From dmacq at instantiations.com Mon Dec 31 13:50:05 2018 From: dmacq at instantiations.com (Donald MacQueen [|]) Date: Mon, 31 Dec 2018 13:50:05 -0500 Subject: [CMake] Accessing ${SITE} in CTestConfig.cmake In-Reply-To: <1546268928.4676.6.camel@kitware.com> References: <1546268928.4676.6.camel@kitware.com> Message-ID: <7fd5e898-5059-d027-426c-2b33993e5a76@instantiations.com> Thanks very much Kyle. I guess I am not real clear about when vars should be used as var versus ${var}. On 12/31/2018 10:08 AM, Kyle Edwards wrote: > On Sat, 2018-12-29 at 09:01 -0500, Donald MacQueen [|] wrote: >> My machine shows up as M6800 under Site in my remote dashboard. >> >> I want to use my local dashboard, so I did this in >> CTestConfigCTestConfig.cmake: >> >> IF (${SITE} STREQUAL "M6800") >> ???? set(CTEST_DROP_SITE "192.168.49.128") # <----------------------- >> -- >> local dashboard >> ELSE() >> ???? set(CTEST_DROP_SITE "192.168.10.150") >> ENDIF() >> >> I also tried IF (${CTEST_SITE} STREQUAL "M6800") with no luck. >> >> Any ideas? >> >> Thanks. >> >> -- >> Donald [|] >> A bad day in [] is better than a good day in {}. >> >> >> --- >> This email has been checked for viruses by Avast antivirus software. >> https://www.avast.com/antivirus >> > Donald, > > Try this instead: > > if(CTEST_SITE STREQUAL "M6800") > # ... > > See the documentation for the if() command to understand how to use it: > > https://cmake.org/cmake/help/latest/command/if.html > > Kyle -- Donald [|] A bad day in [] is better than a good day in {}. From kyle.edwards at kitware.com Mon Dec 31 14:00:21 2018 From: kyle.edwards at kitware.com (Kyle Edwards) Date: Mon, 31 Dec 2018 14:00:21 -0500 Subject: [CMake] Accessing ${SITE} in CTestConfig.cmake In-Reply-To: <7fd5e898-5059-d027-426c-2b33993e5a76@instantiations.com> References: <1546268928.4676.6.camel@kitware.com> <7fd5e898-5059-d027-426c-2b33993e5a76@instantiations.com> Message-ID: <1546282821.4676.17.camel@kitware.com> On Mon, 2018-12-31 at 13:50 -0500, Donald MacQueen [|] wrote: > Thanks very much Kyle. I guess I am not real clear about when vars > should be used as var versus ${var}. Generally speaking, you use var when setting a variable, and ${var} when reading its value. It's a lot like how shell variables are used in bash: foo=bar echo $foo if() and while() break this convention because they were written very early in CMake's history, before there was a concept of variable expansion. However, because of CMP0054, you can put ${var} in quotes: if("${foo}" STREQUAL "bar") and it will have the same effect as: if(foo STREQUAL "bar") See https://cmake.org/cmake/help/latest/policy/CMP0054.html for details. Kyle From dmacq at instantiations.com Mon Dec 31 16:16:41 2018 From: dmacq at instantiations.com (Donald MacQueen [|]) Date: Mon, 31 Dec 2018 16:16:41 -0500 Subject: [CMake] Help with non-standard use of CMake Message-ID: <54faf2d1-f81b-c220-1eed-8c33cfe6f259@instantiations.com> First, CMake is quite impressive. Nice job. I am using it in a non-standard way where I set a bunch of variables and then go straight to CTest thatI installs our software and then runs several hundred tests on it. The batch file looks like this: rmdir /s/q build mkdir build cd build cmake -Dx64=%x64% -Doption:STRING="%opt%" .. ctest -D Experimental -S I do not make or build or compile. I recently hooked this up to a CDash server which is very handy. I want to get the results that are sent to CDash, currently from Windows only, to be all green. Under Build I have one error: Build log line 2. The system cannot find the file specified. CMake Error: Generator: execution of make failed. Make command was: "nmake" "/nologo" "-i" Under Build I have one warning: Build log line 1. *** WARNING non-zero return value in ctest from: C:\Program Files\CMake\bin\cmake.exe Is there a way to suppress the execution of these steps or their error messages? Thanks, Donald -- Donald [|] A bad day in [] is better than a good day in {}. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus From kyle.edwards at kitware.com Mon Dec 31 16:38:21 2018 From: kyle.edwards at kitware.com (Kyle Edwards) Date: Mon, 31 Dec 2018 16:38:21 -0500 Subject: [CMake] Help with non-standard use of CMake In-Reply-To: <54faf2d1-f81b-c220-1eed-8c33cfe6f259@instantiations.com> References: <54faf2d1-f81b-c220-1eed-8c33cfe6f259@instantiations.com> Message-ID: <1546292301.4676.26.camel@kitware.com> On Mon, 2018-12-31 at 16:16 -0500, Donald MacQueen [|] via CMake wrote: > First, CMake is quite impressive. Nice job. > > I am using it in a non-standard way where I set a bunch of variables > and? > then go straight to CTest thatI installs our software and then runs? > several hundred tests on it. The batch file looks like this: > > rmdir /s/q build > mkdir build > cd build > cmake -Dx64=%x64% -Doption:STRING="%opt%" .. > ctest -D Experimental -S > > I do not make or build or compile. > > I recently hooked this up to a CDash server which is very handy. I > want? > to get the results that are sent to CDash, currently from Windows > only,? > to be all green. > > Under Build I have one error: Build log line 2. The system cannot > find? > the file specified. CMake Error: Generator: execution of make > failed.? > Make command was: "nmake" "/nologo" "-i" You could try one of several things: 1) Running with a different generator, such as one of the Visual Studio ? ?generators or the Ninja generator, or 2) Installing NMake. However, I am a little curious about what you're doing in your use case. You say you're not building anything. Does your sofware exist in the form of scripts (Python, Perl, etc.), or are you downloading pre- built binaries from somewhere? > Under Build I have one warning: Build log line 1. *** WARNING non- > zero? > return value in ctest from: C:\Program Files\CMake\bin\cmake.exe > > Is there a way to suppress the execution of these steps or their > error? > messages? Without knowing more details about what you're doing, it's possible that dashboard scripts might be more suited for your use case... though I see you have a -S argument at the end of your ctest invocation but no script after it... what's the purpose of this? See?https://cmake.org/cmake/help/v3.13/manual/ctest.1.html#dashboard-cl ient-via-ctest-script?for details on dashboard scripts. Kyle From Alan.W.Irwin1234 at gmail.com Mon Dec 31 18:29:06 2018 From: Alan.W.Irwin1234 at gmail.com (Alan W. Irwin) Date: Mon, 31 Dec 2018 15:29:06 -0800 (PST) Subject: [CMake] Help with non-standard use of CMake In-Reply-To: <1546292301.4676.26.camel@kitware.com> References: <54faf2d1-f81b-c220-1eed-8c33cfe6f259@instantiations.com> <1546292301.4676.26.camel@kitware.com> Message-ID: On 2018-12-31 16:38-0500 Kyle Edwards via CMake wrote: > On Mon, 2018-12-31 at 16:16 -0500, Donald MacQueen [|] via CMake wrote: >> First, CMake is quite impressive. Nice job. >> >> I am using it in a non-standard way where I set a bunch of variables >> and? >> then go straight to CTest thatI installs our software and then runs? >> several hundred tests on it. The batch file looks like this: >> >> rmdir /s/q build >> mkdir build >> cd build >> cmake -Dx64=%x64% -Doption:STRING="%opt%" .. >> ctest -D Experimental -S >> >> I do not make or build or compile. >> >> I recently hooked this up to a CDash server which is very handy. I >> want? >> to get the results that are sent to CDash, currently from Windows >> only,? >> to be all green. >> >> Under Build I have one error: Build log line 2. The system cannot >> find? >> the file specified. CMake Error: Generator: execution of make >> failed.? >> Make command was: "nmake" "/nologo" "-i" > > You could try one of several things: > > 1) Running with a different generator, such as one of the Visual Studio > ? ?generators or the Ninja generator, or > 2) Installing NMake. > > However, I am a little curious about what you're doing in your use > case. You say you're not building anything. Does your sofware exist in > the form of scripts (Python, Perl, etc.), or are you downloading pre- > built binaries from somewhere? I am curious as well about that issue. It is possible the error he is getting is because one or more of his tests are not working because he doesn't use a build step to build something in his project that is needed by those tests. So to ask the question directly to the OP, do you have any CMake logic anywhere in this project that builds software, e.g., the add_library or add_executable commands? If so, you do have to build all such software first (by building the "all" target) before you run ctest if any of your ctest tests depend on those built libraries or executables. Alan __________________________ Alan W. Irwin 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 dmacq at instantiations.com Mon Dec 31 21:47:22 2018 From: dmacq at instantiations.com (Donald MacQueen [|]) Date: Mon, 31 Dec 2018 21:47:22 -0500 Subject: [CMake] Help with non-standard use of CMake In-Reply-To: <1546292301.4676.26.camel@kitware.com> References: <54faf2d1-f81b-c220-1eed-8c33cfe6f259@instantiations.com> <1546292301.4676.26.camel@kitware.com> Message-ID: On 12/31/2018 4:38 PM, Kyle Edwards wrote: > On Mon, 2018-12-31 at 16:16 -0500, Donald MacQueen [|] via CMake wrote: >> First, CMake is quite impressive. Nice job. >> >> I am using it in a non-standard way where I set a bunch of variables >> and >> then go straight to CTest thatI installs our software and then runs >> several hundred tests on it. The batch file looks like this: >> >> rmdir /s/q build >> mkdir build >> cd build >> cmake -Dx64=%x64% -Doption:STRING="%opt%" .. >> ctest -D Experimental -S >> >> I do not make or build or compile. >> >> I recently hooked this up to a CDash server which is very handy. I >> want >> to get the results that are sent to CDash, currently from Windows >> only, >> to be all green. >> >> However, I am a little curious about what you're doing in your use >> case. You say you're not building anything. Does your sofware exist in >> the form of scripts (Python, Perl, etc.), or are you downloading pre- >> built binaries from somewhere? The purpose here is to 1) test that the installation of our product is successful (all the files are there with the correct permissions, etc.) and 2) that the 13k+ tests we have run correctly after installation.? The installer is created using Install Shield. My CMakelists.txt looks something like this: ++++++++++++++++++++++++++++++++++++++++++++++++++ cmake_minimum_required(VERSION 2.8.8) if(CMAKE_VERSION VERSION_GREATER "3.1") ? cmake_policy(SET CMP0054 NEW) endif() if (${CMAKE_SYSTEM_PROCESSOR} MATCHES "64") ??? set (vasttst_isX86_OS FALSE) ??? set (vasttst_OsBitness 64) endif() ??? set (vasttst_isX86_OS TRUE) ??? set (vasttst_OsBitness 86) endif () 200 more lines.. ENABLE_TESTING() include(CTest) add_subdirectory(test) ++++++++++++++++++++++++++++++++++++++++++++++++++ > Without knowing more details about what you're doing, it's possible > that dashboard scripts might be more suited for your use case... though > I see you have a -S argument at the end of your ctest invocation but no > script after it... what's the purpose of this? The -S is probably left over from when I was trying to set the build name from a script.? I did a lot of looking around and did not see a dashboard script that did CTest only. If I understand what you are saying, I could put all the set variable stuff above in a file called cdash.txt and then simply run rmdir /s/q build mkdir build cd build ctest -D Experimental -S cdash.txt That way I avoid make/build/compile and go straight to CTest. Right? -- Donald [|] A bad day in [] is better than a good day in {}. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus