CMake-3.9.0

.. cmake-manual-description: CMake Buildsystem Reference cmake-buildsystem(7) ******************** .. only:: html .. contents:: Introduction ============ A CMake-based buildsystem is organized as a set of high-level logical targets. Each target corresponds to an executable or library, or is a custom target containing custom commands. Dependencies between the targets are expressed in the buildsystem to determine the build order and the rules for regeneration in response to change. Binary Targets ============== Executables and libraries are defined using the :command:`add_executable` and :command:`add_library` commands. The resulting binary files have appropriate prefixes, suffixes and extensions for the platform targeted. Dependencies between binary targets are expressed using the :command:`target_link_libraries` command: .. code-block:: cmake add_library(archive archive.cpp zip.cpp lzma.cpp) add_executable(zipapp zipapp.cpp) target_link_libraries(zipapp archive) ``archive`` is defined as a static library -- an archive containing objects compiled from ``archive.cpp``, ``zip.cpp``, and ``lzma.cpp``. ``zipapp`` is defined as an executable formed by compiling and linking ``zipapp.cpp``. When linking the ``zipapp`` executable, the ``archive`` static library is linked in. Binary Executables ------------------ The :command:`add_executable` command defines an executable target: .. code-block:: cmake add_executable(mytool mytool.cpp) Commands such as :command:`add_custom_command`, which generates rules to be run at build time can transparently use an :prop_tgt:`EXECUTABLE <TYPE>` target as a ``COMMAND`` executable. The buildsystem rules will ensure that the executable is built before attempting to run the command. Binary Library Types -------------------- .. _`Normal Libraries`: Normal Libraries ^^^^^^^^^^^^^^^^ By default, the :command:`add_library` command defines a static library, unless a type is specified. A type may be specified when using the command: .. code-block:: cmake add_library(archive SHARED archive.cpp zip.cpp lzma.cpp) .. code-block:: cmake add_library(archive STATIC archive.cpp zip.cpp lzma.cpp) The :variable:`BUILD_SHARED_LIBS` variable may be enabled to change the behavior of :command:`add_library` to build shared libraries by default. In the context of the buildsystem definition as a whole, it is largely irrelevant whether particular libraries are ``SHARED`` or ``STATIC`` -- the commands, dependency specifications and other APIs work similarly regardless of the library type. The ``MODULE`` library type is dissimilar in that it is generally not linked to -- it is not used in the right-hand-side of the :command:`target_link_libraries` command. It is a type which is loaded as a plugin using runtime techniques. If the library does not export any unmanaged symbols (e.g. Windows resource DLL, C++/CLI DLL), it is required that the library not be a ``SHARED`` library because CMake expects ``SHARED`` libraries to export at least one symbol. .. code-block:: cmake add_library(archive MODULE 7z.cpp) .. _`Apple Frameworks`: Apple Frameworks """""""""""""""" A ``SHARED`` library may be marked with the :prop_tgt:`FRAMEWORK` target property to create an OS X or iOS Framework Bundle. The ``MACOSX_FRAMEWORK_IDENTIFIER`` sets ``CFBundleIdentifier`` key and it uniquely identifies the bundle. .. code-block:: cmake add_library(MyFramework SHARED MyFramework.cpp) set_target_properties(MyFramework PROPERTIES FRAMEWORK TRUE FRAMEWORK_VERSION A MACOSX_FRAMEWORK_IDENTIFIER org.cmake.MyFramework ) .. _`Object Libraries`: Object Libraries ^^^^^^^^^^^^^^^^ The ``OBJECT`` library type is also not linked to. It defines a non-archival collection of object files resulting from compiling the given source files. The object files collection can be used as source inputs to other targets: .. code-block:: cmake add_library(archive OBJECT archive.cpp zip.cpp lzma.cpp) add_library(archiveExtras STATIC $<TARGET_OBJECTS:archive> extras.cpp) add_executable(test_exe $<TARGET_OBJECTS:archive> test.cpp) ``OBJECT`` libraries may not be used in the right hand side of :command:`target_link_libraries`. They also may not be used as the ``TARGET`` in a use of the :command:`add_custom_command(TARGET)` command signature. They may be installed, and will be exported as an INTERFACE library. Although object libraries may not be named directly in calls to the :command:`target_link_libraries` command, they can be "linked" indirectly by using an :ref:`Interface Library <Interface Libraries>` whose :prop_tgt:`INTERFACE_SOURCES` target property is set to name ``$<TARGET_OBJECTS:objlib>``. Although object libraries may not be used as the ``TARGET`` in a use of the :command:`add_custom_command(TARGET)` command signature, the list of objects can be used by :command:`add_custom_command(OUTPUT)` or :command:`file(GENERATE)` by using ``$<TARGET_OBJECTS:objlib>``. Build Specification and Usage Requirements ========================================== The :command:`target_include_directories`, :command:`target_compile_definitions` and :command:`target_compile_options` commands specify the build specifications and the usage requirements of binary targets. The commands populate the :prop_tgt:`INCLUDE_DIRECTORIES`, :prop_tgt:`COMPILE_DEFINITIONS` and :prop_tgt:`COMPILE_OPTIONS` target properties respectively, and/or the :prop_tgt:`INTERFACE_INCLUDE_DIRECTORIES`, :prop_tgt:`INTERFACE_COMPILE_DEFINITIONS` and :prop_tgt:`INTERFACE_COMPILE_OPTIONS` target properties. Each of the commands has a ``PRIVATE``, ``PUBLIC`` and ``INTERFACE`` mode. The ``PRIVATE`` mode populates only the non-``INTERFACE_`` variant of the target property and the ``INTERFACE`` mode populates only the ``INTERFACE_`` variants. The ``PUBLIC`` mode populates both variants of the respective target property. Each command may be invoked with multiple uses of each keyword: .. code-block:: cmake target_compile_definitions(archive PRIVATE BUILDING_WITH_LZMA INTERFACE USING_ARCHIVE_LIB ) Note that usage requirements are not designed as a way to make downstreams use particular :prop_tgt:`COMPILE_OPTIONS` or :prop_tgt:`COMPILE_DEFINITIONS` etc for convenience only. The contents of the properties must be **requirements**, not merely recommendations or convenience. See the :ref:`Creating Relocatable Packages` section of the :manual:`cmake-packages(7)` manual for discussion of additional care that must be taken when specifying usage requirements while creating packages for redistribution. Target Properties ----------------- The contents of the :prop_tgt:`INCLUDE_DIRECTORIES`, :prop_tgt:`COMPILE_DEFINITIONS` and :prop_tgt:`COMPILE_OPTIONS` target properties are used appropriately when compiling the source files of a binary target. Entries in the :prop_tgt:`INCLUDE_DIRECTORIES` are added to the compile line with ``-I`` or ``-isystem`` prefixes and in the order of appearance in the property value. Entries in the :prop_tgt:`COMPILE_DEFINITIONS` are prefixed with ``-D`` or ``/D`` and added to the compile line in an unspecified order. The :prop_tgt:`DEFINE_SYMBOL` target property is also added as a compile definition as a special convenience case for ``SHARED`` and ``MODULE`` library targets. Entries in the :prop_tgt:`COMPILE_OPTIONS` are escaped for the shell and added in the order of appearance in the property value. Several compile options have special separate handling, such as :prop_tgt:`POSITION_INDEPENDENT_CODE`. The contents of the :prop_tgt:`INTERFACE_INCLUDE_DIRECTORIES`, :prop_tgt:`INTERFACE_COMPILE_DEFINITIONS` and :prop_tgt:`INTERFACE_COMPILE_OPTIONS` target properties are *Usage Requirements* -- they specify content which consumers must use to correctly compile and link with the target they appear on. For any binary target, the contents of each ``INTERFACE_`` property on each target specified in a :command:`target_link_libraries`