Felix Geyer
10 years ago
parent
75c6a19f8d
commit
fd947bac97
@ -1,29 +1,73 @@
|
|||||||
ctest_build
|
ctest_build
|
||||||
-----------
|
-----------
|
||||||
|
|
||||||
Build the project.
|
Perform the :ref:`CTest Build Step` as a :ref:`Dashboard Client`.
|
||||||
|
|
||||||
::
|
::
|
||||||
|
|
||||||
ctest_build([BUILD build_dir] [TARGET target] [RETURN_VALUE res]
|
ctest_build([BUILD <build-dir>] [APPEND]
|
||||||
[APPEND][NUMBER_ERRORS val] [NUMBER_WARNINGS val])
|
[CONFIGURATION <config>]
|
||||||
|
[FLAGS <flags>]
|
||||||
|
[PROJECT_NAME <project-name>]
|
||||||
|
[TARGET <target-name>]
|
||||||
|
[NUMBER_ERRORS <num-err-var>]
|
||||||
|
[NUMBER_WARNINGS <num-warn-var>]
|
||||||
|
[RETURN_VALUE <result-var>]
|
||||||
|
)
|
||||||
|
|
||||||
Builds the given build directory and stores results in Build.xml. If
|
Build the project and store results in ``Build.xml``
|
||||||
no BUILD is given, the CTEST_BINARY_DIRECTORY variable is used.
|
for submission with the :command:`ctest_submit` command.
|
||||||
|
|
||||||
The TARGET variable can be used to specify a build target. If none is
|
The :variable:`CTEST_BUILD_COMMAND` variable may be set to explicitly
|
||||||
specified, the "all" target will be built.
|
specify the build command line. Otherwise the build command line is
|
||||||
|
computed automatically based on the options given.
|
||||||
|
|
||||||
The RETURN_VALUE option specifies a variable in which to store the
|
The options are:
|
||||||
return value of the native build tool. The NUMBER_ERRORS and
|
|
||||||
NUMBER_WARNINGS options specify variables in which to store the number
|
|
||||||
of build errors and warnings detected.
|
|
||||||
|
|
||||||
The APPEND option marks results for append to those previously
|
``BUILD <build-dir>``
|
||||||
submitted to a dashboard server since the last ctest_start. Append
|
Specify the top-level build directory. If not given, the
|
||||||
semantics are defined by the dashboard server in use.
|
:variable:`CTEST_BINARY_DIRECTORY` variable is used.
|
||||||
|
|
||||||
If set, the contents of the variable CTEST_BUILD_FLAGS are passed as
|
``APPEND``
|
||||||
additional arguments to the underlying build command. This can e.g. be
|
Mark results for append to those previously submitted to a
|
||||||
used to trigger a parallel build using the -j option of make. See
|
dashboard server since the last :command:`ctest_start` call.
|
||||||
:module:`ProcessorCount` for an example.
|
Append semantics are defined by the dashboard server in use.
|
||||||
|
|
||||||
|
``CONFIGURATION <config>``
|
||||||
|
Specify the build configuration (e.g. ``Debug``). If not
|
||||||
|
specified the ``CTEST_BUILD_CONFIGURATION`` variable will be checked.
|
||||||
|
Otherwise the ``-C <cfg>`` option given to the :manual:`ctest(1)`
|
||||||
|
command will be used, if any.
|
||||||
|
|
||||||
|
``FLAGS <flags>``
|
||||||
|
Pass additional arguments to the underlying build command.
|
||||||
|
If not specified the ``CTEST_BUILD_FLAGS`` variable will be checked.
|
||||||
|
This can, e.g., be used to trigger a parallel build using the
|
||||||
|
``-j`` option of make. See the :module:`ProcessorCount` module
|
||||||
|
for an example.
|
||||||
|
|
||||||
|
``PROJECT_NAME <project-name>``
|
||||||
|
Set the name of the project to build. This should correspond
|
||||||
|
to the top-level call to the :command:`project` command.
|
||||||
|
If not specified the ``CTEST_PROJECT_NAME`` variable will be checked.
|
||||||
|
|
||||||
|
``TARGET <target-name>``
|
||||||
|
Specify the name of a target to build. If not specified the
|
||||||
|
``CTEST_BUILD_TARGET`` variable will be checked. Otherwise the
|
||||||
|
default target will be built. This is the "all" target
|
||||||
|
(called ``ALL_BUILD`` in :ref:`Visual Studio Generators`).
|
||||||
|
|
||||||
|
``NUMBER_ERRORS <num-err-var>``
|
||||||
|
Store the number of build errors detected in the given variable.
|
||||||
|
|
||||||
|
``NUMBER_WARNINGS <num-warn-var>``
|
||||||
|
Store the number of build warnings detected in the given variable.
|
||||||
|
|
||||||
|
``RETURN_VALUE <result-var>``
|
||||||
|
Store the return value of the native build tool in the given variable.
|
||||||
|
|
||||||
|
``QUIET``
|
||||||
|
Suppress any CTest-specific non-error output that would have been
|
||||||
|
printed to the console otherwise. The summary of warnings / errors,
|
||||||
|
as well as the output from the native build tool is unaffected by
|
||||||
|
this option.
|
||||||
|
|||||||
@ -1,21 +1,39 @@
|
|||||||
ctest_configure
|
ctest_configure
|
||||||
---------------
|
---------------
|
||||||
|
|
||||||
Configure the project build tree.
|
Perform the :ref:`CTest Configure Step` as a :ref:`Dashboard Client`.
|
||||||
|
|
||||||
::
|
::
|
||||||
|
|
||||||
ctest_configure([BUILD build_dir] [SOURCE source_dir] [APPEND]
|
ctest_configure([BUILD <build-dir>] [SOURCE <source-dir>] [APPEND]
|
||||||
[OPTIONS options] [RETURN_VALUE res])
|
[OPTIONS <options>] [RETURN_VALUE <result-var>] [QUIET])
|
||||||
|
|
||||||
Configures the given build directory and stores results in
|
Configure the project build tree and record results in ``Configure.xml``
|
||||||
Configure.xml. If no BUILD is given, the CTEST_BINARY_DIRECTORY
|
for submission with the :command:`ctest_submit` command.
|
||||||
variable is used. If no SOURCE is given, the CTEST_SOURCE_DIRECTORY
|
|
||||||
variable is used. The OPTIONS argument specifies command line
|
|
||||||
arguments to pass to the configuration tool. The RETURN_VALUE option
|
|
||||||
specifies a variable in which to store the return value of the native
|
|
||||||
build tool.
|
|
||||||
|
|
||||||
The APPEND option marks results for append to those previously
|
The options are:
|
||||||
submitted to a dashboard server since the last ctest_start. Append
|
|
||||||
semantics are defined by the dashboard server in use.
|
``BUILD <build-dir>``
|
||||||
|
Specify the top-level build directory. If not given, the
|
||||||
|
:variable:`CTEST_BINARY_DIRECTORY` variable is used.
|
||||||
|
|
||||||
|
``SOURCE <source-dir>``
|
||||||
|
Specify the source directory. If not given, the
|
||||||
|
:variable:`CTEST_SOURCE_DIRECTORY` variable is used.
|
||||||
|
|
||||||
|
``APPEND``
|
||||||
|
Mark results for append to those previously submitted to a
|
||||||
|
dashboard server since the last :command:`ctest_start` call.
|
||||||
|
Append semantics are defined by the dashboard server in use.
|
||||||
|
|
||||||
|
``OPTIONS <options>``
|
||||||
|
Specify command-line arguments to pass to the configuration tool.
|
||||||
|
|
||||||
|
``RETURN_VALUE <result-var>``
|
||||||
|
Store in the ``<result-var>`` variable the return value of the native
|
||||||
|
configuration tool.
|
||||||
|
|
||||||
|
``QUIET``
|
||||||
|
Suppress any CTest-specific non-error messages that would have
|
||||||
|
otherwise been printed to the console. Output from the underlying
|
||||||
|
configure command is not affected.
|
||||||
|
|||||||
@ -1,20 +1,39 @@
|
|||||||
ctest_coverage
|
ctest_coverage
|
||||||
--------------
|
--------------
|
||||||
|
|
||||||
Collect coverage tool results.
|
Perform the :ref:`CTest Coverage Step` as a :ref:`Dashboard Client`.
|
||||||
|
|
||||||
::
|
::
|
||||||
|
|
||||||
ctest_coverage([BUILD build_dir] [RETURN_VALUE res] [APPEND]
|
ctest_coverage([BUILD <build-dir>] [APPEND]
|
||||||
[LABELS label1 [label2 [...]]])
|
[LABELS <label>...]
|
||||||
|
[RETURN_VALUE <result-var>]
|
||||||
|
[QUIET]
|
||||||
|
)
|
||||||
|
|
||||||
Perform the coverage of the given build directory and stores results
|
Collect coverage tool results and stores them in ``Coverage.xml``
|
||||||
in Coverage.xml. The second argument is a variable that will hold
|
for submission with the :command:`ctest_submit` command.
|
||||||
value.
|
|
||||||
|
|
||||||
The LABELS option filters the coverage report to include only source
|
The options are:
|
||||||
files labeled with at least one of the labels specified.
|
|
||||||
|
|
||||||
The APPEND option marks results for append to those previously
|
``BUILD <build-dir>``
|
||||||
submitted to a dashboard server since the last ctest_start. Append
|
Specify the top-level build directory. If not given, the
|
||||||
semantics are defined by the dashboard server in use.
|
:variable:`CTEST_BINARY_DIRECTORY` variable is used.
|
||||||
|
|
||||||
|
``APPEND``
|
||||||
|
Mark results for append to those previously submitted to a
|
||||||
|
dashboard server since the last :command:`ctest_start` call.
|
||||||
|
Append semantics are defined by the dashboard server in use.
|
||||||
|
|
||||||
|
``LABELS``
|
||||||
|
Filter the coverage report to include only source files labeled
|
||||||
|
with at least one of the labels specified.
|
||||||
|
|
||||||
|
``RETURN_VALUE <result-var>``
|
||||||
|
Store in the ``<result-var>`` variable ``0`` if coverage tools
|
||||||
|
ran without error and non-zero otherwise.
|
||||||
|
|
||||||
|
``QUIET``
|
||||||
|
Suppress any CTest-specific non-error output that would have been
|
||||||
|
printed to the console otherwise. The summary indicating how many
|
||||||
|
lines of code were covered is unaffected by this option.
|
||||||
|
|||||||
@ -1,28 +1,28 @@
|
|||||||
ctest_memcheck
|
ctest_memcheck
|
||||||
--------------
|
--------------
|
||||||
|
|
||||||
Run tests with a dynamic analysis tool.
|
Perform the :ref:`CTest MemCheck Step` as a :ref:`Dashboard Client`.
|
||||||
|
|
||||||
::
|
::
|
||||||
|
|
||||||
ctest_memcheck([BUILD build_dir] [RETURN_VALUE res] [APPEND]
|
ctest_memcheck([BUILD <build-dir>] [APPEND]
|
||||||
[START start number] [END end number]
|
[START <start-number>]
|
||||||
[STRIDE stride number] [EXCLUDE exclude regex ]
|
[END <end-number>]
|
||||||
[INCLUDE include regex]
|
[STRIDE <stride-number>]
|
||||||
[EXCLUDE_LABEL exclude regex]
|
[EXCLUDE <exclude-regex>]
|
||||||
[INCLUDE_LABEL label regex]
|
[INCLUDE <include-regex>]
|
||||||
[PARALLEL_LEVEL level] )
|
[EXCLUDE_LABEL <label-exclude-regex>]
|
||||||
|
[INCLUDE_LABEL <label-include-regex>]
|
||||||
|
[PARALLEL_LEVEL <level>]
|
||||||
|
[SCHEDULE_RANDOM <ON|OFF>]
|
||||||
|
[STOP_TIME <time-of-day>]
|
||||||
|
[RETURN_VALUE <result-var>]
|
||||||
|
[QUIET]
|
||||||
|
)
|
||||||
|
|
||||||
Tests the given build directory and stores results in MemCheck.xml.
|
|
||||||
The second argument is a variable that will hold value. Optionally,
|
|
||||||
you can specify the starting test number START, the ending test number
|
|
||||||
END, the number of tests to skip between each test STRIDE, a regular
|
|
||||||
expression for tests to run INCLUDE, or a regular expression for tests
|
|
||||||
not to run EXCLUDE. EXCLUDE_LABEL and INCLUDE_LABEL are regular
|
|
||||||
expressions for tests to be included or excluded by the test property
|
|
||||||
LABEL. PARALLEL_LEVEL should be set to a positive number representing
|
|
||||||
the number of tests to be run in parallel.
|
|
||||||
|
|
||||||
The APPEND option marks results for append to those previously
|
Run tests with a dynamic analysis tool and store results in
|
||||||
submitted to a dashboard server since the last ctest_start. Append
|
``MemCheck.xml`` for submission with the :command:`ctest_submit`
|
||||||
semantics are defined by the dashboard server in use.
|
command.
|
||||||
|
|
||||||
|
The options are the same as those for the :command:`ctest_test` command.
|
||||||
|
|||||||
@ -1,33 +1,79 @@
|
|||||||
ctest_test
|
ctest_test
|
||||||
----------
|
----------
|
||||||
|
|
||||||
Run tests in the project build tree.
|
Perform the :ref:`CTest Test Step` as a :ref:`Dashboard Client`.
|
||||||
|
|
||||||
::
|
::
|
||||||
|
|
||||||
ctest_test([BUILD build_dir] [APPEND]
|
ctest_test([BUILD <build-dir>] [APPEND]
|
||||||
[START start number] [END end number]
|
[START <start-number>]
|
||||||
[STRIDE stride number] [EXCLUDE exclude regex ]
|
[END <end-number>]
|
||||||
[INCLUDE include regex] [RETURN_VALUE res]
|
[STRIDE <stride-number>]
|
||||||
[EXCLUDE_LABEL exclude regex]
|
[EXCLUDE <exclude-regex>]
|
||||||
[INCLUDE_LABEL label regex]
|
[INCLUDE <include-regex>]
|
||||||
[PARALLEL_LEVEL level]
|
[EXCLUDE_LABEL <label-exclude-regex>]
|
||||||
[SCHEDULE_RANDOM on]
|
[INCLUDE_LABEL <label-include-regex>]
|
||||||
[STOP_TIME time of day])
|
[PARALLEL_LEVEL <level>]
|
||||||
|
[SCHEDULE_RANDOM <ON|OFF>]
|
||||||
Tests the given build directory and stores results in Test.xml. The
|
[STOP_TIME <time-of-day>]
|
||||||
second argument is a variable that will hold value. Optionally, you
|
[RETURN_VALUE <result-var>]
|
||||||
can specify the starting test number START, the ending test number
|
[QUIET]
|
||||||
END, the number of tests to skip between each test STRIDE, a regular
|
)
|
||||||
expression for tests to run INCLUDE, or a regular expression for tests
|
|
||||||
to not run EXCLUDE. EXCLUDE_LABEL and INCLUDE_LABEL are regular
|
Run tests in the project build tree and store results in
|
||||||
expression for test to be included or excluded by the test property
|
``Test.xml`` for submission with the :command:`ctest_submit` command.
|
||||||
LABEL. PARALLEL_LEVEL should be set to a positive number representing
|
|
||||||
the number of tests to be run in parallel. SCHEDULE_RANDOM will
|
The options are:
|
||||||
launch tests in a random order, and is typically used to detect
|
|
||||||
implicit test dependencies. STOP_TIME is the time of day at which the
|
``BUILD <build-dir>``
|
||||||
tests should all stop running.
|
Specify the top-level build directory. If not given, the
|
||||||
|
:variable:`CTEST_BINARY_DIRECTORY` variable is used.
|
||||||
The APPEND option marks results for append to those previously
|
|
||||||
submitted to a dashboard server since the last ctest_start. Append
|
``APPEND``
|
||||||
semantics are defined by the dashboard server in use.
|
Mark results for append to those previously submitted to a
|
||||||
|
dashboard server since the last :command:`ctest_start` call.
|
||||||
|
Append semantics are defined by the dashboard server in use.
|
||||||
|
|
||||||
|
``START <start-number>``
|
||||||
|
Specify the beginning of a range of test numbers.
|
||||||
|
|
||||||
|
``END <end-number>``
|
||||||
|
Specify the end of a range of test numbers.
|
||||||
|
|
||||||
|
``STRIDE <stride-number>``
|
||||||
|
Specify the stride by which to step acorss a range of test numbers.
|
||||||
|
|
||||||
|
``EXCLUDE <exclude-regex>``
|
||||||
|
Specify a regular expression matching test names to exclude.
|
||||||
|
|
||||||
|
``INCLUDE <include-regex>``
|
||||||
|
Specify a regular expression matching test names to include.
|
||||||
|
Tests not matching this expression are excluded.
|
||||||
|
|
||||||
|
``EXCLUDE_LABEL <label-exclude-regex>``
|
||||||
|
Specify a regular expression matching test labels to exclude.
|
||||||
|
|
||||||
|
``INCLUDE_LABEL <label-include-regex>``
|
||||||
|
Specify a regular expression matching test labels to include.
|
||||||
|
Tests not matching this expression are excluded.
|
||||||
|
|
||||||
|
``PARALLEL_LEVEL <level>``
|
||||||
|
Specify a positive number representing the number of tests to
|
||||||
|
be run in parallel.
|
||||||
|
|
||||||
|
``SCHEDULE_RANDOM <ON|OFF>``
|
||||||
|
Launch tests in a random order. This may be useful for detecting
|
||||||
|
implicit test dependencies.
|
||||||
|
|
||||||
|
``STOP_TIME <time-of-day>``
|
||||||
|
Specify a time of day at which the tests should all stop running.
|
||||||
|
|
||||||
|
``RETURN_VALUE <result-var>``
|
||||||
|
Store in the ``<result-var>`` variable ``0`` if all tests passed.
|
||||||
|
Store non-zero if anything went wrong.
|
||||||
|
|
||||||
|
``QUIET``
|
||||||
|
Suppress any CTest-specific non-error messages that would have otherwise
|
||||||
|
been printed to the console. Output from the underlying test command is not
|
||||||
|
affected. Summary info detailing the percentage of passing tests is also
|
||||||
|
unaffected by the ``QUIET`` option.
|
||||||
|
|||||||
@ -1,13 +1,27 @@
|
|||||||
ctest_update
|
ctest_update
|
||||||
------------
|
------------
|
||||||
|
|
||||||
Update the work tree from version control.
|
Perform the :ref:`CTest Update Step` as a :ref:`Dashboard Client`.
|
||||||
|
|
||||||
::
|
::
|
||||||
|
|
||||||
ctest_update([SOURCE source] [RETURN_VALUE res])
|
ctest_update([SOURCE <source-dir>] [RETURN_VALUE <result-var>] [QUIET])
|
||||||
|
|
||||||
Updates the given source directory and stores results in Update.xml.
|
Update the source tree from version control and record results in
|
||||||
If no SOURCE is given, the CTEST_SOURCE_DIRECTORY variable is used.
|
``Update.xml`` for submission with the :command:`ctest_submit` command.
|
||||||
The RETURN_VALUE option specifies a variable in which to store the
|
|
||||||
result, which is the number of files updated or -1 on error.
|
The options are:
|
||||||
|
|
||||||
|
``SOURCE <source-dir>``
|
||||||
|
Specify the source directory. If not given, the
|
||||||
|
:variable:`CTEST_SOURCE_DIRECTORY` variable is used.
|
||||||
|
|
||||||
|
``RETURN_VALUE <result-var>``
|
||||||
|
Store in the ``<result-var>`` variable the number of files
|
||||||
|
updated or ``-1`` on error.
|
||||||
|
|
||||||
|
``QUIET``
|
||||||
|
Tell CTest to suppress most non-error messages that it would
|
||||||
|
have otherwise printed to the console. CTest will still report
|
||||||
|
the new revision of the repository and any conflicting files
|
||||||
|
that were found.
|
||||||
|
|||||||
@ -1,11 +1,18 @@
|
|||||||
ctest_upload
|
ctest_upload
|
||||||
------------
|
------------
|
||||||
|
|
||||||
Upload files to a dashboard server.
|
Upload files to a dashboard server as a :ref:`Dashboard Client`.
|
||||||
|
|
||||||
::
|
::
|
||||||
|
|
||||||
ctest_upload(FILES ...)
|
ctest_upload(FILES <file>... [QUIET])
|
||||||
|
|
||||||
Pass a list of files to be sent along with the build results to the
|
The options are:
|
||||||
dashboard server.
|
|
||||||
|
``FILES <file>...``
|
||||||
|
Specify a list of files to be sent along with the build results to the
|
||||||
|
dashboard server.
|
||||||
|
|
||||||
|
``QUIET``
|
||||||
|
Suppress any CTest-specific non-error output that would have been
|
||||||
|
printed to the console otherwise.
|
||||||
|
|||||||
@ -1,116 +1,89 @@
|
|||||||
set
|
set
|
||||||
---
|
---
|
||||||
|
|
||||||
Set a CMake, cache or environment variable to a given value.
|
Set a normal, cache, or environment variable to a given value.
|
||||||
|
See the :ref:`cmake-language(7) variables <CMake Language Variables>`
|
||||||
|
documentation for the scopes and interaction of normal variables
|
||||||
|
and cache entries.
|
||||||
|
|
||||||
|
Signatures of this command that specify a ``<value>...`` placeholder
|
||||||
|
expect zero or more arguments. Multiple arguments will be joined as
|
||||||
|
a :ref:`;-list <CMake Language Lists>` to form the actual variable
|
||||||
|
value to be set. Zero arguments will cause normal variables to be
|
||||||
|
unset. See the :command:`unset` command to unset variables explicitly.
|
||||||
|
|
||||||
|
Set Normal Variable
|
||||||
|
^^^^^^^^^^^^^^^^^^^
|
||||||
|
|
||||||
::
|
::
|
||||||
|
|
||||||
set(<variable> <value>
|
set(<variable> <value>... [PARENT_SCOPE])
|
||||||
[[CACHE <type> <docstring> [FORCE]] | PARENT_SCOPE])
|
|
||||||
|
Set the given ``<variable>`` in the current function or directory scope.
|
||||||
|
|
||||||
Within CMake sets <variable> to the value <value>. <value> is
|
If the ``PARENT_SCOPE`` option is given the variable will be set in
|
||||||
expanded before <variable> is set to it. Normally, set will set a
|
the scope above the current scope. Each new directory or function
|
||||||
regular CMake variable. If CACHE is present, then the <variable> is
|
creates a new scope. This command will set the value of a variable
|
||||||
put in the cache instead, unless it is already in the cache. See
|
into the parent directory or calling function (whichever is applicable
|
||||||
section 'Variable types in CMake' below for details of regular and
|
to the case at hand).
|
||||||
cache variables and their interactions. If CACHE is used, <type> and
|
|
||||||
<docstring> are required. <type> is used by the CMake GUI to choose a
|
Set Cache Entry
|
||||||
widget with which the user sets a value. The value for <type> may be
|
^^^^^^^^^^^^^^^
|
||||||
one of
|
|
||||||
|
|
||||||
::
|
::
|
||||||
|
|
||||||
FILEPATH = File chooser dialog.
|
set(<variable> <value>... CACHE <type> <docstring> [FORCE])
|
||||||
PATH = Directory chooser dialog.
|
|
||||||
STRING = Arbitrary string.
|
|
||||||
BOOL = Boolean ON/OFF checkbox.
|
|
||||||
INTERNAL = No GUI entry (used for persistent variables).
|
|
||||||
|
|
||||||
If <type> is INTERNAL, the cache variable is marked as internal, and
|
Set the given cache ``<variable>`` (cache entry). Since cache entries
|
||||||
will not be shown to the user in tools like cmake-gui. This is
|
are meant to provide user-settable values this does not overwrite
|
||||||
intended for values that should be persisted in the cache, but which
|
existing cache entries by default. Use the ``FORCE`` option to
|
||||||
users should not normally change. INTERNAL implies FORCE.
|
overwrite existing entries.
|
||||||
|
|
||||||
Normally, set(...CACHE...) creates cache variables, but does not
|
The ``<type>`` must be specified as one of:
|
||||||
modify them. If FORCE is specified, the value of the cache variable
|
|
||||||
is set, even if the variable is already in the cache. This should
|
|
||||||
normally be avoided, as it will remove any changes to the cache
|
|
||||||
variable's value by the user.
|
|
||||||
|
|
||||||
If PARENT_SCOPE is present, the variable will be set in the scope
|
``BOOL``
|
||||||
above the current scope. Each new directory or function creates a new
|
Boolean ``ON/OFF`` value. :manual:`cmake-gui(1)` offers a checkbox.
|
||||||
scope. This command will set the value of a variable into the parent
|
|
||||||
directory or calling function (whichever is applicable to the case at
|
|
||||||
hand). PARENT_SCOPE cannot be combined with CACHE.
|
|
||||||
|
|
||||||
If <value> is not specified then the variable is removed instead of
|
``FILEPATH``
|
||||||
set. See also: the unset() command.
|
Path to a file on disk. :manual:`cmake-gui(1)` offers a file dialog.
|
||||||
|
|
||||||
::
|
``PATH``
|
||||||
|
Path to a directory on disk. :manual:`cmake-gui(1)` offers a file dialog.
|
||||||
|
|
||||||
set(<variable> <value1> ... <valueN>)
|
``STRING``
|
||||||
|
A line of text. :manual:`cmake-gui(1)` offers a text field or a
|
||||||
|
drop-down selection if the :prop_cache:`STRINGS` cache entry
|
||||||
|
property is set.
|
||||||
|
|
||||||
In this case <variable> is set to a semicolon separated list of
|
``INTERNAL``
|
||||||
values.
|
A line of text. :manual:`cmake-gui(1)` does not show internal entries.
|
||||||
|
They may be used to store variables persistently across runs.
|
||||||
|
Use of this type implies ``FORCE``.
|
||||||
|
|
||||||
<variable> can be an environment variable such as:
|
The ``<docstring>`` must be specified as a line of text providing
|
||||||
|
a quick summary of the option for presentation to :manual:`cmake-gui(1)`
|
||||||
|
users.
|
||||||
|
|
||||||
|
If the cache entry does not exist prior to the call or the ``FORCE``
|
||||||
|
option is given then the cache entry will be set to the given value.
|
||||||
|
Furthermore, any normal variable binding in the current scope will
|
||||||
|
be removed to expose the newly cached value to any immediately
|
||||||
|
following evaluation.
|
||||||
|
|
||||||
|
It is possible for the cache entry to exist prior to the call but
|
||||||
|
have no type set if it was created on the :manual:`cmake(1)` command
|
||||||
|
line by a user through the ``-D<var>=<value>`` option without
|
||||||
|
specifying a type. In this case the ``set`` command will add the
|
||||||
|
type. Furthermore, if the ``<type>`` is ``PATH`` or ``FILEPATH``
|
||||||
|
and the ``<value>`` provided on the command line is a relative path,
|
||||||
|
then the ``set`` command will treat the path as relative to the
|
||||||
|
current working directory and convert it to an absolute path.
|
||||||
|
|
||||||
|
Set Environment Variable
|
||||||
|
^^^^^^^^^^^^^^^^^^^^^^^^
|
||||||
|
|
||||||
::
|
::
|
||||||
|
|
||||||
set( ENV{PATH} /home/martink )
|
set(ENV{<variable>} <value>...)
|
||||||
|
|
||||||
in which case the environment variable will be set.
|
Set the current process environment ``<variable>`` to the given value.
|
||||||
|
|
||||||
*** Variable types in CMake ***
|
|
||||||
|
|
||||||
In CMake there are two types of variables: normal variables and cache
|
|
||||||
variables. Normal variables are meant for the internal use of the
|
|
||||||
script (just like variables in most programming languages); they are
|
|
||||||
not persisted across CMake runs. Cache variables (unless set with
|
|
||||||
INTERNAL) are mostly intended for configuration settings where the
|
|
||||||
first CMake run determines a suitable default value, which the user
|
|
||||||
can then override, by editing the cache with tools such as ccmake or
|
|
||||||
cmake-gui. Cache variables are stored in the CMake cache file, and
|
|
||||||
are persisted across CMake runs.
|
|
||||||
|
|
||||||
Both types can exist at the same time with the same name but different
|
|
||||||
values. When ${FOO} is evaluated, CMake first looks for a normal
|
|
||||||
variable 'FOO' in scope and uses it if set. If and only if no normal
|
|
||||||
variable exists then it falls back to the cache variable 'FOO'.
|
|
||||||
|
|
||||||
Some examples:
|
|
||||||
|
|
||||||
The code 'set(FOO "x")' sets the normal variable 'FOO'. It does not
|
|
||||||
touch the cache, but it will hide any existing cache value 'FOO'.
|
|
||||||
|
|
||||||
The code 'set(FOO "x" CACHE ...)' checks for 'FOO' in the cache,
|
|
||||||
ignoring any normal variable of the same name. If 'FOO' is in the
|
|
||||||
cache then nothing happens to either the normal variable or the cache
|
|
||||||
variable. If 'FOO' is not in the cache, then it is added to the
|
|
||||||
cache.
|
|
||||||
|
|
||||||
Finally, whenever a cache variable is added or modified by a command,
|
|
||||||
CMake also *removes* the normal variable of the same name from the
|
|
||||||
current scope so that an immediately following evaluation of it will
|
|
||||||
expose the newly cached value.
|
|
||||||
|
|
||||||
Normally projects should avoid using normal and cache variables of the
|
|
||||||
same name, as this interaction can be hard to follow. However, in
|
|
||||||
some situations it can be useful. One example (used by some
|
|
||||||
projects):
|
|
||||||
|
|
||||||
A project has a subproject in its source tree. The child project has
|
|
||||||
its own CMakeLists.txt, which is included from the parent
|
|
||||||
CMakeLists.txt using add_subdirectory(). Now, if the parent and the
|
|
||||||
child project provide the same option (for example a compiler option),
|
|
||||||
the parent gets the first chance to add a user-editable option to the
|
|
||||||
cache. Normally, the child would then use the same value that the
|
|
||||||
parent uses. However, it may be necessary to hard-code the value for
|
|
||||||
the child project's option while still allowing the user to edit the
|
|
||||||
value used by the parent project. The parent project can achieve this
|
|
||||||
simply by setting a normal variable with the same name as the option
|
|
||||||
in a scope sufficient to hide the option's cache variable from the
|
|
||||||
child completely. The parent has already set the cache variable, so
|
|
||||||
the child's set(...CACHE...) will do nothing, and evaluating the
|
|
||||||
option variable will use the value from the normal variable, which
|
|
||||||
hides the cache variable.
|
|
||||||
|
|||||||
@ -0,0 +1,16 @@
|
|||||||
|
Green Hills MULTI
|
||||||
|
-----------------
|
||||||
|
|
||||||
|
Generates Green Hills MULTI project files (experimental, work-in-progress).
|
||||||
|
|
||||||
|
Customizations are available through the following cache variables:
|
||||||
|
|
||||||
|
* ``GHS_BSP_NAME``
|
||||||
|
* ``GHS_CUSTOMIZATION``
|
||||||
|
* ``GHS_GPJ_MACROS``
|
||||||
|
* ``GHS_OS_DIR``
|
||||||
|
|
||||||
|
.. note::
|
||||||
|
This generator is deemed experimental as of CMake |release|
|
||||||
|
and is still a work in progress. Future versions of CMake
|
||||||
|
may make breaking changes as the generator matures.
|
||||||
@ -1,4 +1,10 @@
|
|||||||
Visual Studio 6
|
Visual Studio 6
|
||||||
---------------
|
---------------
|
||||||
|
|
||||||
Generates Visual Studio 6 project files.
|
Deprected. Generates Visual Studio 6 project files.
|
||||||
|
|
||||||
|
.. note::
|
||||||
|
This generator is deprecated and will be removed
|
||||||
|
in a future version of CMake. It will still be
|
||||||
|
possible to build with VS 6 tools using the
|
||||||
|
:generator:`NMake Makefiles` generator.
|
||||||
|
|||||||
@ -1,4 +1,10 @@
|
|||||||
Visual Studio 7
|
Visual Studio 7
|
||||||
---------------
|
---------------
|
||||||
|
|
||||||
Generates Visual Studio .NET 2002 project files.
|
Deprected. Generates Visual Studio .NET 2002 project files.
|
||||||
|
|
||||||
|
.. note::
|
||||||
|
This generator is deprecated and will be removed
|
||||||
|
in a future version of CMake. It will still be
|
||||||
|
possible to build with VS 7.0 tools using the
|
||||||
|
:generator:`NMake Makefiles` generator.
|
||||||
|
|||||||
@ -1,30 +1,18 @@
|
|||||||
|
|
||||||
Note that it is not advisable to populate the ``INSTALL_INTERFACE`` of the
|
Note that it is not advisable to populate the ``INSTALL_INTERFACE`` of the
|
||||||
|INTERFACE_PROPERTY_LINK| of a target with paths for dependencies.
|
|INTERFACE_PROPERTY_LINK| of a target with absolute paths to the include
|
||||||
That would hard-code into installed packages the include directory paths
|
directories of dependencies. That would hard-code into installed packages
|
||||||
for dependencies **as found on the machine the package was made on**.
|
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
|
The ``INSTALL_INTERFACE`` of the |INTERFACE_PROPERTY_LINK| is only
|
||||||
suitable for specifying the required include directories of the target itself,
|
suitable for specifying the required include directories for headers
|
||||||
not its dependencies.
|
provided with the target itself, not those provided by the transitive
|
||||||
|
dependencies listed in its :prop_tgt:`INTERFACE_LINK_LIBRARIES` target
|
||||||
|
property. Those dependencies should themselves be targets that specify
|
||||||
|
their own header locations in |INTERFACE_PROPERTY_LINK|.
|
||||||
|
|
||||||
That is, code like this is incorrect for targets which will be used to
|
See the :ref:`Creating Relocatable Packages` section of the
|
||||||
generate :manual:`cmake-packages(7)`:
|
:manual:`cmake-packages(7)` manual for discussion of additional care
|
||||||
|
that must be taken when specifying usage requirements while creating
|
||||||
.. code-block:: cmake
|
packages for redistribution.
|
||||||
|
|
||||||
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>`.
|
|
||||||
|
|||||||
@ -1,23 +1,10 @@
|
|||||||
|
|
||||||
Note that it is not advisable to populate the
|
Note that it is not advisable to populate the
|
||||||
|INTERFACE_PROPERTY_LINK| of a target with paths for dependencies.
|
|INTERFACE_PROPERTY_LINK| of a target with absolute paths to dependencies.
|
||||||
That would hard-code into installed packages the include directory paths
|
That would hard-code into installed packages the library file paths
|
||||||
for dependencies **as found on the machine the package was made on**.
|
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
|
See the :ref:`Creating Relocatable Packages` section of the
|
||||||
generate :manual:`cmake-packages(7)`:
|
:manual:`cmake-packages(7)` manual for discussion of additional care
|
||||||
|
that must be taken when specifying usage requirements while creating
|
||||||
.. code-block:: cmake
|
packages for redistribution.
|
||||||
|
|
||||||
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 @@
|
|||||||
|
.. cmake-module:: ../../Modules/CheckFortranCompilerFlag.cmake
|
||||||
@ -0,0 +1 @@
|
|||||||
|
.. cmake-module:: ../../Modules/FindXCTest.cmake
|
||||||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in new issue