CMake 3.0 Release Notes

Changes made since CMake 2.8.12 include the following.

Documentation Changes

New Features

Syntax

  • The CMake language has been extended with Bracket Argument and Bracket Comment syntax inspired by Lua long brackets:

    set(x [===[bracket argument]===] #[[bracket comment]])

    Content between equal-length open- and close-brackets is taken literally with no variable replacements.

    Warning

    This syntax change could not be made in a fully compatible way. No policy is possible because syntax parsing occurs before any chance to set a policy. Existing code using an unquoted argument that starts with an open bracket will be interpreted differently without any diagnostic. Fortunately the syntax is obscure enough that this problem is unlikely in practice.

Generators

  • A new CodeLite extra generator is available for use with the Makefile or Ninja generators.

  • A new Kate extra generator is available for use with the Makefile or Ninja generators.

  • The Ninja generator learned to use ninja job pools when specified by a new JOB_POOLS global property.

Commands

  • The add_library() command learned a new INTERFACE library type. Interface libraries have no build rules but may have properties defining usage requirements and may be installed, exported, and imported. This is useful to create header-only libraries that have concrete link dependencies on other libraries.

  • The export() command learned a new EXPORT mode that retrieves the list of targets to export from an export set configured by the install(TARGETS) command EXPORT option. This makes it easy to export from the build tree the same targets that are exported from the install tree.

  • The export() command learned to work with multiple dependent export sets, thus allowing multiple packages to be built and exported from a single tree. The feature requires CMake to wait until the generation step to write the output file. This means one should not include() the generated targets file later during project configuration because it will not be available. Use Alias Targets instead. See policy CMP0024.

  • The install(FILES) command learned to support generator expressions in the list of files.

  • The project() command learned to set some version variables to values specified by the new VERSION option or to empty strings. See policy CMP0048.

  • The string() command learned a new CONCAT mode. It is particularly useful in combination with the new Bracket Argument syntax.

  • The unset() command learned a PARENT_SCOPE option matching that of the set() command.

  • The include_external_msproject() command learned to handle non-C++ projects like .vbproj or .csproj.

  • The ctest_update() command learned to update work trees managed by the Perforce (p4) version control tool.

  • The message() command learned a DEPRECATION mode. Such messages are not issued by default, but may be issued as a warning if CMAKE_WARN_DEPRECATED is enabled, or as an error if CMAKE_ERROR_DEPRECATED is enabled.

  • The target_link_libraries() command now allows repeated use of the LINK_PUBLIC and LINK_PRIVATE keywords.

Variables

Properties

Modules

  • The CheckTypeSize module check_type_size macro and the CheckStructHasMember module check_struct_has_member macro learned a new LANGUAGE option to optionally check C++ types.

  • The ExternalData module learned to work with no URL templates if a local store is available.

  • The ExternalProject function ExternalProject_Add learned a new GIT_SUBMODULES option to specify a subset of available submodules to checkout.

  • A new FindBacktrace module has been added to support find_package(Backtrace) calls.

  • A new FindLua module has been added to support find_package(Lua) calls.

  • The FindBoost module learned a new Boost_NAMESPACE option to change the boost prefix on library names.

  • The FindBoost module learned to control search for libraries with the g tag (for MS debug runtime) with a new Boost_USE_DEBUG_RUNTIME option. It is ON by default to preserve existing behavior.

  • The FindJava and FindJNI modules learned to use a JAVA_HOME CMake variable or environment variable, and then try /usr/libexec/java_home on OS X.

  • The UseJava module add_jar function learned a new MANIFEST option to pass the -m option to jar.

  • A new CMakeFindDependencyMacro module was introduced with a find_dependency macro to find transitive dependencies in a package configuration file. Such dependencies are omitted by the listing of the FeatureSummary module.

  • The FindQt4 module learned to create Imported Targets for Qt executables. This helps disambiguate when using multiple Qt versions in the same buildsystem.

  • The FindRuby module learned to search for Ruby 2.0 and 2.1.

Generator Expressions

Other

  • The cmake(1) -E option learned a new sleep command.

  • The ccmake(1) dialog learned to honor the STRINGS cache entry property to cycle through the enumerated list of possible values.

  • The cmake-gui(1) dialog learned to remember window settings between sessions.

  • The cmake-gui(1) dialog learned to remember the type of a cache entry for completion in the Add Entry dialog.

New Diagnostics

  • Directories named in the INTERFACE_INCLUDE_DIRECTORIES target property of imported targets linked conditionally by a generator expression were not checked for existence. Now they are checked. See policy CMP0027.

  • Build target names must now match a validity pattern and may no longer conflict with CMake-defined targets. See policy CMP0037.

  • Build targets that specify themselves as a link dependency were silently accepted but are now diagnosed. See CMP0038.

  • The target_link_libraries() command used to silently ignore calls specifying as their first argument build targets created by add_custom_target() but now diagnoses this mistake. See policy CMP0039.

  • The add_custom_command() command used to silently ignore calls specifying the TARGET option with a non-existent target but now diagnoses this mistake. See policy CMP0040.

  • Relative paths in the INTERFACE_INCLUDE_DIRECTORIES target property used to be silently accepted if they contained a generator expression but are now rejected. See policy CMP0041.

  • The get_target_property() command learned to reject calls specifying a non-existent target. See policy CMP0045.

  • The add_dependencies() command learned to reject calls specifying a dependency on a non-existent target. See policy CMP0046.

  • Link dependency analysis learned to assume names containing :: refer to Alias Targets or Imported Targets. It will now produce an error if such a linked target is missing. Previously in this case CMake generated a link line that failed at build time. See policy CMP0028.

  • When the project() or enable_language() commands initialize support for a language, it is now an error if the full path to the compiler cannot be found and stored in the corresponding CMAKE_<LANG>_COMPILER variable. This produces nicer error messages up front and stops processing when no working compiler is known to be available.

  • Target sources specified with the add_library() or add_executable() command learned to reject items which require an undocumented extra layer of variable expansion. See policy CMP0049.

  • Use of add_custom_command() undocumented SOURCE signatures now results in an error. See policy CMP0050.

Deprecated and Removed Features

Other Changes

  • The version scheme was changed to use only two components for the feature level instead of three. The third component will now be used for bug-fix releases or the date of development versions. See the CMAKE_VERSION variable documentation for details.

  • The default install locations of CMake itself on Windows and OS X no longer contain the CMake version number. This allows for easy replacement without re-generating local build trees manually.

  • Generators for Visual Studio 10 (2010) and later were renamed to include the product year like generators for older VS versions:

    This clarifies which generator goes with each Visual Studio version. The old names are recognized for compatibility.

  • The CMAKE_<LANG>_COMPILER_ID value for Apple-provided Clang is now AppleClang. It must be distinct from upstream Clang because the version numbers differ. See policy CMP0025.

  • The CMAKE_<LANG>_COMPILER_ID value for qcc on QNX is now QCC. It must be distinct from GNU because the command-line options differ. See policy CMP0047.

  • On 64-bit OS X the CMAKE_HOST_SYSTEM_PROCESSOR value is now correctly detected as x86_64 instead of i386.

  • On OS X, CMake learned to enable behavior specified by the MACOSX_RPATH target property by default. This activates use of @rpath for runtime shared library searches. See policy CMP0042.

  • The build_command() command now returns a cmake(1) --build command line instead of a direct invocation of the native build tool. When using Visual Studio generators, CMake and CTest no longer require CMAKE_MAKE_PROGRAM to be located up front. Selection of the proper msbuild or devenv tool is now performed as late as possible when the solution (.sln) file is available so it can depend on project content.

  • The cmake(1) --build command now shares its own stdout and stderr pipes with the native build tool by default. The --use-stderr option that once activated this is now ignored.

  • The $<C_COMPILER_ID:...> and $<CXX_COMPILER_ID:...> generator expressions used to perform case-insensitive comparison but have now been corrected to perform case-sensitive comparison. See policy CMP0044.

  • The builtin edit_cache target will no longer select ccmake(1) by default when no interactive terminal will be available (e.g. with Ninja or an IDE generator). Instead cmake-gui(1) will be preferred if available.

  • The ExternalProject download step learned to re-attempt download in certain cases to be more robust to temporary network failure.

  • The FeatureSummary no longer lists transitive dependencies since they were not directly requested by the current project.

  • The cmake-mode.el major Emacs editing mode has been cleaned up and enhanced in several ways.

  • Include directories specified in the INTERFACE_INCLUDE_DIRECTORIES of Imported Targets are treated as SYSTEM includes by default when handled as usage requirements.