Static and shared libraries are typically produced from the same set of sources, too, so new CMake users sometimes expect that a single call to add_library will provide whatever mix of types they want.
On the build side, this means that a single library target corresponds to a single physical library on the system.
When you import SomeLib::SomeLib from a package, the library type is already determined by the time you link another target to it. So why is it tricky to provide both a static and shared version of a library in CMake? The core issue is that a CMake library target models the build and usage requirements for a single library configuration.
CMAKE LINUX SHARED LIBRARY FULL
TLDR: See this GitHub repo with the full code, complete with GitHub Actions testing. The main thing it's missing is handling dependencies. This also serves as a basic project template for a modern CMake library build. In this article we're going to design a CMake build and find_package script that enables library users to easily choose and switch between the two library types. How do we make it easy for our users to choose which one they want to link to, and why is this difficult to begin with? However, CMake library targets are always either one or the other. When packaging software libraries, it is a common requirement to deploy both a static and a shared version. Building a Dual Shared and Static Library with CMake Sat 06 March 2021