code:
VERIFY_INTERFACE_HEADER_SETS
----------------------------

.. versionadded:: 3.24

Used to verify that all headers in a target's ``PUBLIC`` and ``INTERFACE``
header sets can be included on their own.

When this property is set to true, and the target is an object library, static
library, shared library, interface library, or executable with exports enabled,
and the target has one or more ``PUBLIC`` or ``INTERFACE`` header sets, an
object library target named ``<target_name>_verify_interface_header_sets`` is
created. This verification target has one source file per header in the
``PUBLIC`` and ``INTERFACE`` header sets. Each source file only includes its
associated header file. The verification target links against the original
target to get all of its usage requirements. The verification target has its
:prop_tgt:`EXCLUDE_FROM_ALL` and :prop_tgt:`DISABLE_PRECOMPILE_HEADERS`
properties set to true, and its :prop_tgt:`AUTOMOC`, :prop_tgt:`AUTORCC`,
:prop_tgt:`AUTOUIC`, and :prop_tgt:`UNITY_BUILD` properties set to false.

If the header's :prop_sf:`LANGUAGE` property is set, the value of that property
is used to determine the language with which to compile the header file.
Otherwise, if the target has any C++ sources, the header is compiled as C++.
Otherwise, if the target has any C sources, the header is compiled as C.
Otherwise, if C++ is enabled globally, the header is compiled as C++.
Otherwise, if C is enabled globally, the header is compiled as C. Otherwise,
the header file is not compiled.

If the header's :prop_sf:`SKIP_LINTING` property is set to true, the file is
not compiled.

If any verification targets are created, a top-level target called
``all_verify_interface_header_sets`` is created which depends on all
verification targets.

This property is initialized by the value of the
:variable:`CMAKE_VERIFY_INTERFACE_HEADER_SETS` variable if it is set when
a target is created.

If the project wishes to control which header sets are verified by this
property, it can set :prop_tgt:`INTERFACE_HEADER_SETS_TO_VERIFY`.


code:
VERSION
-------

Version number of a shared library target.

For shared libraries ``VERSION`` and :prop_tgt:`SOVERSION` can be used
to specify the build version and ABI version respectively.  When building or
installing appropriate symlinks are created if the platform supports
symlinks and the linker supports so-names.  If only one of both is
specified the missing is assumed to have the same version number.  For
executables ``VERSION`` can be used to specify the build version.  When
building or installing appropriate symlinks are created if the
platform supports symlinks.

.. include:: VERSION_SOVERSION_EXAMPLE.txt

Windows Versions
^^^^^^^^^^^^^^^^

For shared libraries and executables on Windows the ``VERSION``
attribute is parsed to extract a ``<major>.<minor>`` version number.
These numbers are used as the image version of the binary.

Mach-O Versions
^^^^^^^^^^^^^^^

For shared libraries and executables on Mach-O systems (e.g. macOS, iOS),
the :prop_tgt:`SOVERSION` property corresponds to the *compatibility version*
and ``VERSION`` corresponds to the *current version* (unless Mach-O specific
overrides are provided, as discussed below).
See the :prop_tgt:`FRAMEWORK` target property for an example.

For shared libraries, the :prop_tgt:`MACHO_COMPATIBILITY_VERSION` and
:prop_tgt:`MACHO_CURRENT_VERSION` properties can be used to
override the *compatibility version* and *current version* respectively.
Note that :prop_tgt:`SOVERSION` will still be used to form the
``install_name`` and both :prop_tgt:`SOVERSION` and ``VERSION`` may also
affect the file and symlink names.

Versions of Mach-O binaries may be checked with the ``otool -L <binary>``
command.

repo_name: lazytadpole/codenamesilverfish

license: mit


code:
A common convention is to specify both ``VERSION`` and ``SOVERSION``
such that ``SOVERSION`` matches the first component of ``VERSION``:

.. code-block:: cmake

  set_target_properties(mylib PROPERTIES VERSION 1.2.3 SOVERSION 1)

The idea is that breaking changes to the ABI increment both the
``SOVERSION`` and the major ``VERSION`` number.


code:
VISIBILITY_INLINES_HIDDEN
-------------------------

Whether to add a compile flag to hide symbols of inline functions

The ``VISIBILITY_INLINES_HIDDEN`` property determines whether a flag for
hiding symbols for inline functions, such as ``-fvisibility-inlines-hidden``,
should be used when invoking the compiler.  This property affects compilation
in sources of all types of targets (subject to policy :policy:`CMP0063`).

This property is initialized by
the value of the :variable:`CMAKE_VISIBILITY_INLINES_HIDDEN` variable if it
is set when a target is created.


code:
VS_CONFIGURATION_TYPE
---------------------

.. versionadded:: 3.6

Visual Studio project configuration type.

Sets the ``ConfigurationType`` attribute for a generated Visual Studio project.
The property value may use
:manual:`generator expressions <cmake-generator-expressions(7)>`.
If this property is set, it overrides the default setting that is based on the
target type (e.g. ``StaticLibrary``, ``Application``, ...).

Supported on :ref:`Visual Studio Generators` for VS 2010 and higher.


code:
VS_DEBUGGER_COMMAND
-------------------

.. versionadded:: 3.12

Sets the local debugger command for Visual Studio C++ targets.
The property value may use
:manual:`generator expressions <cmake-generator-expressions(7)>`.
This is defined in ``<LocalDebuggerCommand>`` in the Visual Studio
project file.  This property is initialized by the value of the variable
:variable:`CMAKE_VS_DEBUGGER_COMMAND` if it is set when a target is
created.

This property only works for Visual Studio 12 2013 and above;
it is ignored on other generators.


code:
VS_DEBUGGER_COMMAND_ARGUMENTS
-----------------------------

.. versionadded:: 3.13

Sets the local debugger command line arguments for Visual Studio C++ targets.
The property value may use
:manual:`generator expressions <cmake-generator-expressions(7)>`.
This is defined in ``<LocalDebuggerCommandArguments>`` in the Visual Studio
project file.  This property is initialized by the value of the variable
:variable:`CMAKE_VS_DEBUGGER_COMMAND_ARGUMENTS` if it is set when a target is
created.

This property only works for Visual Studio 12 2013 and above;
it is ignored on other generators.


code:
VS_DEBUGGER_ENVIRONMENT
-----------------------

.. versionadded:: 3.13

Sets the local debugger environment for Visual Studio C++ targets.
The property value may use
:manual:`generator expressions <cmake-generator-expressions(7)>`.
This is defined in ``<LocalDebuggerEnvironment>`` in the Visual Studio
project file.  This property is initialized by the value of the variable
:variable:`CMAKE_VS_DEBUGGER_ENVIRONMENT` if it is set when a target is
created.

This property only works for Visual Studio 12 2013 and above;
it is ignored on other generators.


code:
VS_DEBUGGER_WORKING_DIRECTORY
-----------------------------

.. versionadded:: 3.8

Sets the local debugger working directory for Visual Studio C++ targets.
The property value may use
:manual:`generator expressions <cmake-generator-expressions(7)>`.
This is defined in ``<LocalDebuggerWorkingDirectory>`` in the Visual Studio
project file.  This property is initialized by the value of the variable
:variable:`CMAKE_VS_DEBUGGER_WORKING_DIRECTORY` if it is set when a target is
created.

This property only works for Visual Studio 12 2013 and above;
it is ignored on other generators.


code:
VS_DESKTOP_EXTENSIONS_VERSION
-----------------------------

.. versionadded:: 3.4

Visual Studio Windows 10 Desktop Extensions Version

Specifies the version of the Desktop Extensions that should be included in the
target. For example ``10.0.10240.0``. If the value is not specified, the Desktop
Extensions will not be included. To use the same version of the extensions as
the Windows 10 SDK that is being used, you can use the
:variable:`CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION` variable.


code:
VS_DOTNET_DOCUMENTATION_FILE
----------------------------

.. versionadded:: 3.17

Visual Studio managed project .NET documentation output

Sets the target XML documentation file output.


code:
VS_DOTNET_REFERENCEPROP_<refname>_TAG_<tagname>
-----------------------------------------------

.. versionadded:: 3.10

Defines an XML property ``<tagname>`` for a .NET reference
``<refname>``.

Reference properties can be set for .NET references which are
defined by the target properties :prop_tgt:`VS_DOTNET_REFERENCES`,
:prop_tgt:`VS_DOTNET_REFERENCE_<refname>`
and also for project references to other C# targets which are
established by :command:`target_link_libraries()`.

This property is only applicable to C# targets and Visual Studio
generators 2010 and later.


code:
VS_DOTNET_REFERENCES
--------------------

Visual Studio managed project .NET references

Adds one or more semicolon-delimited .NET references to a generated
Visual Studio project.  For example, "System;System.Windows.Forms".


code:
VS_DOTNET_REFERENCES_COPY_LOCAL
-------------------------------

.. versionadded:: 3.8

Sets the **Copy Local** property for all .NET hint references in the target

Boolean property to enable/disable copying of .NET hint references to
output directory. The default is ``ON``.


code:
VS_DOTNET_REFERENCE_<refname>
-----------------------------

.. versionadded:: 3.8

Visual Studio managed project .NET reference with name ``<refname>``
and hint path.

Adds one .NET reference to generated Visual Studio project. The
reference will have the name ``<refname>`` and will point to the
assembly given as value of the property.

See also :prop_tgt:`VS_DOTNET_REFERENCES` and
:prop_tgt:`VS_DOTNET_REFERENCES_COPY_LOCAL`


code:
VS_DOTNET_STARTUP_OBJECT
------------------------

.. versionadded:: 3.24

Sets the startup object property in Visual Studio .NET targets.
The property value defines a full qualified class name (including package
name), for example: ``MyCompany.Package.MyStarterClass``.

If the property is unset, Visual Studio uses the first matching
``static void Main(string[])`` function signature by default. When more
than one ``Main()`` method is available in the current project, the property
becomes mandatory for building the project.

This property only works for Visual Studio 12 2013 and above;
it is ignored on other generators.

.. code-block:: cmake

  set_property(TARGET ${TARGET_NAME} PROPERTY
    VS_DOTNET_STARTUP_OBJECT "MyCompany.Package.MyStarterClass")


code:
VS_DOTNET_TARGET_FRAMEWORK_VERSION
----------------------------------

Specify the .NET target framework version.

Used to specify the .NET target framework version for C++/CLI. For
example, "v4.5".

