-----BEGIN PGP SIGNATURE----- iQIcBAABCgAGBQJXgMI4AAoJEP4ixv2DE11FZM8P/jyc83o2r/k3wOcOoPUUxeCS cmk5TDTyrlloxtH9UQEduE+VzH896lehV/41SA29t+tRA+Pc6MpjDR+o9lIAX/WY dv2TMjcCCvNNCpsJwxJCBZqj1fjGU9SJlY0h0YLR79EoRY+XjdXl+6HIQAD+NNHL tlVTPqMyv4gNbYzIaiGfIz8fw1I0yJUzf6vs39yy9WwayoBnZlWY8slvZNBWVN2+ EogQTG9x3SwgXdFUSXmJVFwl0yPQu5nisviKlEEM56RoSj6lwwSS1rOIU8YMg8tp +kJ3edRJ6yXPLaYXL51kWdRvRe725MF1oayC/H4yFx1fkpRMgLltHqBSXUD9TI6Z rkkU5Y6kDlx/e/lQyGmcrO8miF1mhLQrJ99wgYYMvrKoE/qL9VmZZiDimxCkELCn BD8ensZ/yAtlNeR7qANXOj5Gt/mQNcfRTOnCEDJgWevM1s7viJR0/spwaxHvbIHC OMJskuRa4sTJRWo0uJyv4ntBJG5/sFpglGy+eDC0WnDUibGXJXVzpxvCCHQfQzfa SDG167PcrJ4l3X8pcR55p8lgH+tvYgIFFeP98/bzQMZt0P/0nJFq6yBqXp38ln7k a9fgdwYenD91jtUf1xNyzcL24hQpblweF0azrLcBp5UsGyHFaLi8tMopaZjioWLR YoOf6D2E2ISuiiqRaj4B =7Pbi -----END PGP SIGNATURE----- Merge tag 'upstream/3.6.0' into experimental Upstream version 3.6.0 # gpg: Signature made Sa 09 Jul 2016 11:22:00 CEST # gpg: using RSA key 0xFE22C6FD83135D45 # gpg: Good signature from "Felix Geyer <felix@fobos.de>" [ultimate] # gpg: aka "Felix Geyer <debfx-pkg@fobos.de>" [ultimate] # gpg: aka "Felix Geyer <debfx@kubuntu.org>" [ultimate] # gpg: aka "Felix Geyer <debfx@fobos.de>" [ultimate] # gpg: aka "Felix Geyer <debfx@ubuntu.com>" [ultimate] # gpg: aka "Felix Geyer <felix.geyer@fobos.de>" [ultimate] # gpg: aka "Felix Geyer <fgeyer@debian.org>" [ultimate] # Primary key fingerprint: 164C 7051 2F79 2947 6764 AB56 FE22 C6FD 8313 5D45ci/unstable
commit
288265a54d
@ -0,0 +1,9 @@
|
||||
---
|
||||
# This configuration requires clang-format 3.8 or higher.
|
||||
BasedOnStyle: Mozilla
|
||||
AlignOperands: false
|
||||
AlwaysBreakAfterReturnType: None
|
||||
AlwaysBreakAfterDefinitionReturnType: None
|
||||
ColumnLimit: 79
|
||||
Standard: Cpp03
|
||||
...
|
@ -1,10 +1,6 @@
|
||||
Visual Studio 6
|
||||
---------------
|
||||
|
||||
Deprected. Generates Visual Studio 6 project files.
|
||||
|
||||
.. note::
|
||||
This generator is deprecated and will be removed
|
||||
in a future version of CMake. It will still be
|
||||
possible to build with VS 6 tools using the
|
||||
:generator:`NMake Makefiles` generator.
|
||||
Removed. This once generated Visual Studio 6 project files, but the
|
||||
generator has been removed since CMake 3.6. It is still possible to
|
||||
build with VS 6 tools using the :generator:`NMake Makefiles` generator.
|
||||
|
@ -1,4 +1,10 @@
|
||||
Visual Studio 7 .NET 2003
|
||||
-------------------------
|
||||
|
||||
Generates Visual Studio .NET 2003 project files.
|
||||
Deprecated. Generates Visual Studio .NET 2003 project files.
|
||||
|
||||
.. note::
|
||||
This generator is deprecated and will be removed
|
||||
in a future version of CMake. It will still be
|
||||
possible to build with VS 7.1 tools using the
|
||||
:generator:`NMake Makefiles` generator.
|
||||
|
@ -1,10 +1,6 @@
|
||||
Visual Studio 7
|
||||
---------------
|
||||
|
||||
Deprected. Generates Visual Studio .NET 2002 project files.
|
||||
|
||||
.. note::
|
||||
This generator is deprecated and will be removed
|
||||
in a future version of CMake. It will still be
|
||||
possible to build with VS 7.0 tools using the
|
||||
:generator:`NMake Makefiles` generator.
|
||||
Removed. This once generated Visual Studio .NET 2002 project files, but
|
||||
the generator has been removed since CMake 3.6. It is still possible to
|
||||
build with VS 7.0 tools using the :generator:`NMake Makefiles` generator.
|
||||
|
@ -0,0 +1 @@
|
||||
.. cmake-module:: ../../Modules/FindLTTngUST.cmake
|
@ -0,0 +1,18 @@
|
||||
VS_STARTUP_PROJECT
|
||||
------------------
|
||||
|
||||
Specify the default startup project in a Visual Studio solution.
|
||||
|
||||
The :ref:`Visual Studio Generators` create a ``.sln`` file for each directory
|
||||
whose ``CMakeLists.txt`` file calls the :command:`project` command. Set this
|
||||
property in the same directory as a :command:`project` command call (e.g. in
|
||||
the top-level ``CMakeLists.txt`` file) to specify the default startup project
|
||||
for the correpsonding solution file.
|
||||
|
||||
The property must be set to the name of an existing target. This
|
||||
will cause that project to be listed first in the generated solution
|
||||
file causing Visual Studio to make it the startup project if the
|
||||
solution has never been opened before.
|
||||
|
||||
If this property is not specified, then the ``ALL_BUILD`` project
|
||||
will be the default.
|
@ -1,9 +1,10 @@
|
||||
FIND_LIBRARY_USE_LIB64_PATHS
|
||||
----------------------------
|
||||
|
||||
Whether FIND_LIBRARY should automatically search lib64 directories.
|
||||
Whether :command:`find_library` should automatically search lib64
|
||||
directories.
|
||||
|
||||
FIND_LIBRARY_USE_LIB64_PATHS is a boolean specifying whether the
|
||||
FIND_LIBRARY command should automatically search the lib64 variant of
|
||||
directories called lib in the search path when building 64-bit
|
||||
binaries.
|
||||
:command:`find_library` command should automatically search the lib64
|
||||
variant of directories called lib in the search path when building
|
||||
64-bit binaries.
|
||||
|
@ -1,9 +1,10 @@
|
||||
FIND_LIBRARY_USE_OPENBSD_VERSIONING
|
||||
-----------------------------------
|
||||
|
||||
Whether FIND_LIBRARY should find OpenBSD-style shared libraries.
|
||||
Whether :command:`find_library` should find OpenBSD-style shared
|
||||
libraries.
|
||||
|
||||
This property is a boolean specifying whether the FIND_LIBRARY command
|
||||
should find shared libraries with OpenBSD-style versioned extension:
|
||||
".so.<major>.<minor>". The property is set to true on OpenBSD and
|
||||
false on other platforms.
|
||||
This property is a boolean specifying whether the
|
||||
:command:`find_library` command should find shared libraries with
|
||||
OpenBSD-style versioned extension: ".so.<major>.<minor>". The
|
||||
property is set to true on OpenBSD and false on other platforms.
|
||||
|
@ -1,9 +1,10 @@
|
||||
USE_FOLDERS
|
||||
-----------
|
||||
|
||||
Use the FOLDER target property to organize targets into folders.
|
||||
Use the :prop_tgt:`FOLDER` target property to organize targets into
|
||||
folders.
|
||||
|
||||
If not set, CMake treats this property as OFF by default. CMake
|
||||
generators that are capable of organizing into a hierarchy of folders
|
||||
use the values of the FOLDER target property to name those folders.
|
||||
See also the documentation for the FOLDER target property.
|
||||
use the values of the :prop_tgt:`FOLDER` target property to name those
|
||||
folders. See also the documentation for the FOLDER target property.
|
||||
|
@ -0,0 +1,37 @@
|
||||
TIMEOUT_AFTER_MATCH
|
||||
-------------------
|
||||
|
||||
Change a test's timeout duration after a matching line is encountered
|
||||
in its output.
|
||||
|
||||
Usage
|
||||
^^^^^
|
||||
|
||||
.. code-block:: cmake
|
||||
|
||||
add_test(mytest ...)
|
||||
set_property(TEST mytest PROPERTY TIMEOUT_AFTER_MATCH "${seconds}" "${regex}")
|
||||
|
||||
Description
|
||||
^^^^^^^^^^^
|
||||
|
||||
Allow a test ``seconds`` to complete after ``regex`` is encountered in
|
||||
its output.
|
||||
|
||||
When the test outputs a line that matches ``regex`` its start time is
|
||||
reset to the current time and its timeout duration is changed to
|
||||
``seconds``. Prior to this, the timeout duration is determined by the
|
||||
:prop_test:`TIMEOUT` property or the :variable:`CTEST_TEST_TIMEOUT`
|
||||
variable if either of these are set.
|
||||
|
||||
:prop_test:`TIMEOUT_AFTER_MATCH` is useful for avoiding spurious
|
||||
timeouts when your test must wait for some system resource to become
|
||||
available before it can execute. Set :prop_test:`TIMEOUT` to a longer
|
||||
duration that accounts for resource acquisition and use
|
||||
:prop_test:`TIMEOUT_AFTER_MATCH` to control how long the actual test
|
||||
is allowed to run.
|
||||
|
||||
If the required resource can be controlled by CTest you should use
|
||||
:prop_test:`RESOURCE_LOCK` instead of :prop_test:`TIMEOUT_AFTER_MATCH`.
|
||||
This property should be used when only the test itself can determine
|
||||
when its required resources are available.
|
@ -1,6 +1,7 @@
|
||||
CROSSCOMPILING_EMULATOR
|
||||
-----------------------
|
||||
|
||||
Use the given emulator to run executables created when crosscompiling. This
|
||||
command will be added as a prefix to :command:`add_test` test commands for
|
||||
built target system executables.
|
||||
Use the given emulator to run executables created when crosscompiling.
|
||||
This command will be added as a prefix to :command:`add_test`,
|
||||
:command:`add_custom_command`, and :command:`add_custom_target` commands
|
||||
for built target system executables.
|
||||
|
@ -0,0 +1,18 @@
|
||||
DEPLOYMENT_REMOTE_DIRECTORY
|
||||
---------------------------
|
||||
|
||||
Set the WinCE project ``RemoteDirectory`` in ``DeploymentTool`` and
|
||||
``RemoteExecutable`` in ``DebuggerTool`` in ``.vcproj`` files generated
|
||||
by the :generator:`Visual Studio 9 2008` and :generator:`Visual Studio 8 2005`
|
||||
generators. This is useful when you want to debug on remote WinCE device.
|
||||
For example:
|
||||
|
||||
.. code-block:: cmake
|
||||
|
||||
set_property(TARGET ${TARGET} PROPERTY
|
||||
DEPLOYMENT_REMOTE_DIRECTORY "\\FlashStorage")
|
||||
|
||||
produces::
|
||||
|
||||
<DeploymentTool RemoteDirectory="\FlashStorage" ... />
|
||||
<DebuggerTool RemoteExecutable="\FlashStorage\target_file" ... />
|
@ -0,0 +1,13 @@
|
||||
<LANG>_CLANG_TIDY
|
||||
-----------------
|
||||
|
||||
This property is implemented only when ``<LANG>`` is ``C`` or ``CXX``.
|
||||
|
||||
Specify a :ref:`;-list <CMake Language Lists>` containing a command
|
||||
line for the ``clang-tidy`` tool. The :ref:`Makefile Generators`
|
||||
and the :generator:`Ninja` generator will run this tool along with the
|
||||
compiler and report a warning if the tool reports any problems.
|
||||
|
||||
This property is initialized by the value of
|
||||
the :variable:`CMAKE_<LANG>_CLANG_TIDY` variable if it is set
|
||||
when a target is created.
|
@ -0,0 +1,10 @@
|
||||
VS_CONFIGURATION_TYPE
|
||||
---------------------
|
||||
|
||||
Visual Studio project configuration type.
|
||||
|
||||
Sets the ``ConfigurationType`` attribute for a generated Visual Studio project.
|
||||
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.
|
@ -0,0 +1,310 @@
|
||||
CMake 3.6 Release Notes
|
||||
***********************
|
||||
|
||||
.. only:: html
|
||||
|
||||
.. contents::
|
||||
|
||||
Changes made since CMake 3.5 include the following.
|
||||
|
||||
New Features
|
||||
============
|
||||
|
||||
Generators
|
||||
----------
|
||||
|
||||
* The :generator:`Ninja` generator learned to produce phony targets
|
||||
of the form ``sub/dir/all`` to drive the build of a subdirectory.
|
||||
This is equivalent to ``cd sub/dir; make all`` with
|
||||
:ref:`Makefile Generators`.
|
||||
|
||||
* The :generator:`Ninja` generator now includes system header files in build
|
||||
dependencies to ensure correct re-builds when system packages are updated.
|
||||
|
||||
* The :generator:`Visual Studio 14 2015` generator learned to support the
|
||||
Clang/C2 toolsets, e.g. with the ``-T v140_clang_3_7`` option.
|
||||
This feature is experimental.
|
||||
|
||||
Commands
|
||||
--------
|
||||
|
||||
* The :command:`add_custom_command` and :command:`add_custom_target` commands
|
||||
learned how to use the :prop_tgt:`CROSSCOMPILING_EMULATOR` executable
|
||||
target property.
|
||||
|
||||
* The :command:`install` command learned a new ``EXCLUDE_FROM_ALL`` option
|
||||
to leave installation rules out of the default installation.
|
||||
|
||||
* The :command:`list` command gained a ``FILTER`` sub-command to filter
|
||||
list elements by regular expression.
|
||||
|
||||
* The :command:`string(TIMESTAMP)` and :command:`file(TIMESTAMP)`
|
||||
commands gained support for the ``%s`` placeholder. This is
|
||||
the number of seconds since the UNIX Epoch.
|
||||
|
||||
Variables
|
||||
---------
|
||||
|
||||
* A :variable:`CMAKE_DEPENDS_IN_PROJECT_ONLY` variable was introduced
|
||||
to tell :ref:`Makefile Generators` to limit dependency scanning only
|
||||
to files in the project source and build trees.
|
||||
|
||||
* A new :variable:`CMAKE_HOST_SOLARIS` variable was introduced to
|
||||
indicate when CMake is running on an Oracle Solaris host.
|
||||
|
||||
* A :variable:`CMAKE_<LANG>_STANDARD_INCLUDE_DIRECTORIES` variable was
|
||||
added for use by toolchain files to specify system include directories
|
||||
to be appended to all compiler command lines.
|
||||
|
||||
* The :variable:`CMAKE_<LANG>_STANDARD_LIBRARIES` variable is now documented.
|
||||
It is intended for use by toolchain files to specify system libraries to be
|
||||
added to all linker command lines.
|
||||
|
||||
* A :variable:`CMAKE_NINJA_OUTPUT_PATH_PREFIX` variable was introduced
|
||||
to tell the :generator:`Ninja` generator to configure the generated
|
||||
``build.ninja`` file for use as a ``subninja``.
|
||||
|
||||
* A :variable:`CMAKE_TRY_COMPILE_PLATFORM_VARIABLES` variable was
|
||||
added for use by toolchain files to specify platform-specific
|
||||
variables that must be propagated by the :command:`try_compile`
|
||||
command into test projects.
|
||||
|
||||
* A :variable:`CMAKE_TRY_COMPILE_TARGET_TYPE` variable was added
|
||||
to optionally tell the :command:`try_compile` command to build
|
||||
a static library instead of an executable. This is useful for
|
||||
cross-compiling toolchains that cannot link binaries without
|
||||
custom flags or scripts.
|
||||
|
||||
Properties
|
||||
----------
|
||||
|
||||
* A :prop_tgt:`DEPLOYMENT_REMOTE_DIRECTORY` target property was introduced
|
||||
to tell the :generator:`Visual Studio 9 2008` and
|
||||
:generator:`Visual Studio 8 2005` generators to generate the "remote
|
||||
directory" for WinCE project deployment and debugger settings.
|
||||
|
||||
* A :prop_tgt:`<LANG>_CLANG_TIDY` target property and supporting
|
||||
:variable:`CMAKE_<LANG>_CLANG_TIDY` variable were introduced to tell the
|
||||
:ref:`Makefile Generators` and the :generator:`Ninja` generator to run
|
||||
``clang-tidy`` along with the compiler for ``C`` and ``CXX`` languages.
|
||||
|
||||
* A :prop_test:`TIMEOUT_AFTER_MATCH` test property was introduced to
|
||||
optionally tell CTest to enforce a secondary timeout after matching
|
||||
certain output from a test.
|
||||
|
||||
* A :prop_tgt:`VS_CONFIGURATION_TYPE` target property was introduced
|
||||
to specify a custom project file type for :ref:`Visual Studio Generators`
|
||||
supporting VS 2010 and above.
|
||||
|
||||
* A :prop_dir:`VS_STARTUP_PROJECT` directory property was introduced
|
||||
to specify for :ref:`Visual Studio Generators` the default startup
|
||||
project for generated solutions (``.sln`` files).
|
||||
|
||||
Modules
|
||||
-------
|
||||
|
||||
* The :module:`CMakePushCheckState` module now pushes/pops/resets the variable
|
||||
``CMAKE_EXTRA_INCLUDE_FILE`` used in :module:`CheckTypeSize`.
|
||||
|
||||
* The :module:`ExternalProject` module leared the ``GIT_SHALLOW 1``
|
||||
option to perform a shallow clone of a Git repository.
|
||||
|
||||
* The :module:`ExternalProject` module learned to initialize Git submodules
|
||||
recursively and also to initialize new submodules on updates. Use the
|
||||
``GIT_SUBMODULES`` option to restrict which submodules are initalized and
|
||||
updated.
|
||||
|
||||
* The :module:`ExternalProject` module leared the ``DOWNLOAD_NO_EXTRACT 1``
|
||||
argument to skip extracting the file that is downloaded (e.g., for
|
||||
self-extracting shell installers or ``.msi`` files).
|
||||
|
||||
* The :module:`ExternalProject` module now uses ``TLS_VERIFY`` when fetching
|
||||
from git repositories.
|
||||
|
||||
* The :module:`FindBLAS` and :module:`FindLAPACK` modules learned to
|
||||
support `OpenBLAS <http://www.openblas.net>`__.
|
||||
|
||||
* The :module:`FindCUDA` module learned to find the ``cublas_device`` library.
|
||||
|
||||
* The :module:`FindGTest` module ``gtest_add_tests`` function now causes
|
||||
CMake to automatically re-run when test sources change so that they
|
||||
can be re-scanned.
|
||||
|
||||
* The :module:`FindLTTngUST` module was introduced to find the LTTng-UST
|
||||
library.
|
||||
|
||||
* The :module:`FindPkgConfig` module learned to optionally create imported
|
||||
targets for the libraries it has found.
|
||||
|
||||
* The :module:`FindProtobuf` module learned to provide a ``Protobuf_VERSION``
|
||||
variable and check the version number requested in a :command:`find_package`
|
||||
call.
|
||||
|
||||
* The :module:`InstallRequiredSystemLibraries` module learned a new
|
||||
``CMAKE_INSTALL_UCRT_LIBRARIES`` option to enable app-local deployment
|
||||
of the Windows Universal CRT libraries with Visual Studio 2015.
|
||||
|
||||
Platforms
|
||||
---------
|
||||
|
||||
* The Clang compiler is now supported on CYGWIN.
|
||||
|
||||
* Support was added for the Bruce C Compiler with compiler id ``Bruce``.
|
||||
|
||||
CTest
|
||||
-----
|
||||
|
||||
* The :command:`ctest_update` command now looks at the
|
||||
:variable:`CTEST_GIT_INIT_SUBMODULES` variable to determine whether
|
||||
submodules should be updated or not before updating.
|
||||
|
||||
* The :command:`ctest_update` command will now synchronize submodules on an
|
||||
update. Updates which add submodules or change a submodule's URL will now be
|
||||
pulled properly.
|
||||
|
||||
CPack
|
||||
-----
|
||||
|
||||
* The :module:`CPackDeb` module learned how to handle ``$ORIGIN``
|
||||
in ``CMAKE_INSTALL_RPATH`` when :variable:`CPACK_DEBIAN_PACKAGE_SHLIBDEPS`
|
||||
is used for dependency auto detection.
|
||||
|
||||
* The :module:`CPackDeb` module learned how to generate ``DEBIAN/shlibs``
|
||||
contorl file when package contains shared libraries.
|
||||
|
||||
* The :module:`CPackDeb` module learned how to generate ``DEBIAN/postinst`` and
|
||||
``DEBIAN/postrm`` files if the package installs libraries in
|
||||
ldconfig-controlled locations (e.g. ``/lib/``, ``/usr/lib/``).
|
||||
|
||||
* The :module:`CPackDeb` module learned how to generate dependencies between
|
||||
Debian packages if multi-component setup is used and
|
||||
:variable:`CPACK_COMPONENT_<compName>_DEPENDS` variables are set.
|
||||
For backward compatibility this feature is disabled by default.
|
||||
See :variable:`CPACK_DEBIAN_ENABLE_COMPONENT_DEPENDS`.
|
||||
|
||||
* The :module:`CPackDeb` module learned how to set custom package file names
|
||||
including how to generate properly-named Debian packages::
|
||||
|
||||
<PackageName>_<VersionNumber>-<DebianRevisionNumber>_<DebianArchitecture>.deb
|
||||
|
||||
For backward compatibility this feature is disabled by default. See
|
||||
:variable:`CPACK_DEBIAN_FILE_NAME` and
|
||||
:variable:`CPACK_DEBIAN_<COMPONENT>_FILE_NAME`.
|
||||
|
||||
* The :module:`CPackDeb` module learned how to set the package release number
|
||||
(``DebianRevisionNumber`` in package file name when used in combination with
|
||||
``DEB-DEFAULT`` value set by :variable:`CPACK_DEBIAN_FILE_NAME`). See
|
||||
:variable:`CPACK_DEBIAN_PACKAGE_RELEASE`.
|
||||
|
||||
* The :module:`CPackDeb` module learned how to set the package architecture
|
||||
per-component. See :variable:`CPACK_DEBIAN_<COMPONENT>_PACKAGE_ARCHITECTURE`.
|
||||
|
||||
* The :module:`CPackDMG` module learned a new option to tell the CPack
|
||||
``DragNDrop`` generaor to skip the ``/Applications`` symlink.
|
||||
See the :variable:`CPACK_DMG_DISABLE_APPLICATIONS_SYMLINK` variable.
|
||||
|
||||
* The :module:`CPackIFW` module gained a new
|
||||
:command:`cpack_ifw_update_repository` command to update a QtIFW-specific
|
||||
repository from a remote repository.
|
||||
|
||||
* The :module:`CPackRPM` module learned how to set RPM ``dist`` tag as part of
|
||||
RPM ``Release:`` tag when enabled (mandatory on some Linux distributions for
|
||||
e.g. on Fedora).
|
||||
See :variable:`CPACK_RPM_PACKAGE_RELEASE_DIST`.
|
||||
|
||||
* The :module:`CPackRPM` module learned how to set default values for owning
|
||||
user/group and file/directory permissions of package content.
|
||||
See :variable:`CPACK_RPM_DEFAULT_USER`, :variable:`CPACK_RPM_DEFAULT_GROUP`,
|
||||
:variable:`CPACK_RPM_DEFAULT_FILE_PERMISSIONS`,
|
||||
:variable:`CPACK_RPM_DEFAULT_DIR_PERMISSIONS` and their per component
|
||||
counterparts.
|
||||
|
||||
* The :module:`CPackRPM` module learned how to set user defined package file
|
||||
names, how to specify that rpmbuild should decide on file name format as
|
||||
well as handling of multiple rpm packages generated by a single user defined
|
||||
spec file.
|
||||
See :variable:`CPACK_RPM_PACKAGE_NAME` and
|
||||
:variable:`CPACK_RPM_<component>_PACKAGE_NAME`.
|
||||
|
||||
* The :module:`CPackRPM` module learned how to correctly handle symlinks
|
||||
that are pointing outside generated packages.
|
||||
|
||||
Other
|
||||
-----
|
||||
|
||||
* The :manual:`Compile Features <cmake-compile-features(7)>` functionality
|
||||
is now aware of features supported by Intel C++ compilers versions 12.1
|
||||
through 16.0 on UNIX platforms.
|
||||
|
||||
Deprecated and Removed Features
|
||||
===============================
|
||||
|
||||
* The :module:`CMakeForceCompiler` module and its macros are now deprecated.
|
||||
See module documentation for an explanation.
|
||||
|
||||
* The :command:`find_library`, :command:`find_path`, and :command:`find_file`
|
||||
commands no longer search in installation prefixes derived from the ``PATH``
|
||||
environment variable on non-Windows platforms. This behavior was added in
|
||||
CMake 3.3 to support Windows hosts but has proven problematic on UNIX hosts.
|
||||
Users that keep some ``<prefix>/bin`` directories in the ``PATH`` just for
|
||||
their tools do not necessarily want any supporting ``<prefix>/lib``
|
||||
directories searched. One may set the ``CMAKE_PREFIX_PATH`` environment
|
||||
variable with a :ref:`;-list <CMake Language Lists>` of prefixes that are
|
||||
to be searched.
|
||||
|
||||
* The :generator:`Visual Studio 7 .NET 2003` generator is now
|
||||
deprecated and will be removed in a future version of CMake.
|
||||
|
||||
* The :generator:`Visual Studio 7` generator (for VS .NET 2002) has been
|
||||
removed. It had been deprecated since CMake 3.3.
|
||||
|
||||
* The :generator:`Visual Studio 6` generator has been removed.
|
||||
It had been deprecated since CMake 3.3.
|
||||
|
||||
Other Changes
|
||||
=============
|
||||
|
||||
* The precompiled OS X binary provided on ``cmake.org`` now requires
|
||||
OS X 10.7 or newer.
|
||||
|
||||
* On Linux and FreeBSD platforms, when building CMake itself from source and
|
||||
not using a system-provided libcurl, OpenSSL is now used by default if it is
|
||||
found on the system. This enables SSL/TLS support for commands supporting
|
||||
network communication via ``https``, such as :command:`file(DOWNLOAD)`,
|
||||
:command:`file(UPLOAD)`, and :command:`ctest_submit`.
|
||||
|
||||
* The :manual:`cmake(1)` ``--build`` command-line tool now rejects multiple
|
||||
``--target`` options with an error instead of silently ignoring all but the
|
||||
last one.
|
||||
|
||||
* :prop_tgt:`AUTOMOC` now diagnoses name collisions when multiple source
|
||||
files in different directories use ``#include <moc_foo.cpp>`` with the
|
||||
same name (because the generated ``moc_foo.cpp`` files would collide).
|
||||
|
||||
* The :module:`FindBISON` module ``BISON_TARGET`` macro now supports
|
||||
special characters by passing the ``VERBATIM`` option to internal
|
||||
:command:`add_custom_command` calls. This may break clients that
|
||||
added escaping manually to work around the bug.
|
||||
|
||||
* The :module:`FindFLEX` module ``FLEX_TARGET`` macro now supports
|
||||
special characters by passing the ``VERBATIM`` option to internal
|
||||
:command:`add_custom_command` calls. This may break clients that
|
||||
added escaping manually to work around the bug.
|
||||
|
||||
* The :module:`FindProtobuf` module input and output variables were all renamed
|
||||
from ``PROTOBUF_`` to ``Protobuf_`` for consistency with other find modules.
|
||||
Input variables of the old case will be honored if provided, and output
|
||||
variables of the old case are always provided.
|
||||
|
||||
* The :module:`CPackRPM` module now supports upper cased component
|
||||
names in per component CPackRPM specific variables.
|
||||
E.g. component named ``foo`` now expects component specific
|
||||
variable to be ``CPACK_RPM_FOO_PACKAGE_NAME`` while before
|
||||
it expected ``CPACK_RPM_foo_PACKAGE_NAME``.
|
||||
Upper cased component name part in variables is compatible
|
||||
with convention used for other CPack variables.
|
||||
For back compatibility old format of variables is still valid
|
||||
and preferred if both versions of variable are set, but the
|
||||
preferred future use is upper cased component names in variables.
|
||||
New variables that will be added to CPackRPM in later versions
|
||||
will only support upper cased component variable format.
|
@ -0,0 +1,10 @@
|
||||
CMAKE_DEPENDS_IN_PROJECT_ONLY
|
||||
-----------------------------
|
||||
|
||||
When set to ``TRUE`` in a directory, the build system produced by the
|
||||
:ref:`Makefile Generators` is set up to only consider dependencies on source
|
||||
files that appear either in the source or in the binary directories. Changes
|
||||
to source files outside of these directories will not cause rebuilds.
|
||||
|
||||
This should be used carefully in cases where some source files are picked up
|
||||
through external headers during the build.
|
@ -0,0 +1,10 @@
|
||||
CMAKE_ECLIPSE_GENERATE_LINKED_RESOURCES
|
||||
---------------------------------------
|
||||
|
||||
This cache variable is used by the Eclipse project generator. See
|
||||
:manual:`cmake-generators(7)`.
|
||||
|
||||
The Eclipse project generator generates so-called linked resources
|
||||
e.g. to the subproject root dirs in the source tree or to the source files
|
||||
of targets.
|
||||
This can be disabled by setting this variable to FALSE.
|
@ -0,0 +1,11 @@
|
||||
CMAKE_ECLIPSE_GENERATE_SOURCE_PROJECT
|
||||
-------------------------------------
|
||||
|
||||
This cache variable is used by the Eclipse project generator. See
|
||||
:manual:`cmake-generators(7)`.
|
||||
|
||||
If this variable is set to TRUE, the Eclipse project generator will generate
|
||||
an Eclipse project in :variable:`CMAKE_SOURCE_DIR` . This project can then
|
||||
be used in Eclipse e.g. for the version control functionality.
|
||||
:variable:`CMAKE_ECLIPSE_GENERATE_SOURCE_PROJECT` defaults to FALSE; so
|
||||
nothing is written into the source directory.
|
@ -0,0 +1,9 @@
|
||||
CMAKE_ECLIPSE_MAKE_ARGUMENTS
|
||||
----------------------------
|
||||
|
||||
This cache variable is used by the Eclipse project generator. See
|
||||
:manual:`cmake-generators(7)`.
|
||||
|
||||
This variable holds arguments which are used when Eclipse invokes the make
|
||||
tool. By default it is initialized to hold flags to enable parallel builds
|
||||
(using -j typically).
|
@ -0,0 +1,10 @@
|
||||
CMAKE_ECLIPSE_VERSION
|
||||
---------------------
|
||||
|
||||
This cache variable is used by the Eclipse project generator. See
|
||||
:manual:`cmake-generators(7)`.
|
||||
|
||||
When using the Eclipse project generator, CMake tries to find the Eclipse
|
||||
executable and detect the version of it. Depending on the version it finds,
|
||||
some features are enabled or disabled. If CMake doesn't find
|
||||
Eclipse, it assumes the oldest supported version, Eclipse Callisto (3.2).
|
@ -0,0 +1,6 @@
|
||||
CMAKE_HOST_SOLARIS
|
||||
------------------
|
||||
|
||||
``True`` for Oracle Solaris operating systems.
|
||||
|
||||
Set to ``true`` when the host system is Oracle Solaris.
|
@ -0,0 +1,6 @@
|
||||
CMAKE_<LANG>_CLANG_TIDY
|
||||
-----------------------
|
||||
|
||||
Default value for :prop_tgt:`<LANG>_CLANG_TIDY` target property.
|
||||
This variable is used to initialize the property on each target as it is
|
||||
created. This is done only when ``<LANG>`` is ``C`` or ``CXX``.
|
@ -0,0 +1,14 @@
|
||||
CMAKE_<LANG>_STANDARD_INCLUDE_DIRECTORIES
|
||||
-----------------------------------------
|
||||
|
||||
Include directories to be used for every source file compiled with
|
||||
the ``<LANG>`` compiler. This is meant for specification of system
|
||||
include directories needed by the language for the current platform.
|
||||
The directories always appear at the end of the include path passed
|
||||
to the compiler.
|
||||
|
||||
This variable should not be set by project code. It is meant to be set by
|
||||
CMake's platform information modules for the current toolchain, or by a
|
||||
toolchain file when used with :variable:`CMAKE_TOOLCHAIN_FILE`.
|
||||
|
||||
See also :variable:`CMAKE_<LANG>_STANDARD_LIBRARIES`.
|
@ -0,0 +1,12 @@
|
||||
CMAKE_<LANG>_STANDARD_LIBRARIES
|
||||
-------------------------------
|
||||
|
||||
Libraries linked into every executable and shared library linked
|
||||
for language ``<LANG>``. This is meant for specification of system
|
||||
libraries needed by the language for the current platform.
|
||||
|
||||
This variable should not be set by project code. It is meant to be set by
|
||||
CMake's platform information modules for the current toolchain, or by a
|
||||
toolchain file when used with :variable:`CMAKE_TOOLCHAIN_FILE`.
|
||||
|
||||
See also :variable:`CMAKE_<LANG>_STANDARD_INCLUDE_DIRECTORIES`.
|
@ -0,0 +1,27 @@
|
||||
CMAKE_NINJA_OUTPUT_PATH_PREFIX
|
||||
------------------------------
|
||||
|
||||
Set output files path prefix for the :generator:`Ninja` generator.
|
||||
|
||||
Every output files listed in the generated ``build.ninja`` will be
|
||||
prefixed by the contents of this variable (a trailing slash is
|
||||
appended if missing). This is useful when the generated ninja file is
|
||||
meant to be embedded as a ``subninja`` file into a *super* ninja
|
||||
project. For example, a ninja build file generated with a command
|
||||
like::
|
||||
|
||||
cd top-build-dir/sub &&
|
||||
cmake -G Ninja -DCMAKE_NINJA_OUTPUT_PATH_PREFIX=sub/ path/to/source
|
||||
|
||||
can be embedded in ``top-build-dir/build.ninja`` with a directive like
|
||||
this::
|
||||
|
||||
subninja sub/build.ninja
|
||||
|
||||
The ``auto-regeneration`` rule in ``top-build-dir/build.ninja`` must have an
|
||||
order-only dependency on ``sub/build.ninja``.
|
||||
|
||||
.. note::
|
||||
When ``CMAKE_NINJA_OUTPUT_PATH_PREFIX`` is set, the project generated
|
||||
by CMake cannot be used as a standalone project. No default targets
|
||||
are specified.
|
@ -1,7 +0,0 @@
|
||||
CMAKE_STANDARD_LIBRARIES
|
||||
------------------------
|
||||
|
||||
Libraries linked into every executable and shared library.
|
||||
|
||||
This is the list of libraries that are linked into all executables and
|
||||
libraries.
|
@ -0,0 +1,26 @@
|
||||
CMAKE_TRY_COMPILE_PLATFORM_VARIABLES
|
||||
------------------------------------
|
||||
|
||||
List of variables that the :command:`try_compile` command source file signature
|
||||
must propagate into the test project in order to target the same platform as
|
||||
the host project.
|
||||
|
||||
This variable should not be set by project code. It is meant to be set by
|
||||
CMake's platform information modules for the current toolchain, or by a
|
||||
toolchain file when used with :variable:`CMAKE_TOOLCHAIN_FILE`.
|
||||
|
||||
Variables meaningful to CMake, such as :variable:`CMAKE_<LANG>_FLAGS`, are
|
||||
propagated automatically. The ``CMAKE_TRY_COMPILE_PLATFORM_VARIABLES``
|
||||
variable may be set to pass custom variables meaningful to a toolchain file.
|
||||
For example, a toolchain file may contain:
|
||||
|
||||
.. code-block:: cmake
|
||||
|
||||
set(CMAKE_SYSTEM_NAME ...)
|
||||
set(CMAKE_TRY_COMPILE_PLATFORM_VARIABLES MY_CUSTOM_VARIABLE)
|
||||
# ... use MY_CUSTOM_VARIABLE ...
|
||||
|
||||
If a user passes ``-DMY_CUSTOM_VARIABLE=SomeValue`` to CMake then this
|
||||
setting will be made visible to the toolchain file both for the main
|
||||
project and for test projects generated by the :command:`try_compile`
|
||||
command source file signature.
|
@ -0,0 +1,15 @@
|
||||
CMAKE_TRY_COMPILE_TARGET_TYPE
|
||||
-----------------------------
|
||||
|
||||
Type of target generated for :command:`try_compile` calls using the
|
||||
source file signature. Valid values are:
|
||||
|
||||
``EXECUTABLE``
|
||||
Use :command:`add_executable` to name the source file in the
|
||||
generated project. This is the default if no value is given.
|
||||
|
||||
``STATIC_LIBRARY``
|
||||
Use :command:`add_library` with the ``STATIC`` option to name the
|
||||
source file in the generated project. This avoids running the
|
||||
linker and is intended for use with cross-compiling toolchains
|
||||
that cannot link without custom flags or linker scripts.
|
@ -1,10 +0,0 @@
|
||||
CMAKE_VS_MSDEV_COMMAND
|
||||
----------------------
|
||||
|
||||
The :generator:`Visual Studio 6` generator sets this variable to the
|
||||
``msdev.exe`` command installed with Visual Studio 6.
|
||||
|
||||
This variable is not defined by other generators even if ``msdev.exe``
|
||||
is installed on the computer.
|
||||
|
||||
See also the :variable:`CMAKE_MAKE_PROGRAM` variable.
|
@ -0,0 +1,5 @@
|
||||
CTEST_GIT_INIT_SUBMODULES
|
||||
-------------------------
|
||||
|
||||
Specify the CTest ``GITInitSubmodules`` setting
|
||||
in a :manual:`ctest(1)` dashboard client script.
|
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in new issue