View source for CMake 2.6 Notes

__TOC__

This page documents some of the changes and new features available in CMake 2.6.

=Exporting and Importing Targets=

CMake 2.6 introduces support for exporting targets from one project and importing them into another.
The main feature allowing this functionality is the notion of an <code>IMPORTED</code> target.
Here we present imported targets and then show how CMake files may be generated by a project to export its targets for use by other projects.

==Importing Targets==

Imported targets are used to convert files outside the project on disk into logical targets inside a CMake project.
They are created using the <code>IMPORTED</code> option to <code>add_executable</code> and <code>add_library</code> commands.
No build files are generated for imported targets.
They are useful simply for convenient, flexible reference to outside executables and libraries.

Consider the following example which creates and uses an IMPORTED executable target:

  add_executable(generator IMPORTED)                                                     # 1
  set_property(TARGET generator PROPERTY IMPORTED_LOCATION "/path/to/some_generator")    # 2
  
  set(GENERATED_SRC ${CMAKE_CURRENT_BINARY_DIR}/generated.c)
  add_custom_command(
    OUTPUT ${GENERATED_SRC}
    COMMAND generator ${GENERATED_SRC}                                                   # 3
    )
  
  add_executable(myexe src1.c src2.c ${GENERATED_SRC})

Line #1 creates a new CMake target called "<code>generator</code>".
Line #2 tells CMake the location of the file on disk to import.
Line #3 references the target in a custom command.  The generated build system will contain a command line such as

  /path/to/some_generator /project/binary/dir/generated.c

in the rule to generate the source file.

Libraries may also be used through imported targets:

  add_library(foo STATIC IMPORTED)
  set_property(TARGET foo PROPERTY IMPORTED_LOCATION /path/to/libfoo.a)
  add_executable(myexe src1.c src2.c)
  target_link_libraries(myexe foo)

The generated build system will contain a command line such as

  ... -o myexe /path/to/libfoo.a ...

in the rule to link <code>myexe</code>.
On Windows a .dll and its .lib import library may be imported together:

  add_library(bar SHARED IMPORTED)
  set_property(TARGET bar PROPERTY IMPORTED_LOCATION c:/path/to/bar.dll)
  set_property(TARGET bar PROPERTY IMPORTED_IMPLIB c:/path/to/bar.lib)
  add_executable(myexe src1.c src2.c)
  target_link_libraries(myexe bar)

The generated build system will contain a command line such as

  ... -o myexe.exe c:/path/to/bar.lib ...

in the rule to link <code>myexe</code>.
A library with multiple configurations may be imported with a single target:

  add_library(foo STATIC IMPORTED)
  set_property(TARGET foo PROPERTY IMPORTED_LOCATION_RELEASE c:/path/to/foo.lib)
  set_property(TARGET foo PROPERTY IMPORTED_LOCATION_DEBUG   c:/path/to/foo_d.lib)
  add_executable(myexe src1.c src2.c)
  target_link_libraries(myexe foo)

The generated build system will link <code>myexe</code> to <code>foo.lib</code> when it is built in the release configuration and <code>foo_d.lib</code> when built in the debug configuration.

==Exporting Targets==

Imported targets on their own are useful, but they still require the project that imports targets to know the locations of the target files on disk.
The real power of this feature is when the project providing the target files also provides a file to help import them.

===Exporting from an Installation Tree===

The <code>install(TARGETS)</code> and <code>install(EXPORT)</code> commands work together to install a target and a file to help import it.
For example, the code

  add_executable(generator generator.c)
  install(TARGETS generator DESTINATION lib/myproj/generators EXPORT myproj-targets)
  install(EXPORT myproj-targets DESTINATION lib/myproj)

installs the files

  <prefix>/lib/myproj/generators/generator
  <prefix>/lib/myproj/myproj-targets.cmake

The <code>myproj-targets.cmake</code> file contains code such as

  add_executable(generator IMPORTED)
  set_property(
    TARGET generator
    PROPERTY IMPORTED_LOCATION ${PREFIX}/lib/myproj/generators/generator
    )

