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
|
||||
--------------
|
||||
|
||||
Deprecated. Use the target_link_libraries() command instead.
|
||||
|
||||
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
|
||||
(typically added with the add_executable or add_library calls). This
|
||||
command is passed down to all subdirectories. The debug and optimized
|
||||
strings may be used to indicate that the next library listed is to be
|
||||
used only for that specific type of build.
|
||||
.. note::
|
||||
The :command:`target_link_libraries` command should be preferred whenever
|
||||
possible. Library dependencies are chained automatically, so directory-wide
|
||||
specification of link libraries is rarely needed.
|
||||
|
||||
@ -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
|
||||
-----------
|
||||
|
||||
.. only:: html
|
||||
|
||||
.. contents::
|
||||
|
||||
Try building some code.
|
||||
|
||||
Try Compiling Whole Projects
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
::
|
||||
|
||||
try_compile(RESULT_VAR <bindir> <srcdir>
|
||||
<projectName> [targetName] [CMAKE_FLAGS flags...]
|
||||
<projectName> [<targetName>] [CMAKE_FLAGS <flags>...]
|
||||
[OUTPUT_VARIABLE <var>])
|
||||
|
||||
Try building a project. In this form, srcdir should contain a
|
||||
complete CMake project with a 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.
|
||||
Try building a project. The success or failure of the ``try_compile``,
|
||||
i.e. ``TRUE`` or ``FALSE`` respectively, is returned in ``RESULT_VAR``.
|
||||
|
||||
In this form, ``<srcdir>`` should contain a complete CMake project with a
|
||||
``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...>
|
||||
[CMAKE_FLAGS flags...]
|
||||
[COMPILE_DEFINITIONS flags...]
|
||||
[LINK_LIBRARIES libs...]
|
||||
[CMAKE_FLAGS <flags>...]
|
||||
[COMPILE_DEFINITIONS <defs>...]
|
||||
[LINK_LIBRARIES <libs>...]
|
||||
[OUTPUT_VARIABLE <var>]
|
||||
[COPY_FILE <fileName> [COPY_FILE_ERROR <var>]])
|
||||
|
||||
Try building an executable from one or more source files. 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. 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:
|
||||
Try building an executable from one or more source files. The success or
|
||||
failure of the ``try_compile``, i.e. ``TRUE`` or ``FALSE`` respectively, is
|
||||
returned in ``RESULT_VAR``.
|
||||
|
||||
::
|
||||
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})
|
||||
link_directories(${LINK_DIRECTORIES})
|
||||
add_executable(cmTryCompileExec sources)
|
||||
add_executable(cmTryCompileExec <srcfile>...)
|
||||
target_link_libraries(cmTryCompileExec ${LINK_LIBRARIES})
|
||||
|
||||
In both versions of the command, if OUTPUT_VARIABLE is specified, then
|
||||
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
|
||||
respectively, is returned in RESULT_VAR. CMAKE_FLAGS can be used to
|
||||
pass -DVAR:TYPE=VALUE flags to the cmake that is run during the build.
|
||||
Set variable CMAKE_TRY_COMPILE_CONFIGURATION to choose a build
|
||||
configuration.
|
||||
The options are:
|
||||
|
||||
``CMAKE_FLAGS <flags>...``
|
||||
Specify flags of the form ``-DVAR:TYPE=VALUE`` to be passed to
|
||||
the ``cmake`` command-line used to drive the test build.
|
||||
The above example 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.
|
||||
|
||||
``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
|
||||
-------
|
||||
|
||||
.. only:: html
|
||||
|
||||
.. contents::
|
||||
|
||||
Try compiling and then running some code.
|
||||
|
||||
Try Compiling and Running Source Files
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
::
|
||||
|
||||
try_run(RUN_RESULT_VAR COMPILE_RESULT_VAR
|
||||
bindir srcfile [CMAKE_FLAGS <Flags>]
|
||||
[COMPILE_DEFINITIONS <flags>]
|
||||
[COMPILE_OUTPUT_VARIABLE comp]
|
||||
[RUN_OUTPUT_VARIABLE run]
|
||||
[OUTPUT_VARIABLE var]
|
||||
[ARGS <arg1> <arg2>...])
|
||||
|
||||
Try compiling a srcfile. Return TRUE or FALSE for success or failure
|
||||
in COMPILE_RESULT_VAR. Then if the compile succeeded, run the
|
||||
executable and return its exit code in RUN_RESULT_VAR. If the
|
||||
executable was built, but failed to run, then RUN_RESULT_VAR will be
|
||||
set to FAILED_TO_RUN. COMPILE_OUTPUT_VARIABLE specifies the variable
|
||||
where the output from the compile step goes. RUN_OUTPUT_VARIABLE
|
||||
specifies the variable where the output from the running executable
|
||||
goes.
|
||||
|
||||
For compatibility reasons OUTPUT_VARIABLE is still supported, which
|
||||
gives you the output from the compile and run step combined.
|
||||
|
||||
Cross compiling issues
|
||||
bindir srcfile [CMAKE_FLAGS <flags>...]
|
||||
[COMPILE_DEFINITIONS <defs>...]
|
||||
[LINK_LIBRARIES <libs>...]
|
||||
[COMPILE_OUTPUT_VARIABLE <var>]
|
||||
[RUN_OUTPUT_VARIABLE <var>]
|
||||
[OUTPUT_VARIABLE <var>]
|
||||
[ARGS <args>...])
|
||||
|
||||
Try compiling a ``<srcfile>``. Returns ``TRUE`` or ``FALSE`` for success
|
||||
or failure in ``COMPILE_RESULT_VAR``. If the compile succeeded, runs the
|
||||
executable and returns its exit code in ``RUN_RESULT_VAR``. If the
|
||||
executable was built, but failed to run, then ``RUN_RESULT_VAR`` will be
|
||||
set to ``FAILED_TO_RUN``. See the :command:`try_compile` command for
|
||||
information on how the test project is constructed to build the source file.
|
||||
|
||||
The options are:
|
||||
|
||||
``CMAKE_FLAGS <flags>...``
|
||||
Specify flags of the form ``-DVAR:TYPE=VALUE`` to be passed to
|
||||
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
|
||||
usually cannot be run on the build host. try_run() checks the
|
||||
CMAKE_CROSSCOMPILING variable to detect whether CMake is in
|
||||
crosscompiling mode. If that's the case, it will still try to compile
|
||||
usually cannot be run on the build host. The ``try_run`` command checks
|
||||
the :variable:`CMAKE_CROSSCOMPILING` variable to detect whether CMake is in
|
||||
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
|
||||
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
|
||||
would have produced if it had been run on its actual target platform.
|
||||
These variables are RUN_RESULT_VAR (explanation see above) and if
|
||||
RUN_OUTPUT_VARIABLE (or OUTPUT_VARIABLE) was used, an additional cache
|
||||
variable RUN_RESULT_VAR__COMPILE_RESULT_VAR__TRYRUN_OUTPUT.This is
|
||||
intended to hold stdout and stderr from the executable.
|
||||
|
||||
In order to make cross compiling your project easier, use try_run only
|
||||
if really required. If you use try_run, use RUN_OUTPUT_VARIABLE (or
|
||||
OUTPUT_VARIABLE) only if really required. Using them will require
|
||||
that when crosscompiling, the cache variables will have to be set
|
||||
manually to the output of the executable. You can also "guard" the
|
||||
calls to try_run with if(CMAKE_CROSSCOMPILING) and provide an
|
||||
easy-to-preset alternative for this case.
|
||||
|
||||
Set variable CMAKE_TRY_COMPILE_CONFIGURATION to choose a build
|
||||
configuration.
|
||||
These cache entries are:
|
||||
|
||||
``<RUN_RESULT_VAR>``
|
||||
Exit code if the executable were to be run on the target platform.
|
||||
|
||||
``<RUN_RESULT_VAR>__TRYRUN_OUTPUT``
|
||||
Output from stdout and stderr if the executable were to be run on
|
||||
the target platform. This is created only if the
|
||||
``RUN_OUTPUT_VARIABLE`` or ``OUTPUT_VARIABLE`` option was used.
|
||||
|
||||
In order to make cross compiling your project easier, use ``try_run``
|
||||
only if really required. If you use ``try_run``, use the
|
||||
``RUN_OUTPUT_VARIABLE`` or ``OUTPUT_VARIABLE`` options only if really
|
||||
required. Using them will require that when cross-compiling, the cache
|
||||
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
|
||||
--------------
|
||||
|
||||
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
|
||||
installed on the machine.
|
||||
Use this generator in a MSYS shell prompt and using ``make`` as the build
|
||||
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
|
||||
---------------
|
||||
|
||||
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
|
||||
msys or a unix shell.
|
||||
Use this generator under a Windows command prompt with MinGW in the ``PATH``
|
||||
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.
|
||||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in new issue