Mario Lang
10 years ago
parent
7434651728
commit
75c6a19f8d
@ -1,3 +0,0 @@
|
|||||||
# This file is provided for compatibility with CMake 2.2 and lower.
|
|
||||||
# Just include the custom file by its new name.
|
|
||||||
INCLUDE("CTestCustom.cmake")
|
|
||||||
@ -1,121 +0,0 @@
|
|||||||
ExpectedBuilds: \
|
|
||||||
{andoria.kitware Linux-g++3.4-KDevelop} \
|
|
||||||
{andoria.kitware Linux-g++3.4-SVN} \
|
|
||||||
{DASH1.kitware Win32-nmake71} \
|
|
||||||
{DASH1.kitware Win32-vs71} \
|
|
||||||
{DASH1.kitware Win32-vs71Rel} \
|
|
||||||
{DASH1.kitware zRel24-Win32-nmake71} \
|
|
||||||
{DASH1.kitware zRel24-Win32-vs71} \
|
|
||||||
{DASH11.kitware zRel24-Win32-nmake71} \
|
|
||||||
{dash14.kitware Win32-bcc5.6} \
|
|
||||||
{dash14.kitware Win32-cygwin} \
|
|
||||||
{dash14.kitware Win32-mingw} \
|
|
||||||
{dash14.kitware zRel24-Win32-bcc5.6} \
|
|
||||||
{dash17.kitware Linux-g++4.0} \
|
|
||||||
{dash1win64.kitware Win64-vs80} \
|
|
||||||
{dash1win98.kitware Win32-vs60} \
|
|
||||||
{DASH2.kitware Win32-nmake70} \
|
|
||||||
{DASH2.kitware Win32-vs70} \
|
|
||||||
{DASH2.kitware Win32-vs70-InPlace} \
|
|
||||||
{DASH2.kitware zRel24-Win32-nmake70} \
|
|
||||||
{DASH2.kitware zRel24-Win32-vs70} \
|
|
||||||
{DASH3.kitware Win32-nmake60} \
|
|
||||||
{DASH3.kitware Win32-vs60} \
|
|
||||||
{DASH3.kitware zRel24-Win32-nmake60} \
|
|
||||||
{DASH3.kitware zRel24-Win32-vs60} \
|
|
||||||
{dash4.kitware Win32-bcc5.8} \
|
|
||||||
{DASH5.kitware Linux-gcc332-InPlace} \
|
|
||||||
{DASH5.kitware zRel24-Linix-gcc332} \
|
|
||||||
{DASH6.kitware zRel24-Linix-gcc332} \
|
|
||||||
{dash8.kitware Linux64-g++} \
|
|
||||||
{dash8.kitware Linux64-g++332} \
|
|
||||||
{dash8.kitware Linux64-g++341} \
|
|
||||||
{dash8.kitware zRel24-Linux64-g++} \
|
|
||||||
{dash8.kitware zRel24-Linux64-g++332} \
|
|
||||||
{dashmacmini1.kitware Darwin-Tiger-Xcode21} \
|
|
||||||
{dashmacmini1.kitware zRel24-Darwin-Tiger-g++} \
|
|
||||||
{dashmacmini2.kitware DarwinIntel-g++} \
|
|
||||||
{dashmacmini2.kitware DarwinIntel-Universal} \
|
|
||||||
{dashmacmini2.kitware Darwin-Tiger-Xcode21-univ} \
|
|
||||||
{dashmacmini3.kitware Darwin-LeopardIntel-g++} \
|
|
||||||
{dashmacmini3.kitware Darwin-LeopardIntel-Universal} \
|
|
||||||
{dashmacmini3.kitware Darwin-Leopard-Xcode21-univ} \
|
|
||||||
{dashsgi1.kitware IRIX32-CC} \
|
|
||||||
{dashsgi1.kitware IRIX64-CC} \
|
|
||||||
{dashsun1.kitware SunOS-CC} \
|
|
||||||
{dashsun1.kitware SunOS-CC-64} \
|
|
||||||
{dashsun1.kitware SunOS-gcc34-64} \
|
|
||||||
{destiny.kitware HP-UX-aCC} \
|
|
||||||
{destiny.kitware HP-UX-aCC-gmake} \
|
|
||||||
{devqnx.acfr.usyd.edu.au qnx-V3.3.5-gcc_ntox86} \
|
|
||||||
{grayson.kitware Win32-nmake80} \
|
|
||||||
{heart HP-UXia64-aCC} \
|
|
||||||
{hythloth.kitware Linux64-bullseye-cov} \
|
|
||||||
{hythloth.kitware Linux64-suncc-5.9} \
|
|
||||||
{hythloth.kitware Linux-nightly-win32-release} \
|
|
||||||
{insight.journal.kitware KWStyle} \
|
|
||||||
{iris.elemtech IRIX64-CC64-7.4} \
|
|
||||||
{iris.elemtech IRIX64-CC-7.4} \
|
|
||||||
{JET.kitware Linux-valgrind2} \
|
|
||||||
{krondor.kitware Darwin-c++} \
|
|
||||||
{krondor.kitware zRel24-Darwin-c++} \
|
|
||||||
{midworld.kitware DarwinG5-g++} \
|
|
||||||
{midworld.kitware DarwinG5-XCode15} \
|
|
||||||
{midworld.kitware zRel24-DarwinG5-g++} \
|
|
||||||
{pre.vision.cs.rpi.edu FreeBSD-CC-gmake} \
|
|
||||||
{pre.vision.cs.rpi.edu FreeBSD-CC-make} \
|
|
||||||
{RogueResearch3 Mac10.5-CMake-gcc-dbg-ppc} \
|
|
||||||
{RogueResearch3 Mac10.5-CMake-gcc-dbg-ppc64} \
|
|
||||||
{RogueResearch3 Mac10.5-CMake-gcc-rel-ppc} \
|
|
||||||
{RogueResearch3 Mac10.5-CMake-gcc-rel-ppc64} \
|
|
||||||
{RogueResearch3 Mac10.5-CMake-Xcode-dbg-ppc} \
|
|
||||||
{RogueResearch3 Mac10.5-CMake-Xcode-dbg-ppc64} \
|
|
||||||
{RogueResearch4 Mac10.5-CMake-gcc-dbg-i386} \
|
|
||||||
{RogueResearch4 Mac10.5-CMake-gcc-dbg-rosetta} \
|
|
||||||
{RogueResearch4 Mac10.5-CMake-gcc-rel-i386} \
|
|
||||||
{tick.rz.uni-augsburg.de LinuxPPC-g++3.3} \
|
|
||||||
{tick.rz.uni-augsburg.de LinuxPPC-g++3.4} \
|
|
||||||
{trinsic.kitware Win32-mingw} \
|
|
||||||
{r06n01.pbm.ihost.com AIX53-xlC} \
|
|
||||||
{r06n01.pbm.ihost.com zRel24-AIX53-xlC} \
|
|
||||||
{valhalla.kitware Win32-wcl386}
|
|
||||||
|
|
||||||
#{devqnx.acfr.usyd.edu.au qnx-V3.3.5-gcc_ntox86 } \
|
|
||||||
#{mr-orange.obtech.net gentoo-linux-x86\_64-gcc-4.0.2 } \
|
|
||||||
#{G5.Nfsnet.Org Darwin8.3-gcc4} \
|
|
||||||
|
|
||||||
# commas in names do not work for expected builds....
|
|
||||||
|
|
||||||
#{G4.Nfsnet.Org Darwin-c++} \
|
|
||||||
#{salmon.nlm.nih.gov Darwin8.7-gcc4} \
|
|
||||||
|
|
||||||
#{crd.ge.com Solaris-gcc343} \
|
|
||||||
#{crd.ge.com Linux-icc81} \
|
|
||||||
#{crd.ge.com Windows-bcc32} \
|
|
||||||
#{crd.ge.com Windows-nmake71} \
|
|
||||||
#{crd.ge.com Windows-nmake60} \
|
|
||||||
|
|
||||||
#{dash16.kitware Linux-g++4.0} \
|
|
||||||
#{styx Linuxia64-g++} \
|
|
||||||
#{crd.ge.com Cygwin-gcc344} \
|
|
||||||
#{valhalla.kitware Win32-bccRel} \
|
|
||||||
#{valhalla.kitware Win32-bcc} \
|
|
||||||
#{valhalla.kitware Win32-g++} \
|
|
||||||
#{valhalla.kitware Win32-nmake60} \
|
|
||||||
#{valhalla.kitware Win32-nmake70} \
|
|
||||||
#{valhalla.kitware Win32-vs60} \
|
|
||||||
#{valhalla.kitware Win32-vs70}
|
|
||||||
#{crd.ge.com FreeBSD-gcc321} \
|
|
||||||
#{crd.ge.com Linux-gcc320} \
|
|
||||||
|
|
||||||
#{cogattaca.kitware LinuxWin32-g++-Werror} \
|
|
||||||
#{cogattaca.kitware LinuxWin32-g++} \
|
|
||||||
|
|
||||||
#{dash8.kitware Win64-icl80} \
|
|
||||||
#{dash8.kitware zLRB-Win64-icl80} \
|
|
||||||
|
|
||||||
#{hythloth.kitware Linux-icc-8.1} \
|
|
||||||
|
|
||||||
CompressionMode: ALL
|
|
||||||
CompressionCommand: /bin/gzip
|
|
||||||
CompressionType: gzip
|
|
||||||
@ -0,0 +1,12 @@
|
|||||||
|
continue
|
||||||
|
--------
|
||||||
|
|
||||||
|
Continue to the top of enclosing foreach or while loop.
|
||||||
|
|
||||||
|
::
|
||||||
|
|
||||||
|
continue()
|
||||||
|
|
||||||
|
The ``continue`` command allows a cmake script to abort the rest of a block
|
||||||
|
in a :command:`foreach` or :command:`while` loop, and start at the top of
|
||||||
|
the next iteration. See also the :command:`break` command.
|
||||||
@ -1,16 +1,19 @@
|
|||||||
link_libraries
|
link_libraries
|
||||||
--------------
|
--------------
|
||||||
|
|
||||||
Deprecated. Use the target_link_libraries() command instead.
|
|
||||||
|
|
||||||
Link libraries to all targets added later.
|
Link libraries to all targets added later.
|
||||||
|
|
||||||
::
|
::
|
||||||
|
|
||||||
link_libraries(library1 <debug | optimized> library2 ...)
|
link_libraries([item1 [item2 [...]]]
|
||||||
|
[[debug|optimized|general] <item>] ...)
|
||||||
|
|
||||||
|
Specify libraries or flags to use when linking any targets created later in
|
||||||
|
the current directory or below by commands such as :command:`add_executable`
|
||||||
|
or :command:`add_library`. See the :command:`target_link_libraries` command
|
||||||
|
for meaning of arguments.
|
||||||
|
|
||||||
Specify a list of libraries to be linked into any following targets
|
.. note::
|
||||||
(typically added with the add_executable or add_library calls). This
|
The :command:`target_link_libraries` command should be preferred whenever
|
||||||
command is passed down to all subdirectories. The debug and optimized
|
possible. Library dependencies are chained automatically, so directory-wide
|
||||||
strings may be used to indicate that the next library listed is to be
|
specification of link libraries is rarely needed.
|
||||||
used only for that specific type of build.
|
|
||||||
|
|||||||
@ -0,0 +1,32 @@
|
|||||||
|
target_compile_features
|
||||||
|
-----------------------
|
||||||
|
|
||||||
|
Add expected compiler features to a target.
|
||||||
|
|
||||||
|
::
|
||||||
|
|
||||||
|
target_compile_features(<target> <PRIVATE|PUBLIC|INTERFACE> <feature> [...])
|
||||||
|
|
||||||
|
Specify compiler features required when compiling a given target. If the
|
||||||
|
feature is not listed in the :variable:`CMAKE_C_COMPILE_FEATURES` variable
|
||||||
|
or :variable:`CMAKE_CXX_COMPILE_FEATURES` variable,
|
||||||
|
then an error will be reported by CMake. If the use of the feature requires
|
||||||
|
an additional compiler flag, such as ``-std=gnu++11``, the flag will be added
|
||||||
|
automatically.
|
||||||
|
|
||||||
|
The ``INTERFACE``, ``PUBLIC`` and ``PRIVATE`` keywords are required to
|
||||||
|
specify the scope of the features. ``PRIVATE`` and ``PUBLIC`` items will
|
||||||
|
populate the :prop_tgt:`COMPILE_FEATURES` property of ``<target>``.
|
||||||
|
``PUBLIC`` and ``INTERFACE`` items will populate the
|
||||||
|
:prop_tgt:`INTERFACE_COMPILE_FEATURES` property of ``<target>``. Repeated
|
||||||
|
calls for the same ``<target>`` append items.
|
||||||
|
|
||||||
|
The named ``<target>`` must have been created by a command such as
|
||||||
|
:command:`add_executable` or :command:`add_library` and must not be
|
||||||
|
an ``IMPORTED`` target.
|
||||||
|
|
||||||
|
Arguments to ``target_compile_features`` may use "generator expressions"
|
||||||
|
with the syntax ``$<...>``.
|
||||||
|
See the :manual:`cmake-generator-expressions(7)` manual for available
|
||||||
|
expressions. See the :manual:`cmake-compile-features(7)` manual for
|
||||||
|
information on compile features.
|
||||||
@ -0,0 +1,32 @@
|
|||||||
|
target_sources
|
||||||
|
--------------
|
||||||
|
|
||||||
|
Add sources to a target.
|
||||||
|
|
||||||
|
::
|
||||||
|
|
||||||
|
target_sources(<target>
|
||||||
|
<INTERFACE|PUBLIC|PRIVATE> [items1...]
|
||||||
|
[<INTERFACE|PUBLIC|PRIVATE> [items2...] ...])
|
||||||
|
|
||||||
|
Specify sources to use when compiling a given target. The
|
||||||
|
named ``<target>`` must have been created by a command such as
|
||||||
|
:command:`add_executable` or :command:`add_library` and must not be an
|
||||||
|
:ref:`IMPORTED Target <Imported Targets>`.
|
||||||
|
|
||||||
|
The ``INTERFACE``, ``PUBLIC`` and ``PRIVATE`` keywords are required to
|
||||||
|
specify the scope of the following arguments. ``PRIVATE`` and ``PUBLIC``
|
||||||
|
items will populate the :prop_tgt:`SOURCES` property of
|
||||||
|
``<target>``. ``PUBLIC`` and ``INTERFACE`` items will populate the
|
||||||
|
:prop_tgt:`INTERFACE_SOURCES` property of ``<target>``. The
|
||||||
|
following arguments specify sources. Repeated calls for the same
|
||||||
|
``<target>`` append items in the order called.
|
||||||
|
|
||||||
|
Targets with :prop_tgt:`INTERFACE_SOURCES` may not be exported with the
|
||||||
|
:command:`export` or :command:`install(EXPORT)` commands. This limitation may be
|
||||||
|
lifted in a future version of CMake.
|
||||||
|
|
||||||
|
Arguments to ``target_sources`` 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.
|
||||||
@ -1,71 +1,100 @@
|
|||||||
try_compile
|
try_compile
|
||||||
-----------
|
-----------
|
||||||
|
|
||||||
|
.. only:: html
|
||||||
|
|
||||||
|
.. contents::
|
||||||
|
|
||||||
Try building some code.
|
Try building some code.
|
||||||
|
|
||||||
|
Try Compiling Whole Projects
|
||||||
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||||
|
|
||||||
::
|
::
|
||||||
|
|
||||||
try_compile(RESULT_VAR <bindir> <srcdir>
|
try_compile(RESULT_VAR <bindir> <srcdir>
|
||||||
<projectName> [targetName] [CMAKE_FLAGS flags...]
|
<projectName> [<targetName>] [CMAKE_FLAGS <flags>...]
|
||||||
[OUTPUT_VARIABLE <var>])
|
[OUTPUT_VARIABLE <var>])
|
||||||
|
|
||||||
Try building a project. In this form, srcdir should contain a
|
Try building a project. The success or failure of the ``try_compile``,
|
||||||
complete CMake project with a CMakeLists.txt file and all sources.
|
i.e. ``TRUE`` or ``FALSE`` respectively, is returned in ``RESULT_VAR``.
|
||||||
The bindir and srcdir will not be deleted after this command is run.
|
|
||||||
Specify targetName to build a specific target instead of the 'all' or
|
In this form, ``<srcdir>`` should contain a complete CMake project with a
|
||||||
'ALL_BUILD' target.
|
``CMakeLists.txt`` file and all sources. The ``<bindir>`` and ``<srcdir>``
|
||||||
|
will not be deleted after this command is run. Specify ``<targetName>`` to
|
||||||
|
build a specific target instead of the ``all`` or ``ALL_BUILD`` target. See
|
||||||
|
below for the meaning of other options.
|
||||||
|
|
||||||
|
Try Compiling Source Files
|
||||||
|
^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||||
|
|
||||||
::
|
::
|
||||||
|
|
||||||
try_compile(RESULT_VAR <bindir> <srcfile|SOURCES srcfile...>
|
try_compile(RESULT_VAR <bindir> <srcfile|SOURCES srcfile...>
|
||||||
[CMAKE_FLAGS flags...]
|
[CMAKE_FLAGS <flags>...]
|
||||||
[COMPILE_DEFINITIONS flags...]
|
[COMPILE_DEFINITIONS <defs>...]
|
||||||
[LINK_LIBRARIES libs...]
|
[LINK_LIBRARIES <libs>...]
|
||||||
[OUTPUT_VARIABLE <var>]
|
[OUTPUT_VARIABLE <var>]
|
||||||
[COPY_FILE <fileName> [COPY_FILE_ERROR <var>]])
|
[COPY_FILE <fileName> [COPY_FILE_ERROR <var>]])
|
||||||
|
|
||||||
Try building an executable from one or more source files. In this
|
Try building an executable from one or more source files. The success or
|
||||||
form the user need only supply one or more source files that include a
|
failure of the ``try_compile``, i.e. ``TRUE`` or ``FALSE`` respectively, is
|
||||||
definition for 'main'. CMake will create a CMakeLists.txt file to
|
returned in ``RESULT_VAR``.
|
||||||
build the source(s) as an executable. Specify COPY_FILE to get a copy
|
|
||||||
of the linked executable at the given fileName and optionally
|
|
||||||
COPY_FILE_ERROR to capture any error.
|
|
||||||
|
|
||||||
In this version all files in bindir/CMakeFiles/CMakeTmp will be
|
|
||||||
cleaned automatically. For debugging, --debug-trycompile can be
|
|
||||||
passed to cmake to avoid this clean. However, multiple sequential
|
|
||||||
try_compile operations reuse this single output directory. If you use
|
|
||||||
--debug-trycompile, you can only debug one try_compile call at a time.
|
|
||||||
The recommended procedure is to configure with cmake all the way
|
|
||||||
through once, then delete the cache entry associated with the
|
|
||||||
try_compile call of interest, and then re-run cmake again with
|
|
||||||
--debug-trycompile.
|
|
||||||
|
|
||||||
Some extra flags that can be included are, INCLUDE_DIRECTORIES,
|
|
||||||
LINK_DIRECTORIES, and LINK_LIBRARIES. COMPILE_DEFINITIONS are
|
|
||||||
-Ddefinition that will be passed to the compile line.
|
|
||||||
|
|
||||||
The srcfile signature also accepts a LINK_LIBRARIES argument which may
|
|
||||||
contain a list of libraries or IMPORTED targets which will be linked
|
|
||||||
to in the generated project. If LINK_LIBRARIES is specified as a
|
|
||||||
parameter to try_compile, then any LINK_LIBRARIES passed as
|
|
||||||
CMAKE_FLAGS will be ignored.
|
|
||||||
|
|
||||||
try_compile creates a CMakeList.txt file on the fly that looks like
|
|
||||||
this:
|
|
||||||
|
|
||||||
::
|
In this form the user need only supply one or more source files that include a
|
||||||
|
definition for ``main``. CMake will create a ``CMakeLists.txt`` file to build
|
||||||
|
the source(s) as an executable that looks something like this::
|
||||||
|
|
||||||
add_definitions( <expanded COMPILE_DEFINITIONS from calling cmake>)
|
add_definitions(<expanded COMPILE_DEFINITIONS from caller>)
|
||||||
include_directories(${INCLUDE_DIRECTORIES})
|
include_directories(${INCLUDE_DIRECTORIES})
|
||||||
link_directories(${LINK_DIRECTORIES})
|
link_directories(${LINK_DIRECTORIES})
|
||||||
add_executable(cmTryCompileExec sources)
|
add_executable(cmTryCompileExec <srcfile>...)
|
||||||
target_link_libraries(cmTryCompileExec ${LINK_LIBRARIES})
|
target_link_libraries(cmTryCompileExec ${LINK_LIBRARIES})
|
||||||
|
|
||||||
In both versions of the command, if OUTPUT_VARIABLE is specified, then
|
The options are:
|
||||||
the output from the build process is stored in the given variable.
|
|
||||||
The success or failure of the try_compile, i.e. TRUE or FALSE
|
``CMAKE_FLAGS <flags>...``
|
||||||
respectively, is returned in RESULT_VAR. CMAKE_FLAGS can be used to
|
Specify flags of the form ``-DVAR:TYPE=VALUE`` to be passed to
|
||||||
pass -DVAR:TYPE=VALUE flags to the cmake that is run during the build.
|
the ``cmake`` command-line used to drive the test build.
|
||||||
Set variable CMAKE_TRY_COMPILE_CONFIGURATION to choose a build
|
The above example shows how values for variables
|
||||||
configuration.
|
``INCLUDE_DIRECTORIES``, ``LINK_DIRECTORIES``, and ``LINK_LIBRARIES``
|
||||||
|
are used.
|
||||||
|
|
||||||
|
``COMPILE_DEFINITIONS <defs>...``
|
||||||
|
Specify ``-Ddefinition`` arguments to pass to ``add_definitions``
|
||||||
|
in the generated test project.
|
||||||
|
|
||||||
|
``COPY_FILE <fileName>``
|
||||||
|
Copy the linked executable to the given ``<fileName>``.
|
||||||
|
|
||||||
|
``COPY_FILE_ERROR <var>``
|
||||||
|
Use after ``COPY_FILE`` to capture into variable ``<var>`` any error
|
||||||
|
message encountered while trying to copy the file.
|
||||||
|
|
||||||
|
``LINK_LIBRARIES <libs>...``
|
||||||
|
Specify libraries to be linked in the generated project.
|
||||||
|
The list of libraries may refer to system libraries and to
|
||||||
|
:ref:`Imported Targets <Imported Targets>` from the calling project.
|
||||||
|
|
||||||
|
If this option is specified, any ``-DLINK_LIBRARIES=...`` value
|
||||||
|
given to the ``CMAKE_FLAGS`` option will be ignored.
|
||||||
|
|
||||||
|
``OUTPUT_VARIABLE <var>``
|
||||||
|
Store the output from the build process the given variable.
|
||||||
|
|
||||||
|
In this version all files in ``<bindir>/CMakeFiles/CMakeTmp`` will be
|
||||||
|
cleaned automatically. For debugging, ``--debug-trycompile`` can be
|
||||||
|
passed to ``cmake`` to avoid this clean. However, multiple sequential
|
||||||
|
``try_compile`` operations reuse this single output directory. If you use
|
||||||
|
``--debug-trycompile``, you can only debug one ``try_compile`` call at a time.
|
||||||
|
The recommended procedure is to protect all ``try_compile`` calls in your
|
||||||
|
project by ``if(NOT DEFINED RESULT_VAR)`` logic, configure with cmake
|
||||||
|
all the way through once, then delete the cache entry associated with
|
||||||
|
the try_compile call of interest, and then re-run cmake again with
|
||||||
|
``--debug-trycompile``.
|
||||||
|
|
||||||
|
Other Behavior Settings
|
||||||
|
^^^^^^^^^^^^^^^^^^^^^^^
|
||||||
|
|
||||||
|
Set the :variable:`CMAKE_TRY_COMPILE_CONFIGURATION` variable to choose
|
||||||
|
a build configuration.
|
||||||
|
|||||||
@ -1,52 +1,97 @@
|
|||||||
try_run
|
try_run
|
||||||
-------
|
-------
|
||||||
|
|
||||||
|
.. only:: html
|
||||||
|
|
||||||
|
.. contents::
|
||||||
|
|
||||||
Try compiling and then running some code.
|
Try compiling and then running some code.
|
||||||
|
|
||||||
|
Try Compiling and Running Source Files
|
||||||
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||||
|
|
||||||
::
|
::
|
||||||
|
|
||||||
try_run(RUN_RESULT_VAR COMPILE_RESULT_VAR
|
try_run(RUN_RESULT_VAR COMPILE_RESULT_VAR
|
||||||
bindir srcfile [CMAKE_FLAGS <Flags>]
|
bindir srcfile [CMAKE_FLAGS <flags>...]
|
||||||
[COMPILE_DEFINITIONS <flags>]
|
[COMPILE_DEFINITIONS <defs>...]
|
||||||
[COMPILE_OUTPUT_VARIABLE comp]
|
[LINK_LIBRARIES <libs>...]
|
||||||
[RUN_OUTPUT_VARIABLE run]
|
[COMPILE_OUTPUT_VARIABLE <var>]
|
||||||
[OUTPUT_VARIABLE var]
|
[RUN_OUTPUT_VARIABLE <var>]
|
||||||
[ARGS <arg1> <arg2>...])
|
[OUTPUT_VARIABLE <var>]
|
||||||
|
[ARGS <args>...])
|
||||||
Try compiling a srcfile. Return TRUE or FALSE for success or failure
|
|
||||||
in COMPILE_RESULT_VAR. Then if the compile succeeded, run the
|
Try compiling a ``<srcfile>``. Returns ``TRUE`` or ``FALSE`` for success
|
||||||
executable and return its exit code in RUN_RESULT_VAR. If the
|
or failure in ``COMPILE_RESULT_VAR``. If the compile succeeded, runs the
|
||||||
executable was built, but failed to run, then RUN_RESULT_VAR will be
|
executable and returns its exit code in ``RUN_RESULT_VAR``. If the
|
||||||
set to FAILED_TO_RUN. COMPILE_OUTPUT_VARIABLE specifies the variable
|
executable was built, but failed to run, then ``RUN_RESULT_VAR`` will be
|
||||||
where the output from the compile step goes. RUN_OUTPUT_VARIABLE
|
set to ``FAILED_TO_RUN``. See the :command:`try_compile` command for
|
||||||
specifies the variable where the output from the running executable
|
information on how the test project is constructed to build the source file.
|
||||||
goes.
|
|
||||||
|
The options are:
|
||||||
For compatibility reasons OUTPUT_VARIABLE is still supported, which
|
|
||||||
gives you the output from the compile and run step combined.
|
``CMAKE_FLAGS <flags>...``
|
||||||
|
Specify flags of the form ``-DVAR:TYPE=VALUE`` to be passed to
|
||||||
Cross compiling issues
|
the ``cmake`` command-line used to drive the test build.
|
||||||
|
The example in :command:`try_compile` shows how values for variables
|
||||||
|
``INCLUDE_DIRECTORIES``, ``LINK_DIRECTORIES``, and ``LINK_LIBRARIES``
|
||||||
|
are used.
|
||||||
|
|
||||||
|
``COMPILE_DEFINITIONS <defs>...``
|
||||||
|
Specify ``-Ddefinition`` arguments to pass to ``add_definitions``
|
||||||
|
in the generated test project.
|
||||||
|
|
||||||
|
``COMPILE_OUTPUT_VARIABLE <var>``
|
||||||
|
Report the compile step build output in a given variable.
|
||||||
|
|
||||||
|
``LINK_LIBRARIES <libs>...``
|
||||||
|
Specify libraries to be linked in the generated project.
|
||||||
|
The list of libraries may refer to system libraries and to
|
||||||
|
:ref:`Imported Targets <Imported Targets>` from the calling project.
|
||||||
|
|
||||||
|
If this option is specified, any ``-DLINK_LIBRARIES=...`` value
|
||||||
|
given to the ``CMAKE_FLAGS`` option will be ignored.
|
||||||
|
|
||||||
|
``OUTPUT_VARIABLE <var>``
|
||||||
|
Report the compile build output and the output from running the executable
|
||||||
|
in the given variable. This option exists for legacy reasons. Prefer
|
||||||
|
``COMPILE_OUTPUT_VARIABLE`` and ``RUN_OUTPUT_VARIABLE`` instead.
|
||||||
|
|
||||||
|
``RUN_OUTPUT_VARIABLE <var>``
|
||||||
|
Report the output from running the executable in a given variable.
|
||||||
|
|
||||||
|
Other Behavior Settings
|
||||||
|
^^^^^^^^^^^^^^^^^^^^^^^
|
||||||
|
|
||||||
|
Set the :variable:`CMAKE_TRY_COMPILE_CONFIGURATION` variable to choose
|
||||||
|
a build configuration.
|
||||||
|
|
||||||
|
Behavior when Cross Compiling
|
||||||
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||||
|
|
||||||
When cross compiling, the executable compiled in the first step
|
When cross compiling, the executable compiled in the first step
|
||||||
usually cannot be run on the build host. try_run() checks the
|
usually cannot be run on the build host. The ``try_run`` command checks
|
||||||
CMAKE_CROSSCOMPILING variable to detect whether CMake is in
|
the :variable:`CMAKE_CROSSCOMPILING` variable to detect whether CMake is in
|
||||||
crosscompiling mode. If that's the case, it will still try to compile
|
cross-compiling mode. If that is the case, it will still try to compile
|
||||||
the executable, but it will not try to run the executable. Instead it
|
the executable, but it will not try to run the executable. Instead it
|
||||||
will create cache variables which must be filled by the user or by
|
will create cache variables which must be filled by the user or by
|
||||||
presetting them in some CMake script file to the values the executable
|
presetting them in some CMake script file to the values the executable
|
||||||
would have produced if it had been run on its actual target platform.
|
would have produced if it had been run on its actual target platform.
|
||||||
These variables are RUN_RESULT_VAR (explanation see above) and if
|
These cache entries are:
|
||||||
RUN_OUTPUT_VARIABLE (or OUTPUT_VARIABLE) was used, an additional cache
|
|
||||||
variable RUN_RESULT_VAR__COMPILE_RESULT_VAR__TRYRUN_OUTPUT.This is
|
``<RUN_RESULT_VAR>``
|
||||||
intended to hold stdout and stderr from the executable.
|
Exit code if the executable were to be run on the target platform.
|
||||||
|
|
||||||
In order to make cross compiling your project easier, use try_run only
|
``<RUN_RESULT_VAR>__TRYRUN_OUTPUT``
|
||||||
if really required. If you use try_run, use RUN_OUTPUT_VARIABLE (or
|
Output from stdout and stderr if the executable were to be run on
|
||||||
OUTPUT_VARIABLE) only if really required. Using them will require
|
the target platform. This is created only if the
|
||||||
that when crosscompiling, the cache variables will have to be set
|
``RUN_OUTPUT_VARIABLE`` or ``OUTPUT_VARIABLE`` option was used.
|
||||||
manually to the output of the executable. You can also "guard" the
|
|
||||||
calls to try_run with if(CMAKE_CROSSCOMPILING) and provide an
|
In order to make cross compiling your project easier, use ``try_run``
|
||||||
easy-to-preset alternative for this case.
|
only if really required. If you use ``try_run``, use the
|
||||||
|
``RUN_OUTPUT_VARIABLE`` or ``OUTPUT_VARIABLE`` options only if really
|
||||||
Set variable CMAKE_TRY_COMPILE_CONFIGURATION to choose a build
|
required. Using them will require that when cross-compiling, the cache
|
||||||
configuration.
|
variables will have to be set manually to the output of the executable.
|
||||||
|
You can also "guard" the calls to ``try_run`` with an :command:`if`
|
||||||
|
block checking the :variable:`CMAKE_CROSSCOMPILING` variable and
|
||||||
|
provide an easy-to-preset alternative for this case.
|
||||||
|
|||||||
@ -1,7 +1,11 @@
|
|||||||
MSYS Makefiles
|
MSYS Makefiles
|
||||||
--------------
|
--------------
|
||||||
|
|
||||||
Generates MSYS makefiles.
|
Generates makefiles for use with MSYS ``make`` under the MSYS shell.
|
||||||
|
|
||||||
The makefiles use /bin/sh as the shell. They require msys to be
|
Use this generator in a MSYS shell prompt and using ``make`` as the build
|
||||||
installed on the machine.
|
tool. The generated makefiles use ``/bin/sh`` as the shell to launch build
|
||||||
|
rules. They are not compatible with a Windows command prompt.
|
||||||
|
|
||||||
|
To build under a Windows command prompt, use the
|
||||||
|
:generator:`MinGW Makefiles` generator.
|
||||||
|
|||||||
@ -1,7 +1,12 @@
|
|||||||
MinGW Makefiles
|
MinGW Makefiles
|
||||||
---------------
|
---------------
|
||||||
|
|
||||||
Generates a make file for use with mingw32-make.
|
Generates makefiles for use with ``mingw32-make`` under a Windows command
|
||||||
|
prompt.
|
||||||
|
|
||||||
The makefiles generated use cmd.exe as the shell. They do not require
|
Use this generator under a Windows command prompt with MinGW in the ``PATH``
|
||||||
msys or a unix shell.
|
and using ``mingw32-make`` as the build tool. The generated makefiles use
|
||||||
|
``cmd.exe`` as the shell to launch build rules. They are not compatible with
|
||||||
|
MSYS or a unix shell.
|
||||||
|
|
||||||
|
To build under the MSYS shell, use the :generator:`MSYS Makefiles` generator.
|
||||||
|
|||||||
@ -0,0 +1,16 @@
|
|||||||
|
Visual Studio 14 2015
|
||||||
|
---------------------
|
||||||
|
|
||||||
|
Generates Visual Studio 14 (VS 2015) project files.
|
||||||
|
|
||||||
|
The :variable:`CMAKE_GENERATOR_PLATFORM` variable may be set
|
||||||
|
to specify a target platform name.
|
||||||
|
|
||||||
|
For compatibility with CMake versions prior to 3.1, one may specify
|
||||||
|
a target platform name optionally at the end of this generator name:
|
||||||
|
|
||||||
|
``Visual Studio 14 2015 Win64``
|
||||||
|
Specify target platform ``x64``.
|
||||||
|
|
||||||
|
``Visual Studio 14 2015 ARM``
|
||||||
|
Specify target platform ``ARM``.
|
||||||
@ -0,0 +1,30 @@
|
|||||||
|
|
||||||
|
Note that it is not advisable to populate the ``INSTALL_INTERFACE`` of the
|
||||||
|
|INTERFACE_PROPERTY_LINK| of a target with paths for dependencies.
|
||||||
|
That would hard-code into installed packages the include directory paths
|
||||||
|
for dependencies **as found on the machine the package was made on**.
|
||||||
|
|
||||||
|
The ``INSTALL_INTERFACE`` of the |INTERFACE_PROPERTY_LINK| is only
|
||||||
|
suitable for specifying the required include directories of the target itself,
|
||||||
|
not its dependencies.
|
||||||
|
|
||||||
|
That is, code like this is incorrect for targets which will be used to
|
||||||
|
generate :manual:`cmake-packages(7)`:
|
||||||
|
|
||||||
|
.. code-block:: cmake
|
||||||
|
|
||||||
|
target_include_directories(mylib INTERFACE
|
||||||
|
$<INSTALL_INTERFACE:${Boost_INCLUDE_DIRS};${OtherDep_INCLUDE_DIRS}>
|
||||||
|
)
|
||||||
|
|
||||||
|
Dependencies must provide their own :ref:`IMPORTED targets <Imported Targets>`
|
||||||
|
which have their own |INTERFACE_PROPERTY_LINK| populated
|
||||||
|
appropriately. Those :ref:`IMPORTED targets <Imported Targets>` may then be
|
||||||
|
used with the :command:`target_link_libraries` command for ``mylib``.
|
||||||
|
|
||||||
|
That way, when a consumer uses the installed package, the
|
||||||
|
consumer will run the appropriate :command:`find_package` command to find
|
||||||
|
the dependencies on their own machine and populate the
|
||||||
|
:ref:`IMPORTED targets <Imported Targets>` with appropriate paths. See
|
||||||
|
:ref:`Creating Packages` for more. Note that many modules currently shipped
|
||||||
|
with CMake do not currently provide :ref:`IMPORTED targets <Imported Targets>`.
|
||||||
@ -0,0 +1,23 @@
|
|||||||
|
|
||||||
|
Note that it is not advisable to populate the
|
||||||
|
|INTERFACE_PROPERTY_LINK| of a target with paths for dependencies.
|
||||||
|
That would hard-code into installed packages the include directory paths
|
||||||
|
for dependencies **as found on the machine the package was made on**.
|
||||||
|
|
||||||
|
That is, code like this is incorrect for targets which will be used to
|
||||||
|
generate :manual:`cmake-packages(7)`:
|
||||||
|
|
||||||
|
.. code-block:: cmake
|
||||||
|
|
||||||
|
target_link_libraries(mylib INTERFACE
|
||||||
|
${Boost_LIBRARIES};${OtherDep_LIBRARIES}
|
||||||
|
)
|
||||||
|
|
||||||
|
Dependencies must provide their own :ref:`IMPORTED targets <Imported Targets>`
|
||||||
|
which have their own :prop_tgt:`IMPORTED_LOCATION` populated
|
||||||
|
appropriately. That way, when a consumer uses the installed package, the
|
||||||
|
consumer will run the appropriate :command:`find_package` command to find
|
||||||
|
the dependencies on their own machine and populate the
|
||||||
|
:ref:`IMPORTED targets <Imported Targets>` with appropriate paths. See
|
||||||
|
:ref:`Creating Packages` for more. Note that many modules currently shipped
|
||||||
|
with CMake do not currently provide :ref:`IMPORTED targets <Imported Targets>`.
|
||||||
@ -0,0 +1,297 @@
|
|||||||
|
.. cmake-manual-description: CMake Compile Features Reference
|
||||||
|
|
||||||
|
cmake-compile-features(7)
|
||||||
|
*************************
|
||||||
|
|
||||||
|
.. only:: html
|
||||||
|
|
||||||
|
.. contents::
|
||||||
|
|
||||||
|
Introduction
|
||||||
|
============
|
||||||
|
|
||||||
|
Project source code may depend on, or be conditional on, the availability
|
||||||
|
of certain features of the compiler. There are three use-cases which arise:
|
||||||
|
`Compile Feature Requirements`_, `Optional Compile Features`_
|
||||||
|
and `Conditional Compilation Options`_.
|
||||||
|
|
||||||
|
While features are typically specified in programming language standards,
|
||||||
|
CMake provides a primary user interface based on granular handling of
|
||||||
|
the features, not the language standard that introduced the feature.
|
||||||
|
|
||||||
|
The :prop_gbl:`CMAKE_C_KNOWN_FEATURES` and
|
||||||
|
:prop_gbl:`CMAKE_CXX_KNOWN_FEATURES` global properties contain all the
|
||||||
|
features known to CMake, regardless of compiler support for the feature.
|
||||||
|
The :variable:`CMAKE_C_COMPILE_FEATURES` and
|
||||||
|
:variable:`CMAKE_CXX_COMPILE_FEATURES` variables contain all features
|
||||||
|
CMake knows are known to the compiler, regardless of language standard
|
||||||
|
or compile flags needed to use them.
|
||||||
|
|
||||||
|
Features known to CMake are named mostly following the same convention
|
||||||
|
as the Clang feature test macros. The are some exceptions, such as
|
||||||
|
CMake using ``cxx_final`` and ``cxx_override`` instead of the single
|
||||||
|
``cxx_override_control`` used by Clang.
|
||||||
|
|
||||||
|
Compile Feature Requirements
|
||||||
|
============================
|
||||||
|
|
||||||
|
Compile feature requirements may be specified with the
|
||||||
|
:command:`target_compile_features` command. For example, if a target must
|
||||||
|
be compiled with compiler support for the
|
||||||
|
:prop_gbl:`cxx_constexpr <CMAKE_CXX_KNOWN_FEATURES>` feature:
|
||||||
|
|
||||||
|
.. code-block:: cmake
|
||||||
|
|
||||||
|
add_library(mylib requires_constexpr.cpp)
|
||||||
|
target_compile_features(mylib PRIVATE cxx_constexpr)
|
||||||
|
|
||||||
|
In processing the requirement for the ``cxx_constexpr`` feature,
|
||||||
|
:manual:`cmake(1)` will ensure that the in-use C++ compiler is capable
|
||||||
|
of the feature, and will add any necessary flags such as ``-std=gnu++11``
|
||||||
|
to the compile lines of C++ files in the ``mylib`` target. A
|
||||||
|
``FATAL_ERROR`` is issued if the compiler is not capable of the
|
||||||
|
feature.
|
||||||
|
|
||||||
|
The exact compile flags and language standard are deliberately not part
|
||||||
|
of the user interface for this use-case. CMake will compute the
|
||||||
|
appropriate compile flags to use by considering the features specified
|
||||||
|
for each target.
|
||||||
|
|
||||||
|
Such compile flags are added even if the compiler supports the
|
||||||
|
particular feature without the flag. For example, the GNU compiler
|
||||||
|
supports variadic templates (with a warning) even if ``-std=gnu++98`` is
|
||||||
|
used. CMake adds the ``-std=gnu++11`` flag if ``cxx_variadic_templates``
|
||||||
|
is specified as a requirement.
|
||||||
|
|
||||||
|
In the above example, ``mylib`` requires ``cxx_constexpr`` when it
|
||||||
|
is built itself, but consumers of ``mylib`` are not required to use a
|
||||||
|
compiler which supports ``cxx_constexpr``. If the interface of
|
||||||
|
``mylib`` does require the ``cxx_constexpr`` feature (or any other
|
||||||
|
known feature), that may be specified with the ``PUBLIC`` or
|
||||||
|
``INTERFACE`` signatures of :command:`target_compile_features`:
|
||||||
|
|
||||||
|
.. code-block:: cmake
|
||||||
|
|
||||||
|
add_library(mylib requires_constexpr.cpp)
|
||||||
|
# cxx_constexpr is a usage-requirement
|
||||||
|
target_compile_features(mylib PUBLIC cxx_constexpr)
|
||||||
|
|
||||||
|
# main.cpp will be compiled with -std=gnu++11 on GNU for cxx_constexpr.
|
||||||
|
add_executable(myexe main.cpp)
|
||||||
|
target_link_libraries(myexe mylib)
|
||||||
|
|
||||||
|
Feature requirements are evaluated transitively by consuming the link
|
||||||
|
implementation. See :manual:`cmake-buildsystem(7)` for more on
|
||||||
|
transitive behavior of build properties and usage requirements.
|
||||||
|
|
||||||
|
Because the :prop_tgt:`CXX_EXTENSIONS` target property is ``ON`` by default,
|
||||||
|
CMake uses extended variants of language dialects by default, such as
|
||||||
|
``-std=gnu++11`` instead of ``-std=c++11``. That target property may be
|
||||||
|
set to ``OFF`` to use the non-extended variant of the dialect flag. Note
|
||||||
|
that because most compilers enable extensions by default, this could
|
||||||
|
expose cross-platform bugs in user code or in the headers of third-party
|
||||||
|
dependencies.
|
||||||
|
|
||||||
|
Optional Compile Features
|
||||||
|
=========================
|
||||||
|
|
||||||
|
Compile features may be preferred if available, without creating a hard
|
||||||
|
requirement. For example, a library may provides alternative
|
||||||
|
implementations depending on whether the ``cxx_variadic_templates``
|
||||||
|
feature is available:
|
||||||
|
|
||||||
|
.. code-block:: c++
|
||||||
|
|
||||||
|
#if Foo_COMPILER_CXX_VARIADIC_TEMPLATES
|
||||||
|
template<int I, int... Is>
|
||||||
|
struct Interface;
|
||||||
|
|
||||||
|
template<int I>
|
||||||
|
struct Interface<I>
|
||||||
|
{
|
||||||
|
static int accumulate()
|
||||||
|
{
|
||||||
|
return I;
|
||||||
|
}
|
||||||
|
};
|
||||||
|
|
||||||
|
template<int I, int... Is>
|
||||||
|
struct Interface
|
||||||
|
{
|
||||||
|
static int accumulate()
|
||||||
|
{
|
||||||
|
return I + Interface<Is...>::accumulate();
|
||||||
|
}
|
||||||
|
};
|
||||||
|
#else
|
||||||
|
template<int I1, int I2 = 0, int I3 = 0, int I4 = 0>
|
||||||
|
struct Interface
|
||||||
|
{
|
||||||
|
static int accumulate() { return I1 + I2 + I3 + I4; }
|
||||||
|
};
|
||||||
|
#endif
|
||||||
|
|
||||||
|
Such an interface depends on using the correct preprocessor defines for the
|
||||||
|
compiler features. CMake can generate a header file containing such
|
||||||
|
defines using the :module:`WriteCompilerDetectionHeader` module. The
|
||||||
|
module contains the ``write_compiler_detection_header`` function which
|
||||||
|
accepts parameters to control the content of the generated header file:
|
||||||
|
|
||||||
|
.. code-block:: cmake
|
||||||
|
|
||||||
|
write_compiler_detection_header(
|
||||||
|
FILE "${CMAKE_CURRENT_BINARY_DIR}/foo_compiler_detection.h"
|
||||||
|
PREFIX Foo
|
||||||
|
COMPILERS GNU
|
||||||
|
FEATURES
|
||||||
|
cxx_variadic_templates
|
||||||
|
)
|
||||||
|
|
||||||
|
Such a header file may be used internally in the source code of a project,
|
||||||
|
and it may be installed and used in the interface of library code.
|
||||||
|
|
||||||
|
For each feature listed in ``FEATURES``, a preprocessor definition
|
||||||
|
is created in the header file, and defined to either ``1`` or ``0``.
|
||||||
|
|
||||||
|
Additionally, some features call for additional defines, such as the
|
||||||
|
``cxx_final`` and ``cxx_override`` features. Rather than being used in
|
||||||
|
``#ifdef`` code, the ``final`` keyword is abstracted by a symbol
|
||||||
|
which is defined to either ``final``, a compiler-specific equivalent, or
|
||||||
|
to empty. That way, C++ code can be written to unconditionally use the
|
||||||
|
symbol, and compiler support determines what it is expanded to:
|
||||||
|
|
||||||
|
.. code-block:: c++
|
||||||
|
|
||||||
|
struct Interface {
|
||||||
|
virtual void Execute() = 0;
|
||||||
|
};
|
||||||
|
|
||||||
|
struct Concrete Foo_FINAL {
|
||||||
|
void Execute() Foo_OVERRIDE;
|
||||||
|
};
|
||||||
|
|
||||||
|
In this case, ``Foo_FINAL`` will expand to ``final`` if the
|
||||||
|
compiler supports the keyword, or to empty otherwise.
|
||||||
|
|
||||||
|
In this use-case, the CMake code will wish to enable a particular language
|
||||||
|
standard if available from the compiler. The :prop_tgt:`CXX_STANDARD`
|
||||||
|
target property variable may be set to the desired language standard
|
||||||
|
for a particular target, and the :variable:`CMAKE_CXX_STANDARD` may be
|
||||||
|
set to influence all following targets:
|
||||||
|
|
||||||
|
.. code-block:: cmake
|
||||||
|
|
||||||
|
write_compiler_detection_header(
|
||||||
|
FILE "${CMAKE_CURRENT_BINARY_DIR}/foo_compiler_detection.h"
|
||||||
|
PREFIX Foo
|
||||||
|
COMPILERS GNU
|
||||||
|
FEATURES
|
||||||
|
cxx_final cxx_override
|
||||||
|
)
|
||||||
|
|
||||||
|
# Includes foo_compiler_detection.h and uses the Foo_FINAL symbol
|
||||||
|
# which will expand to 'final' if the compiler supports the requested
|
||||||
|
# CXX_STANDARD.
|
||||||
|
add_library(foo foo.cpp)
|
||||||
|
set_property(TARGET foo PROPERTY CXX_STANDARD 11)
|
||||||
|
|
||||||
|
# Includes foo_compiler_detection.h and uses the Foo_FINAL symbol
|
||||||
|
# which will expand to 'final' if the compiler supports the feature,
|
||||||
|
# even though CXX_STANDARD is not set explicitly. The requirement of
|
||||||
|
# cxx_constexpr causes CMake to set CXX_STANDARD internally, which
|
||||||
|
# affects the compile flags.
|
||||||
|
add_library(foo_impl foo_impl.cpp)
|
||||||
|
target_compile_features(foo_impl PRIVATE cxx_constexpr)
|
||||||
|
|
||||||
|
The ``write_compiler_detection_header`` function also creates compatibility
|
||||||
|
code for other features which have standard equivalents. For example, the
|
||||||
|
``cxx_static_assert`` feature is emulated with a template and abstracted
|
||||||
|
via the ``<PREFIX>_STATIC_ASSERT`` and ``<PREFIX>_STATIC_ASSERT_MSG``
|
||||||
|
function-macros.
|
||||||
|
|
||||||
|
Conditional Compilation Options
|
||||||
|
===============================
|
||||||
|
|
||||||
|
Libraries may provide entirely different header files depending on
|
||||||
|
requested compiler features.
|
||||||
|
|
||||||
|
For example, a header at ``with_variadics/interface.h`` may contain:
|
||||||
|
|
||||||
|
.. code-block:: c++
|
||||||
|
|
||||||
|
template<int I, int... Is>
|
||||||
|
struct Interface;
|
||||||
|
|
||||||
|
template<int I>
|
||||||
|
struct Interface<I>
|
||||||
|
{
|
||||||
|
static int accumulate()
|
||||||
|
{
|
||||||
|
return I;
|
||||||
|
}
|
||||||
|
};
|
||||||
|
|
||||||
|
template<int I, int... Is>
|
||||||
|
struct Interface
|
||||||
|
{
|
||||||
|
static int accumulate()
|
||||||
|
{
|
||||||
|
return I + Interface<Is...>::accumulate();
|
||||||
|
}
|
||||||
|
};
|
||||||
|
|
||||||
|
while a header at ``no_variadics/interface.h`` may contain:
|
||||||
|
|
||||||
|
.. code-block:: c++
|
||||||
|
|
||||||
|
template<int I1, int I2 = 0, int I3 = 0, int I4 = 0>
|
||||||
|
struct Interface
|
||||||
|
{
|
||||||
|
static int accumulate() { return I1 + I2 + I3 + I4; }
|
||||||
|
};
|
||||||
|
|
||||||
|
It would be possible to write a abstraction ``interface.h`` header
|
||||||
|
containing something like:
|
||||||
|
|
||||||
|
.. code-block:: c++
|
||||||
|
|
||||||
|
#include "foo_compiler_detection.h"
|
||||||
|
#if Foo_COMPILER_CXX_VARIADIC_TEMPLATES
|
||||||
|
#include "with_variadics/interface.h"
|
||||||
|
#else
|
||||||
|
#include "no_variadics/interface.h"
|
||||||
|
#endif
|
||||||
|
|
||||||
|
However this could be unmaintainable if there are many files to
|
||||||
|
abstract. What is needed is to use alternative include directories
|
||||||
|
depending on the compiler capabilities.
|
||||||
|
|
||||||
|
CMake provides a ``COMPILE_FEATURES``
|
||||||
|
:manual:`generator expression <cmake-generator-expressions(7)>` to implement
|
||||||
|
such conditions. This may be used with the build-property commands such as
|
||||||
|
:command:`target_include_directories` and :command:`target_link_libraries`
|
||||||
|
to set the appropriate :manual:`buildsystem <cmake-buildsystem(7)>`
|
||||||
|
properties:
|
||||||
|
|
||||||
|
.. code-block:: cmake
|
||||||
|
|
||||||
|
add_library(foo INTERFACE)
|
||||||
|
set(with_variadics ${CMAKE_CURRENT_SOURCE_DIR}/with_variadics)
|
||||||
|
set(no_variadics ${CMAKE_CURRENT_SOURCE_DIR}/no_variadics)
|
||||||
|
target_link_libraries(foo
|
||||||
|
INTERFACE
|
||||||
|
"$<$<COMPILE_FEATURES:cxx_variadic_templates>:${with_variadics}>"
|
||||||
|
"$<$<NOT:$<COMPILE_FEATURES:cxx_variadic_templates>>:${no_variadics}>"
|
||||||
|
)
|
||||||
|
|
||||||
|
Consuming code then simply links to the ``foo`` target as usual and uses
|
||||||
|
the feature-appropriate include directory
|
||||||
|
|
||||||
|
.. code-block:: cmake
|
||||||
|
|
||||||
|
add_executable(consumer_with consumer_with.cpp)
|
||||||
|
target_link_libraries(consumer_with foo)
|
||||||
|
set_property(TARGET consumer_with CXX_STANDARD 11)
|
||||||
|
|
||||||
|
add_executable(consumer_no consumer_no.cpp)
|
||||||
|
target_link_libraries(consumer_no foo)
|
||||||
File diff suppressed because it is too large
Load Diff
@ -0,0 +1 @@
|
|||||||
|
.. cmake-module:: ../../Modules/CPackIFW.cmake
|
||||||
@ -0,0 +1 @@
|
|||||||
|
.. cmake-module:: ../../Modules/CTestCoverageCollectGCOV.cmake
|
||||||
@ -0,0 +1 @@
|
|||||||
|
.. cmake-module:: ../../Modules/CheckFortranSourceCompiles.cmake
|
||||||
@ -0,0 +1 @@
|
|||||||
|
.. cmake-module:: ../../Modules/FindGSL.cmake
|
||||||
@ -1 +1,10 @@
|
|||||||
.. cmake-module:: ../../Modules/FindITK.cmake
|
FindITK
|
||||||
|
-------
|
||||||
|
|
||||||
|
This module no longer exists.
|
||||||
|
|
||||||
|
This module existed in versions of CMake prior to 3.1, but became
|
||||||
|
only a thin wrapper around ``find_package(ITK NO_MODULE)`` to
|
||||||
|
provide compatibility for projects using long-outdated conventions.
|
||||||
|
Now ``find_package(ITK)`` will search for ``ITKConfig.cmake``
|
||||||
|
directly.
|
||||||
|
|||||||
@ -0,0 +1 @@
|
|||||||
|
.. cmake-module:: ../../Modules/FindIce.cmake
|
||||||
@ -0,0 +1 @@
|
|||||||
|
.. cmake-module:: ../../Modules/FindIntl.cmake
|
||||||
@ -0,0 +1 @@
|
|||||||
|
.. cmake-module:: ../../Modules/FindOpenCL.cmake
|
||||||
@ -1 +1,10 @@
|
|||||||
.. cmake-module:: ../../Modules/FindVTK.cmake
|
FindVTK
|
||||||
|
-------
|
||||||
|
|
||||||
|
This module no longer exists.
|
||||||
|
|
||||||
|
This module existed in versions of CMake prior to 3.1, but became
|
||||||
|
only a thin wrapper around ``find_package(VTK NO_MODULE)`` to
|
||||||
|
provide compatibility for projects using long-outdated conventions.
|
||||||
|
Now ``find_package(VTK)`` will search for ``VTKConfig.cmake``
|
||||||
|
directly.
|
||||||
|
|||||||
@ -0,0 +1 @@
|
|||||||
|
.. cmake-module:: ../../Modules/FindXercesC.cmake
|
||||||
@ -0,0 +1 @@
|
|||||||
|
.. cmake-module:: ../../Modules/WriteCompilerDetectionHeader.cmake
|
||||||
@ -0,0 +1,24 @@
|
|||||||
|
CMP0051
|
||||||
|
-------
|
||||||
|
|
||||||
|
List TARGET_OBJECTS in SOURCES target property.
|
||||||
|
|
||||||
|
CMake 3.0 and lower did not include the ``TARGET_OBJECTS``
|
||||||
|
:manual:`generator expression <cmake-generator-expressions(7)>` when
|
||||||
|
returning the :prop_tgt:`SOURCES` target property.
|
||||||
|
|
||||||
|
Configure-time CMake code is not able to handle generator expressions. If
|
||||||
|
using the :prop_tgt:`SOURCES` target property at configure time, it may be
|
||||||
|
necessary to first remove generator expressions using the
|
||||||
|
:command:`string(GENEX_STRIP)` command. Generate-time CMake code such as
|
||||||
|
:command:`file(GENERATE)` can handle the content without stripping.
|
||||||
|
|
||||||
|
The ``OLD`` behavior for this policy is to omit ``TARGET_OBJECTS``
|
||||||
|
expressions from the :prop_tgt:`SOURCES` target property. The ``NEW``
|
||||||
|
behavior for this policy is to include ``TARGET_OBJECTS`` expressions
|
||||||
|
in the output.
|
||||||
|
|
||||||
|
This policy was introduced in CMake version 3.1.
|
||||||
|
CMake version |release| warns when the policy is not set and uses
|
||||||
|
``OLD`` behavior. Use the :command:`cmake_policy` command to set it
|
||||||
|
to ``OLD`` or ``NEW`` explicitly.
|
||||||
@ -0,0 +1,24 @@
|
|||||||
|
CMP0052
|
||||||
|
-------
|
||||||
|
|
||||||
|
Reject source and build dirs in installed INTERFACE_INCLUDE_DIRECTORIES.
|
||||||
|
|
||||||
|
CMake 3.0 and lower allowed subdirectories of the source directory or build
|
||||||
|
directory to be in the :prop_tgt:`INTERFACE_INCLUDE_DIRECTORIES` of
|
||||||
|
installed and exported targets, if the directory was also a subdirectory of
|
||||||
|
the installation prefix. This makes the installation depend on the
|
||||||
|
existence of the source dir or binary dir, and the installation will be
|
||||||
|
broken if either are removed after installation.
|
||||||
|
|
||||||
|
See :ref:`Include Directories and Usage Requirements` for more on
|
||||||
|
specifying include directories for targets.
|
||||||
|
|
||||||
|
The OLD behavior for this policy is to export the content of the
|
||||||
|
:prop_tgt:`INTERFACE_INCLUDE_DIRECTORIES` with the source or binary
|
||||||
|
directory. The NEW behavior for this
|
||||||
|
policy is to issue an error if such a directory is used.
|
||||||
|
|
||||||
|
This policy was introduced in CMake version 3.1.
|
||||||
|
CMake version |release| warns when the policy is not set and uses
|
||||||
|
``OLD`` behavior. Use the :command:`cmake_policy` command to set it
|
||||||
|
to ``OLD`` or ``NEW`` explicitly.
|
||||||
@ -0,0 +1,44 @@
|
|||||||
|
CMP0053
|
||||||
|
-------
|
||||||
|
|
||||||
|
Simplify variable reference and escape sequence evaluation.
|
||||||
|
|
||||||
|
CMake 3.1 introduced a much faster implementation of evaluation of the
|
||||||
|
:ref:`Variable References` and :ref:`Escape Sequences` documented in the
|
||||||
|
:manual:`cmake-language(7)` manual. While the behavior is identical
|
||||||
|
to the legacy implementation in most cases, some corner cases were
|
||||||
|
cleaned up to simplify the behavior. Specifically:
|
||||||
|
|
||||||
|
* Expansion of ``@VAR@`` reference syntax defined by the
|
||||||
|
:command:`configure_file` and :command:`string(CONFIGURE)`
|
||||||
|
commands is no longer performed in other contexts.
|
||||||
|
|
||||||
|
* Literal ``${VAR}`` reference syntax may contain only
|
||||||
|
alphanumeric characters (``A-Z``, ``a-z``, ``0-9``) and
|
||||||
|
the characters ``_``, ``.``, ``/``, ``-``, and ``+``.
|
||||||
|
Variables with other characters in their name may still
|
||||||
|
be referenced indirectly, e.g.
|
||||||
|
|
||||||
|
.. code-block:: cmake
|
||||||
|
|
||||||
|
set(varname "otherwise & disallowed $ characters")
|
||||||
|
message("${${varname}}")
|
||||||
|
|
||||||
|
* The setting of policy :policy:`CMP0010` is not considered,
|
||||||
|
so improper variable reference syntax is always an error.
|
||||||
|
|
||||||
|
* More characters are allowed to be escaped in variable names.
|
||||||
|
Previously, only ``()#" \@^`` were valid characters to
|
||||||
|
escape. Now any non-alphanumeric, non-semicolon, non-NUL
|
||||||
|
character may be escaped following the ``escape_identity``
|
||||||
|
production in the :ref:`Escape Sequences` section of the
|
||||||
|
:manual:`cmake-language(7)` manual.
|
||||||
|
|
||||||
|
The ``OLD`` behavior for this policy is to honor the legacy behavior for
|
||||||
|
variable references and escape sequences. The ``NEW`` behavior is to
|
||||||
|
use the simpler variable expansion and escape sequence evaluation rules.
|
||||||
|
|
||||||
|
This policy was introduced in CMake version 3.1.
|
||||||
|
CMake version |release| warns when the policy is not set and uses
|
||||||
|
``OLD`` behavior. Use the :command:`cmake_policy` command to set
|
||||||
|
it to ``OLD`` or ``NEW`` explicitly.
|
||||||
@ -0,0 +1,46 @@
|
|||||||
|
CMP0054
|
||||||
|
-------
|
||||||
|
|
||||||
|
Only interpret :command:`if` arguments as variables or keywords when unquoted.
|
||||||
|
|
||||||
|
CMake 3.1 and above no longer implicitly dereference variables or
|
||||||
|
interpret keywords in an :command:`if` command argument when
|
||||||
|
it is a :ref:`Quoted Argument` or a :ref:`Bracket Argument`.
|
||||||
|
|
||||||
|
The ``OLD`` behavior for this policy is to dereference variables and
|
||||||
|
interpret keywords even if they are quoted or bracketed.
|
||||||
|
The ``NEW`` behavior is to not dereference variables or interpret keywords
|
||||||
|
that have been quoted or bracketed.
|
||||||
|
|
||||||
|
Given the following partial example:
|
||||||
|
|
||||||
|
::
|
||||||
|
|
||||||
|
set(MONKEY 1)
|
||||||
|
set(ANIMAL MONKEY)
|
||||||
|
|
||||||
|
if("${ANIMAL}" STREQUAL "MONKEY")
|
||||||
|
|
||||||
|
After explicit expansion of variables this gives:
|
||||||
|
|
||||||
|
::
|
||||||
|
|
||||||
|
if("MONKEY" STREQUAL "MONKEY")
|
||||||
|
|
||||||
|
With the policy set to ``OLD`` implicit expansion reduces this semantically to:
|
||||||
|
|
||||||
|
::
|
||||||
|
|
||||||
|
if("1" STREQUAL "1")
|
||||||
|
|
||||||
|
With the policy set to ``NEW`` the quoted arguments will not be
|
||||||
|
further dereferenced:
|
||||||
|
|
||||||
|
::
|
||||||
|
|
||||||
|
if("MONKEY" STREQUAL "MONKEY")
|
||||||
|
|
||||||
|
This policy was introduced in CMake version 3.1.
|
||||||
|
CMake version |release| warns when the policy is not set and uses
|
||||||
|
``OLD`` behavior. Use the :command:`cmake_policy` command to set
|
||||||
|
it to ``OLD`` or ``NEW`` explicitly.
|
||||||
@ -0,0 +1,17 @@
|
|||||||
|
CMP0055
|
||||||
|
-------
|
||||||
|
|
||||||
|
Strict checking for the :command:`break` command.
|
||||||
|
|
||||||
|
CMake 3.1 and lower allowed calls to the :command:`break` command
|
||||||
|
outside of a loop context and also ignored any given arguments.
|
||||||
|
This was undefined behavior.
|
||||||
|
|
||||||
|
The OLD behavior for this policy is to allow :command:`break` to be placed
|
||||||
|
outside of loop contexts and ignores any arguments. The NEW behavior for this
|
||||||
|
policy is to issue an error if a misplaced break or any arguments are found.
|
||||||
|
|
||||||
|
This policy was introduced in CMake version 3.2.
|
||||||
|
CMake version |release| warns when the policy is not set and uses
|
||||||
|
OLD behavior. Use the cmake_policy command to set it to OLD or
|
||||||
|
NEW explicitly.
|
||||||
@ -0,0 +1,32 @@
|
|||||||
|
CMP0056
|
||||||
|
-------
|
||||||
|
|
||||||
|
Honor link flags in :command:`try_compile` source-file signature.
|
||||||
|
|
||||||
|
The :command:`try_compile` command source-file signature generates a
|
||||||
|
``CMakeLists.txt`` file to build the source file into an executable.
|
||||||
|
In order to compile the source the same way as it might be compiled
|
||||||
|
by the calling project, the generated project sets the value of the
|
||||||
|
:variable:`CMAKE_<LANG>_FLAGS` variable to that in the calling project.
|
||||||
|
The value of the :variable:`CMAKE_EXE_LINKER_FLAGS` variable may be
|
||||||
|
needed in some cases too, but CMake 3.1 and lower did not set it in
|
||||||
|
the generated project. CMake 3.2 and above prefer to set it so that
|
||||||
|
linker flags are honored as well as compiler flags. This policy
|
||||||
|
provides compatibility with the pre-3.2 behavior.
|
||||||
|
|
||||||
|
The OLD behavior for this policy is to not set the value of the
|
||||||
|
:variable:`CMAKE_EXE_LINKER_FLAGS` variable in the generated test
|
||||||
|
project. The NEW behavior for this policy is to set the value of
|
||||||
|
the :variable:`CMAKE_EXE_LINKER_FLAGS` variable in the test project
|
||||||
|
to the same as it is in the calling project.
|
||||||
|
|
||||||
|
If the project code does not set the policy explicitly, users may
|
||||||
|
set it on the command line by defining the
|
||||||
|
:variable:`CMAKE_POLICY_DEFAULT_CMP0056 <CMAKE_POLICY_DEFAULT_CMP<NNNN>>`
|
||||||
|
variable in the cache.
|
||||||
|
|
||||||
|
This policy was introduced in CMake version 3.2. Unlike most policies,
|
||||||
|
CMake version |release| does *not* warn by default when this policy
|
||||||
|
is not set and simply uses OLD behavior. See documentation of the
|
||||||
|
:variable:`CMAKE_POLICY_WARNING_CMP0056 <CMAKE_POLICY_WARNING_CMP<NNNN>>`
|
||||||
|
variable to control the warning.
|
||||||
@ -0,0 +1,303 @@
|
|||||||
|
CMAKE_CXX_KNOWN_FEATURES
|
||||||
|
------------------------
|
||||||
|
|
||||||
|
List of C++ features known to this version of CMake.
|
||||||
|
|
||||||
|
The features listed in this global property may be known to be available to the
|
||||||
|
C++ compiler. If the feature is available with the C++ compiler, it will
|
||||||
|
be listed in the :variable:`CMAKE_CXX_COMPILE_FEATURES` variable.
|
||||||
|
|
||||||
|
The features listed here may be used with the :command:`target_compile_features`
|
||||||
|
command. See the :manual:`cmake-compile-features(7)` manual for information on
|
||||||
|
compile features.
|
||||||
|
|
||||||
|
|
||||||
|
The features known to this version of CMake are:
|
||||||
|
|
||||||
|
``cxx_aggregate_default_initializers``
|
||||||
|
Aggregate default initializers, as defined in N3605_.
|
||||||
|
|
||||||
|
.. _N3605: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3605.html
|
||||||
|
|
||||||
|
``cxx_alias_templates``
|
||||||
|
Template aliases, as defined in N2258_.
|
||||||
|
|
||||||
|
.. _N2258: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2258.pdf
|
||||||
|
|
||||||
|
``cxx_alignas``
|
||||||
|
Alignment control ``alignas``, as defined in N2341_.
|
||||||
|
|
||||||
|
.. _N2341: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2341.pdf
|
||||||
|
|
||||||
|
``cxx_alignof``
|
||||||
|
Alignment control ``alignof``, as defined in N2341_.
|
||||||
|
|
||||||
|
.. _N2341: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2341.pdf
|
||||||
|
|
||||||
|
``cxx_attributes``
|
||||||
|
Generic attributes, as defined in N2761_.
|
||||||
|
|
||||||
|
.. _N2761: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2761.pdf
|
||||||
|
|
||||||
|
``cxx_attribute_deprecated``
|
||||||
|
``[[deprecated]]`` attribute, as defined in N3760_.
|
||||||
|
|
||||||
|
.. _N3760: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3760.html
|
||||||
|
|
||||||
|
``cxx_auto_type``
|
||||||
|
Automatic type deduction, as defined in N1984_.
|
||||||
|
|
||||||
|
.. _N1984: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1984.pdf
|
||||||
|
|
||||||
|
``cxx_binary_literals``
|
||||||
|
Binary literals, as defined in N3472_.
|
||||||
|
|
||||||
|
.. _N3472: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3472.pdf
|
||||||
|
|
||||||
|
``cxx_constexpr``
|
||||||
|
Constant expressions, as defined in N2235_.
|
||||||
|
|
||||||
|
.. _N2235: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2235.pdf
|
||||||
|
|
||||||
|
``cxx_contextual_conversions``
|
||||||
|
Contextual conversions, as defined in N3323_.
|
||||||
|
|
||||||
|
.. _N3323: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3323.pdf
|
||||||
|
|
||||||
|
``cxx_decltype_incomplete_return_types``
|
||||||
|
Decltype on incomplete return types, as defined in N3276_.
|
||||||
|
|
||||||
|
.. _N3276 : http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3276.pdf
|
||||||
|
|
||||||
|
``cxx_decltype``
|
||||||
|
Decltype, as defined in N2343_.
|
||||||
|
|
||||||
|
.. _N2343: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2343.pdf
|
||||||
|
|
||||||
|
``cxx_decltype_auto``
|
||||||
|
``decltype(auto)`` semantics, as defined in N3638_.
|
||||||
|
|
||||||
|
.. _N3638: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3638.html
|
||||||
|
|
||||||
|
``cxx_default_function_template_args``
|
||||||
|
Default template arguments for function templates, as defined in DR226_
|
||||||
|
|
||||||
|
.. _DR226: http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#226
|
||||||
|
|
||||||
|
``cxx_defaulted_functions``
|
||||||
|
Defaulted functions, as defined in N2346_.
|
||||||
|
|
||||||
|
.. _N2346: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2346.htm
|
||||||
|
|
||||||
|
``cxx_defaulted_move_initializers``
|
||||||
|
Defaulted move initializers, as defined in N3053_.
|
||||||
|
|
||||||
|
.. _N3053: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3053.html
|
||||||
|
|
||||||
|
``cxx_delegating_constructors``
|
||||||
|
Delegating constructors, as defined in N1986_.
|
||||||
|
|
||||||
|
.. _N1986: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1986.pdf
|
||||||
|
|
||||||
|
``cxx_deleted_functions``
|
||||||
|
Deleted functions, as defined in N2346_.
|
||||||
|
|
||||||
|
.. _N2346: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2346.htm
|
||||||
|
|
||||||
|
``cxx_digit_separators``
|
||||||
|
Digit separators, as defined in N3781_.
|
||||||
|
|
||||||
|
.. _N3781: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3781.pdf
|
||||||
|
|
||||||
|
``cxx_enum_forward_declarations``
|
||||||
|
Enum forward declarations, as defined in N2764_.
|
||||||
|
|
||||||
|
.. _N2764: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2764.pdf
|
||||||
|
|
||||||
|
``cxx_explicit_conversions``
|
||||||
|
Explicit conversion operators, as defined in N2437_.
|
||||||
|
|
||||||
|
.. _N2437: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2437.pdf
|
||||||
|
|
||||||
|
``cxx_extended_friend_declarations``
|
||||||
|
Extended friend declarations, as defined in N1791_.
|
||||||
|
|
||||||
|
.. _N1791: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1791.pdf
|
||||||
|
|
||||||
|
``cxx_extern_templates``
|
||||||
|
Extern templates, as defined in N1987_.
|
||||||
|
|
||||||
|
.. _N1987: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1987.htm
|
||||||
|
|
||||||
|
``cxx_final``
|
||||||
|
Override control ``final`` keyword, as defined in N2928_, N3206_ and N3272_.
|
||||||
|
|
||||||
|
.. _N2928: http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2928.htm
|
||||||
|
.. _N3206: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3206.htm
|
||||||
|
.. _N3272: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3272.htm
|
||||||
|
|
||||||
|
``cxx_func_identifier``
|
||||||
|
Predefined ``__func__`` identifier, as defined in N2340_.
|
||||||
|
|
||||||
|
.. _N2340: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2340.htm
|
||||||
|
|
||||||
|
``cxx_generalized_initializers``
|
||||||
|
Initializer lists, as defined in N2672_.
|
||||||
|
|
||||||
|
.. _N2672: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2672.htm
|
||||||
|
|
||||||
|
``cxx_generic_lambdas``
|
||||||
|
Generic lambdas, as defined in N3649_.
|
||||||
|
|
||||||
|
.. _N3649: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3649.html
|
||||||
|
|
||||||
|
``cxx_inheriting_constructors``
|
||||||
|
Inheriting constructors, as defined in N2540_.
|
||||||
|
|
||||||
|
.. _N2540: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2540.htm
|
||||||
|
|
||||||
|
``cxx_inline_namespaces``
|
||||||
|
Inline namespaces, as defined in N2535_.
|
||||||
|
|
||||||
|
.. _N2535: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2535.htm
|
||||||
|
|
||||||
|
``cxx_lambdas``
|
||||||
|
Lambda functions, as defined in N2927_.
|
||||||
|
|
||||||
|
.. _N2927: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2927.pdf
|
||||||
|
|
||||||
|
``cxx_lambda_init_captures``
|
||||||
|
Initialized lambda captures, as defined in N3648_.
|
||||||
|
|
||||||
|
.. _N3648: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3648.html
|
||||||
|
|
||||||
|
``cxx_local_type_template_args``
|
||||||
|
Local and unnamed types as template arguments, as defined in N2657_.
|
||||||
|
|
||||||
|
.. _N2657: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2657.htm
|
||||||
|
|
||||||
|
``cxx_long_long_type``
|
||||||
|
``long long`` type, as defined in N1811_.
|
||||||
|
|
||||||
|
.. _N1811: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1811.pdf
|
||||||
|
|
||||||
|
``cxx_noexcept``
|
||||||
|
Exception specifications, as defined in N3050_.
|
||||||
|
|
||||||
|
.. _N3050: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3050.html
|
||||||
|
|
||||||
|
``cxx_nonstatic_member_init``
|
||||||
|
Non-static data member initialization, as defined in N2756_.
|
||||||
|
|
||||||
|
.. _N2756: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2756.htm
|
||||||
|
|
||||||
|
``cxx_nullptr``
|
||||||
|
Null pointer, as defined in N2431_.
|
||||||
|
|
||||||
|
.. _N2431: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2431.pdf
|
||||||
|
|
||||||
|
``cxx_override``
|
||||||
|
Override control ``override`` keyword, as defined in N2928_, N3206_
|
||||||
|
and N3272_.
|
||||||
|
|
||||||
|
.. _N2928: http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2928.htm
|
||||||
|
.. _N3206: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3206.htm
|
||||||
|
.. _N3272: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3272.htm
|
||||||
|
|
||||||
|
``cxx_range_for``
|
||||||
|
Range-based for, as defined in N2930_.
|
||||||
|
|
||||||
|
.. _N2930: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2930.html
|
||||||
|
|
||||||
|
``cxx_raw_string_literals``
|
||||||
|
Raw string literals, as defined in N2442_.
|
||||||
|
|
||||||
|
.. _N2442: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2442.htm
|
||||||
|
|
||||||
|
``cxx_reference_qualified_functions``
|
||||||
|
Reference qualified functions, as defined in N2439_.
|
||||||
|
|
||||||
|
.. _N2439: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2439.htm
|
||||||
|
|
||||||
|
``cxx_relaxed_constexpr``
|
||||||
|
Relaxed constexpr, as defined in N3652_.
|
||||||
|
|
||||||
|
.. _N3652: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3652.html
|
||||||
|
|
||||||
|
``cxx_return_type_deduction``
|
||||||
|
Return type deduction on normal functions, as defined in N3386_.
|
||||||
|
|
||||||
|
.. _N3386: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3386.html
|
||||||
|
|
||||||
|
``cxx_right_angle_brackets``
|
||||||
|
Right angle bracket parsing, as defined in N1757_.
|
||||||
|
|
||||||
|
.. _N1757: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1757.html
|
||||||
|
|
||||||
|
``cxx_rvalue_references``
|
||||||
|
R-value references, as defined in N2118_.
|
||||||
|
|
||||||
|
.. _N2118: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2118.html
|
||||||
|
|
||||||
|
``cxx_sizeof_member``
|
||||||
|
Size of non-static data members, as defined in N2253_.
|
||||||
|
|
||||||
|
.. _N2253: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2253.html
|
||||||
|
|
||||||
|
``cxx_static_assert``
|
||||||
|
Static assert, as defined in N1720_.
|
||||||
|
|
||||||
|
.. _N1720: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1720.html
|
||||||
|
|
||||||
|
``cxx_strong_enums``
|
||||||
|
Strongly typed enums, as defined in N2347_.
|
||||||
|
|
||||||
|
.. _N2347: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2347.pdf
|
||||||
|
|
||||||
|
``cxx_thread_local``
|
||||||
|
Thread-local variables, as defined in N2659_.
|
||||||
|
|
||||||
|
.. _N2659: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2659.htm
|
||||||
|
|
||||||
|
``cxx_trailing_return_types``
|
||||||
|
Automatic function return type, as defined in N2541_.
|
||||||
|
|
||||||
|
.. _N2541: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2541.htm
|
||||||
|
|
||||||
|
``cxx_unicode_literals``
|
||||||
|
Unicode string literals, as defined in N2442_.
|
||||||
|
|
||||||
|
.. _N2442: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2442.htm
|
||||||
|
|
||||||
|
``cxx_uniform_initialization``
|
||||||
|
Uniform intialization, as defined in N2640_.
|
||||||
|
|
||||||
|
.. _N2640: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2640.pdf
|
||||||
|
|
||||||
|
``cxx_unrestricted_unions``
|
||||||
|
Unrestricted unions, as defined in N2544_.
|
||||||
|
|
||||||
|
.. _N2544: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2544.pdf
|
||||||
|
|
||||||
|
``cxx_user_literals``
|
||||||
|
User-defined literals, as defined in N2765_.
|
||||||
|
|
||||||
|
.. _N2765: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2765.pdf
|
||||||
|
|
||||||
|
``cxx_variable_templates``
|
||||||
|
Variable templates, as defined in N3651_.
|
||||||
|
|
||||||
|
.. _N3651: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3651.pdf
|
||||||
|
|
||||||
|
``cxx_variadic_macros``
|
||||||
|
Variadic macros, as defined in N1653_.
|
||||||
|
|
||||||
|
.. _N1653: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1653.htm
|
||||||
|
|
||||||
|
``cxx_variadic_templates``
|
||||||
|
Variadic templates, as defined in N2242_.
|
||||||
|
|
||||||
|
.. _N2242: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2242.pdf
|
||||||
|
|
||||||
|
``cxx_template_template_parameters``
|
||||||
|
Template template parameters, as defined in ``ISO/IEC 14882:1998``.
|
||||||
@ -0,0 +1,26 @@
|
|||||||
|
CMAKE_C_KNOWN_FEATURES
|
||||||
|
----------------------
|
||||||
|
|
||||||
|
List of C features known to this version of CMake.
|
||||||
|
|
||||||
|
The features listed in this global property may be known to be available to the
|
||||||
|
C compiler. If the feature is available with the C compiler, it will
|
||||||
|
be listed in the :variable:`CMAKE_C_COMPILE_FEATURES` variable.
|
||||||
|
|
||||||
|
The features listed here may be used with the :command:`target_compile_features`
|
||||||
|
command. See the :manual:`cmake-compile-features(7)` manual for information on
|
||||||
|
compile features.
|
||||||
|
|
||||||
|
The features known to this version of CMake are:
|
||||||
|
|
||||||
|
``c_function_prototypes``
|
||||||
|
Function prototypes, as defined in ``ISO/IEC 9899:1990``.
|
||||||
|
|
||||||
|
``c_restrict``
|
||||||
|
``restrict`` keyword, as defined in ``ISO/IEC 9899:1999``.
|
||||||
|
|
||||||
|
``c_static_assert``
|
||||||
|
Static assert, as defined in ``ISO/IEC 9899:2011``.
|
||||||
|
|
||||||
|
``c_variadic_macros``
|
||||||
|
Variadic macros, as defined in ``ISO/IEC 9899:1999``.
|
||||||
@ -0,0 +1,6 @@
|
|||||||
|
CPACK_NEVER_OVERWRITE
|
||||||
|
---------------------
|
||||||
|
|
||||||
|
Request that this file not be overwritten on install or reinstall.
|
||||||
|
|
||||||
|
The property is currently only supported by the WIX generator.
|
||||||
@ -0,0 +1,6 @@
|
|||||||
|
CPACK_PERMANENT
|
||||||
|
---------------
|
||||||
|
|
||||||
|
Request that this file not be removed on uninstall.
|
||||||
|
|
||||||
|
The property is currently only supported by the WIX generator.
|
||||||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in new issue