This property is deprecated and should not be used anymore. Use
:prop_tgt:`DOTNET_TARGET_FRAMEWORK` or
:prop_tgt:`DOTNET_TARGET_FRAMEWORK_VERSION` instead.


code:
VS_DPI_AWARE
------------

.. versionadded:: 3.16

Set the Manifest Tool -> Input and Output -> DPI Awareness in the Visual Studio
target project properties.

Valid values are ``PerMonitor``, ``ON``, or ``OFF``.

For example:

.. code-block:: cmake

  add_executable(myproject myproject.cpp)
  set_property(TARGET myproject PROPERTY VS_DPI_AWARE "PerMonitor")


code:
VS_GLOBAL_KEYWORD
-----------------

Visual Studio project keyword for VS 10 (2010) and newer.

Sets the "keyword" attribute for a generated Visual Studio project.
Defaults to "Win32Proj".  You may wish to override this value with
"ManagedCProj", for example, in a Visual Studio managed C++ unit test
project.

Use the :prop_tgt:`VS_KEYWORD` target property to set the
keyword for Visual Studio 9 (2008) and older.


code:
VS_GLOBAL_PROJECT_TYPES
-----------------------

Visual Studio project type(s).

Can be set to one or more UUIDs recognized by Visual Studio to
indicate the type of project.  This value is copied verbatim into the
generated project file.  Example for a managed C++ unit testing
project:

::

 {3AC096D0-A1C2-E12C-1390-A8335801FDAB};{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}

UUIDs are semicolon-delimited.


code:
VS_GLOBAL_ROOTNAMESPACE
-----------------------

Visual Studio project root namespace.

Sets the "RootNamespace" attribute for a generated Visual Studio
project.  The attribute will be generated only if this is set.


code:
VS_GLOBAL_<variable>
--------------------

Visual Studio project-specific global variable.

Tell the Visual Studio generator to set the global variable
'<variable>' to a given value in the generated Visual Studio project.
Ignored on other generators.  Qt integration works better if
VS_GLOBAL_QtVersion is set to the version FindQt4.cmake found.  For
example, "4.7.3"


code:
VS_IOT_EXTENSIONS_VERSION
-------------------------

.. versionadded:: 3.4

Visual Studio Windows 10 IoT Extensions Version

Specifies the version of the IoT Extensions that should be included in the
target. For example ``10.0.10240.0``. If the value is not specified, the IoT
Extensions will not be included. To use the same version of the extensions as
the Windows 10 SDK that is being used, you can use the
:variable:`CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION` variable.


code:
VS_IOT_STARTUP_TASK
-------------------

.. versionadded:: 3.4

Visual Studio Windows 10 IoT Continuous Background Task

Specifies that the target should be compiled as a Continuous Background Task library.


code:
VS_JUST_MY_CODE_DEBUGGING
-------------------------

.. versionadded:: 3.15

Enable Just My Code with Visual Studio debugger.

Supported on :ref:`Visual Studio Generators` for VS 2010 and higher,
:ref:`Makefile Generators` and the :generator:`Ninja` generators.

This property is initialized by the :variable:`CMAKE_VS_JUST_MY_CODE_DEBUGGING`
variable if it is set when a target is created.


code:
VS_KEYWORD
----------

Visual Studio project keyword for VS 9 (2008) and older.

Can be set to change the visual studio keyword, for example Qt
integration works better if this is set to Qt4VSv1.0.

Use the :prop_tgt:`VS_GLOBAL_KEYWORD` target property to set the
keyword for Visual Studio 12 (2013) and newer.


code:
VS_MOBILE_EXTENSIONS_VERSION
----------------------------

.. versionadded:: 3.4

Visual Studio Windows 10 Mobile Extensions Version

Specifies the version of the Mobile Extensions that should be included in the
target. For example ``10.0.10240.0``. If the value is not specified, the Mobile
Extensions will not be included. To use the same version of the extensions as
the Windows 10 SDK that is being used, you can use the
:variable:`CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION` variable.


code:
VS_NO_COMPILE_BATCHING
----------------------

.. versionadded:: 3.24

Turn off compile batching for the target. Usually MSBuild calls the compiler
with multiple c/cpp files and compiler starts subprocesses for each file to
make the build parallel. If you want compiler to be invoked with one file at
a time set ``VS_NO_COMPILE_BATCHING`` to ON. If this flag is set MSBuild will
call compiler with one c/cpp file at a time. Useful when you want to use tool
that replaces the compiler, for example some build caching tool.

This property is initialized by the :variable:`CMAKE_VS_NO_COMPILE_BATCHING`
variable if it is set when a target is created.

Example
^^^^^^^

This shows setting the property for the target ``foo``.

.. code-block:: cmake

  add_library(foo SHARED foo.cpp)
  set_property(TARGET foo PROPERTY VS_NO_COMPILE_BATCHING ON)


code:
VS_NO_SOLUTION_DEPLOY
---------------------

.. versionadded:: 3.15

Specify that the target should not be marked for deployment to a Windows CE
or Windows Phone device in the generated Visual Studio solution.

Be default, all EXE and shared library (DLL) targets are marked to deploy to
the target device in the generated Visual Studio solution.

Generator expressions are supported.

There are reasons one might want to exclude a target / generated project from
deployment:

- The library or executable may not be necessary in the primary deploy/debug
  scenario, and excluding from deployment saves time in the
  develop/download/debug cycle.
- There may be insufficient space on the target device to accommodate all of
  the build products.
- Visual Studio 2013 requires a target device IP address be entered for each
  target marked for deployment.  For large numbers of targets, this can be
  tedious.
  NOTE: Visual Studio *will* deploy all project dependencies of a project
  tagged for deployment to the IP address configured for that project even
  if those dependencies are not tagged for deployment.

Example 1
^^^^^^^^^

This shows setting the variable for the target foo.

.. code-block:: cmake

  add_library(foo SHARED foo.cpp)
  set_property(TARGET foo PROPERTY VS_NO_SOLUTION_DEPLOY ON)

Example 2
^^^^^^^^^

This shows setting the variable for the Release configuration only.

.. code-block:: cmake

  add_library(foo SHARED foo.cpp)
  set_property(TARGET foo PROPERTY VS_NO_SOLUTION_DEPLOY "$<CONFIG:Release>")


code:
VS_PACKAGE_REFERENCES
---------------------

.. versionadded:: 3.15

Visual Studio package references for nuget.

Adds one or more semicolon-delimited package references to a generated
Visual Studio project. The version of the package will be
underscore delimited. For example, ``boost_1.7.0;nunit_3.12.*``.

.. code-block:: cmake

  set_property(TARGET ${TARGET_NAME} PROPERTY
    VS_PACKAGE_REFERENCES "boost_1.7.0")


code:
VS_PLATFORM_TOOLSET
-------------------

.. versionadded:: 3.18

Overrides the platform toolset used to build a target.

Only supported when the compiler used by the given toolset is the
same as the compiler used to build the whole source tree.

This is especially useful to create driver projects with the toolsets
"WindowsUserModeDriver10.0" or "WindowsKernelModeDriver10.0".


code:
VS_PROJECT_IMPORT
-----------------

.. versionadded:: 3.15

Visual Studio managed project imports

Adds to a generated Visual Studio project one or more semicolon-delimited paths
to .props files needed when building projects from some NuGet packages.
For example, ``my_packages_path/MyPackage.1.0.0/build/MyPackage.props``.


code:
VS_SCC_AUXPATH
--------------

Visual Studio Source Code Control Aux Path.

Can be set to change the visual studio source code control auxpath
property.


code:
VS_SCC_LOCALPATH
----------------

Visual Studio Source Code Control Local Path.

Can be set to change the visual studio source code control local path
property.


code:
VS_SCC_PROJECTNAME
------------------

Visual Studio Source Code Control Project.

Can be set to change the visual studio source code control project
name property.


code:
VS_SCC_PROVIDER
---------------

Visual Studio Source Code Control Provider.

Can be set to change the visual studio source code control provider
property.


code:
VS_SDK_REFERENCES
-----------------

.. versionadded:: 3.7

Visual Studio project SDK references.
Specify a :ref:`semicolon-separated list <CMake Language Lists>` of SDK references
to be added to a generated Visual Studio project, e.g.
``Microsoft.AdMediatorWindows81, Version=1.0``.


code:
VS_SOLUTION_DEPLOY
------------------

.. versionadded:: 3.18

Specify that the target should be marked for deployment when not targeting
Windows CE, Windows Phone or a Windows Store application.

If the target platform doesn't support deployment, this property won't have
any effect.

:manual:`Generator expressions <cmake-generator-expressions(7)>` are supported.

Examples
^^^^^^^^

Always deploy target ``foo``:

.. code-block:: cmake

  add_executable(foo SHARED foo.cpp)
  set_property(TARGET foo PROPERTY VS_SOLUTION_DEPLOY ON)

Deploy target ``foo`` for all configurations except ``Release``:

.. code-block:: cmake

  add_executable(foo SHARED foo.cpp)
  set_property(TARGET foo PROPERTY VS_SOLUTION_DEPLOY "$<NOT:$<CONFIG:Release>>")


code:
VS_SOURCE_SETTINGS_<tool>
-------------------------

.. versionadded:: 3.18

Set any item metadata on all non-built files that use <tool>.

Takes a list of ``Key=Value`` pairs. Tells the Visual Studio generator
to set ``Key`` to ``Value`` as item metadata on all non-built files
that use ``<tool>``.

For example:

.. code-block:: cmake

  set_property(TARGET main PROPERTY VS_SOURCE_SETTINGS_FXCompile "Key=Value" "Key2=Value2")

will set ``Key`` to ``Value`` and ``Key2`` to ``Value2`` for all
non-built files that use ``FXCompile``.

:manual:`Generator expressions <cmake-generator-expressions(7)>` are supported.


code:
VS_USER_PROPS
-------------

.. versionadded:: 3.8

Sets the user props file to be included in the visual studio
C++ project file. The standard path is
``$(UserRootDir)\\Microsoft.Cpp.$(Platform).user.props``, which is
in most cases the same as
``%LOCALAPPDATA%\\Microsoft\\MSBuild\\v4.0\\Microsoft.Cpp.Win32.user.props``
or ``%LOCALAPPDATA%\\Microsoft\\MSBuild\\v4.0\\Microsoft.Cpp.x64.user.props``.

The ``*.user.props`` files can be used for Visual Studio wide
configuration which is independent from cmake.