(in practice the <code>${PREFIX}</code> is computed relative to the file location automatically).
An outside project may now contain code such as

  include(${PREFIX}/lib/myproj/myproj-targets.cmake)          # 1
  set(GENERATED_SRC ${CMAKE_CURRENT_BINARY_DIR}/generated.c)
  add_custom_command(
    OUTPUT ${GENERATED_SRC}
    COMMAND generator ${GENERATED_SRC}                        # 2
    )
  add_executable(myexe src1.c src2.c ${GENERATED_SRC})

Line #1 loads the target import script.  The script may import any number of targets.  Their locations are computed relative to the script location so the install tree may be moved around.
The importing project need only find the import script (see the packaging section of this document for how this might be done).
Line #2 references the generator executable in a custom command.  The resulting build system will run the executable from its installed location.

Libraries may also be exported and imported:

  add_library(foo STATIC foo1.c)
  install(TARGETS foo DESTINATION lib EXPORTS myproj-targets)
  install(EXPORT myproj-targets DESTINATION lib/myproj)

This installs the library and an import file referencing it.  Outside projects may simply write

  include(${PREFIX}/lib/myproj/myproj-targets.cmake)
  add_executable(myexe src1.c)
  target_link_libraries(myexe foo)

and the executable will be linked to the library <code>foo</code> exported and installed by the original project.

Any number of target installations may be associated with the same export name.
The export names are considered global so any directory may contribute a target installation.
Only one call to the <code>install(EXPORT)</code> command is needed to install an import file that references all targets.
Both of the examples above may be combined into a single export, even if they are in different subdirectories of the project:

  # A/CMakeLists.txt
  add_executable(generator generator.c)
  install(TARGETS generator DESTINATION lib/myproj/generators EXPORT myproj-targets)
  
  # B/CMakeLists.txt
  add_library(foo STATIC foo1.c)
  install(TARGETS foo DESTINATION lib EXPORTS myproj-targets)
  
  # Top CMakeLists.txt
  add_subdirectory(A)
  add_subdirectory(B)
  install(EXPORT myproj-targets DESTINATION lib/myproj)

===Exporting from a Build Tree===

Typically projects are built and installed before being used by an outside project.
However in some cases it is desirable to export targets directly from a build tree.
The targets may then be used by an outside project that references the build tree with no installation involved.

The <code>export</code> command is used to generate a file exporting targets from a project build tree.
For example, the code

  add_executable(generator generator.c)
  export(TARGETS generator FILE myproj-exports.cmake)

will create a file in the project build tree called <code>myproj-exports.cmake</code> that contains code such as

  add_executable(generator IMPORTED)
  set_property(TARGET generator PROPERTY IMPORTED_LOCATION "/path/to/build/tree/generator")

This file may be loaded by an outside project that is aware of the project build tree in order to use the executable to generate a source file.

An example application of this feature is for building a generator executable on a host platform when cross compiling.
The project containing the generator executable may be built on the host platform and then the project that is being cross-compiled for another platform may load it.

=Packages=

This section documents creation and use of packages that help projects locate each other.
These features are distinct from CPack which is meant for creating source and binary distributions and installers.

The <code>find_package</code> command has been enhanced with features to help find packages without the use of "find" modules (FindXXX.cmake files).
Projects that are aware of CMake may provide a "package configuration file" inside their installation trees.
Naming the file correctly and installing it in a suitable location will allow the <code>find_package</code> command to find it easily.

==Package Configuration Files==

Consider a project "Foo" that installs the following files:

  <prefix>/include/foo-1.2/foo.h
  <prefix>/lib/foo-1.2/libfoo.a

It may also provide a CMake package configuration file

  <prefix>/lib/foo-1.2/foo-config.cmake

with content such as

  # ...
  # (compute PREFIX relative to file location)
  # ...
  set(foo_INCLUDE_DIRS ${PREFIX}/include/foo-1.2)
  set(foo_LIBRARY ${PREFIX}/lib/foo-1.2/libfoo.a)

