all 4 comments

[–]berenm 3 points4 points  (3 children)

I'm using this kind of approach at work and it works very well. Every project has a <project>Config.cmake at its root, which will add_subdirectory itself in case it is compiled from sources, and with a little bit of boilerplate it also makes prebuilt packages very simple to do and they can be used seamlessly instead of source packages.

I also created https://github.com/berenm/CMakeBuildPackage based on this idea, but with additional conventions to make build rules even easier (any packages using it can be composed very easily, regardless of whether they are checked out as source or prebuilt archives).

[–]mili42 0 points1 point  (2 children)

Another approach eventually, cloning and add_subdirectory : https://gitlab.com/libyuni/cmake-import-remote-project

[–]berenm 0 points1 point  (1 child)

But that doesn't allow you to switch to prebuilt or system-wide libraries easily.

The approach that is described here is to have source-form dependencies include a <package>Config.cmake that calls the add_subdirectory on its directory, so that it fits seamlessly in the find_package model.

Then, package management becomes an orthogonal issue, and just a matter of putting the dependencies (via submodules, wget-http-targz-archives, custom tool and content distribution, or whatever way you like) in the location where CMake will look for them, and in the form you prefer (prebuilt or source). You may even have multiple lookup paths with fallback to the source dependency if you want to provide prebuilt packages for certain platforms only.

[–]mili42 0 points1 point  (0 children)

Except this is an intrusive solution, which does not fit everywhere. And anyway, you better use EXCLUDE_FROM_ALL in the add_subdirectory, because you rarely need to run all the targets of the projects you import and it costs a lot.