code:
VS_WINDOWS_TARGET_PLATFORM_MIN_VERSION
--------------------------------------

.. versionadded:: 3.4

Visual Studio Windows Target Platform Minimum Version

For Windows 10. Specifies the minimum version of the OS that is being
targeted. For example ``10.0.10240.0``. If the value is not specified, the
value of the :variable:`CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION` variable
will be used on WindowsStore projects.  Otherwise the target platform
minimum version will not be specified for the project.

.. versionadded:: 3.27
  This property is initialized by the value of the
  :variable:`CMAKE_VS_WINDOWS_TARGET_PLATFORM_MIN_VERSION` variable
  if it is set when a target is created.


code:
VS_WINRT_COMPONENT
------------------

.. versionadded:: 3.1

Mark a target as a Windows Runtime component for the Visual Studio generator.
Compile the target with ``C++/CX`` language extensions for Windows Runtime.
For ``SHARED`` and ``MODULE`` libraries, this also defines the
``_WINRT_DLL`` preprocessor macro.

.. note::
  Currently this is implemented only by Visual Studio generators.
  Support may be added to other generators in the future.


code:
VS_WINRT_EXTENSIONS
-------------------

Deprecated.  Use :prop_tgt:`VS_WINRT_COMPONENT` instead.
This property was an experimental partial implementation of that one.


code:
VS_WINRT_REFERENCES
-------------------

Visual Studio project Windows Runtime Metadata references

Adds one or more semicolon-delimited WinRT references to a generated
Visual Studio project.  For example, "Windows;Windows.UI.Core".


code:
``SingleThreaded``
  Compile without additional flags to use a single-threaded
  statically-linked runtime library.
``SingleThreadedDLL``
  Compile with ``-br`` or equivalent flag(s) to use a single-threaded
  dynamically-linked runtime library. This is not available for Linux
  targets.
``MultiThreaded``
  Compile with ``-bm`` or equivalent flag(s) to use a multi-threaded
  statically-linked runtime library.
``MultiThreadedDLL``
  Compile with ``-bm -br`` or equivalent flag(s) to use a multi-threaded
  dynamically-linked runtime library. This is not available for Linux
  targets.

The value is ignored on non-Watcom compilers but an unsupported value will
be rejected as an error when using a compiler targeting the Watcom ABI.

The value may also be the empty string (``""``) in which case no runtime
library selection flag will be added explicitly by CMake.


code:
WATCOM_RUNTIME_LIBRARY
----------------------

.. versionadded:: 3.24

Select the Watcom runtime library for use by compilers targeting the Watcom ABI.

The allowed values are:

.. include:: WATCOM_RUNTIME_LIBRARY-VALUES.txt

Use :manual:`generator expressions <cmake-generator-expressions(7)>` to
support per-configuration specification.

For example, the code:

.. code-block:: cmake

  add_executable(foo foo.c)
  set_property(TARGET foo PROPERTY
    WATCOM_RUNTIME_LIBRARY "MultiThreaded")

selects for the target ``foo`` a multi-threaded statically-linked runtime
library.

If this property is not set then CMake uses the default value
``MultiThreadedDLL`` on Windows and ``SingleThreaded`` on other
platforms to select a Watcom runtime library.

.. note::

  This property has effect only when policy :policy:`CMP0136` is set to ``NEW``
  prior to the first :command:`project` or :command:`enable_language` command
  that enables a language using a compiler targeting the Watcom ABI.


code:
WIN32_EXECUTABLE
----------------

Build an executable with a WinMain entry point on windows.

When this property is set to true the executable when linked on
Windows will be created with a WinMain() entry point instead of just
main().  This makes it a GUI executable instead of a console application.
See the :variable:`CMAKE_MFC_FLAG` variable documentation to
configure use of the Microsoft Foundation Classes (MFC) for WinMain
executables.  This property is initialized by the value of the
:variable:`CMAKE_WIN32_EXECUTABLE` variable if it is set when
a target is created.

