Today, to build many internal Git projects, my company uses a dedicated Git project to build other projects through batch scripts, then CMakeLists.txt and other CMake script, to finally use ExternalProject to retrieve the project to build or its dependencies. There are several scripts to retrieve dependencies. So these scripts are mutualized in this building project.
The problem is that so, our projects are not autonomous. This is especially true for our libraries : we have to include them in any project to be able to test them or submit them to Sonar.
So is this system a good practice ?
Should the project be buildable from its own CMakeLists.txt ?
If so, how to factorize some code (CMake scripts) ?
Very interesting thread. It is reassuring to see that @dabrahams wonders about same subjects as me.
It seems that for Kitware, retrieving dependencies with CMake implies building them, and that for retrieving
build dependencies, CMake wouldn’t be the right tool,because they seem to suggest Conan or vcpkg.
Generally you want to make a “superbuild” (basically a focused package manager) to build everything as ExternalProjects (including your own). The projects themselves then just use find_package() to find each other and the superbuild “stitches” things together (like a package manager).
Well, that’s what our current building systems do… But so all these scripts may have to compile all the dependencies.
If a superbuild is not suitable, it might be that you can document a list of Conan or vcpkg packages that are needed and use those environments to provide dependencies.
Should I conclude that retrieving binaries go clearly against the CMake/Kiware philosophy ?
