-----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAABCAAGBQJV0atkAAoJEP4ixv2DE11F+KoP/0P607WlzA6xcrwTYxY85oDe jIbBcqJsrbMYrxPU0LphUoMRpZ9m52DlJStrPlaTxVAX4aZ5vu+j6MhSNLp55xDB qCql6+T9rWBJX0V6pK7bSVsmdRoGipE+UplPQHUTEmSZxTyQCB0+IKYAPQYyMX+s WO8tAVsOtJsyL6j3Qh/Gc7McaYWTNbZ7r71YYBDYplGwX+vc4DK3jSFzk1p36w+9 ccLOAq/MUBzXX+ChkryWiBA0thvKFK52dGTyoDgx4YMNZLzWvplqkqFCDhc6AZ17 7J4cYQ2uNbfVFUBVoyBzAwSn0hsYShQTzjpn6hu+0WQ9ZAJfL/EsPg1eNwCPlomL 5y3ArafoGhBzl7TfJ0ZTgn9BKfEdysxm6dZ0rj8DT2ZZKnmAifne3beMeOA9E8Gq NWWngKbpbVstud/6IOw52zUisVcSa5pzh5RDGe+mYd7545DVjbK0coRKQxA6A2aX fDQtNBDg56Bw2tuwNJbQqEQSq8L6D7hdierna423da90XVfGW7hMy21y9kIx773c yhsFCcRg8PTm6v9UGRDSxBKAlGRE5uQE8C0eKvk52zCnlsHDvUOXV4UY9ZpohmcN 38z6L64XCIoeOWlyHMlNq5n0S9fRQuBANMDrNbNOI8FjBG+kNRsmrUq51NrI0CGj 0HHBSdt9AGOT0IkAJhkU =u9i1 -----END PGP SIGNATURE----- Merge tag 'upstream/3.3.1' into experimental Upstream version 3.3.1 # gpg: Signature made Mo 17 Aug 2015 11:37:40 CEST using RSA key ID 83135D45 # gpg: Good signature from "Felix Geyer <felix@fobos.de>" # gpg: aka "Felix Geyer <debfx@kubuntu.org>" # gpg: aka "Felix Geyer <debfx@fobos.de>" # gpg: aka "Felix Geyer <debfx-pkg@fobos.de>" # gpg: aka "Felix Geyer <debfx@ubuntu.com>" # gpg: aka "Felix Geyer <felix.geyer@fobos.de>"ci/unstable
Felix Geyer
9 years ago
commit
7dae6a3540
@ -1,29 +1,73 @@
|
||||
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]
|
||||
[APPEND][NUMBER_ERRORS val] [NUMBER_WARNINGS val])
|
||||
ctest_build([BUILD <build-dir>] [APPEND]
|
||||
[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
|
||||
no BUILD is given, the CTEST_BINARY_DIRECTORY variable is used.
|
||||
Build the project and store results in ``Build.xml``
|
||||
for submission with the :command:`ctest_submit` command.
|
||||
|
||||
The TARGET variable can be used to specify a build target. If none is
|
||||
specified, the "all" target will be built.
|
||||
The :variable:`CTEST_BUILD_COMMAND` variable may be set to explicitly
|
||||
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
|
||||
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 options are:
|
||||
|
||||
The APPEND option marks results for append to those previously
|
||||
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.
|
||||
|
||||
If set, the contents of the variable CTEST_BUILD_FLAGS are passed as
|
||||
additional arguments to the underlying build command. This can e.g. be
|
||||
used to trigger a parallel build using the -j option of make. See
|
||||
:module:`ProcessorCount` for an example.
|
||||
``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.
|
||||
|
||||
``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
|
||||
---------------
|
||||
|
||||
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]
|
||||
[OPTIONS options] [RETURN_VALUE res])
|
||||
ctest_configure([BUILD <build-dir>] [SOURCE <source-dir>] [APPEND]
|
||||
[OPTIONS <options>] [RETURN_VALUE <result-var>] [QUIET])
|
||||
|
||||
Configures the given build directory and stores results in
|
||||
Configure.xml. If no BUILD is given, the CTEST_BINARY_DIRECTORY
|
||||
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.
|
||||
Configure the project build tree and record results in ``Configure.xml``
|
||||
for submission with the :command:`ctest_submit` command.
|
||||
|
||||
The APPEND option marks results for append to those previously
|
||||
submitted to a dashboard server since the last ctest_start. Append
|
||||
semantics are defined by the dashboard server in use.
|
||||
The options are:
|
||||
|
||||
``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
|
||||
--------------
|
||||
|
||||
Collect coverage tool results.
|
||||
Perform the :ref:`CTest Coverage Step` as a :ref:`Dashboard Client`.
|
||||
|
||||
::
|
||||
|
||||
ctest_coverage([BUILD build_dir] [RETURN_VALUE res] [APPEND]
|
||||
[LABELS label1 [label2 [...]]])
|
||||
ctest_coverage([BUILD <build-dir>] [APPEND]
|
||||
[LABELS <label>...]
|
||||
[RETURN_VALUE <result-var>]
|
||||
[QUIET]
|
||||
)
|
||||
|
||||
Perform the coverage of the given build directory and stores results
|
||||
in Coverage.xml. The second argument is a variable that will hold
|
||||
value.
|
||||
Collect coverage tool results and stores them in ``Coverage.xml``
|
||||
for submission with the :command:`ctest_submit` command.
|
||||
|
||||
The LABELS option filters the coverage report to include only source
|
||||
files labeled with at least one of the labels specified.
|
||||
The options are:
|
||||
|
||||
The APPEND option marks results for append to those previously
|
||||
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.
|
||||
|
||||
``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
|
||||
--------------
|
||||
|
||||
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]
|
||||
[START start number] [END end number]
|
||||
[STRIDE stride number] [EXCLUDE exclude regex ]
|
||||
[INCLUDE include regex]
|
||||
[EXCLUDE_LABEL exclude regex]
|
||||
[INCLUDE_LABEL label regex]
|
||||
[PARALLEL_LEVEL level] )
|
||||
ctest_memcheck([BUILD <build-dir>] [APPEND]
|
||||
[START <start-number>]
|
||||
[END <end-number>]
|
||||
[STRIDE <stride-number>]
|
||||
[EXCLUDE <exclude-regex>]
|
||||
[INCLUDE <include-regex>]
|
||||
[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
|
||||
submitted to a dashboard server since the last ctest_start. Append
|
||||
semantics are defined by the dashboard server in use.
|
||||
Run tests with a dynamic analysis tool and store results in
|
||||
``MemCheck.xml`` for submission with the :command:`ctest_submit`
|
||||
command.
|
||||
|
||||
The options are the same as those for the :command:`ctest_test` command.
|
||||
|
||||
@ -1,33 +1,79 @@
|
||||
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]
|
||||
[START start number] [END end number]
|
||||
[STRIDE stride number] [EXCLUDE exclude regex ]
|
||||
[INCLUDE include regex] [RETURN_VALUE res]
|
||||
[EXCLUDE_LABEL exclude regex]
|
||||
[INCLUDE_LABEL label regex]
|
||||
[PARALLEL_LEVEL level]
|
||||
[SCHEDULE_RANDOM on]
|
||||
[STOP_TIME time of day])
|
||||
|
||||
Tests the given build directory and stores results in Test.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
|
||||
to not run EXCLUDE. EXCLUDE_LABEL and INCLUDE_LABEL are regular
|
||||
expression for test 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. SCHEDULE_RANDOM will
|
||||
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
|
||||
tests should all stop running.
|
||||
|
||||
The APPEND option marks results for append to those previously
|
||||
submitted to a dashboard server since the last ctest_start. Append
|
||||
semantics are defined by the dashboard server in use.
|
||||
ctest_test([BUILD <build-dir>] [APPEND]
|
||||
[START <start-number>]
|
||||
[END <end-number>]
|
||||
[STRIDE <stride-number>]
|
||||
[EXCLUDE <exclude-regex>]
|
||||
[INCLUDE <include-regex>]
|
||||
[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]
|
||||
)
|
||||
|
||||
Run tests in the project build tree and store results in
|
||||
``Test.xml`` for submission with the :command:`ctest_submit` command.
|
||||
|
||||
The options are:
|
||||
|
||||
``BUILD <build-dir>``
|
||||
Specify the top-level build directory. If not given, the
|
||||
: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.
|
||||
|
||||
``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
|
||||
------------
|
||||
|
||||
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.
|
||||
If no SOURCE is given, the CTEST_SOURCE_DIRECTORY variable is used.
|
||||
The RETURN_VALUE option specifies a variable in which to store the
|
||||
result, which is the number of files updated or -1 on error.
|
||||
Update the source tree from version control and record results in
|
||||
``Update.xml`` for submission with the :command:`ctest_submit` command.
|
||||
|
||||
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
|
||||
------------
|
||||
|
||||
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
|
||||
dashboard server.
|
||||
The options are:
|
||||
|
||||
``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 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>
|
||||
[[CACHE <type> <docstring> [FORCE]] | PARENT_SCOPE])
|
||||
set(<variable> <value>... [PARENT_SCOPE])
|
||||
|
||||
Set the given ``<variable>`` in the current function or directory scope.
|
||||
|
||||
Within CMake sets <variable> to the value <value>. <value> is
|
||||
expanded before <variable> is set to it. Normally, set will set a
|
||||
regular CMake variable. If CACHE is present, then the <variable> is
|
||||
put in the cache instead, unless it is already in the cache. See
|
||||
section 'Variable types in CMake' below for details of regular and
|
||||
cache variables and their interactions. If CACHE is used, <type> and
|
||||
<docstring> are required. <type> is used by the CMake GUI to choose a
|
||||
widget with which the user sets a value. The value for <type> may be
|
||||
one of
|
||||
If the ``PARENT_SCOPE`` option is given the variable will be set in
|
||||
the scope above the current scope. Each new directory or function
|
||||
creates a new 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).
|
||||
|
||||
Set Cache Entry
|
||||
^^^^^^^^^^^^^^^
|
||||
|
||||
::
|
||||
|
||||
FILEPATH = File chooser dialog.
|
||||
PATH = Directory chooser dialog.
|
||||
STRING = Arbitrary string.
|
||||
BOOL = Boolean ON/OFF checkbox.
|
||||
INTERNAL = No GUI entry (used for persistent variables).
|
||||
set(<variable> <value>... CACHE <type> <docstring> [FORCE])
|
||||
|
||||
If <type> is INTERNAL, the cache variable is marked as internal, and
|
||||
will not be shown to the user in tools like cmake-gui. This is
|
||||
intended for values that should be persisted in the cache, but which
|
||||
users should not normally change. INTERNAL implies FORCE.
|
||||
Set the given cache ``<variable>`` (cache entry). Since cache entries
|
||||
are meant to provide user-settable values this does not overwrite
|
||||
existing cache entries by default. Use the ``FORCE`` option to
|
||||
overwrite existing entries.
|
||||
|
||||
Normally, set(...CACHE...) creates cache variables, but does not
|
||||
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.
|
||||
The ``<type>`` must be specified as one of:
|
||||
|
||||
If PARENT_SCOPE is present, the variable will be set in the scope
|
||||
above the current scope. Each new directory or function creates a new
|
||||
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.
|
||||
``BOOL``
|
||||
Boolean ``ON/OFF`` value. :manual:`cmake-gui(1)` offers a checkbox.
|
||||
|
||||
If <value> is not specified then the variable is removed instead of
|
||||
set. See also: the unset() command.
|
||||
``FILEPATH``
|
||||
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
|
||||
values.
|
||||
``INTERNAL``
|
||||
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 )
|
||||
|
||||
in which case the environment variable will be set.
|
||||
|
||||
*** 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.
|
||||
set(ENV{<variable>} <value>...)
|
||||
|
||||
Set the current process environment ``<variable>`` to the given value.
|
||||
|
||||
@ -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
|
||||
---------------
|
||||
|
||||
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
|
||||
---------------
|
||||
|
||||
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
|
||||
|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**.
|
||||
|INTERFACE_PROPERTY_LINK| of a target with absolute paths to the include
|
||||
directories of 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.
|
||||
suitable for specifying the required include directories for headers
|
||||
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
|
||||
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>`.
|
||||
See the :ref:`Creating Relocatable Packages` section of the
|
||||
:manual:`cmake-packages(7)` manual for discussion of additional care
|
||||
that must be taken when specifying usage requirements while creating
|
||||
packages for redistribution.
|
||||
|
||||
@ -1,23 +1,10 @@
|
||||
|
||||
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
|
||||
|INTERFACE_PROPERTY_LINK| of a target with absolute paths to dependencies.
|
||||
That would hard-code into installed packages the library file 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>`.
|
||||
See the :ref:`Creating Relocatable Packages` section of the
|
||||
:manual:`cmake-packages(7)` manual for discussion of additional care
|
||||
that must be taken when specifying usage requirements while creating
|
||||
packages for redistribution.
|
||||
|
||||
@ -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