Re: [CMake] List all packages
Thanks for the answers You can visualize dependencies between targets with Graphvis: This is not really what I need, I want to see all the available packages installed on my PC (package registry, Find_XXX modules …), not the hierarchy of targets in a cmakelists.txt Hey, As far as I know there is no such mechanism. But you can write a little script f.e. in python (or cmake itself) which can do that, because it is just a simple file search. Greetings Tonka Aw that’s sad, I’d like to avoid writing my own script because there are a lot of things to take into account based on the platform. It would be better if I could invoke cmake from the commandline to do this. Should such feature-request be sent to the mailing list or gitlab ? De : Konstantin Podsvirov Envoyé le :dimanche 13 janvier 2019 11:23 À : Cmake Mailing List Objet :Re: [CMake] List all packages Hello, Lectem. 11:43, 13 January 2019 г., Lectem : Hi, Is there a way to list all the packages (both config files and find-modules) that find_package could find ? Could we even imagine this would also permit to list the variables and targets created in it ? I think that would be a very helpful to have for debugging find_package, especially when you don’t have access to the system having issues (user bug reports for example). Cheers, Lectem You can visualize dependencies between targets with Graphvis: https://gitlab.kitware.com/cmake/community/wikis/doc/cmake/Graphviz -- With regards, Konstantin Podsvirov -- 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
[CMake] List all packages
Hi, Is there a way to list all the packages (both config files and find-modules) that find_package could find ? Could we even imagine this would also permit to list the variables and targets created in it ? I think that would be a very helpful to have for debugging find_package, especially when you don’t have access to the system having issues (user bug reports for example). Cheers, Lectem -- 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
Re: [CMake] pkg-config file format versus CMake packages
Hi, I’ll start by saying that I love the fact we’re now talking about a common representation of packages ! ➢ The reason I say this is that extending pkg-config seems like it would help adoption rather then creating a completely new format. There is already a good portion of open source projects that already support pkg-config, so tweaking them to support more complicated scenarios seems easier than converting everything to a new format. I’m not very familiar with pkg-config (working more in the Windows world) so excuse me if I’m wrong. >From what I remember it is very basic and relies on compiler flags being the >same everywhere (ie gcc-like flags), and does not provide any information >about things such as ABI, C-runtime Library used (arguably could be >represented as a package ?). As far as I know, it assumes that the libraries >are always compiled with the same compiler on the same system, hence has no >knowledge of compatibility between compiler versions. As you mentionned, it currently relies on -l for both libraries and linker flags, which would need to be changed. ➢ so tweaking them to support more complicated scenarios seems easier than converting everything to a new format. Wouldn’t that create more confusion ? I fear it’d end up as a python2 python3 issue, where both versions look alike but are incompatible. Have a nice Week-end, Lectem -- 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
Re: [CMake] target_compile_features question
Because you are looking at an old CMake version 😉 I think it was introduced in cmake 3.8.2 ? De : Florian Lindner Envoyé le :dimanche 5 novembre 2017 17:03 À : cmake@cmake.org Objet :Re: [CMake] target_compile_features question Am 05.11.2017 um 15:07 schrieb Jan Christoph Uhde: > Hi, > > I have a project using CMake 3.9. > The project contains a header only library mylib. > The library hast set the following property: > > target_compile_features(mylib INTERFACE cxx_std_17) > > Now I try to add otherlib to mylib (INTERFACE as well). otherlib has set > some c++11 compile_features. > > When I try to compile tests for my lib I see gnu++11 as requested > standard. Without otherlib gnu++17 is selected. Hey, just being curious, is cxx_std_17 a valid feature? I don't see it listed in https://cmake.org/cmake/help/v3.1/prop_gbl/CMAKE_CXX_KNOWN_FEATURES.html Best, Florian -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] cmake-gui on windows and qt5 dlls
Right, as mentionned by Craig Scott, a script might do the trick ? Just a cmake-gui.bat that calls cmake-gui.exe should work. De : Robert Maynard Envoyé le :lundi 14 août 2017 15:24 À : Craig Scott Cc : Clément Gregoire; CMake Objet :Re: [CMake] cmake-gui on windows and qt5 dlls More importantly symlinks are restricted to administrator accounts only in Windows Vista/7/8. Windows 10 with Developer Mode activated allows none-elevated accounts to create symlinks. This is important as CMake does ship non-installer windows binaries. On Mon, Aug 14, 2017 at 9:00 AM, Craig Scott wrote: > > > On Mon, Aug 14, 2017 at 9:05 PM, Clément Gregoire wrote: >> >> Wouldn't it be possible to move it to a subfolder with the DLLs and put a >> link next to cmake and ccmake? Executables look for DLLs in their directory >> and it wouldn't pollute the PATH > > > Symlinks are available on NTFS filesystems from Vista onwards. If the user > installed CMake on, say, a FAT filesystem instead or on an old XP box (CMake > appears to still try to support that), then symlinks wouldn't be available > from what I can make out. One could potentially use a forwarding script of > some kind though to achieve essentially the same thing. > > >> I personally like to be able to launch it through the command line, it is >> faster than looking for it and then browse for the folder. >> >> >> Le lun. 14 août 2017 à 11:48, Craig Scott a >> écrit : >>> >>> This is a common problem, not just with CMake. I'm wondering if there's >>> any real need for cmake-gui to be on the PATH at all, since it will usually >>> be invoked by a desktop or menu icon. At the moment though, it is in the >>> same directory as the cmake and ccmake executables which have a much >>> stronger case for being on the PATH. There's a reasonable argument that >>> cmake-gui should be in a different directory, then it wouldn't be an issue >>> if shared Qt libs were used rather than static. I'll bring this up on the >>> developer mailing list and see what discussions yield. >>> >>> >>> On Mon, Aug 14, 2017 at 6:22 PM, Christian Ehrlicher >>> wrote: Hi, I recently upgraded from cmake 3.3 to 3.9 on windows and got some problems during my build because it looks like the pre-compile binaries for windows are now shipping Qt5 - dlls instead static compile libs (since 3.5 afaics). The problem is, that I had the path to cmake *before* the path to my own Qt5 libaries. So during the build / run of my application, the wrong libraries were loaded and I got a symbol lookup error. Would it be possible to use the static Qt5 libs instead or maybe prefix the Qt5 libs shipped with cmake-gui somehow? Thx, Christian -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake >>> >>> >>> >>> >>> -- >>> Craig Scott >>> Melbourne, Australia >>> https://crascit.com >>> -- >>> >>> Powered by www.kitware.com >>> >>> Please keep messages on-topic and check the CMake FAQ at: >>> http://www.cmake.org/Wiki/CMake_FAQ >>> >>> Kitware offers various services to support the CMake community. For more >>> information on each offering, please visit: >>> >>> CMake Support: http://cmake.org/cmake/help/support.html >>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>> >>> Visit other Kitware open-source projects at >>> http://www.kitware.com/opensource/opensource.html >>> >>> Follow this link to subscribe/unsubscribe: >>> http://public.kitware.com/mailman/listinfo/cmake > > > > > -- > Craig Scott > Melbourne, Australia > https://crascit.com > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake -- Powered by www.kitware.com Please keep
Re: [CMake] Coverage support
OK so I ended up doing the following : Use a cmake script to detect coverage support and set up a new build type + Let CTest run GCov for me Final result can be seen here : https://github.com/Lectem/cpp-boilerplate link to the Coverage setup script : https://github.com/Lectem/cpp-boilerplate/blob/master/cmake/Coverage.cmake This seems to be the best way to do it, it is non-intrusive (no CMAKE__FLAGS clobbering), plus it really does check that it is supported by the compiler, not assuming versions or anything. If the user wants to build with coverage support, he only needs to use the Coverage build type, and can change the flags from the cache if needed, just as he would do with any build type. Also not that since the codecov.io script runs GCov by default, using CTest is facultative. (but you need to make sure the gcov version matches the compiler used). De : Konstantin Tokarev Envoyé le :lundi 7 août 2017 19:52 À : Clément Gregoire; Rolf Eike Beer Cc : Cmake Mailing List Objet :Re: [CMake] Coverage support 07.08.2017, 20:50, "Clément Gregoire" : This is mainly why I started this thread, I want to know the best way to do this without using those variables. CMAKE_lang_FLAGS is a pain as soon as someone wants to use add_subdirectory (be it to add an external project or your project being used in another) or a user wants to change the value. Those variables should really only be set by the toolchain file or from the command-line. There's ExternalProject for this purpose Other solutions were mentioned in my first mail, the easiest one being to add a new build type. The other option is to uses something like a special script that will set those variables before your Cmakelists.txt (ie a toolchain file). Le lun. 7 août 2017 à 17:22, Konstantin Tokarev a écrit : 07.08.2017, 17:24, "Clément Gregoire" : >> I usually stop reading Cmakelists.txt as soon as I see this >> >> set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -pedantic -pthread -g -O0 >> -fprofile-arcs -ftest-coverage") >> >> The pthread thing there is likely wrong anyway, and the -Wall is entirely >> optional. The other things are needed, otherwise gcov will not produce any >> useful output. > > I don't have an issue with the flags per se, but with the usage of > set(CMAKE_CXX_FLAGS). Setting flags like that should be banned from modern > cmake scripts. How can one set global compiler flags without use of CMAKE_CXX_FLAGS or setting flags for each individual target? > >> Also you need to use the SETUP_TARGET_FOR_COVERAGE for every single test >> target, which seems to be a difficult to scale on big projects >> >> No, you don't. It's entirely fine if you just run "make test" as I do in >> OSM2go. > From what I saw in the documentation of the script : > >> # Param _testrunner The name of the target which runs the tests > > It seems to call directly the command named _testrunner, which is somehow > confirmed from the cmakelists : > >> # src/CMakelists.txt >> add_executable(tests ${TEST_FILES}) >> >> # Linking up all libraries >> >> target_link_libraries(tests complex) >> >> add_test(NAME example_test COMMAND tests) >> # CMakelists.txt >> setup_target_for_coverage(${PROJECT_NAME}_coverage tests coverage) > From this I deduce that you need to call setup_target_for_coverage for each > different test executable. > > 2017-08-07 13:37 GMT+02:00 Rolf Eike Beer : >> Am 2017-08-07 11:06, schrieb Clément Gregoire: >> I usually stop reading Cmakelists.txt as soon as I see this >> >> set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -pedantic -pthread -g -O0 >> -fprofile-arcs -ftest-coverage") >> >> The pthread thing there is likely wrong anyway, and the -Wall is entirely >> optional. The other things are needed, otherwise gcov will not produce any >> useful output. >> >> Also you need to use the SETUP_TARGET_FOR_COVERAGE for every single test >> target, which seems to be a difficult to scale on big projects >> >> No, you don't. It's entirely fine if you just run "make test" as I do in >> OSM2go. >> >> Eike >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >&g
Re: [CMake] CMake equivalent to Boost.Build site-config.jam oruser-config.jam
I think that you are looking for the toolchain files : https://cmake.org/cmake/help/v3.0/manual/cmake-toolchains.7.html The other option is to use a cmake script to specify your variables which includes CMakelists.txt (or the other way around if you can modify the CMakelists.txt). This would be quite similar to ctests scripts. Some good examples are in Daniel Pfeifer’s « Effective cmake » talk https://github.com/boostcon/cppnow_presentations_2017/blob/master/05-19-2017_friday/effective_cmake__daniel_pfeifer__cppnow_05-19-2017.pdf De : Brian Davis Envoyé le :mardi 8 août 2017 20:09 À : cmake Mailing List Objet :[CMake] CMake equivalent to Boost.Build site-config.jam oruser-config.jam Is there a CMake equivalent to a site-config.jam or user-config.jam http://www.boost.org/build/doc/html/bbv2/recipies/site-config.html basically a CMake file the user can put in a project directory that CMake will read first when using cmake-gui that allows user to specify stuff they don't want to have to keep specifying in cmake-gui each "delete cache" such as set( CMAKE_INSTALL_PREFIX ${CURRENT_LIST_DIR}/install CACHE STRING "" FORCE) set( CMAKE_DEBUG_POSTFIX d CACHE STRING "" FORCE ) There is cmake.exe -C but requires command line come to think of it would be nice if set( CMAKE_GENERATOR_PLATFORM "Visual Studio 12 2013 Win64" ) in desired user config file and CMake would just "make it so" on clicking Generate. I can do this with my own projects, by implementing it myself, but when checking out 3rd party projs they can be all over the map on config allowing a user-config.cmake would provide mechanism to tame the config problems. Desired workflow 1) Checkout 3rd party proj 2) put a CMakeUser.txt or whatever file per project 3) Run CMake GUI Generate 4) Click Open Project 5) Change whatever manual bits in in gui 6) Update project suing git witch branches versions 7) Delete Cache 8) Return to 3 9) Doopy doopy doo whatever else -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
[CMake] INTERPROCEDURAL_OPTIMIZATION still not using CMAKE__COMPILER_AR
Hello guys, So I downloaded the 3.9 release and thought my LTO nightmares were over but… cmake still isn’t using CMAKE__COMPILER_AR when linking on MSYS. I’m using the « MSYS Makefiles » generator, and when building an executable it still uses the plain ar instead of gcc-ar… CMAKE_CXX_COMPILER_AR is correctly set to C:/msys64/mingw64/bin/gcc-ar.exe but won’t use it… I also tried to set CMAKE_AR to C:/msys64/mingw64/bin/gcc-ar.exe from cmake-gui but it’s not taken into account Here’s the output : [100%] Linking CXX executable BoilerPlate.exe "/C/Program Files/CMake/bin/cmake.exe" -E remove -f CMakeFiles/BoilerPlate.dir/objects.a /C/msys64/mingw64/bin/ar.exe cr CMakeFiles/BoilerPlate.dir/objects.a @CMakeFiles/BoilerPlate.dir/objects1.rsp C:\msys64\mingw64\bin\ar.exe: CMakeFiles/BoilerPlate.dir/source/main.cpp.obj: plugin needed to handle lto object /C/msys64/mingw64/bin/g++.exe -flto -fno-fat-lto-objects -Wl,--whole-archive CMakeFiles/BoilerPlate.dir/objects.a -Wl,--no-whole-archive -o BoilerPlate.exe -Wl,--out-implib,libBoilerPlate.dll.a -Wl,--major-image-version,0,--minor-image-version,0 @CMakeFiles/BoilerPlate.dir/linklibs.rsp I’m not sure if it is a Windows/MSYS related problem (I think it is), but I really don’t understand why CMAKE wants to use C:/msys64/mingw64/bin/ar.exe so much and not the one in CMAKE_AR / CMAKE_CXX_COMPILER_AR… If you guys have any idea. Thanks, Lectem -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] DLL handling under CMake
I managed to get it working by using an intermediate script. One might want to generate the script instead of using the « RUN_IT » variable trick. This was only tested on Windows, but seems to work fine. Put the following code in a xx.cmake file, include it from your CMakeLists.txt and enjoy. # This is a helper script to run BundleUtilities fixup_bundle as postbuild # for a target. The primary use case is to copy .DLLs to the build directory for # the Windows platform. It allows generator expressions to be used to determine # the binary location # # Usage : run_fixup(TARGET LIBS DIRS) # - TARGET : A cmake target # - See fixup_bundle for LIBS and DIRS arguments if(RUN_IT) # Script ran by the add_custom_command include(BundleUtilities) fixup_bundle("${TO_FIXUP_FILE}" "${TO_FIXUP_LIBS}" "${TO_FIXUP_DIRS}") # End of script ran by the add_custom_command else() set(THIS_FILE ${CMAKE_CURRENT_LIST_FILE}) message(${THIS_FILE}) function(run_fixup _target _libs _dirs) message(${THIS_FILE}) add_custom_command( TARGET ${_target} POST_BUILD COMMAND ${CMAKE_COMMAND} -DRUN_IT:BOOL=ON -DTO_FIXUP_FILE=$ -DTO_FIXUP_LIBS=${_libs} -DTO_FIXUP_DIRS=${_dirs} -P ${THIS_FILE} COMMENT "Fixing up dependencies for ${_target}" VERBATIM ) endfunction() endif() De : Clément Gregoire Envoyé le :jeudi 4 mai 2017 08:37 À : Hendrik Sattler; Louis-Paul CORDIER; Cmake Mailing List Objet :Re: [CMake] DLL handling under CMake I'd also be interested in this. I saw an old mail in the ML about this, but it seems fixup_bundle is old and cant use generator expressions, making it hard to use (I don't want to hardcode the executable path). Do you have a sample for this ? CMake would really benefit from having those features made more accessible instead of everyone having to write its own script Le sam. 29 avr. 2017 22:10, Hendrik Sattler a écrit : Am 27. April 2017 10:43:50 MESZ schrieb Louis-Paul CORDIER : >This steps are tedious and I'm wondering if there is a mechanism that >exists or that have to be imagined to make the DLL nightmare end. I use BundleUtilities to achieve the copying of DLL files to the installation directory. The main problem for this is to enumerate the needed directories. I use the same for copying DLL files to the output directory to ease debugging. The advantage is the inspection of the exe for really needed DLL files. This AUTOMATICALLY handles the case debug vs. release. HS -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake