cmake-init VS cmake-init-fetchcontent

https://github.com/friendlyanon/cmake-init This is how you do CMake properly. If you deviate from its install rules you are highly likely to do something wrong.

CMake itself is as declarative as a build systems need to be. For anything nontrivial, these "declarative" solutions all fall apart. Just use https://github.com/friendlyanon/cmake-init, learn CMake and you won't have any issues.

If you want something with a (mostly) Just Works experience then just use https://github.com/friendlyanon/cmake-init

For CMake basics check out the official "Getting started" tutorial: https://cmake.org/cmake/help/latest/guide/tutorial/index.html, as well as Introduction to Modern CMake. You can also get inspired by the CMake project generator cmake-init

You can just use https://github.com/friendlyanon/cmake-init to get a CMake + Conan C project ready to go with a short little command: cmake-init --c -e -p conan coolio

You can see that in action here: https://github.com/friendlyanon/cmake-init-fetchcontent This example has the idiomatic find_package(headeronly REQUIRED) call in the CMakeLists.txt, but when configuring ${sourceDir}/cmake/find is added to CMAKE_MODULE_PATH, so the FetchContent code is run to "find" the dependency. There are comments to further explain this.

Please consider using https://github.com/friendlyanon/cmake-init before this has any significant amount of users. There is an example that shows you how to still rely on FetchContent as an opt-in.

Are they only on git(hub)? You can write a vcpkg overlay port (example) or use FetchContent if the projects are FetchContent ready in a way that doesn't force FetchContent on people trying to build the project (example).

This came up somewhere else, but I created an example repo that idiomatically uses find_package and an opt-in find module to FetchContent a dependency from GitHub: https://github.com/friendlyanon/cmake-init-fetchcontent