cmake-init-multi-target VS cmake-init

But also a lot of problems come from people not understanding that regardless of CMake and C++, how shared and static libraries work and why they work the way they work. For example, if your CMake project has multiple targets, one being the main export and another being just a "utilities" target of sorts, then you must do some extra work to make the main export target be installed properly when it is built as a static library. This has nothing to do with CMake or C++, but that fact that static libraries are "just" archives of object files that the linker will later roll into a "real" binary (shared library or executable). When you are creating a project you must account for propagating the "utility" target as well, because otherwise the consuming project will not get the code for the "utility" target that was linked to your main export PRIVATEly. I created an example repository on how to deal with this, because a Conan package maintainer was curious about why CMake was inserting $ genex into the installed export set.

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