If another project wishes to use Foo it need only to locate the <code>foo-config.cmake</code> file and load it to get all the information it needs about package content locations.
Since the package configuration file is provided by the package installation it already knows all the file locations.

The <code>find_package</code> command may be used to search for the configuration file:

  find_package(Foo)

This command (assuming no <code>FindFoo.cmake</code> module exists) constructs a set of installation prefixes and searches under each prefix in several locations.
Given the name "Foo", it looks for a file called "<code>FooConfig.cmake</code>" or "<code>foo-config.cmake</code>".
The full set of locations is specified in the <code>find_package</code> command documentation, but one place it looks is

  <prefix>/lib/Foo*/

where "<code>Foo*</code>" is a case-insensitive globbing expression.
In our example the globbing expression will match "<code><prefix>/lib/foo-1.2</code>" and the configuration file will be found.

Once found, a package configuration file is immediately loaded.  It contains all the information the project needs to use the package.

===Packaging and Exporting===

Package configuration files may also work in conjunction with the target exporting/importing feature discussed above.
For example, a project might write

  add_library(mylib STATIC mylib.c mylib.h)
  install(FILES mylib.h DESTINATION include/myproj)
  install(TARGETS mylib DESTINATION lib/myproj EXPORT mylib-targets)
  install(EXPORT mylib-targets DESTINATION lib/myproj)
  install(FILES mylib-config.cmake DESTINATION lib/myproj)

where <code>mylib-config.cmake</code> contains something like

  get_filename_component(SELF_DIR "${CMAKE_CURRENT_LIST_FILE}" PATH)
  include(${SELF_DIR}/mylib-targets.cmake)
  get_filename_component(myproj_INCLUDE_DIRS "${SELF_DIR}/../../include/myproj" ABSOLUTE)

After the project is built and installed, an outside project may use it by writing

  find_package(myproj REQUIRED)
  include_directories(${myproj_INCLUDE_DIRS})
  add_executable(myexe myexe.c)
  target_link_libraries(myexe mylib)

==Package Version Files==

The <code>find_package</code> command offers a version request argument.  One might write

  find_package(Foo 1.2)
  find_package(Bar 4.2 EXACT)

in order to get a version of package <code>Foo</code> that is compatible with version 1.2 and exactly package <code>Bar</code> version 4.2.
CMake does not attempt to define any convention for the compatibility or exactness of version numbers for a package.
It also does not try to map the version number to a directory or file name.
Instead packages must provide "version" files next to their package configuration files.
This allows maximum flexibility for project authors and package maintainers.

A package version file is placed next to the package configuration file.
Its name matches that of the configuration file but has either "<code>-version</code>" or "<code>Version</code>" appended to the name before the "<code>.cmake</code>" extension.
For example, the files

  <prefix>/lib/foo-1.3/foo-config.cmake
  <prefix>/lib/foo-1.3/foo-config-version.cmake

and

  <prefix>/lib/bar-4.2/BarConfig.cmake
  <prefix>/lib/bar-4.2/BarConfigVersion.cmake

are each pairs of package configuration files and corresponding version files.
When the <code>find_package</code> command finds a candidate package configuration file it looks next to it for a version file.
The version file is loaded to test whether the package version is an acceptable match for the version requested.
If the version file claims compatibility the configuration file is accepted.  Otherwise it is ignored.

When the <code>find_package</code> command loads a version file it first sets the following variables:

  PACKAGE_FIND_NAME          = the <package> name given as the first argument of find_package
  PACKAGE_FIND_VERSION       = full requested version string
  PACKAGE_FIND_VERSION_MAJOR = requested major version, if any
  PACKAGE_FIND_VERSION_MINOR = requested minor version, if any
  PACKAGE_FIND_VERSION_PATCH = requested patch version, if any

The version file must use these variables to check whether it is compatible or an exact match for the requested version.
It sets the following variables with results:

  PACKAGE_VERSION            = package version (major[.minor[.patch]])
  PACKAGE_VERSION_EXACT      = true if version is exact match
  PACKAGE_VERSION_COMPATIBLE = true if version is compatible

