Changes made since CMake 2.8.12.2 include the following.
The CMake documentation has been converted to reStructuredText and
now transforms via Sphinx (http://sphinx-doc.org) into man and
html pages. This allows the documentation to be properly indexed
and to contain cross-references.
Conversion from the old internal documentation format was done by
an automatic process so some documents may still contain artifacts.
They will be updated incrementally over time.
A basic reStructuredText processor has been implemented to support
cmake --help-command and similar command-line options.
New manuals were added:
Release notes for CMake 3.0.0 and above will now be included with
the html documentation.
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.
- 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.
- 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.
- 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 libraies 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.
- 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.
- 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.
- Compatibility options supporting code written for CMake versions
prior to 2.4 have been removed.
- Several long-outdated commands that should no longer be called
have been disallowed in new code by policies:
- The cmake(1) -i wizard mode has been removed.
Instead use an interactive dialog such as ccmake(1)
or use the -D option to set cache values from the command line.
- The builtin documentation formatters that supported command-line
options such as --help-man and --help-html have been removed
in favor of the above-mentioned new documentation system. These and
other command-line options that used to generate man- and html-
formatted pages no longer work. The cmake(1)
--help-custom-modules option now produces a warning at runtime
and generates a minimal document that reports the limitation.
- The COMPILE_DEFINITIONS_<CONFIG> directory properties and the
COMPILE_DEFINITIONS_<CONFIG> target properties have been
deprecated. Instead set the corresponding COMPILE_DEFINITIONS
directory property or COMPILE_DEFINITIONS target property and
use generator expressions like
$<CONFIG:...> to specify per-configuration definitions.
See policy CMP0043.
- The LOCATION target property should no longer be read from
non-IMPORTED targets. It does not make sense in multi-configuration
generators since the build configuration is not known while configuring
the project. It has been superseded by the $<TARGET_FILE> generator
expression. See policy CMP0026.
- The COMPILE_FLAGS target property is now documented
as deprecated, though no warning is issued. Use the
COMPILE_OPTIONS target property or the
target_compile_options() command instead.
- The GenerateExportHeader module add_compiler_export_flags
function is now deprecated. It has been superseded by the
<LANG>_VISIBILITY_PRESET and
VISIBILITY_INLINES_HIDDEN target properties.
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.
