[CMake] Passing CMake Arguments to FetchContent
I'm upgrading from cmake 3.5.1 and am trying to understand the new FetchContent command. So far I have: cmake_minimum_required(VERSION 3.14) project (json_test) include(FetchContent) set(JSON_BuildTests OFF) #if I try this I get a warning as it appears to be deprecated FetchContent_Declare( nlohmann_json_fc GIT_REPOSITORY https://github.com/nlohmann/json.git GIT_TAG v3.6.1 GIT_SHALLOW TRUE #CMAKE_ARGS -DJSON_BuildTests=OFF #doesn't work ) FetchContent_MakeAvailable(nlohmann_json_fc) add_executable(main src/main.cpp) target_link_libraries(main nlohmann_json::nlohmann_json) I first tried sending in the JSON_BuildTests=OFF with CMAKE_ARGS in the FetchContent_Declare command but that didn't work. On this post https://cmake.org/pipermail/cmake/2018-July/067804.html it appears this is because only the download portion of FetchContent_Declare is enabled with the intent to not do too much during configure time. How does specifying how the external project is configured fit that rationale? If I execute cmake -DJSON_BuildTests=OFF .. the argument successfully makes it through to the external project. I guess I'm trying to understand why it's ok to specify it on the command line but not permanently in the CMakeLists.txt, particularly if you have many libraries each potentially with their options that need to be configured. Thanks, Jason -- 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] FetchContent or Export Targets
Hi, As I've been learning CMake, it seems the best practice for a library is for it to export the targets it creates. There is also the relatively new command FetchContent. It seems that at least in part the FetchContent command obviates the need for exporting targets. I can see that for larger more permanent libraries exporting targets is still preferred so the library can be installed once and used by multiple projects on a developers workstation without having to install it on each project. At work we're a bunch of research engineers that happen to write a lot of software-- exporting targets still seems cumbersome and it seems not exporting targets and then just have users use FetchContent to pull in a library is not a bad idea. Are there other reasons /advantages of exporting targets? Thanks, Jason -- 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] add_subdirectory namespaces
I've been reorganizing / updating our software cmake build. It currently uses a mixture of Externa Projects and normal target definitions that depend on the external projects (which has you probably know causes much sorrow and grief). One of my goals in the reorganization was to replace all the ExternalProjectAdd statements with FetchContent, however I soon discovered that some of the external projects declare targets with the same name (i.e. an uninstall target). These external projects are third party libraries that are not under our control. It appears there's been a suggestion to add namespaces to the add_subdirectory command: https://gitlab.kitware.com/cmake/cmake/issues/16414 Is that going anywhere? It seems like that would address FetchContent's main limitation. I guess for the time being I'll use ExternalProject for thirdparty libraries not under our control and FetchContent for libraries that are and do a true super build instead of the muddled sort of arrangement we have now. One other kind of not-so-random question-the documentation on the Project statement is fine if it's in the toplevel CMakeLists.txt (in which case it defines some project level variables, etc.) but it's silent about what happens if it's not in the top level CMakeLists.txt. i.e. if I add a library via add_subdirectory or FetchContent and that library's toplevel CMakeLists.txt has the project statement, what happens when it's executed? Is it silently ignored? Thanks, Jason -- 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] Don't list Up-to-date files during install
When installing files, cmakes prints a list of all files that are to be installed, even if some of those files are already installed and up-to-date (i.e. installed from a previous build). If the file is not installed or out-of date, cmake prints "Installing: ..." and if a file was already installed and didn't change it prints "Up-to-date: ..." Is there a way to suppress listing all of the up-to-date files and only show the files that are being installed because they changed? Some of the libraries we use install a ton of files and if we change only one it's difficult to find and verify that one was installed among the sea of up-to-date files. Thanks, Jason -- 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