For example, <code>foo-config-version.cmake</code> might contain

  set(PACKAGE_VERSION 1.3)
  if("${PACKAGE_FIND_VERSION_MAJOR}" EQUAL 1)
    set(PACKAGE_VERSION_COMPATIBLE 1) # compatible with any version 1.x
    if("${PACKAGE_FIND_VERSION_MINOR}" EQUAL 3)
      set(PACKAGE_VERSION_EXACT 1)    # exact match for version 1.3
    endif("${PACKAGE_FIND_VERSION_MINOR}" EQUAL 3)
  endif("${PACKAGE_FIND_VERSION_MAJOR}" EQUAL 1)

if it is compatible with all "<code>1.x</code>" versions of Foo and exactly matches version "<code>1.3</code>".
Note that the input variable names all start in "<code>PACKAGE_FIND_</code>" and the output variable names all start in "<code>PACKAGE_</code>".
The names are fixed and do not vary with the package name.

Version files are loaded in a nested scope so they are free to set any variables they wish as part of their computation.
The <code>find_package</code> command wipes out the scope when the version file has completed and it has checked the output variables.
When the version file claims to be an acceptable match for the requested version the <code>find_package</code> command sets the following variables for use by the project:

  <package>_VERSION       = package version (major[.minor[.patch]])
  <package>_VERSION_MAJOR = major from major[.minor[.patch]], if any
  <package>_VERSION_MINOR = minor from major[.minor[.patch]], if any
  <package>_VERSION_PATCH = patch from major[.minor[.patch]], if any

The variables report the version of the package that was actually found.
The "<code><package></code>" part of their name matches the argument given to the <code>find_package</code> command.

=Preprocessor Definitions=

Preprocessor definitions may now be added to builds with much finer granularity than in previous versions of CMake.  There is a new property called <code>COMPILE_DEFINITIONS</code> that is defined directories, targets, and source files.  For example, the code

  add_library(mylib src1.c src2.c)
  add_executable(myexe main1.c)

  set_property(
    DIRECTORY
    PROPERTY COMPILE_DEFINITIONS A AV=1
    )
  set_property(
    TARGET mylib
    PROPERTY COMPILE_DEFINITIONS B BV=2
    )
  set_property(
    SOURCE src1.c
    PROPERTY COMPILE_DEFINITIONS C CV=3
    )

will build the source files with these definitions:

  src1.c:   -DA -DAV=1 -DB -DBV=2 -DC -DCV=3
  src2.c:   -DA -DAV=1 -DB -DBV=2
  main2.c:  -DA -DAV=1

When the <code>add_definitions</code> command is called with flags like "<code>-DX</code>" the definitions are extracted and added to the current directory's <code>COMPILE_DEFINITIONS</code> property.  When a new subdirectory is created with <code>add_subdirectory</code> the current state of the directory-level property is used to initialize the same property in the subdirectory.

Note in the above example that the <code>set_property</code> command will actually '''set''' the property and replace any existing value.  The command provides the <code>APPEND</code> option to help add more definitions without removing existing ones.  For example, the code

  set_property(
    SOURCE src1.c
    APPEND PROPERTY COMPILE_DEFINITIONS D DV=4
    )

will add the definitions "<code>-DD -DDV=4</code>" when building <code>src1.c</code>.

Definitions may also be added on a per-configuration basis using the <code>COMPILE_DEFINITIONS_<CONFIG></code> property.  For example, the code

  set_property(
    TARGET mylib
    PROPERTY COMPILE_DEFINITIONS_DEBUG MYLIB_DEBUG_MODE
    )

will build sources in mylib with <code>-DMYLIB_DEBUG_MODE</code> only when compiling in a <code>Debug</code> configuration.

=Link Line Generation=

CMake 2.6 implements a new approach to generating link lines for targets.

Consider these libraries:

   /path/to/libfoo.a
   /path/to/libfoo.so

Previously if someone wrote

   target_link_libraries(myexe /path/to/libfoo.a)

CMake would generate this code to link it:

   ... -L/path/to -Wl,-Bstatic -lfoo -Wl,-Bdynamic ...

