So instead of copying a convention that doesn't exist, we will follow a few guiding principles while trying to establish a new convention: Others, like FindHDF5 and FindOpenSSL, use variables with no common convention: HDF5 uses HDF5_USE_STATIC_LIBRARIES while OpenSSL uses OPENSSL_USE_STATIC_LIBS. Some modules, like FindCUDAToolkit, use separate targets for each type. There's also no good guidance inside CMake for solving this problem from the find_package side. This often means that static and shared libraries cannot share object files. Although most desktop systems (especially Linux) favor PIC for its security benefits (see: ASLR), many embedded systems with slow CPUs and strict power budgets either don't want or can't afford the overhead and prefer to link statically. It would also make it harder to make independent decisions about position-independent code. However, this is fundamentally incompatible with CMake's model of linking, which admits no properties on the link itself. 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. 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. The views and opinions expressed in this website are those of Alex Reinking and do not necessarily reflect the views or positions of his employer.
0 Comments
Leave a Reply. |