This property supports
:manual:`generator expressions <cmake-generator-expressions(7)>`, except if the
target is managed (contains C# code.)


code:
WINDOWS_EXPORT_ALL_SYMBOLS
--------------------------

.. versionadded:: 3.4

This property is implemented only for MS-compatible tools on Windows.

Enable this boolean property to automatically create a module definition
(``.def``) file with all global symbols found in the input ``.obj`` files
for a ``SHARED`` library (or executable with :prop_tgt:`ENABLE_EXPORTS`)
on Windows.  The module definition file will be passed to the linker
causing all symbols to be exported from the ``.dll``.
For global *data* symbols, ``__declspec(dllimport)`` must still be used when
compiling against the code in the ``.dll``.  All other function symbols will
be automatically exported and imported by callers.  This simplifies porting
projects to Windows by reducing the need for explicit ``dllexport`` markup,
even in ``C++`` classes.

When this property is enabled, zero or more ``.def`` files may also be
specified as source files of the target.  The exports named by these files
will be merged with those detected from the object files to generate a
single module definition file to be passed to the linker.  This can be
used to export symbols from a ``.dll`` that are not in any of its object
files but are added by the linker from dependencies (e.g. ``msvcrt.lib``).

This property is initialized by the value of
the :variable:`CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS` variable if it is set
when a target is created.


code:
XCODE_ATTRIBUTE_<an-attribute>
------------------------------

Set Xcode target attributes directly.

Tell the :generator:`Xcode` generator to set ``<an-attribute>`` to a given
value in the generated Xcode project.  Ignored on other generators.

This offers low-level control over the generated Xcode project file.
It is meant as a last resort for specifying settings that CMake does
not otherwise have a way to control.  Although this can override a
setting CMake normally produces on its own, doing so bypasses CMake's
model of the project and can break things.

See the :variable:`CMAKE_XCODE_ATTRIBUTE_<an-attribute>` variable
to set attributes on all targets in a directory tree.

Contents of ``XCODE_ATTRIBUTE_<an-attribute>`` may use
"generator expressions" with the syntax ``$<...>``.  See the
:manual:`cmake-generator-expressions(7)` manual for available
expressions.  See the :manual:`cmake-buildsystem(7)` manual
for more on defining buildsystem properties.


code:
XCODE_EMBED_FRAMEWORKS_CODE_SIGN_ON_COPY
----------------------------------------

.. versionadded:: 3.20

Tell the :generator:`Xcode` generator to perform code signing for all the
frameworks and libraries that are embedded using the
:prop_tgt:`XCODE_EMBED_FRAMEWORKS <XCODE_EMBED_<type>>` property.

.. versionadded:: 3.21

This property was generalized to other types of embedded items.  See
:prop_tgt:`XCODE_EMBED_<type>_CODE_SIGN_ON_COPY` for the more general form.


code:
XCODE_EMBED_FRAMEWORKS_REMOVE_HEADERS_ON_COPY
---------------------------------------------

.. versionadded:: 3.20

Tell the :generator:`Xcode` generator to remove headers from all the
frameworks that are embedded using the
:prop_tgt:`XCODE_EMBED_FRAMEWORKS <XCODE_EMBED_<type>>` property.

.. versionadded:: 3.21

This property was generalized to other types of embedded items.  See
:prop_tgt:`XCODE_EMBED_<type>_REMOVE_HEADERS_ON_COPY` for the more
general form.


code:
XCODE_EMBED_<type>
------------------

.. versionadded:: 3.20

Tell the :generator:`Xcode` generator to embed the specified list of items into
the target bundle.  ``<type>`` specifies the embed build phase to use.
See the Xcode documentation for the base location of each ``<type>``.

The supported values for ``<type>`` are:

``FRAMEWORKS``
  The specified items will be added to the ``Embed Frameworks`` build phase.
  The items can be CMake target names or paths to frameworks or libraries.

``APP_EXTENSIONS``
  .. versionadded:: 3.21

  The specified items will be added to the ``Embed App Extensions`` build
  phase, with ``Destination`` set to ``PlugIns and Foundation Extensions``
  They must be CMake target names.

``EXTENSIONKIT_EXTENSIONS``
  .. versionadded:: 3.26

  The specified items will be added to the ``Embed App Extensions`` build
  phase, with ``Destination`` set to ``ExtensionKit Extensions``
  They must be CMake target names, and should likely have the
  ``XCODE_PRODUCT_TYPE`` target property set to
  ``com.apple.product-type.extensionkit-extension``
  as well as the  ``XCODE_EXPLICIT_FILE_TYPE`` to
  ``wrapper.extensionkit-extension``

``PLUGINS``
  .. versionadded:: 3.23

  The specified items will be added to the ``Embed PlugIns`` build phase.
  They must be CMake target names.

``RESOURCES``
  .. versionadded:: 3.28

  The specified items will be added to the ``Embed Resources`` build phase.
  They must be CMake target names or folder paths.

``XPC_SERVICES``
  .. versionadded:: 3.29

  The specified items will be added to the ``Embed XPC Services`` build phase.
  They must be CMake target names.

When listing a target as any of the things to embed, Xcode must see that target
as part of the same Xcode project, or a sub-project of the one defining the
bundle.  In order to satisfy this constraint, the CMake project must ensure
at least one of the following:

* The :variable:`CMAKE_XCODE_GENERATE_TOP_LEVEL_PROJECT_ONLY` variable is set
  to true in the top level ``CMakeLists.txt`` file.  This is the simplest and
  most robust approach.
* Define the target-to-embed in a subdirectory of the one that defines the
  target being embedded into.
* If the target-to-embed and the target being embedded into are in separate,
  unrelated directories (i.e. they are siblings, not one a parent of the
  other), ensure they have a common :command:`project` call in a parent
  directory and no other :command:`project` calls between themselves and that
  common :command:`project` call.

See also :prop_tgt:`XCODE_EMBED_<type>_PATH`,
:prop_tgt:`XCODE_EMBED_<type>_REMOVE_HEADERS_ON_COPY` and
:prop_tgt:`XCODE_EMBED_<type>_CODE_SIGN_ON_COPY`.


code:
XCODE_EMBED_<type>_CODE_SIGN_ON_COPY
------------------------------------

.. versionadded:: 3.20

Boolean property used only by the :generator:`Xcode` generator.  It specifies
whether to perform code signing for the items that are embedded using the
:prop_tgt:`XCODE_EMBED_<type>` property.

The supported values for ``<type>`` are:

``FRAMEWORKS``

``APP_EXTENSIONS``
  .. versionadded:: 3.21

``EXTENSIONKIT_EXTENSIONS``
  .. versionadded:: 3.26

``PLUGINS``
  .. versionadded:: 3.23

If a ``XCODE_EMBED_<type>_CODE_SIGN_ON_COPY`` property is not defined on the
target, no code signing on copy will be performed for that ``<type>``.


code:
XCODE_EMBED_<type>_PATH
-----------------------

.. versionadded:: 3.20

This property is used only by the :generator:`Xcode` generator.  When defined,
it specifies the relative path to use when embedding the items specified by
:prop_tgt:`XCODE_EMBED_<type>`.  The path is relative
to the base location of the ``Embed XXX`` build phase associated with
``<type>``.  See the Xcode documentation for the base location of each
``<type>``.

The supported values for ``<type>`` are:

``FRAMEWORKS``

``APP_EXTENSIONS``
  .. versionadded:: 3.21

``EXTENSIONKIT_EXTENSIONS``
  .. versionadded:: 3.26

``PLUGINS``
  .. versionadded:: 3.23

``RESOURCES``
  .. versionadded:: 3.28

``XPC_SERVICES``
  .. versionadded:: 3.29


code:
XCODE_EMBED_<type>_REMOVE_HEADERS_ON_COPY
-----------------------------------------

.. versionadded:: 3.20

Boolean property used only by the :generator:`Xcode` generator.  It specifies
whether to remove headers from all the frameworks that are embedded using the
:prop_tgt:`XCODE_EMBED_<type>` property.

The supported values for ``<type>`` are:

``FRAMEWORKS``
  If the ``XCODE_EMBED_FRAMEWORKS_REMOVE_HEADERS_ON_COPY`` property is not
  defined, headers will not be removed on copy by default.

``APP_EXTENSIONS``
  .. versionadded:: 3.21

  If the ``XCODE_EMBED_APP_EXTENSIONS_REMOVE_HEADERS_ON_COPY`` property is not
  defined, headers WILL be removed on copy by default.

``EXTENSIONKIT_EXTENSIONS``
  .. versionadded:: 3.26

  If the ``XCODE_EMBED_APP_EXTENSIONS_REMOVE_HEADERS_ON_COPY`` property is not
  defined, headers WILL be removed on copy by default.

``PLUGINS``
  .. versionadded:: 3.23


code:
XCODE_EXPLICIT_FILE_TYPE
------------------------

.. versionadded:: 3.8

Set the Xcode ``explicitFileType`` attribute on its reference to a
target.  CMake computes a default based on target type but
can be told explicitly with this property.

See also :prop_tgt:`XCODE_PRODUCT_TYPE`.


code:
XCODE_GENERATE_SCHEME
---------------------

.. versionadded:: 3.15

If enabled, the :generator:`Xcode` generator will generate schema files.  These
are useful to invoke analyze, archive, build-for-testing and test
actions from the command line.

This property is initialized by the value of the variable
:variable:`CMAKE_XCODE_GENERATE_SCHEME` if it is set when a target
is created.

The following target properties overwrite the default of the
corresponding settings on the "Diagnostic" tab for each schema file.
Each of those is initialized by the respective ``CMAKE_`` variable
at target creation time.

- :prop_tgt:`XCODE_SCHEME_ADDRESS_SANITIZER`
- :prop_tgt:`XCODE_SCHEME_ADDRESS_SANITIZER_USE_AFTER_RETURN`
- :prop_tgt:`XCODE_SCHEME_DISABLE_MAIN_THREAD_CHECKER`
- :prop_tgt:`XCODE_SCHEME_DYNAMIC_LIBRARY_LOADS`
- :prop_tgt:`XCODE_SCHEME_DYNAMIC_LINKER_API_USAGE`
- :prop_tgt:`XCODE_SCHEME_GUARD_MALLOC`
- :prop_tgt:`XCODE_SCHEME_MAIN_THREAD_CHECKER_STOP`
- :prop_tgt:`XCODE_SCHEME_MALLOC_GUARD_EDGES`
- :prop_tgt:`XCODE_SCHEME_MALLOC_SCRIBBLE`
- :prop_tgt:`XCODE_SCHEME_MALLOC_STACK`
- :prop_tgt:`XCODE_SCHEME_THREAD_SANITIZER`
- :prop_tgt:`XCODE_SCHEME_THREAD_SANITIZER_STOP`
- :prop_tgt:`XCODE_SCHEME_UNDEFINED_BEHAVIOUR_SANITIZER`
- :prop_tgt:`XCODE_SCHEME_UNDEFINED_BEHAVIOUR_SANITIZER_STOP`
- :prop_tgt:`XCODE_SCHEME_LAUNCH_CONFIGURATION`
- :prop_tgt:`XCODE_SCHEME_ENABLE_GPU_API_VALIDATION`
- :prop_tgt:`XCODE_SCHEME_ENABLE_GPU_SHADER_VALIDATION`
- :prop_tgt:`XCODE_SCHEME_ZOMBIE_OBJECTS`

The following target properties will be applied on the
"Info", "Arguments", and "Options" tab:

- :prop_tgt:`XCODE_SCHEME_ARGUMENTS`
- :prop_tgt:`XCODE_SCHEME_DEBUG_AS_ROOT`
- :prop_tgt:`XCODE_SCHEME_DEBUG_DOCUMENT_VERSIONING`
- :prop_tgt:`XCODE_SCHEME_ENABLE_GPU_FRAME_CAPTURE_MODE`
- :prop_tgt:`XCODE_SCHEME_ENVIRONMENT`
- :prop_tgt:`XCODE_SCHEME_EXECUTABLE`
- :prop_tgt:`XCODE_SCHEME_LAUNCH_MODE`
- :prop_tgt:`XCODE_SCHEME_WORKING_DIRECTORY`


code:
XCODE_LINK_BUILD_PHASE_MODE
---------------------------

.. versionadded:: 3.19

When using the :generator:`Xcode` generator, libraries to be linked will be
specified in the Xcode project file using either the "Link Binary With
Libraries" build phase or directly as linker flags.  The former allows Xcode
to manage build paths, which may be necessary when creating Xcode archives
because it may use different build paths to a regular build.

This property controls usage of "Link Binary With Libraries" build phase for
a target that is an app bundle, executable, shared library, shared framework
or a module library.

Possible values are:

* ``NONE``
  The libraries will be linked by specifying the linker flags directly.

* ``BUILT_ONLY``
  The "Link Binary With Libraries" build phase will be used to link to another
  target under the following conditions:

  - The target to be linked to is a regular non-imported, non-interface library
    target.
  - The output directory of the target being built has not been changed from
    its default (see :prop_tgt:`RUNTIME_OUTPUT_DIRECTORY` and
    :prop_tgt:`LIBRARY_OUTPUT_DIRECTORY`).

* ``KNOWN_LOCATION``
  The "Link Binary With Libraries" build phase will be used to link to another
  target under the same conditions as with ``BUILT_ONLY`` and also:

  - Imported library targets except those of type ``UNKNOWN``.
  - Any non-target library specified directly with a path.

For all other cases, the libraries will be linked by specifying the linker
flags directly.

.. warning::
  Libraries linked using "Link Binary With Libraries" are linked after the
  ones linked through regular linker flags.  This order should be taken into
  account when different static libraries contain symbols with the same name,
  as the former ones will take precedence over the latter.

.. warning::
  If two or more directories contain libraries with identical file names and
  some libraries are linked from those directories, the library search path
  lookup will end up linking libraries from the first directory.  This is a
  known limitation of Xcode.

This property is initialized by the value of the
:variable:`CMAKE_XCODE_LINK_BUILD_PHASE_MODE` variable if it is set when a
target is created.


code:
XCODE_PRODUCT_TYPE
------------------

.. versionadded:: 3.8

Set the Xcode ``productType`` attribute on its reference to a
target.  CMake computes a default based on target type but
can be told explicitly with this property.

See also :prop_tgt:`XCODE_EXPLICIT_FILE_TYPE`.


code:
XCODE_SCHEME_ADDRESS_SANITIZER
------------------------------

.. versionadded:: 3.13

Whether to enable ``Address Sanitizer`` in the Diagnostics
section of the generated Xcode scheme.

This property is initialized by the value of the variable
:variable:`CMAKE_XCODE_SCHEME_ADDRESS_SANITIZER` if it is set
when a target is created.

Please refer to the :prop_tgt:`XCODE_GENERATE_SCHEME` target property
documentation to see all Xcode schema related properties.


code:
XCODE_SCHEME_ADDRESS_SANITIZER_USE_AFTER_RETURN
-----------------------------------------------

.. versionadded:: 3.13

Whether to enable ``Detect use of stack after return``
in the Diagnostics section of the generated Xcode scheme.

This property is initialized by the value of the variable
:variable:`CMAKE_XCODE_SCHEME_ADDRESS_SANITIZER_USE_AFTER_RETURN`
if it is set when a target is created.

Please refer to the :prop_tgt:`XCODE_GENERATE_SCHEME` target property
documentation to see all Xcode schema related properties.


code:
XCODE_SCHEME_ARGUMENTS
----------------------

.. versionadded:: 3.13

Specify command line arguments that should be added to the Arguments
section of the generated Xcode scheme.

If set to a list of arguments those will be added to the scheme.

Please refer to the :prop_tgt:`XCODE_GENERATE_SCHEME` target property
documentation to see all Xcode schema related properties.


code:
XCODE_SCHEME_DEBUG_AS_ROOT
--------------------------

.. versionadded:: 3.15

Whether to debug the target as 'root'.

Please refer to the :prop_tgt:`XCODE_GENERATE_SCHEME` target property
documentation to see all Xcode schema related properties.


code:
XCODE_SCHEME_DEBUG_DOCUMENT_VERSIONING
--------------------------------------

.. versionadded:: 3.16

Whether to enable
``Allow debugging when using document Versions Browser``
in the Options section of the generated Xcode scheme.

This property is initialized by the value of the variable
:variable:`CMAKE_XCODE_SCHEME_DEBUG_DOCUMENT_VERSIONING`
if it is set when a target is created.

Please refer to the :prop_tgt:`XCODE_GENERATE_SCHEME` target property
documentation to see all Xcode schema related properties.


code:
XCODE_SCHEME_DISABLE_MAIN_THREAD_CHECKER
----------------------------------------

.. versionadded:: 3.13

Whether to disable the ``Main Thread Checker``
in the Diagnostics section of the generated Xcode scheme.

This property is initialized by the value of the variable
:variable:`CMAKE_XCODE_SCHEME_DISABLE_MAIN_THREAD_CHECKER`
if it is set when a target is created.

Please refer to the :prop_tgt:`XCODE_GENERATE_SCHEME` target property
documentation to see all Xcode schema related properties.


code:
XCODE_SCHEME_DYNAMIC_LIBRARY_LOADS
----------------------------------

.. versionadded:: 3.13

Whether to enable ``Dynamic Library Loads``
in the Diagnostics section of the generated Xcode scheme.

This property is initialized by the value of the variable
:variable:`CMAKE_XCODE_SCHEME_DYNAMIC_LIBRARY_LOADS` if it is set
when a target is created.

Please refer to the :prop_tgt:`XCODE_GENERATE_SCHEME` target property
documentation to see all Xcode schema related properties.


code:
XCODE_SCHEME_DYNAMIC_LINKER_API_USAGE
-------------------------------------

.. versionadded:: 3.13

Whether to enable ``Dynamic Linker API usage``
in the Diagnostics section of the generated Xcode scheme.

This property is initialized by the value of the variable
:variable:`CMAKE_XCODE_SCHEME_DYNAMIC_LINKER_API_USAGE` if it is set
when a target is created.

Please refer to the :prop_tgt:`XCODE_GENERATE_SCHEME` target property
documentation to see all Xcode schema related properties.


code:
XCODE_SCHEME_ENABLE_GPU_API_VALIDATION
--------------------------------------

.. versionadded:: 3.25

Property value for ``Metal: API Validation`` in the Options section of
the generated Xcode scheme.

This property is initialized by the value of the variable
:variable:`CMAKE_XCODE_SCHEME_ENABLE_GPU_API_VALIDATION`
if it is set when a target is created.

Please refer to the :prop_tgt:`XCODE_GENERATE_SCHEME` target property
documentation to see all Xcode schema related properties.


code:
XCODE_SCHEME_ENABLE_GPU_FRAME_CAPTURE_MODE
------------------------------------------

.. versionadded:: 3.23

Property value for ``GPU Frame Capture`` in the Options section of
the generated Xcode scheme. Example values are `Metal` and
`Disabled`.

This property is initialized by the value of the variable
:variable:`CMAKE_XCODE_SCHEME_ENABLE_GPU_FRAME_CAPTURE_MODE`
if it is set when a target is created.

Please refer to the :prop_tgt:`XCODE_GENERATE_SCHEME` target property
documentation to see all Xcode schema related properties.


code:
XCODE_SCHEME_ENABLE_GPU_SHADER_VALIDATION
-----------------------------------------

.. versionadded:: 3.25

Property value for ``Metal: Shader Validation`` in the Options section of
the generated Xcode scheme.

This property is initialized by the value of the variable
:variable:`CMAKE_XCODE_SCHEME_ENABLE_GPU_SHADER_VALIDATION`
if it is set when a target is created.

Please refer to the :prop_tgt:`XCODE_GENERATE_SCHEME` target property
documentation to see all Xcode schema related properties.


code:
XCODE_SCHEME_ENVIRONMENT
------------------------

.. versionadded:: 3.13

Specify environment variables that should be added to the Arguments
section of the generated Xcode scheme.

If set to a list of environment variables and values of the form
``MYVAR=value`` those environment variables will be added to the
scheme.

Please refer to the :prop_tgt:`XCODE_GENERATE_SCHEME` target property
documentation to see all Xcode schema related properties.


code:
XCODE_SCHEME_EXECUTABLE
-----------------------

.. versionadded:: 3.13

Specify path to executable in the Info section of the generated
Xcode scheme. If not set the schema generator will select the
current target if it is actually executable.

Please refer to the :prop_tgt:`XCODE_GENERATE_SCHEME` target property
documentation to see all Xcode schema related properties.


code:
XCODE_SCHEME_GUARD_MALLOC
------------------------------

.. versionadded:: 3.13

Whether to enable ``Guard Malloc``
in the Diagnostics section of the generated Xcode scheme.

This property is initialized by the value of the variable
:variable:`CMAKE_XCODE_SCHEME_GUARD_MALLOC` if it is set
when a target is created.

Please refer to the :prop_tgt:`XCODE_GENERATE_SCHEME` target property
documentation to see all Xcode schema related properties.


code:
XCODE_SCHEME_LAUNCH_CONFIGURATION
---------------------------------

.. versionadded:: 3.25

Set the build configuration to run the target.

This property is initialized by the value of the variable
:variable:`CMAKE_XCODE_SCHEME_LAUNCH_CONFIGURATION`
if it is set when a target is created.

Please refer to the :prop_tgt:`XCODE_GENERATE_SCHEME` target property
documentation to see all Xcode schema related properties.


code:
XCODE_SCHEME_LAUNCH_MODE
------------------------

.. versionadded:: 3.25

Property value for ``Launch`` in the Info section of the generated Xcode
scheme.

Possible values are:

``AUTO``
  Launch automatically. This is the default.

``WAIT``
  Wait for the executable to be launched.

This property is initialized by the value of the variable
:variable:`CMAKE_XCODE_SCHEME_LAUNCH_MODE` if it is set when a target is
created.

Please refer to the :prop_tgt:`XCODE_GENERATE_SCHEME` target property
documentation to see all Xcode schema related properties.


code:
XCODE_SCHEME_MAIN_THREAD_CHECKER_STOP
-------------------------------------

.. versionadded:: 3.13

Whether to enable the ``Main Thread Checker`` option
``Pause on issues``
in the Diagnostics section of the generated Xcode scheme.

This property is initialized by the value of the variable
:variable:`CMAKE_XCODE_SCHEME_MAIN_THREAD_CHECKER_STOP` if it is set
when a target is created.

Please refer to the :prop_tgt:`XCODE_GENERATE_SCHEME` target property
documentation to see all Xcode schema related properties.


code:
XCODE_SCHEME_MALLOC_GUARD_EDGES
-------------------------------

.. versionadded:: 3.13

Whether to enable ``Malloc Guard Edges``
in the Diagnostics section of the generated Xcode scheme.

This property is initialized by the value of the variable
:variable:`CMAKE_XCODE_SCHEME_MALLOC_GUARD_EDGES` if it is set
when a target is created.

Please refer to the :prop_tgt:`XCODE_GENERATE_SCHEME` target property
documentation to see all Xcode schema related properties.


code:
XCODE_SCHEME_MALLOC_SCRIBBLE
------------------------------

.. versionadded:: 3.13

Whether to enable ``Malloc Scribble``
in the Diagnostics section of the generated Xcode scheme.

This property is initialized by the value of the variable
:variable:`CMAKE_XCODE_SCHEME_MALLOC_SCRIBBLE` if it is set
when a target is created.

Please refer to the :prop_tgt:`XCODE_GENERATE_SCHEME` target property
documentation to see all Xcode schema related properties.


code:
XCODE_SCHEME_MALLOC_STACK
-------------------------

.. versionadded:: 3.13

Whether to enable ``Malloc Stack`` in the Diagnostics
section of the generated Xcode scheme.

This property is initialized by the value of the variable
:variable:`CMAKE_XCODE_SCHEME_MALLOC_STACK` if it is set
when a target is created.

Please refer to the :prop_tgt:`XCODE_GENERATE_SCHEME` target property
documentation to see all Xcode schema related properties.


code:
XCODE_SCHEME_THREAD_SANITIZER
-----------------------------

.. versionadded:: 3.13

Whether to enable ``Thread Sanitizer`` in the Diagnostics
section of the generated Xcode scheme.

This property is initialized by the value of the variable
:variable:`CMAKE_XCODE_SCHEME_THREAD_SANITIZER` if it is set
when a target is created.

Please refer to the :prop_tgt:`XCODE_GENERATE_SCHEME` target property
documentation to see all Xcode schema related properties.


code:
XCODE_SCHEME_THREAD_SANITIZER_STOP
----------------------------------

.. versionadded:: 3.13

Whether to enable ``Thread Sanitizer - Pause on issues``
in the Diagnostics section of the generated Xcode scheme.

This property is initialized by the value of the variable
:variable:`CMAKE_XCODE_SCHEME_THREAD_SANITIZER_STOP` if it is set
when a target is created.

Please refer to the :prop_tgt:`XCODE_GENERATE_SCHEME` target property
documentation to see all Xcode schema related properties.


code:
XCODE_SCHEME_UNDEFINED_BEHAVIOUR_SANITIZER
------------------------------------------

.. versionadded:: 3.13

Whether to enable ``Undefined Behavior Sanitizer``
in the Diagnostics section of the generated Xcode scheme.

This property is initialized by the value of the variable
:variable:`CMAKE_XCODE_SCHEME_UNDEFINED_BEHAVIOUR_SANITIZER`
if it is set when a target is created.

Please refer to the :prop_tgt:`XCODE_GENERATE_SCHEME` target property
documentation to see all Xcode schema related properties.


code:
XCODE_SCHEME_UNDEFINED_BEHAVIOUR_SANITIZER_STOP
-----------------------------------------------

.. versionadded:: 3.13

Whether to enable ``Undefined Behavior Sanitizer`` option
``Pause on issues``
in the Diagnostics section of the generated Xcode scheme.

This property is initialized by the value of the variable
:variable:`CMAKE_XCODE_SCHEME_UNDEFINED_BEHAVIOUR_SANITIZER_STOP`
if it is set when a target is created.

Please refer to the :prop_tgt:`XCODE_GENERATE_SCHEME` target property
documentation to see all Xcode schema related properties.


code:
XCODE_SCHEME_WORKING_DIRECTORY
------------------------------

.. versionadded:: 3.17

Specify the ``Working Directory`` of the *Run* and *Profile*
actions in the generated Xcode scheme. In case the value contains
generator expressions those are evaluated.

This property is initialized by the value of the variable
:variable:`CMAKE_XCODE_SCHEME_WORKING_DIRECTORY` if it is set
when a target is created.

Please refer to the :prop_tgt:`XCODE_GENERATE_SCHEME` target property
documentation to see all Xcode schema related properties.


code:
XCODE_SCHEME_ZOMBIE_OBJECTS
------------------------------

.. versionadded:: 3.13

Whether to enable ``Zombie Objects``
in the Diagnostics section of the generated Xcode scheme.

This property is initialized by the value of the variable
:variable:`CMAKE_XCODE_SCHEME_ZOMBIE_OBJECTS` if it is set
when a target is created.

Please refer to the :prop_tgt:`XCODE_GENERATE_SCHEME` target property
documentation to see all Xcode schema related properties.


code:
XCODE_XCCONFIG
--------------

.. versionadded:: 3.24

If set, the :generator:`Xcode` generator will register the specified
file as a target-level XCConfig file. For global XCConfig files see
the :variable:`CMAKE_XCODE_XCCONFIG` variable.

This feature is intended to ease migration from native Xcode projects
to CMake projects.

Contents of ``XCODE_XCCONFIG`` may use
:manual:`generator expressions <cmake-generator-expressions(7)>`.


code:
XCTEST
------

.. versionadded:: 3.3

This target is a XCTest CFBundle on the Mac.

This property will usually get set via the :command:`xctest_add_bundle`
macro in :module:`FindXCTest` module.

If a module library target has this property set to true it will be
built as a CFBundle when built on the Mac.  It will have the directory
structure required for a CFBundle.

This property depends on :prop_tgt:`BUNDLE` to be effective.


code:
Output directory in which to build |XXX| target files.

This property specifies the directory into which |xxx| target files
should be built.  The property value may use
:manual:`generator expressions <cmake-generator-expressions(7)>`.
Multi-configuration generators (:ref:`Visual Studio <Visual Studio Generators>`,
:generator:`Xcode`, :generator:`Ninja Multi-Config`) append a
per-configuration subdirectory to the specified directory unless a generator
expression is used.

This property is initialized by the value of the
|CMAKE_XXX_OUTPUT_DIRECTORY| variable if it is set when a target is created.


code:
Output name for |XXX| target files.

This property specifies the base name for |xxx| target files.  It
overrides :prop_tgt:`OUTPUT_NAME` and :prop_tgt:`OUTPUT_NAME_<CONFIG>`
properties.


code:
CMake 3.0 Release Notes
***********************

.. only:: html

  .. contents::

Changes made since CMake 2.8.12 include the following.

Documentation Changes
=====================

* The CMake documentation has been converted to reStructuredText and
  now transforms via Sphinx (`<https://www.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:

  - :manual:`cmake-buildsystem(7)`
  - :manual:`cmake-commands(7)`, replacing ``cmakecommands(1)``
    and ``cmakecompat(1)``
  - :manual:`cmake-developer(7)`
  - :manual:`cmake-generator-expressions(7)`
  - :manual:`cmake-generators(7)`
  - :manual:`cmake-language(7)`
  - :manual:`cmake-modules(7)`, replacing ``cmakemodules(1)``
  - :manual:`cmake-packages(7)`
  - :manual:`cmake-policies(7)`, replacing ``cmakepolicies(1)``
  - :manual:`cmake-properties(7)`, replacing ``cmakeprops(1)``
  - :manual:`cmake-qt(7)`
  - :manual:`cmake-toolchains(7)`
  - :manual:`cmake-variables(7)`, replacing ``cmakevars(1)``

* Release notes for CMake 3.0.0 and above will now be included with
  the html documentation.

New Features
============

Syntax
------

* The CMake language has been extended with
  :ref:`Bracket Argument` and  :ref:`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 :generator:`CodeLite` extra generator is available
  for use with the Makefile or Ninja generators.

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

* The :generator:`Ninja` generator learned to use ``ninja`` job pools
  when specified by a new :prop_gbl:`JOB_POOLS` global property.

Commands
--------

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

* The :command:`export()` command learned a new ``EXPORT`` mode that
  retrieves the list of targets to export from an export set configured
  by the :command:`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 :command:`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
  :command:`include` the generated targets file later during project
  configuration because it will not be available.
  Use :ref:`Alias Targets` instead.  See policy :policy:`CMP0024`.

* The :command:`install(FILES)` command learned to support
  :manual:`generator expressions <cmake-generator-expressions(7)>`
  in the list of files.

* The :command:`project` command learned to set some version variables
  to values specified by the new ``VERSION`` option or to empty strings.
  See policy :policy:`CMP0048`.

* The :command:`string` command learned a new ``CONCAT`` mode.
  It is particularly useful in combination with the new
  :ref:`Bracket Argument` syntax.

* The :command:`unset` command learned a ``PARENT_SCOPE`` option
  matching that of the :command:`set` command.

* The :command:`include_external_msproject` command learned
  to handle non-C++ projects like ``.vbproj`` or ``.csproj``.

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

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

* The :command:`target_link_libraries` command now allows repeated use of
  the ``LINK_PUBLIC`` and ``LINK_PRIVATE`` keywords.

Variables
---------

* Variable :variable:`CMAKE_FIND_NO_INSTALL_PREFIX` has been
  introduced to tell CMake not to add the value of
  :variable:`CMAKE_INSTALL_PREFIX` to the
  :variable:`CMAKE_SYSTEM_PREFIX_PATH` variable by default.
  This is useful when building a project that installs some
  of its own dependencies to avoid finding files it is about
  to replace.

* Variable :variable:`CMAKE_STAGING_PREFIX` was introduced for use
  when cross-compiling to specify an installation prefix on the
  host system that differs from a :variable:`CMAKE_INSTALL_PREFIX`
  value meant for the target system.

* Variable :variable:`CMAKE_SYSROOT` was introduced to specify the
  toolchain SDK installation prefix, typically for cross-compiling.
  This is used to pass a ``--sysroot`` option to the compiler and
  as a prefix searched by ``find_*`` commands.

* Variable :variable:`CMAKE_<LANG>_COMPILER_TARGET` was introduced
  for use when cross-compiling to specify the target platform in the
  :ref:`toolchain file <Cross Compiling Toolchain>` specified by the
  :variable:`CMAKE_TOOLCHAIN_FILE` variable.
  This is used to pass an option such as ``--target=<triple>`` to some
  cross-compiling compiler drivers.

* Variable :variable:`CMAKE_MAP_IMPORTED_CONFIG_<CONFIG>` has been
  introduced to optionally initialize the
  :prop_tgt:`MAP_IMPORTED_CONFIG_<CONFIG>` target property.

Properties
----------

* The :prop_dir:`ADDITIONAL_MAKE_CLEAN_FILES` directory property
  learned to support
  :manual:`generator expressions <cmake-generator-expressions(7)>`.

* A new directory property :prop_dir:`CMAKE_CONFIGURE_DEPENDS`
  was introduced to allow projects to specify additional
  files on which the configuration process depends.  CMake will
  re-run at build time when one of these files is modified.
  Previously this was only possible to achieve by specifying
  such files as the input to a :command:`configure_file` command.

* A new :ref:`Qt AUTORCC` feature replaces the need to
  invoke ``qt4_add_resources()`` by allowing ``.qrc`` files to
  be listed as target sources.

* A new :ref:`Qt AUTOUIC` feature replaces the need to
  invoke ``qt4_wrap_ui()``.

* Test properties learned to support
  :manual:`generator expressions <cmake-generator-expressions(7)>`.
  This is useful to specify per-configuration values for test
  properties like :prop_test:`REQUIRED_FILES` and
  :prop_test:`WORKING_DIRECTORY`.

* A new :prop_test:`SKIP_RETURN_CODE` test property was introduced
  to tell :manual:`ctest(1)` to treat a particular test return code as
  if the test were not run.  This is useful for test drivers to report
  that certain test requirements were not available.

* New types of :ref:`Compatible Interface Properties` were introduced,
  namely the :prop_tgt:`COMPATIBLE_INTERFACE_NUMBER_MAX` and
  :prop_tgt:`COMPATIBLE_INTERFACE_NUMBER_MIN` for calculating numeric
  maximum and minimum values respectively.

Modules
-------

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

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

* The :module:`ExternalProject` function ``ExternalProject_Add``
  learned a new ``GIT_SUBMODULES`` option to specify a subset
  of available submodules to checkout.

* A new :module:`FindBacktrace` module has been added to support
  :command:`find_package(Backtrace)` calls.

* A new :module:`FindLua` module has been added to support
  :command:`find_package(Lua)` calls.

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

* The :module:`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 :module:`FindJava` and :module:`FindJNI` modules learned
  to use a ``JAVA_HOME`` CMake variable or environment variable,
  and then try ``/usr/libexec/java_home`` on OS X.

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

* A new :module:`CMakeFindDependencyMacro` module was introduced with
  a ``find_dependency`` macro to find transitive dependencies in
  a :manual:`package configuration file <cmake-packages(7)>`.  Such
  dependencies are omitted by the listing of the :module:`FeatureSummary`
  module.

* The :module:`FindQt4` module learned to create :ref:`Imported Targets`
  for Qt executables.  This helps disambiguate when using multiple
  :manual:`Qt versions <cmake-qt(7)>` in the same buildsystem.

* The :module:`FindRuby` module learned to search for Ruby 2.0 and 2.1.

Generator Expressions
---------------------

* New ``$<PLATFORM_ID>`` and ``$<PLATFORM_ID:...>``
  :manual:`generator expressions <cmake-generator-expressions(7)>`
  have been added.

* The ``$<CONFIG>``
  :manual:`generator expression <cmake-generator-expressions(7)>` now has
  a variant which takes no argument.  This is equivalent to the
  ``$<CONFIGURATION>`` expression.

* New ``$<UPPER_CASE:...>`` and ``$<LOWER_CASE:...>``
  :manual:`generator expressions <cmake-generator-expressions(7)>`
  generator expressions have been added.

* A new ``$<MAKE_C_IDENTIFIER:...>``
  :manual:`generator expression <cmake-generator-expressions(7)>` has
  been added.

Other
-----

* The :manual:`cmake(1)` ``-E`` option learned a new ``sleep`` command.

* The :manual:`ccmake(1)` dialog learned to honor the
  :prop_cache:`STRINGS` cache entry property to cycle through
  the enumerated list of possible values.

* The :manual:`cmake-gui(1)` dialog learned to remember window
  settings between sessions.

* The :manual:`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 :prop_tgt:`INTERFACE_INCLUDE_DIRECTORIES`
  target property of imported targets linked conditionally by a
  :manual:`generator expression <cmake-generator-expressions(7)>`
  were not checked for existence.  Now they are checked.
  See policy :policy:`CMP0027`.

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

* Build targets that specify themselves as a link dependency were
  silently accepted but are now diagnosed.  See :policy:`CMP0038`.

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

* The :command:`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 :policy:`CMP0040`.

* Relative paths in the :prop_tgt:`INTERFACE_INCLUDE_DIRECTORIES`
  target property used to be silently accepted if they contained a
  :manual:`generator expression <cmake-generator-expressions(7)>`
  but are now rejected.  See policy :policy:`CMP0041`.

* The :command:`get_target_property` command learned to reject calls
  specifying a non-existent target.  See policy :policy:`CMP0045`.

* The :command:`add_dependencies` command learned to reject calls
  specifying a dependency on a non-existent target.
  See policy :policy:`CMP0046`.

* Link dependency analysis learned to assume names containing ``::``
  refer to :ref:`Alias Targets` or :ref:`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 :policy:`CMP0028`.

* When the :command:`project` or :command:`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
  :variable:`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 :command:`add_library` or
  :command:`add_executable` command learned to reject items which
  require an undocumented extra layer of variable expansion.
  See policy :policy:`CMP0049`.

* Use of :command:`add_custom_command` undocumented ``SOURCE``
  signatures now results in an error.  See policy :policy:`CMP0050`.

Deprecated and Removed Features
===============================

* 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:

  - Policy :policy:`CMP0029` disallows :command:`subdir_depends`
  - Policy :policy:`CMP0030` disallows :command:`use_mangled_mesa`
  - Policy :policy:`CMP0031` disallows :command:`load_command`
  - Policy :policy:`CMP0032` disallows :command:`output_required_files`
  - Policy :policy:`CMP0033` disallows :command:`export_library_dependencies`
  - Policy :policy:`CMP0034` disallows :command:`utility_source`
  - Policy :policy:`CMP0035` disallows :command:`variable_requires`
  - Policy :policy:`CMP0036` disallows :command:`build_name`

* The :manual:`cmake(1)` ``-i`` wizard mode has been removed.
  Instead use an interactive dialog such as :manual:`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 :manual:`cmake(1)`
  ``--help-custom-modules`` option now produces a warning at runtime
  and generates a minimal document that reports the limitation.

* The :prop_dir:`COMPILE_DEFINITIONS_<CONFIG>` directory properties and the
  :prop_tgt:`COMPILE_DEFINITIONS_<CONFIG>` target properties have been
  deprecated.  Instead set the corresponding :prop_dir:`COMPILE_DEFINITIONS`
  directory property or :prop_tgt:`COMPILE_DEFINITIONS` target property and
  use :manual:`generator expressions <cmake-generator-expressions(7)>` like
  ``$<CONFIG:...>`` to specify per-configuration definitions.
  See policy :policy:`CMP0043`.

* The :prop_tgt:`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 :policy:`CMP0026`.

* The :prop_tgt:`COMPILE_FLAGS` target property is now documented
  as deprecated, though no warning is issued.  Use the
  :prop_tgt:`COMPILE_OPTIONS` target property or the
  :command:`target_compile_options` command instead.

* The :module:`GenerateExportHeader` module ``add_compiler_export_flags``
  function is now deprecated.  It has been superseded by the
  :prop_tgt:`<LANG>_VISIBILITY_PRESET` and
  :prop_tgt:`VISIBILITY_INLINES_HIDDEN` target properties.

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 :variable:`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:

  - ``Visual Studio 10`` -> :generator:`Visual Studio 10 2010`
  - ``Visual Studio 11`` -> :generator:`Visual Studio 11 2012`
  - ``Visual Studio 12`` -> :generator:`Visual Studio 12 2013`

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

* The :variable:`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 :policy:`CMP0025`.

* The :variable:`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 :policy:`CMP0047`.

* On 64-bit OS X the :variable:`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
  :prop_tgt:`MACOSX_RPATH` target property by default.  This activates
  use of ``@rpath`` for runtime shared library searches.
  See policy :policy:`CMP0042`.

* The :command:`build_command` command now returns a :manual:`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 :variable:`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 :manual:`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:...>``
  :manual:`generator expressions <cmake-generator-expressions(7)>`
  used to perform case-insensitive comparison but have now been
  corrected to perform case-sensitive comparison.
  See policy :policy:`CMP0044`.

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

* The :module:`ExternalProject` download step learned to
  re-attempt download in certain cases to be more robust to
  temporary network failure.

* The :module:`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
  :prop_tgt:`INTERFACE_INCLUDE_DIRECTORIES` of :ref:`Imported Targets`
  are treated as ``SYSTEM`` includes by default when handled as
  :ref:`usage requirements <Include Directories and Usage Requirements>`.


code:
CMake 3.1 Release Notes
***********************

.. only:: html

  .. contents::

Changes made since CMake 3.0 include the following.

Documentation Changes
=====================

* A new :manual:`cmake-compile-features(7)` manual was added.

New Features
============

Generators
----------

* The :generator:`Visual Studio 14 2015` generator was added.

Windows Phone and Windows Store
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

* Generators for Visual Studio 11 (2012) and above learned to generate
  projects for Windows Phone and Windows Store.  One may set the
  :variable:`CMAKE_SYSTEM_NAME` variable to ``WindowsPhone``
  or ``WindowsStore`` on the :manual:`cmake(1)` command-line
  or in a :variable:`CMAKE_TOOLCHAIN_FILE` to activate these platforms.
  Also set :variable:`CMAKE_SYSTEM_VERSION` to ``8.0`` or ``8.1`` to
  specify the version of Windows to be targeted.

NVIDIA Nsight Tegra
^^^^^^^^^^^^^^^^^^^

* Generators for Visual Studio 10 (2010) and above learned to generate
  projects for NVIDIA Nsight Tegra Visual Studio Edition.  One may set
  the :variable:`CMAKE_SYSTEM_NAME` variable to ``Android`` on the
  :manual:`cmake(1)` command-line or in a :variable:`CMAKE_TOOLCHAIN_FILE`
  to activate this platform.

Syntax
------

* The :manual:`cmake-language(7)` syntax for :ref:`Variable References` and
  :ref:`Escape Sequences` was simplified in order to allow a much faster
  implementation.  See policy :policy:`CMP0053`.

* The :command:`if` command no longer automatically dereferences
  variables named in quoted or bracket arguments.  See policy
  :policy:`CMP0054`.

Commands
--------

* The :command:`add_custom_command` command learned to interpret
  :manual:`cmake-generator-expressions(7)` in arguments to ``DEPENDS``.

* The :command:`export(PACKAGE)` command learned to check the
  :variable:`CMAKE_EXPORT_NO_PACKAGE_REGISTRY` variable to skip
  exporting the package.

* The :command:`file(STRINGS)` command gained a new ``ENCODING``
  option to enable extraction of ``UTF-8`` strings.

* The :command:`find_package` command learned to check the
  :variable:`CMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY` and
  :variable:`CMAKE_FIND_PACKAGE_NO_SYSTEM_PACKAGE_REGISTRY`
  variables to skip searching the package registries.

* The :command:`get_property` command learned a new ``INSTALL`` scope
  for properties.

* The :command:`install` command learned a ``MESSAGE_NEVER`` option
  to avoid output during installation.

* The :command:`set_property` command learned a new ``INSTALL`` scope
  for properties.

* The :command:`string` command learned a new ``GENEX_STRIP`` subcommand
  which removes
  :manual:`generator expression <cmake-generator-expressions(7)>`.

* The :command:`string` command learned a new ``UUID`` subcommand
  to generate a universally unique identifier.

* New :command:`target_compile_features` command allows populating the
  :prop_tgt:`COMPILE_FEATURES` target property, just like any other
  build variable.

* The :command:`target_sources` command was added to add to the
  :prop_tgt:`SOURCES` target property.

Variables
---------

* The Visual Studio generators for versions 8 (2005) and above
  learned to read the target platform name from a new
  :variable:`CMAKE_GENERATOR_PLATFORM` variable when it is
  not specified as part of the generator name.  The platform
  name may be specified on the :manual:`cmake(1)` command line
  with the ``-A`` option, e.g. ``-G "Visual Studio 12 2013" -A x64``.

* The :variable:`CMAKE_GENERATOR_TOOLSET` variable may now be
  initialized in a toolchain file specified by the
  :variable:`CMAKE_TOOLCHAIN_FILE` variable.  This is useful
  when cross-compiling with the Xcode or Visual Studio
  generators.

* The :variable:`CMAKE_INSTALL_MESSAGE` variable was introduced to
  optionally reduce output installation.

Properties
----------

* New :prop_tgt:`CXX_STANDARD` and :prop_tgt:`CXX_EXTENSIONS` target
  properties may specify values which CMake uses to compute required
  compile options such as ``-std=c++11`` or ``-std=gnu++11``. The
  :variable:`CMAKE_CXX_STANDARD` and :variable:`CMAKE_CXX_EXTENSIONS`
  variables may be set to initialize the target properties.

* New :prop_tgt:`C_STANDARD` and :prop_tgt:`C_EXTENSIONS` target
  properties may specify values which CMake uses to compute required
  compile options such as ``-std=c11`` or ``-std=gnu11``. The
  :variable:`CMAKE_C_STANDARD` and :variable:`CMAKE_C_EXTENSIONS`
  variables may be set to initialize the target properties.

* New :prop_tgt:`COMPILE_FEATURES` target property may contain a list
  of features required to compile a target.  CMake uses this
  information to ensure that the compiler in use is capable of building
  the target, and to add any necessary compile flags to support language
  features.

* New :prop_tgt:`COMPILE_PDB_NAME` and
  :prop_tgt:`COMPILE_PDB_OUTPUT_DIRECTORY` target properties
  were introduced to specify the MSVC compiler program database
  file location (``cl /Fd``).  This complements the existing
  :prop_tgt:`PDB_NAME` and :prop_tgt:`PDB_OUTPUT_DIRECTORY`
  target properties that specify the linker program database
  file location (``link /pdb``).

* The :prop_tgt:`INTERFACE_LINK_LIBRARIES` target property now supports
  a ``$<LINK_ONLY:...>``
  :manual:`generator expression <cmake-generator-expressions(7)>`.

* A new :prop_tgt:`INTERFACE_SOURCES` target property was introduced. This is
  consumed by dependent targets, which compile and link the listed sources.

* The :prop_tgt:`SOURCES` target property now contains
  :manual:`generator expression <cmake-generator-expressions(7)>`
  such as ``TARGET_OBJECTS`` when read at configure time, if
  policy :policy:`CMP0051` is ``NEW``.

* The :prop_tgt:`SOURCES` target property now generally supports
  :manual:`generator expression <cmake-generator-expressions(7)>`.  The
  generator expressions may be used in the :command:`add_library` and
  :command:`add_executable` commands.

* It is now possible to write and append to the :prop_tgt:`SOURCES` target
  property.  The :variable:`CMAKE_DEBUG_TARGET_PROPERTIES` variable may be
  used to trace the origin of sources.

* A :prop_sf:`VS_DEPLOYMENT_CONTENT` source file property was added
  to tell the Visual Studio generators to mark content for deployment
  in Windows Phone and Windows Store projects.

* A :prop_sf:`VS_DEPLOYMENT_LOCATION` source file property was added
  to tell the Visual Studio generators the relative location of content
  marked for deployment in Windows Phone and Windows Store projects.

* The :prop_tgt:`VS_WINRT_COMPONENT` target property was created to
  tell Visual Studio generators to compile a shared library as a
  Windows Runtime (WinRT) component.

* The :generator:`Xcode` generator learned to check source
  file properties  :prop_sf:`XCODE_EXPLICIT_FILE_TYPE` and
  :prop_sf:`XCODE_LAST_KNOWN_FILE_TYPE` for a custom Xcode
  file reference type.

Modules
-------

* The :module:`BundleUtilities` module learned to resolve and replace
  ``@rpath`` placeholders on OS X to correctly bundle applications
  using them.

* The :module:`CMakePackageConfigHelpers` module
  :command:`configure_package_config_file` command learned a new
  ``INSTALL_PREFIX`` option to generate package configuration files
  meant for a prefix other than :variable:`CMAKE_INSTALL_PREFIX`.

* The :module:`CheckFortranSourceCompiles` module was added to
  provide a ``CHECK_Fortran_SOURCE_COMPILES`` macro.

* The :module:`ExternalData` module learned to tolerate a ``DATA{}``
  reference to a missing source file with a warning instead of
  rejecting it with an error.  This helps developers write new
  ``DATA{}`` references to test reference outputs that have not
  yet been created.

* The :module:`ExternalProject` module learned to support lzma-compressed
  source tarballs with ``.7z``, ``.tar.xz``, and ``.txz`` extensions.

* The :module:`ExternalProject` module ``ExternalProject_Add`` command
  learned a new ``BUILD_ALWAYS`` option to cause the external project
  build step to run every time the host project is built.

* The :module:`ExternalProject` module ``ExternalProject_Add`` command
  learned a new ``EXCLUDE_FROM_ALL`` option to cause the external
  project target to have the :prop_tgt:`EXCLUDE_FROM_ALL` target
  property set.

* The :module:`ExternalProject` module ``ExternalProject_Add_Step`` command
  learned a new ``EXCLUDE_FROM_MAIN`` option to cause the step to not be
  a direct dependency of the main external project target.

* The :module:`ExternalProject` module ``ExternalProject_Add`` command
  learned a new ``DOWNLOAD_NO_PROGRESS`` option to disable progress
  output while downloading the source tarball.

* The :module:`FeatureSummary` module ``feature_summary`` API
  learned to accept multiple values for the ``WHAT`` option and
  combine them appropriately.

* The :module:`FindCUDA` module learned to support ``fatbin`` and ``cubin``
  modules.

* The :module:`FindGTest` module ``gtest_add_tests`` macro learned
  a new ``AUTO`` option to automatically read the :prop_tgt:`SOURCES`
  target property of the test executable and scan the source files
  for tests to be added.

* The :module:`FindGLEW` module now provides imported targets.

* The :module:`FindGLUT` module now provides imported targets.

* The :module:`FindHg` module gained a new ``Hg_WC_INFO`` macro to
  help run ``hg`` to extract information about a Mercurial work copy.

* The :module:`FindOpenCL` module was introduced.

* The :module:`FindOpenMP` module learned to support Fortran.

* The :module:`FindPkgConfig` module learned to use the ``PKG_CONFIG``
  environment variable value as the ``pkg-config`` executable, if set.

* The :module:`FindXercesC` module was introduced.

* The :module:`FindZLIB` module now provides imported targets.

* The :module:`GenerateExportHeader` module ``generate_export_header``
  function learned to allow use with :ref:`Object Libraries`.

* The :module:`InstallRequiredSystemLibraries` module gained a new
  ``CMAKE_INSTALL_OPENMP_LIBRARIES`` option to install MSVC OpenMP
  runtime libraries.

* The :module:`UseSWIG` module learned to detect the module name
  from ``.i`` source files if possible to avoid the need to set
  the ``SWIG_MODULE_NAME`` source file property explicitly.

* The :module:`WriteCompilerDetectionHeader` module was added to allow
  creation of a portable header file for compiler optional feature detection.

Generator Expressions
---------------------

* New ``COMPILE_FEATURES``
  :manual:`generator expression <cmake-generator-expressions(7)>` allows
  setting build properties based on available compiler features.

CTest
-----

* The :command:`ctest_coverage` command learned to read variable
  ``CTEST_COVERAGE_EXTRA_FLAGS`` to set ``CoverageExtraFlags``.

* The :command:`ctest_coverage` command learned to support
  Intel coverage files with the ``codecov`` tool.

* The :command:`ctest_memcheck` command learned to support sanitizer
  modes, including ``AddressSanitizer``, ``MemorySanitizer``,
  ``ThreadSanitizer``, and ``UndefinedBehaviorSanitizer``.
  Options may be set using the new
  :variable:`CTEST_MEMORYCHECK_SANITIZER_OPTIONS` variable.

CPack
-----

* :manual:`cpack(1)` gained an ``IFW`` generator to package using
  Qt Framework Installer tools.  See the :cpack_gen:`CPack IFW Generator`.

* :manual:`cpack(1)` gained ``7Z`` and ``TXZ`` generators supporting
  lzma-compressed archives.

* The :cpack_gen:`CPack DEB Generator` learned a new
  :variable:`CPACK_DEBIAN_COMPRESSION_TYPE` variable to set the
  tarball compression type.

* The :cpack_gen:`CPack WIX Generator` learned to support
  a :prop_inst:`CPACK_WIX_ACL` installed file property to
  specify an Access Control List.

Other
-----

* The :manual:`cmake(1)` ``-E`` option learned a new ``env`` command.

* The :manual:`cmake(1)` ``-E tar`` command learned to support
  lzma-compressed files.

* :ref:`Object Libraries` may now have extra sources that do not
  compile to object files so long as they would not affect linking
  of a normal library (e.g. ``.dat`` is okay but not ``.def``).

* Visual Studio generators for VS 8 and later learned to support
  the ``ASM_MASM`` language.

* The Visual Studio generators learned to treat ``.hlsl`` source
  files as High Level Shading Language sources (using ``FXCompile``
  in ``.vcxproj`` files).  Source file properties
  :prop_sf:`VS_SHADER_TYPE`, :prop_sf:`VS_SHADER_MODEL`, and
  :prop_sf:`VS_SHADER_ENTRYPOINT` were added added to specify the
  shader type, model, and entry point name.

New Diagnostics
===============

* Policy :policy:`CMP0052` introduced to control directories in the
  :prop_tgt:`INTERFACE_INCLUDE_DIRECTORIES` of exported targets.

Deprecated and Removed Features
===============================

* In CMake 3.0 the :command:`target_link_libraries` command
  accidentally began allowing unquoted arguments to use
  :manual:`generator expressions <cmake-generator-expressions(7)>`
  containing a (``;`` separated) list within them.  For example::

    set(libs B C)
    target_link_libraries(A PUBLIC $<BUILD_INTERFACE:${libs}>)

  This is equivalent to writing::

    target_link_libraries(A PUBLIC $<BUILD_INTERFACE:B C>)

  and was never intended to work.  It did not work in CMake 2.8.12.
  Such generator expressions should be in quoted arguments::

    set(libs B C)
    target_link_libraries(A PUBLIC "$<BUILD_INTERFACE:${libs}>")

  CMake 3.1 again requires the quotes for this to work correctly.

* Prior to CMake 3.1 the Makefile generators did not escape ``#``
  correctly inside make variable assignments used in generated
  makefiles, causing them to be treated as comments.  This made
  code like::

    add_compile_options(-Wno-#pragma-messages)

  not work in Makefile generators, but work in other generators.
  Now it is escaped correctly, making the behavior consistent
  across generators.  However, some projects may have tried to
  workaround the original bug with code like::

    set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Wno-\\#pragma-messages")

  This added the needed escape for Makefile generators but also
  caused other generators to pass ``-Wno-\#pragma-messages`` to
  the shell, which would work only in POSIX shells.
  Unfortunately the escaping fix could not be made in a compatible
  way so this platform- and generator-specific workaround no
  longer works.  Project code may test the :variable:`CMAKE_VERSION`
  variable value to make the workaround version-specific too.

* Callbacks established by the :command:`variable_watch` command will no
  longer receive the ``ALLOWED_UNKNOWN_READ_ACCESS`` access type when
  the undocumented ``CMAKE_ALLOW_UNKNOWN_VARIABLE_READ_ACCESS`` variable is
  set.  Uninitialized variable accesses will always be reported as
  ``UNKNOWN_READ_ACCESS``.

* The :module:`CMakeDetermineVSServicePack` module now warns that
  it is deprecated and should not longer be used.  Use the
  :variable:`CMAKE_<LANG>_COMPILER_VERSION` variable instead.

* The :module:`FindITK` module has been removed altogether.
  It was a thin-wrapper around ``find_package(ITK ... NO_MODULE)``.
  This produces much clearer error messages when ITK is not found.

* The :module:`FindVTK` module has been removed altogether.
  It was a thin-wrapper around ``find_package(VTK ... NO_MODULE)``.
  This produces much clearer error messages when VTK is not found.

  The module also provided compatibility support for finding VTK 4.0.
  This capability has been dropped.

Other Changes
=============

* The :manual:`cmake-gui(1)` learned to capture output from child
  processes started by the :command:`execute_process` command
  and display it in the output window.

* The :manual:`cmake-language(7)` internal implementation of generator
  expression and list expansion parsers have been optimized and shows
  non-trivial speedup on large projects.

* The Makefile generators learned to use response files with GNU tools
  on Windows to pass library directories and names to the linker.

* When generating linker command-lines, CMake now avoids repeating
  items corresponding to SHARED library targets.

* Support for the Open Watcom compiler has been overhauled.
  The :variable:`CMAKE_<LANG>_COMPILER_ID` is now ``OpenWatcom``,
  and the :variable:`CMAKE_<LANG>_COMPILER_VERSION` now uses
  the Open Watcom external version numbering.  The external
  version numbers are lower than the internal version number
  by 11.

* The ``cmake-mode.el`` major Emacs editing mode no longer
  treats ``_`` as part of words, making it more consistent
  with other major modes.