This worked most of the time, but some platforms (such as OS X) do not 
support the <code>-Bstatic</code> or equivalent flag.  This made it impossible to 
link to the static version of a library without creating a symlink in 
another directory and using that one instead.

Now CMake will generate this code:

   ... /path/to/libfoo.a ...

This guarantees that the correct library is chosen.  However there are some side-effects that affect compatibility with existing projects (documented in the next two subsections).

==Missing Linker Search Directories==

Projects used to be able to write this (wrong) code and it would work by accident:

   add_executable(myexe myexe.c)
   target_link_libraries(myexe /path/to/libA.so B)

where "<code>B</code>" is meant to link "<code>/path/to/libB.so</code>".  This code is incorrect 
because it asks CMake to link to <code>B</code> but does not provide the proper 
linker search path for it.  It used to work by accident because the 
<code>-L/path/to</code> would get added as part of the implementation of linking to 
A.  The correct code would be

   link_directories(/path/to)
   add_executable(myexe myexe.c)
   target_link_libraries(myexe /path/to/libA.so B)

or even better

   add_executable(myexe myexe.c)
   target_link_libraries(myexe /path/to/libA.so /path/to/libB.so)

In order to support projects that have this bug, we've added a 
compatibility feature that adds the "<code>-L/path/to</code>" paths for all libraries 
linked with full paths even though the linker will not need those paths 
to find the main libraries.  See policy CMP0003 for details.

==Linking to System Libraries==

System libraries on UNIX-like systems are typically provided in <code>/usr/lib</code> or <code>/lib</code>.  These directories are considered implicit linker search paths because linkers automatically search these locations even without a flag like <code>-L/usr/lib</code>.  Consider the code

  find_library(M_LIB m)
  target_link_libraries(myexe ${M_LIB})

Typically the <code>find_library</code> command would find the math library

  /usr/lib/libm.so

Some platforms provide multiple versions of libraries corresponding to different architectures.  For example, on an IRIX machine one might find the libraries

  /usr/lib/libm.so         (ELF o32)
  /usr/lib32/libm.so       (ELF n32)
  /usr/lib64/libm.so       (ELF 64)

On a Solaris machine one might find

  /usr/lib/libm.so          (sparcv8 architecture)
  /usr/lib/sparcv9/libm.so  (sparcv9 architecture)

Unfortunately <code>find_library</code> may not know about all the architecture-specific system search paths used by the linker.  In fact when it finds <code>/usr/lib/libm.so</code> it may be finding a library of incorrect architecture.  If the link computation were to produce the line

  ... /usr/lib/libm.so ...

the linker might complain if <code>/usr/lib/libm.so</code> does not match the architecture it wants.

One solution to this problem is for the link computation to recognize that the library is in a system directory and ask the linker to search for the library.  It could produce the link line

  ... -lm ...

and the linker would search through its architecture-specific implicit link directories to find the correct library.  Unfortunately this solution suffers from the original problem of distinguishing between static and shared versions:

  /usr/lib/libm.a
  /usr/lib/libm.so

In order to ask the linker to find the static system library of the correct architecture it must produce the link line

  ... -Wl,-Bstatic -lm ... -Wl,-Bshared ...

This solution directly contradicts the original motivation to give the linker paths to libraries instead of <code>-l</code> options: not all platforms have an option like <code>-Bstatic</code>.
Fortunately the platforms that do not provide such flags also tend to not have architecture-specific implicit link directories.

The solution used by CMake is:

* Libraries not in implicit system locations are linked by passing the file path to the linker
* Libraries in implicit system locations are linked by
** passing the <code>-l</code> option if a flag like <code>-Bstatic</code> is available
** passing the file path to the linker otherwise

Users can override this behavior by using the IMPORTED targets feature:

  add_library(math STATIC IMPORTED)
  set_property(TARGET math PROPERTY IMPORTED_LOCATION /usr/lib/libm.a)
  add_executable(foo foo.c)
  target_link_libraries(foo math) # will link using full path

=CMake Policy Mechanism=

CMake 2.6 introduces a new mechanism for backwards compatibility support.  See [[CMake Policies]] for more information.