How it works

The previous example introduced two new commands:

• add_library(message STATIC Message.hpp Message.cpp): This will generate the necessary build tool instructions for compiling the specified sources into a library. The first argument to add_library is the name of the target. The same name can be used throughout CMakeLists.txt to refer to the library. The actual name of the generated library will be formed by CMake by adding the prefix lib in front and the appropriate extension as a suffix. The library extension is determined based on the second argument, STATIC or SHARED, and the operating system.
• target_link_libraries(hello-world message): Links the library into the executable. This command will also guarantee that the hello-world executable properly depends on the message library. We thus ensure that the message library is always built before we attempt to link it to the hello-world executable.

After successful compilation, the build directory will contain the libmessage.a static library (on GNU/Linux) and the hello-world executable. 

CMake accepts other values as valid for the second argument to add_library and we will encounter all of them in the rest of the book:

• STATIC, which we have already encountered, will be used to create static libraries, that is, archives of object files for use when linking other targets, such as executables.
• SHARED will be used to create shared libraries, that is, libraries that can be linked dynamically and loaded at runtime. Switching from a static library to a dynamic shared object (DSO) is as easy as using add_library(message SHARED Message.hpp Message.cpp) in CMakeLists.txt. 
• OBJECT can be used to compile the sources in the list given to add_library to object files, but then neither archiving them into a static library nor linking them into a shared object. The use of object libraries is particularly useful if one needs to create both static and shared libraries in one go. We will demonstrate this in this recipe.
• MODULE libraries are once again DSOs. In contrast to SHARED libraries, they are not linked to any other target within the project, but may be loaded dynamically later on. This is the argument to use when building a runtime plugin.

CMake is also able to generate special types of libraries. These produce no output in the build system but are extremely helpful in organizing dependencies and build requirements between targets:

• IMPORTED, this type of library target represents a library located outside the project. The main use for this type of library is to model pre-existing dependencies of the project that are provided by upstream packages. As such IMPORTED libraries are to be treated as immutable. We will show examples of using IMPORTED libraries throughout the rest of the book. See also: https://cmake.org/cmake/help/latest/manual/cmake-buildsystem.7.html#imported-targets
• INTERFACE, this special type of CMake library is similar to an IMPORTED library, but is mutable and has no location. Its main use case is to model usage requirements for a target that is outside our project. We will show a use case for INTERFACE libraries in Recipe 5, Distributing a project with dependencies as Conda package, in Chapter 11, Packaging Projects. See also: https://cmake.org/cmake/help/latest/manual/cmake-buildsystem.7.html#interface-libraries
• ALIAS, as the name suggests, a library of this type defines an alias for a pre-existing library target within the project. It is thus not possible to choose an alias for an IMPORTED library. See also: https://cmake.org/cmake/help/latest/manual/cmake-buildsystem.7.html#alias-libraries

In this example, we have collected the sources directly using add_library. In later chapters, we demonstrate the use of the target_sources CMake command to collect sources, in particular in Chapter 7, Structuring Projects. See also this wonderful blog post by Craig Scott: https://crascit.com/2016/01/31/enhanced-source-file-handling-with-target_sources/ which further motivates the use of the target_sources command.