Update cmake (this should support latest stuff!)

This commit is contained in:
Detanup01
2026-01-27 19:22:27 +01:00
parent b023bd3987
commit 702f658c7b
4015 changed files with 20875 additions and 4976 deletions

View File

@@ -2,7 +2,7 @@
https://gitlab.kitware.com/cmake/cmake
VERSION: https://github.com/Kitware/CMake/releases/tag/v4.1.5
VERSION: https://github.com/Kitware/CMake/releases/tag/v4.2.3
#### LICENSE

Binary file not shown.

View File

@@ -1,70 +0,0 @@
cmake_instrumentation
---------------------
.. versionadded:: 4.0
.. note::
This command is only available when experimental support for instrumentation
has been enabled by the ``CMAKE_EXPERIMENTAL_INSTRUMENTATION`` gate.
Enables interacting with the
:manual:`CMake Instrumentation API <cmake-instrumentation(7)>`.
This allows for configuring instrumentation at the project-level.
.. code-block:: cmake
cmake_instrumentation(
API_VERSION <version>
DATA_VERSION <version>
[HOOKS <hooks>...]
[QUERIES <queries>...]
[CALLBACK <callback>]
)
The ``API_VERSION`` and ``DATA_VERSION`` must always be given. Currently, the
only supported value for both fields is 1. See :ref:`cmake-instrumentation API v1`
for details of the ``API_VERSION`` and :ref:`cmake-instrumentation Data v1` for details
of the ``DATA_VERSION``.
Each of the optional keywords ``HOOKS``, ``QUERIES``, and ``CALLBACK``
correspond to one of the parameters to the :ref:`cmake-instrumentation v1 Query Files`.
The ``CALLBACK`` keyword can be provided multiple times to create multiple callbacks.
Whenever ``cmake_instrumentation`` is invoked, a query file is generated in
``<build>/.cmake/instrumentation/v1/query/generated`` to enable instrumentation
with the provided arguments.
Example
^^^^^^^
The following example shows an invocation of the command and its
equivalent JSON query file.
.. code-block:: cmake
cmake_instrumentation(
API_VERSION 1
DATA_VERSION 1
HOOKS postGenerate preCMakeBuild postCMakeBuild
QUERIES staticSystemInformation dynamicSystemInformation
CALLBACK ${CMAKE_COMMAND} -P /path/to/handle_data.cmake
CALLBACK ${CMAKE_COMMAND} -P /path/to/handle_data_2.cmake
)
.. code-block:: json
{
"version": 1,
"hooks": [
"postGenerate", "preCMakeBuild", "postCMakeBuild"
],
"queries": [
"staticSystemInformation", "dynamicSystemInformation"
],
"callbacks": [
"/path/to/cmake -P /path/to/handle_data.cmake"
"/path/to/cmake -P /path/to/handle_data_2.cmake"
]
}

View File

@@ -1,41 +0,0 @@
unset
-----
Unset a variable, cache variable, or environment variable.
Unset Normal Variable or Cache Entry
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. code-block:: cmake
unset(<variable> [CACHE | PARENT_SCOPE])
Removes a normal variable from the current scope, causing it
to become undefined. If ``CACHE`` is present, then a cache variable
is removed instead of a normal variable.
If ``PARENT_SCOPE`` is present then the variable is removed from the scope
above the current scope. See the same option in the :command:`set` command
for further details.
.. include:: include/UNSET_NOTE.rst
Unset Environment Variable
^^^^^^^^^^^^^^^^^^^^^^^^^^
.. code-block:: cmake
unset(ENV{<variable>})
Removes ``<variable>`` from the currently available
:manual:`Environment Variables <cmake-env-variables(7)>`.
Subsequent calls of ``$ENV{<variable>}`` will return the empty string.
This command affects only the current CMake process, not the process
from which CMake was called, nor the system environment at large,
nor the environment of subsequent build or test processes.
See Also
^^^^^^^^
* :command:`set`

View File

@@ -1,16 +0,0 @@
POSITION_INDEPENDENT_CODE
-------------------------
Whether to create a position-independent target
The ``POSITION_INDEPENDENT_CODE`` property determines whether position
independent executables or libraries will be created. This
property is ``True`` by default for ``SHARED`` and ``MODULE`` library
targets. For other targets, this property is initialized by the value
of the :variable:`CMAKE_POSITION_INDEPENDENT_CODE` variable if it is set
when the target is created, or ``False`` otherwise.
.. note::
For executable targets, the link step is controlled by the :policy:`CMP0083`
policy and the :module:`CheckPIESupported` module.

View File

@@ -1,7 +0,0 @@
CMAKE_DL_LIBS
-------------
Name of library containing ``dlopen`` and ``dlclose``.
The name of the library that has ``dlopen`` and ``dlclose`` in it, usually
``-ldl`` on most UNIX machines.

View File

@@ -1,41 +0,0 @@
CMAKE_FIND_PACKAGE_SORT_ORDER
-----------------------------
.. versionadded:: 3.7
The default order for sorting directories which match a search path containing
a glob expression found using :command:`find_package`. It can assume one of
the following values:
``NONE``
Default. No attempt is done to sort directories.
The first valid package found will be selected.
``NAME``
Sort directories lexicographically before searching.
``NATURAL``
Sort directories using natural order (see ``strverscmp(3)`` manual),
i.e. such that contiguous digits are compared as whole numbers.
Natural sorting can be employed to return the highest version when multiple
versions of the same library are available to be found by
:command:`find_package`. For example suppose that the following libraries
have package configuration files on disk, in a directory of the same name,
with all such directories residing in the same parent directory:
* libX-1.1.0
* libX-1.2.9
* libX-1.2.10
By setting ``NATURAL`` order we can select the one with the highest
version number ``libX-1.2.10``.
.. code-block:: cmake
set(CMAKE_FIND_PACKAGE_SORT_ORDER NATURAL)
find_package(libX CONFIG)
The sort direction can be controlled using the
:variable:`CMAKE_FIND_PACKAGE_SORT_DIRECTION` variable
(by default descending, e.g. lib-B will be tested before lib-A).

View File

@@ -1,27 +0,0 @@
CMAKE_GLOBAL_AUTOGEN_TARGET
---------------------------
.. versionadded:: 3.14
Switch to enable generation of a global ``autogen`` target.
When ``CMAKE_GLOBAL_AUTOGEN_TARGET`` is enabled, a custom target
``autogen`` is generated. This target depends on all :prop_tgt:`AUTOMOC` and
:prop_tgt:`AUTOUIC` generated :ref:`<ORIGIN>_autogen` targets in the project.
By building the global ``autogen`` target, all :prop_tgt:`AUTOMOC` and
:prop_tgt:`AUTOUIC` files in the project will be generated.
The name of the global ``autogen`` target can be changed by setting
:variable:`CMAKE_GLOBAL_AUTOGEN_TARGET_NAME`.
By default ``CMAKE_GLOBAL_AUTOGEN_TARGET`` is unset.
See the :manual:`cmake-qt(7)` manual for more information on using CMake
with Qt.
.. note::
:ref:`<ORIGIN>_autogen` targets by default inherit their origin target's
dependencies. This might result in unintended dependency target builds when
only :ref:`<ORIGIN>_autogen` targets are built. A solution is to disable
:prop_tgt:`AUTOGEN_ORIGIN_DEPENDS` on the respective origin targets.

View File

@@ -1,20 +0,0 @@
CMAKE_<LANG>_BYTE_ORDER
-----------------------
.. versionadded:: 3.20
Byte order of ``<LANG>`` compiler target architecture, if known.
If defined and not empty, the value is one of:
``BIG_ENDIAN``
The target architecture is Big Endian.
``LITTLE_ENDIAN``
The target architecture is Little Endian.
This is defined for languages ``C``, ``CXX``, ``OBJC``, ``OBJCXX``,
and ``CUDA``.
If :variable:`CMAKE_OSX_ARCHITECTURES` specifies multiple architectures, the
value of ``CMAKE_<LANG>_BYTE_ORDER`` is non-empty only if all architectures
share the same byte order.

View File

@@ -1,9 +0,0 @@
CMAKE_POSITION_INDEPENDENT_CODE
-------------------------------
Default value for :prop_tgt:`POSITION_INDEPENDENT_CODE` of targets.
This variable is used to initialize the
:prop_tgt:`POSITION_INDEPENDENT_CODE` property on targets that
are not ``SHARED`` or ``MODULE`` library targets.
If set, its value is also used by the :command:`try_compile` command.

View File

@@ -1,33 +0,0 @@
# Distributed under the OSI-approved BSD 3-Clause License. See accompanying
# file LICENSE.rst or https://cmake.org/licensing for details.
#[=======================================================================[.rst:
AddFileDependencies
-------------------
.. deprecated:: 3.20
Add dependencies to a source file.
.. code-block:: cmake
add_file_dependencies(<source> <files>...)
Adds the given ``<files>`` to the dependencies of file ``<source>``.
Do not use this command in new code. It is just a wrapper around:
.. code-block:: cmake
set_property(SOURCE <source> APPEND PROPERTY OBJECT_DEPENDS <files>...)
Instead use the :command:`set_property` command to append to the
:prop_sf:`OBJECT_DEPENDS` source file property directly.
#]=======================================================================]
function(add_file_dependencies _file)
set_property(SOURCE "${_file}" APPEND PROPERTY OBJECT_DEPENDS "${ARGN}")
endfunction()

View File

@@ -1,41 +0,0 @@
# Distributed under the OSI-approved BSD 3-Clause License. See accompanying
# file LICENSE.rst or https://cmake.org/licensing for details.
# Do NOT include this module directly into any of your code. It is meant as
# a library for Check*CompilerFlag.cmake modules. It's content may change in
# any way between releases.
macro (CHECK_COMPILER_FLAG_COMMON_PATTERNS _VAR)
set(${_VAR}
FAIL_REGEX "[Uu]nrecogni[sz]ed .*option" # GNU, NAG, Fujitsu
FAIL_REGEX "switch .* is no longer supported" # GNU
FAIL_REGEX "unknown .*option" # Clang
FAIL_REGEX "optimization flag .* not supported" # Clang
FAIL_REGEX "unknown argument ignored" # Clang (cl)
FAIL_REGEX "ignoring unknown option" # MSVC, Intel
FAIL_REGEX "warning D9002" # MSVC, any lang
FAIL_REGEX "option.*not supported" # Intel
FAIL_REGEX "invalid argument .*option" # Intel
FAIL_REGEX "ignoring option .*argument required" # Intel
FAIL_REGEX "ignoring option .*argument is of wrong type" # Intel
# noqa: spellcheck off
FAIL_REGEX "[Uu]nknown option" # HP
# noqa: spellcheck on
FAIL_REGEX "[Ww]arning: [Oo]ption" # SunPro
FAIL_REGEX "command option .* is not recognized" # XL
FAIL_REGEX "command option .* contains an incorrect subargument" # XL
FAIL_REGEX "Option .* is not recognized. Option will be ignored." # XL
FAIL_REGEX "not supported in this configuration. ignored" # AIX
FAIL_REGEX "File with unknown suffix passed to linker" # PGI
# noqa: spellcheck off
FAIL_REGEX "[Uu]nknown switch" # PGI
# noqa: spellcheck on
FAIL_REGEX "WARNING: unknown flag:" # Open64
FAIL_REGEX "Incorrect command line option:" # Borland
FAIL_REGEX "Warning: illegal option" # SunStudio 12
FAIL_REGEX "[Ww]arning: Invalid suboption" # Fujitsu
FAIL_REGEX "An invalid option .* appears on the command line" # Cray
FAIL_REGEX "WARNING: invalid compiler option" # TI armcl
)
endmacro ()

View File

@@ -1,114 +0,0 @@
# Distributed under the OSI-approved BSD 3-Clause License. See accompanying
# file LICENSE.rst or https://cmake.org/licensing for details.
#[=======================================================================[.rst:
CMakeForceCompiler
------------------
.. deprecated:: 3.6
Do not use.
The macros provided by this module were once intended for use by
cross-compiling toolchain files when CMake was not able to automatically
detect the compiler identification. Since the introduction of this module,
CMake's compiler identification capabilities have improved and can now be
taught to recognize any compiler. Furthermore, the suite of information
CMake detects from a compiler is now too extensive to be provided by
toolchain files using these macros.
One common use case for this module was to skip CMake's checks for a
working compiler when using a cross-compiler that cannot link binaries
without special flags or custom linker scripts. This case is now supported
by setting the :variable:`CMAKE_TRY_COMPILE_TARGET_TYPE` variable in the
toolchain file instead.
-------------------------------------------------------------------------
Macro ``CMAKE_FORCE_C_COMPILER`` has the following signature:
.. code-block:: cmake
CMAKE_FORCE_C_COMPILER(<compiler> <compiler-id>)
It sets :variable:`CMAKE_C_COMPILER <CMAKE_<LANG>_COMPILER>` to
the given compiler and the cmake internal variable
:variable:`CMAKE_C_COMPILER_ID <CMAKE_<LANG>_COMPILER_ID>` to the given
compiler-id. It also bypasses the check for working compiler and basic
compiler information tests.
Macro ``CMAKE_FORCE_CXX_COMPILER`` has the following signature:
.. code-block:: cmake
CMAKE_FORCE_CXX_COMPILER(<compiler> <compiler-id>)
It sets :variable:`CMAKE_CXX_COMPILER <CMAKE_<LANG>_COMPILER>` to
the given compiler and the cmake internal variable
:variable:`CMAKE_CXX_COMPILER_ID <CMAKE_<LANG>_COMPILER_ID>` to the given
compiler-id. It also bypasses the check for working compiler and basic
compiler information tests.
Macro ``CMAKE_FORCE_Fortran_COMPILER`` has the following signature:
.. code-block:: cmake
CMAKE_FORCE_Fortran_COMPILER(<compiler> <compiler-id>)
It sets :variable:`CMAKE_Fortran_COMPILER <CMAKE_<LANG>_COMPILER>` to
the given compiler and the cmake internal variable
:variable:`CMAKE_Fortran_COMPILER_ID <CMAKE_<LANG>_COMPILER_ID>` to the given
compiler-id. It also bypasses the check for working compiler and basic
compiler information tests.
So a simple toolchain file could look like this:
.. code-block:: cmake
include (CMakeForceCompiler)
set(CMAKE_SYSTEM_NAME Generic)
CMAKE_FORCE_C_COMPILER (chc12 MetrowerksHicross)
CMAKE_FORCE_CXX_COMPILER (chc12 MetrowerksHicross)
#]=======================================================================]
macro(CMAKE_FORCE_C_COMPILER compiler id)
message(DEPRECATION "The CMAKE_FORCE_C_COMPILER macro is deprecated. "
"Instead just set CMAKE_C_COMPILER and allow CMake to identify the compiler.")
set(CMAKE_C_COMPILER "${compiler}")
set(CMAKE_C_COMPILER_ID_RUN TRUE)
set(CMAKE_C_COMPILER_ID ${id})
set(CMAKE_C_COMPILER_FORCED TRUE)
# Set old compiler id variables.
if(CMAKE_C_COMPILER_ID MATCHES "GNU")
set(CMAKE_COMPILER_IS_GNUCC 1)
endif()
endmacro()
macro(CMAKE_FORCE_CXX_COMPILER compiler id)
message(DEPRECATION "The CMAKE_FORCE_CXX_COMPILER macro is deprecated. "
"Instead just set CMAKE_CXX_COMPILER and allow CMake to identify the compiler.")
set(CMAKE_CXX_COMPILER "${compiler}")
set(CMAKE_CXX_COMPILER_ID_RUN TRUE)
set(CMAKE_CXX_COMPILER_ID ${id})
set(CMAKE_CXX_COMPILER_FORCED TRUE)
# Set old compiler id variables.
if("${CMAKE_CXX_COMPILER_ID}" MATCHES "GNU")
set(CMAKE_COMPILER_IS_GNUCXX 1)
endif()
endmacro()
macro(CMAKE_FORCE_Fortran_COMPILER compiler id)
message(DEPRECATION "The CMAKE_FORCE_Fortran_COMPILER macro is deprecated. "
"Instead just set CMAKE_Fortran_COMPILER and allow CMake to identify the compiler.")
set(CMAKE_Fortran_COMPILER "${compiler}")
set(CMAKE_Fortran_COMPILER_ID_RUN TRUE)
set(CMAKE_Fortran_COMPILER_ID ${id})
set(CMAKE_Fortran_COMPILER_FORCED TRUE)
# Set old compiler id variables.
if(CMAKE_Fortran_COMPILER_ID MATCHES "GNU")
set(CMAKE_COMPILER_IS_GNUG77 1)
endif()
endmacro()

View File

@@ -1,150 +0,0 @@
# Distributed under the OSI-approved BSD 3-Clause License. See accompanying
# file LICENSE.rst or https://cmake.org/licensing for details.
#[=======================================================================[.rst:
CMakeGraphVizOptions
--------------------
The builtin Graphviz support of CMake.
Generating Graphviz files
^^^^^^^^^^^^^^^^^^^^^^^^^
CMake can generate `Graphviz <https://www.graphviz.org/>`_ files showing the
dependencies between the targets in a project, as well as external libraries
which are linked against.
When running CMake with the ``--graphviz=foo.dot`` option, it produces:
* a ``foo.dot`` file, showing all dependencies in the project
* a ``foo.dot.<target>`` file for each target, showing on which other targets
it depends
* a ``foo.dot.<target>.dependers`` file for each target, showing which other
targets depend on it
Those .dot files can be converted to images using the *dot* command from the
Graphviz package:
.. code-block:: shell
dot -Tpng -o foo.png foo.dot
.. versionadded:: 3.10
The different dependency types ``PUBLIC``, ``INTERFACE`` and ``PRIVATE``
are represented as solid, dashed and dotted edges.
Variables specific to the Graphviz support
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The resulting graphs can be huge. The look and content of the generated graphs
can be controlled using the file ``CMakeGraphVizOptions.cmake``. This file is
first searched in :variable:`CMAKE_BINARY_DIR`, and then in
:variable:`CMAKE_SOURCE_DIR`. If found, the variables set in it are used to
adjust options for the generated Graphviz files.
.. variable:: GRAPHVIZ_GRAPH_NAME
The graph name.
* Mandatory: NO
* Default: value of :variable:`CMAKE_PROJECT_NAME`
.. variable:: GRAPHVIZ_GRAPH_HEADER
The header written at the top of the Graphviz files.
* Mandatory: NO
* Default: "node [ fontsize = "12" ];"
.. variable:: GRAPHVIZ_NODE_PREFIX
The prefix for each node in the Graphviz files.
* Mandatory: NO
* Default: "node"
.. variable:: GRAPHVIZ_EXECUTABLES
Set to FALSE to exclude executables from the generated graphs.
* Mandatory: NO
* Default: TRUE
.. variable:: GRAPHVIZ_STATIC_LIBS
Set to FALSE to exclude static libraries from the generated graphs.
* Mandatory: NO
* Default: TRUE
.. variable:: GRAPHVIZ_SHARED_LIBS
Set to FALSE to exclude shared libraries from the generated graphs.
* Mandatory: NO
* Default: TRUE
.. variable:: GRAPHVIZ_MODULE_LIBS
Set to FALSE to exclude module libraries from the generated graphs.
* Mandatory: NO
* Default: TRUE
.. variable:: GRAPHVIZ_INTERFACE_LIBS
Set to FALSE to exclude interface libraries from the generated graphs.
* Mandatory: NO
* Default: TRUE
.. variable:: GRAPHVIZ_OBJECT_LIBS
Set to FALSE to exclude object libraries from the generated graphs.
* Mandatory: NO
* Default: TRUE
.. variable:: GRAPHVIZ_UNKNOWN_LIBS
Set to FALSE to exclude unknown libraries from the generated graphs.
* Mandatory: NO
* Default: TRUE
.. variable:: GRAPHVIZ_EXTERNAL_LIBS
Set to FALSE to exclude external libraries from the generated graphs.
* Mandatory: NO
* Default: TRUE
.. variable:: GRAPHVIZ_CUSTOM_TARGETS
Set to TRUE to include custom targets in the generated graphs.
* Mandatory: NO
* Default: FALSE
.. variable:: GRAPHVIZ_IGNORE_TARGETS
A list of regular expressions for names of targets to exclude from the
generated graphs.
* Mandatory: NO
* Default: empty
.. variable:: GRAPHVIZ_GENERATE_PER_TARGET
Set to FALSE to not generate per-target graphs ``foo.dot.<target>``.
* Mandatory: NO
* Default: TRUE
.. variable:: GRAPHVIZ_GENERATE_DEPENDERS
Set to FALSE to not generate depender graphs ``foo.dot.<target>.dependers``.
* Mandatory: NO
* Default: TRUE
#]=======================================================================]

View File

@@ -1,10 +0,0 @@
include(Compiler/GHS)
set(CMAKE_C_VERBOSE_FLAG "-v")
set(CMAKE_C_OUTPUT_EXTENSION ".o")
string(APPEND CMAKE_C_FLAGS_INIT " ")
string(APPEND CMAKE_C_FLAGS_DEBUG_INIT " -Odebug -g")
string(APPEND CMAKE_C_FLAGS_MINSIZEREL_INIT " -Ospace")
string(APPEND CMAKE_C_FLAGS_RELEASE_INIT " -O")
string(APPEND CMAKE_C_FLAGS_RELWITHDEBINFO_INIT " -O -g")

View File

@@ -1,10 +0,0 @@
include(Compiler/GHS)
set(CMAKE_CXX_VERBOSE_FLAG "-v")
set(CMAKE_CXX_OUTPUT_EXTENSION ".o")
string(APPEND CMAKE_CXX_FLAGS_INIT " ")
string(APPEND CMAKE_CXX_FLAGS_DEBUG_INIT " -Odebug -g")
string(APPEND CMAKE_CXX_FLAGS_MINSIZEREL_INIT " -Ospace")
string(APPEND CMAKE_CXX_FLAGS_RELEASE_INIT " -O")
string(APPEND CMAKE_CXX_FLAGS_RELWITHDEBINFO_INIT " -O -g")

View File

@@ -1,103 +0,0 @@
# Distributed under the OSI-approved BSD 3-Clause License. See accompanying
# file LICENSE.rst or https://cmake.org/licensing for details.
#[=======================================================================[.rst:
FindKDE4
--------
Find KDE4 and provide all necessary variables and macros to compile
software for it. It looks for KDE 4 in the following directories in
the given order:
::
CMAKE_INSTALL_PREFIX
KDEDIRS
/opt/kde4
Please look in ``FindKDE4Internal.cmake`` and ``KDE4Macros.cmake`` for more
information. They are installed with the KDE 4 libraries in
$KDEDIRS/share/apps/cmake/modules/.
Author: Alexander Neundorf <neundorf@kde.org>
#]=======================================================================]
# If Qt3 has already been found, fail.
if(QT_QT_LIBRARY)
if(KDE4_FIND_REQUIRED)
message( FATAL_ERROR "KDE4/Qt4 and Qt3 cannot be used together in one project.")
else()
if(NOT KDE4_FIND_QUIETLY)
message( STATUS "KDE4/Qt4 and Qt3 cannot be used together in one project.")
endif()
return()
endif()
endif()
file(TO_CMAKE_PATH "$ENV{KDEDIRS}" _KDEDIRS)
# when cross compiling, searching kde4-config in order to run it later on
# doesn't make a lot of sense. We'll have to do something about this.
# Searching always in the target environment ? Then we get at least the correct one,
# still it can't be used to run it. Alex
# For KDE4 kde-config has been renamed to kde4-config
find_program(KDE4_KDECONFIG_EXECUTABLE NAMES kde4-config
# the suffix must be used since KDEDIRS can be a list of directories which don't have bin/ appended
PATH_SUFFIXES bin
HINTS
${CMAKE_INSTALL_PREFIX}
${_KDEDIRS}
/opt/kde4
ONLY_CMAKE_FIND_ROOT_PATH
)
if (NOT KDE4_KDECONFIG_EXECUTABLE)
if (KDE4_FIND_REQUIRED)
message(FATAL_ERROR "ERROR: Could not find KDE4 kde4-config")
endif ()
endif ()
# when cross compiling, KDE4_DATA_DIR may be already preset
if(NOT KDE4_DATA_DIR)
if(CMAKE_CROSSCOMPILING)
# when cross compiling, don't run kde4-config but use its location as install dir
get_filename_component(KDE4_DATA_DIR "${KDE4_KDECONFIG_EXECUTABLE}" PATH)
get_filename_component(KDE4_DATA_DIR "${KDE4_DATA_DIR}" PATH)
else()
# then ask kde4-config for the kde data dirs
if(KDE4_KDECONFIG_EXECUTABLE)
execute_process(COMMAND "${KDE4_KDECONFIG_EXECUTABLE}" --path data OUTPUT_VARIABLE _data_DIR ERROR_QUIET OUTPUT_STRIP_TRAILING_WHITESPACE)
file(TO_CMAKE_PATH "${_data_DIR}" _data_DIR)
# then check the data dirs for FindKDE4Internal.cmake
find_path(KDE4_DATA_DIR cmake/modules/FindKDE4Internal.cmake HINTS ${_data_DIR})
endif()
endif()
endif()
# if it has been found...
if (KDE4_DATA_DIR)
set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} ${KDE4_DATA_DIR}/cmake/modules)
if (KDE4_FIND_QUIETLY)
set(_quiet QUIET)
endif ()
if (KDE4_FIND_REQUIRED)
set(_req REQUIRED)
endif ()
# use FindKDE4Internal.cmake to do the rest
find_package(KDE4Internal ${_req} ${_quiet} NO_POLICY_SCOPE)
else ()
if (KDE4_FIND_REQUIRED)
message(FATAL_ERROR "ERROR: cmake/modules/FindKDE4Internal.cmake not found in ${_data_DIR}")
endif ()
endif ()

View File

@@ -1,292 +0,0 @@
# Distributed under the OSI-approved BSD 3-Clause License. See accompanying
# file LICENSE.rst or https://cmake.org/licensing for details.
cmake_minimum_required(VERSION 3.30)
cmake_policy(SET CMP0174 NEW) # TODO: Remove this when we can update the above to 3.31
function(add_command name test_name)
set(args "")
foreach(arg ${ARGN})
if(arg MATCHES "[^-./:a-zA-Z0-9_]")
string(APPEND args " [==[${arg}]==]")
else()
string(APPEND args " ${arg}")
endif()
endforeach()
string(APPEND script "${name}(${test_name} ${args})\n")
set(script "${script}" PARENT_SCOPE)
endfunction()
function(generate_testname_guards output open_guard_var close_guard_var)
set(open_guard "[=[")
set(close_guard "]=]")
set(counter 1)
while("${output}" MATCHES "${close_guard}")
math(EXPR counter "${counter} + 1")
string(REPEAT "=" ${counter} equals)
set(open_guard "[${equals}[")
set(close_guard "]${equals}]")
endwhile()
set(${open_guard_var} "${open_guard}" PARENT_SCOPE)
set(${close_guard_var} "${close_guard}" PARENT_SCOPE)
endfunction()
function(escape_square_brackets output bracket placeholder placeholder_var output_var)
if("${output}" MATCHES "\\${bracket}")
set(placeholder "${placeholder}")
while("${output}" MATCHES "${placeholder}")
set(placeholder "${placeholder}_")
endwhile()
string(REPLACE "${bracket}" "${placeholder}" output "${output}")
set(${placeholder_var} "${placeholder}" PARENT_SCOPE)
set(${output_var} "${output}" PARENT_SCOPE)
endif()
endfunction()
function(gtest_discover_tests_impl)
set(options "")
set(oneValueArgs
NO_PRETTY_TYPES # These two take a value, unlike gtest_discover_tests()
NO_PRETTY_VALUES #
TEST_EXECUTABLE
TEST_WORKING_DIR
TEST_PREFIX
TEST_SUFFIX
TEST_LIST
CTEST_FILE
TEST_DISCOVERY_TIMEOUT
TEST_XML_OUTPUT_DIR
# The following are all multi-value arguments in gtest_discover_tests(),
# but they are each given to us as a single argument. We parse them that
# way to avoid problems with preserving empty list values and escaping.
TEST_FILTER
TEST_EXTRA_ARGS
TEST_DISCOVERY_EXTRA_ARGS
TEST_PROPERTIES
TEST_EXECUTOR
)
set(multiValueArgs "")
cmake_parse_arguments(PARSE_ARGV 0 arg
"${options}" "${oneValueArgs}" "${multiValueArgs}"
)
set(prefix "${arg_TEST_PREFIX}")
set(suffix "${arg_TEST_SUFFIX}")
set(script)
set(suite)
set(tests)
set(tests_buffer "")
# If a file at ${arg_CTEST_FILE} already exists, we overwrite it.
# For performance reasons, we write to this file in chunks, and this variable
# is updated to APPEND after the first write.
set(file_write_mode WRITE)
if(arg_TEST_FILTER)
set(filter "--gtest_filter=${arg_TEST_FILTER}")
else()
set(filter)
endif()
# CMP0178 has already been handled in gtest_discover_tests(), so we only need
# to implement NEW behavior here. This means preserving empty arguments for
# TEST_EXECUTOR. For OLD or WARN, gtest_discover_tests() already removed any
# empty arguments.
set(launcherArgs "")
if(NOT "${arg_TEST_EXECUTOR}" STREQUAL "")
list(JOIN arg_TEST_EXECUTOR "]==] [==[" launcherArgs)
set(launcherArgs "[==[${launcherArgs}]==]")
endif()
# Run test executable to get list of available tests
if(NOT EXISTS "${arg_TEST_EXECUTABLE}")
message(FATAL_ERROR
"Specified test executable does not exist.\n"
" Path: '${arg_TEST_EXECUTABLE}'"
)
endif()
set(discovery_extra_args "")
if(NOT "${arg_TEST_DISCOVERY_EXTRA_ARGS}" STREQUAL "")
list(JOIN arg_TEST_DISCOVERY_EXTRA_ARGS "]==] [==[" discovery_extra_args)
set(discovery_extra_args "[==[${discovery_extra_args}]==]")
endif()
cmake_language(EVAL CODE
"execute_process(
COMMAND ${launcherArgs} [==[${arg_TEST_EXECUTABLE}]==] --gtest_list_tests ${filter} ${discovery_extra_args}
WORKING_DIRECTORY [==[${arg_TEST_WORKING_DIR}]==]
TIMEOUT ${arg_TEST_DISCOVERY_TIMEOUT}
OUTPUT_VARIABLE output
RESULT_VARIABLE result
)"
)
if(NOT ${result} EQUAL 0)
string(REPLACE "\n" "\n " output "${output}")
if(arg_TEST_EXECUTOR)
set(path "${arg_TEST_EXECUTOR} ${arg_TEST_EXECUTABLE}")
else()
set(path "${arg_TEST_EXECUTABLE}")
endif()
message(FATAL_ERROR
"Error running test executable.\n"
" Path: '${path}'\n"
" Working directory: '${arg_TEST_WORKING_DIR}'\n"
" Result: ${result}\n"
" Output:\n"
" ${output}\n"
)
endif()
generate_testname_guards("${output}" open_guard close_guard)
escape_square_brackets("${output}" "[" "__osb" open_sb output)
escape_square_brackets("${output}" "]" "__csb" close_sb output)
# Preserve semicolon in test-parameters
string(REPLACE [[;]] [[\;]] output "${output}")
string(REPLACE "\n" ";" output "${output}")
# Parse output
foreach(line ${output})
# Skip header
if(NOT line MATCHES "gtest_main\\.cc")
# Do we have a module name or a test name?
if(NOT line MATCHES "^ ")
# Module; remove trailing '.' to get just the name...
string(REGEX REPLACE "\\.( *#.*)?$" "" suite "${line}")
if(line MATCHES "#")
string(REGEX REPLACE "/[0-9].*" "" pretty_suite "${line}")
if(NOT arg_NO_PRETTY_TYPES)
string(REGEX REPLACE ".*/[0-9]+[ .#]+TypeParam = (.*)" "\\1" type_parameter "${line}")
else()
string(REGEX REPLACE ".*/([0-9]+)[ .#]+TypeParam = .*" "\\1" type_parameter "${line}")
endif()
set(test_name_template "@prefix@@pretty_suite@.@pretty_test@<@type_parameter@>@suffix@")
else()
set(pretty_suite "${suite}")
set(test_name_template "@prefix@@pretty_suite@.@pretty_test@@suffix@")
endif()
string(REGEX REPLACE "^DISABLED_" "" pretty_suite "${pretty_suite}")
else()
string(STRIP "${line}" test)
if(test MATCHES "#" AND NOT arg_NO_PRETTY_VALUES)
string(REGEX REPLACE "/[0-9]+[ #]+GetParam\\(\\) = " "/" pretty_test "${test}")
else()
string(REGEX REPLACE " +#.*" "" pretty_test "${test}")
endif()
string(REGEX REPLACE "^DISABLED_" "" pretty_test "${pretty_test}")
string(REGEX REPLACE " +#.*" "" test "${test}")
if(NOT "${arg_TEST_XML_OUTPUT_DIR}" STREQUAL "")
set(TEST_XML_OUTPUT_PARAM "--gtest_output=xml:${arg_TEST_XML_OUTPUT_DIR}/${prefix}${suite}.${test}${suffix}.xml")
else()
unset(TEST_XML_OUTPUT_PARAM)
endif()
string(CONFIGURE "${test_name_template}" testname)
# unescape []
if(open_sb)
string(REPLACE "${open_sb}" "[" testname "${testname}")
endif()
if(close_sb)
string(REPLACE "${close_sb}" "]" testname "${testname}")
endif()
set(guarded_testname "${open_guard}${testname}${close_guard}")
# Add to script. Do not use add_command() here because it messes up the
# handling of empty values when forwarding arguments, and we need to
# preserve those carefully for arg_TEST_EXECUTOR and arg_EXTRA_ARGS.
string(APPEND script "add_test(${guarded_testname} ${launcherArgs}")
foreach(arg IN ITEMS
"${arg_TEST_EXECUTABLE}"
"--gtest_filter=${suite}.${test}"
"--gtest_also_run_disabled_tests"
${TEST_XML_OUTPUT_PARAM}
)
if(arg MATCHES "[^-./:a-zA-Z0-9_]")
string(APPEND script " [==[${arg}]==]")
else()
string(APPEND script " ${arg}")
endif()
endforeach()
if(arg_TEST_EXTRA_ARGS)
list(JOIN arg_TEST_EXTRA_ARGS "]==] [==[" extra_args)
string(APPEND script " [==[${extra_args}]==]")
endif()
string(APPEND script ")\n")
set(maybe_disabled "")
if(suite MATCHES "^DISABLED_" OR test MATCHES "^DISABLED_")
set(maybe_disabled DISABLED TRUE)
endif()
add_command(set_tests_properties
"${guarded_testname}"
PROPERTIES
${maybe_disabled}
WORKING_DIRECTORY "${arg_TEST_WORKING_DIR}"
SKIP_REGULAR_EXPRESSION "\\[ SKIPPED \\]"
${arg_TEST_PROPERTIES}
)
# possibly unbalanced square brackets render lists invalid so skip such
# tests in ${arg_TEST_LIST}
if(NOT "${testname}" MATCHES [=[(\[|\])]=])
# escape ;
string(REPLACE [[;]] [[\\;]] testname "${testname}")
list(APPEND tests_buffer "${testname}")
list(LENGTH tests_buffer tests_buffer_length)
if(tests_buffer_length GREATER "250")
# Chunk updates to the final "tests" variable, keeping the
# "tests_buffer" variable that we append each test to relatively
# small. This mitigates worsening performance impacts for the
# corner case of having many thousands of tests.
list(APPEND tests "${tests_buffer}")
set(tests_buffer "")
endif()
endif()
endif()
# If we've built up a sizable script so far, write it out as a chunk now
# so we don't accumulate a massive string to write at the end
string(LENGTH "${script}" script_len)
if(${script_len} GREATER "50000")
file(${file_write_mode} "${arg_CTEST_FILE}" "${script}")
set(file_write_mode APPEND)
set(script "")
endif()
endif()
endforeach()
if(NOT tests_buffer STREQUAL "")
list(APPEND tests "${tests_buffer}")
endif()
# Create a list of all discovered tests, which users may use to e.g. set
# properties on the tests
add_command(set "" ${arg_TEST_LIST} "${tests}")
# Write remaining content to the CTest script
file(${file_write_mode} "${arg_CTEST_FILE}" "${script}")
endfunction()
if(CMAKE_SCRIPT_MODE_FILE)
gtest_discover_tests_impl(
NO_PRETTY_TYPES ${NO_PRETTY_TYPES}
NO_PRETTY_VALUES ${NO_PRETTY_VALUES}
TEST_EXECUTABLE ${TEST_EXECUTABLE}
TEST_EXECUTOR "${TEST_EXECUTOR}"
TEST_WORKING_DIR ${TEST_WORKING_DIR}
TEST_PREFIX ${TEST_PREFIX}
TEST_SUFFIX ${TEST_SUFFIX}
TEST_FILTER ${TEST_FILTER}
TEST_LIST ${TEST_LIST}
CTEST_FILE ${CTEST_FILE}
TEST_DISCOVERY_TIMEOUT ${TEST_DISCOVERY_TIMEOUT}
TEST_XML_OUTPUT_DIR ${TEST_XML_OUTPUT_DIR}
TEST_EXTRA_ARGS "${TEST_EXTRA_ARGS}"
TEST_DISCOVERY_EXTRA_ARGS "${TEST_DISCOVERY_EXTRA_ARGS}"
TEST_PROPERTIES "${TEST_PROPERTIES}"
)
endif()

View File

@@ -1,29 +0,0 @@
# Distributed under the OSI-approved BSD 3-Clause License. See accompanying
# file LICENSE.rst or https://cmake.org/licensing for details.
#[=======================================================================[.rst:
MacroAddFileDependencies
------------------------
.. deprecated:: 3.14
.. code-block:: cmake
macro_add_file_dependencies(<source> <files>...)
Do not use this command in new code. It is just a wrapper around:
.. code-block:: cmake
set_property(SOURCE <source> APPEND PROPERTY OBJECT_DEPENDS <files>...)
Instead use the :command:`set_property` command to append to the
:prop_sf:`OBJECT_DEPENDS` source file property directly.
#]=======================================================================]
macro (MACRO_ADD_FILE_DEPENDENCIES _file)
set_property(SOURCE "${_file}" APPEND PROPERTY OBJECT_DEPENDS "${ARGN}")
endmacro ()

View File

@@ -357,6 +357,7 @@ The options are:
Execute the command with the given current working directory.
If it is a relative path, it will be interpreted relative to the
build tree directory corresponding to the current source directory.
If not specified, set to :variable:`CMAKE_CURRENT_BINARY_DIR`.
This option is currently ignored if ``APPEND`` is given, but a future
version may use it.

View File

@@ -191,6 +191,7 @@ The options are:
Execute the command with the given current working directory.
If it is a relative path it will be interpreted relative to the
build tree directory corresponding to the current source directory.
If not specified, set to :variable:`CMAKE_CURRENT_BINARY_DIR`.
.. versionadded:: 3.13
Arguments to ``WORKING_DIRECTORY`` may use

View File

@@ -196,6 +196,30 @@ Interface Libraries
call are ``PRIVATE`` to the interface library and do not appear in its
:prop_tgt:`INTERFACE_SOURCES` target property.
.. signature::
add_library(<name> INTERFACE SYMBOLIC)
:target: INTERFACE-SYMBOLIC
.. versionadded:: 4.2
Add a symbolic :ref:`Interface Library <Interface Libraries>` target.
Symbolic interface libraries are useful for representing optional components
or features in a package. They have no usage requirements, do not compile
sources, and do not produce a library artifact on disk, but they may be
exported and installed. They can also be tested for existence with the
regular :command:`if(TARGET)` subcommand.
A symbolic interface library may be used as a linkable target to enforce the
presence of optional components in a dependency. For example, if a library
``libgui`` may or may not provide a feature ``widget``, a consumer package
can link against ``widget`` to express that it requires this component to be
available. This allows :command:`find_package` calls that declare required
components to be validated by linking against the corresponding symbolic
targets.
A symbolic interface library has the :prop_tgt:`SYMBOLIC` target property
set to true.
.. _`add_library imported libraries`:
Imported Libraries

View File

@@ -114,4 +114,5 @@ Add a test called ``<name>`` with the given command-line.
Unlike the above ``NAME`` signature, target names are not supported
in the command-line. Furthermore, tests added with this signature do not
support :manual:`generator expressions <cmake-generator-expressions(7)>`
in the command-line or test properties.
in the command-line or test properties, and the :prop_tgt:`TEST_LAUNCHER`
and :prop_tgt:`CROSSCOMPILING_EMULATOR` target properties are not supported.

View File

@@ -0,0 +1,117 @@
cmake_instrumentation
---------------------
.. versionadded:: 4.0
.. note::
This command is only available when experimental support for instrumentation
has been enabled by the ``CMAKE_EXPERIMENTAL_INSTRUMENTATION`` gate.
Enables interacting with the
:manual:`CMake Instrumentation API <cmake-instrumentation(7)>`.
This allows for configuring instrumentation at the project-level.
.. code-block:: cmake
cmake_instrumentation(
API_VERSION <version>
DATA_VERSION <version>
[HOOKS <hooks>...]
[OPTIONS <options>...]
[CALLBACK <callback>]
[CUSTOM_CONTENT <name> <type> <content>]
)
The ``API_VERSION`` and ``DATA_VERSION`` must always be given. Currently, the
only supported value for both fields is 1. See :ref:`cmake-instrumentation API v1`
for details of the ``API_VERSION`` and :ref:`cmake-instrumentation Data v1` for details
of the ``DATA_VERSION``.
Each of the optional keywords ``HOOKS``, ``OPTIONS``, and ``CALLBACK``
correspond to one of the parameters to the :ref:`cmake-instrumentation v1 Query Files`.
The ``CALLBACK`` keyword can be provided multiple times to create multiple callbacks.
Whenever ``cmake_instrumentation`` is invoked, a query file is generated in
``<build>/.cmake/instrumentation/v1/query/generated`` to enable instrumentation
with the provided arguments.
.. _`cmake_instrumentation CUSTOM_CONTENT`:
Custom CMake Content
^^^^^^^^^^^^^^^^^^^^
The ``CUSTOM_CONTENT`` argument specifies certain data from configure time to
include in each :ref:`cmake-instrumentation v1 CMake Content File`. This
may be used to associate instrumentation data with certain information about its
configuration, such as the optimization level or whether it is part of a
coverage build.
``CUSTOM_CONTENT`` expects ``name``, ``type`` and ``content`` arguments.
``name`` is a specifier to identify the content being reported.
``type`` specifies how the content should be interpreted. Supported values are:
* ``STRING`` the content is a string.
* ``BOOL`` the content should be interpreted as a boolean. It will be ``true``
under the same conditions that ``if()`` would be true for the given value.
* ``LIST`` the content is a CMake ``;`` separated list that should be parsed.
* ``JSON`` the content should be parsed as a JSON string. This can be a
number such as ``1`` or ``5.0``, a quoted string such as ``\"string\"``,
a boolean value ``true``/``false``, or a JSON object such as
``{ \"key\" : \"value\" }`` that may be constructed using
``string(JSON ...)`` commands.
``content`` is the actual content to report.
Example
^^^^^^^
The following example shows an invocation of the command and its
equivalent JSON query file.
.. code-block:: cmake
cmake_instrumentation(
API_VERSION 1
DATA_VERSION 1
HOOKS postGenerate preCMakeBuild postCMakeBuild
OPTIONS staticSystemInformation dynamicSystemInformation trace
CALLBACK ${CMAKE_COMMAND} -P /path/to/handle_data.cmake
CALLBACK ${CMAKE_COMMAND} -P /path/to/handle_data_2.cmake
CUSTOM_CONTENT myString STRING string
CUSTOM_CONTENT myList LIST "item1;item2"
CUSTOM_CONTENT myObject JSON "{ \"key\" : \"value\" }"
)
.. code-block:: json
{
"version": 1,
"hooks": [
"postGenerate", "preCMakeBuild", "postCMakeBuild"
],
"options": [
"staticSystemInformation", "dynamicSystemInformation", "trace"
],
"callbacks": [
"/path/to/cmake -P /path/to/handle_data.cmake"
"/path/to/cmake -P /path/to/handle_data_2.cmake"
]
}
This will also result in the following content included in each
:ref:`cmake-instrumentation v1 CMake Content File`:
.. code-block:: json
"custom": {
"myString": "string",
"myList": [
"item1", "item2"
],
"myObject": {
"key": "value"
}
}

View File

@@ -16,6 +16,7 @@ Synopsis
cmake_language(`SET_DEPENDENCY_PROVIDER`_ <command> SUPPORTED_METHODS <methods>...)
cmake_language(`GET_MESSAGE_LOG_LEVEL`_ <out-var>)
cmake_language(`EXIT`_ <exit-code>)
cmake_language(`TRACE`_ <boolean> ...)
Introduction
^^^^^^^^^^^^
@@ -534,3 +535,28 @@ Terminating Scripts
shell or platform, and some shells may interpret values
above 125 specially. Therefore, it is advisable to only
specify an ``<exit-code>`` in the range 0 to 125.
Trace Control
^^^^^^^^^^^^^
.. versionadded:: 4.2
.. signature::
cmake_language(TRACE ON [EXPAND])
cmake_language(TRACE OFF)
:target:
TRACE
TRACE-OFF
The TRACE subcommand controls runtime tracing of executed CMake commands and
macros within the current process. When enabled, trace output is written
in the same format as if CMake had been started with the
:option:`cmake --trace` or :option:`cmake --trace-expand` command line options.
Tracing scopes are nestable. Multiple ``TRACE ON`` calls may be active at the
same time, and each ``TRACE OFF`` deactivates one nesting level.
If CMake is run with :option:`cmake --trace` or :option:`cmake --trace-expand`,
those options override and force tracing globally, regardless of
``cmake_language(TRACE OFF)`` calls. In such cases, the command may still
be invoked but has no effect on the trace state.

View File

@@ -30,14 +30,14 @@ Synopsis
`Normalization`_
`Decomposition`_
cmake_path(`GET`_ <path-var> :ref:`ROOT_NAME <GET_ROOT_NAME>` <out-var>)
cmake_path(`GET`_ <path-var> :ref:`ROOT_DIRECTORY <GET_ROOT_DIRECTORY>` <out-var>)
cmake_path(`GET`_ <path-var> :ref:`ROOT_PATH <GET_ROOT_PATH>` <out-var>)
cmake_path(`GET`_ <path-var> :ref:`FILENAME <GET_FILENAME>` <out-var>)
cmake_path(`GET`_ <path-var> :ref:`EXTENSION <GET_EXTENSION>` [LAST_ONLY] <out-var>)
cmake_path(`GET`_ <path-var> :ref:`STEM <GET_STEM>` [LAST_ONLY] <out-var>)
cmake_path(`GET`_ <path-var> :ref:`RELATIVE_PART <GET_RELATIVE_PART>` <out-var>)
cmake_path(`GET`_ <path-var> :ref:`PARENT_PATH <GET_PARENT_PATH>` <out-var>)
cmake_path(`GET`_ <path-var> `ROOT_NAME <GET ... ROOT_NAME_>`_ <out-var>)
cmake_path(`GET`_ <path-var> `ROOT_DIRECTORY <GET ... ROOT_DIRECTORY_>`_ <out-var>)
cmake_path(`GET`_ <path-var> `ROOT_PATH <GET ... ROOT_PATH_>`_ <out-var>)
cmake_path(`GET`_ <path-var> `FILENAME <GET ... FILENAME_>`_ <out-var>)
cmake_path(`GET`_ <path-var> `EXTENSION <GET ... EXTENSION_>`_ [LAST_ONLY] <out-var>)
cmake_path(`GET`_ <path-var> `STEM <GET ... STEM_>`_ [LAST_ONLY] <out-var>)
cmake_path(`GET`_ <path-var> `RELATIVE_PART <GET ... RELATIVE_PART_>`_ <out-var>)
cmake_path(`GET`_ <path-var> `PARENT_PATH <GET ... PARENT_PATH_>`_ <out-var>)
`Query`_
cmake_path(`HAS_ROOT_NAME`_ <path-var> <out-var>)
@@ -51,10 +51,12 @@ Synopsis
cmake_path(`IS_ABSOLUTE`_ <path-var> <out-var>)
cmake_path(`IS_RELATIVE`_ <path-var> <out-var>)
cmake_path(`IS_PREFIX`_ <path-var> <input> [NORMALIZE] <out-var>)
cmake_path(`COMPARE`_ <input1> <OP> <input2> <out-var>)
`Comparison`_
cmake_path(`COMPARE`_ <input1> <op> <input2> <out-var>)
`Modification`_
cmake_path(:ref:`SET <cmake_path-SET>` <path-var> [NORMALIZE] <input>)
cmake_path(`SET`_ <path-var> [NORMALIZE] <input>)
cmake_path(`APPEND`_ <path-var> [<input>...] [OUTPUT_VARIABLE <out-var>])
cmake_path(`APPEND_STRING`_ <path-var> [<input>...] [OUTPUT_VARIABLE <out-var>])
cmake_path(`REMOVE_FILENAME`_ <path-var> [OUTPUT_VARIABLE <out-var>])
@@ -69,8 +71,8 @@ Synopsis
`Native Conversion`_
cmake_path(`NATIVE_PATH`_ <path-var> [NORMALIZE] <out-var>)
cmake_path(`CONVERT`_ <input> `TO_CMAKE_PATH_LIST`_ <out-var> [NORMALIZE])
cmake_path(`CONVERT`_ <input> `TO_NATIVE_PATH_LIST`_ <out-var> [NORMALIZE])
cmake_path(`CONVERT`_ <input> `TO_CMAKE_PATH_LIST <CONVERT ... TO_CMAKE_PATH_LIST_>`_ <out-var> [NORMALIZE])
cmake_path(`CONVERT`_ <input> `TO_NATIVE_PATH_LIST <CONVERT ... TO_NATIVE_PATH_LIST_>`_ <out-var> [NORMALIZE])
`Hashing`_
cmake_path(`HASH`_ <path-var> <out-var>)
@@ -172,12 +174,11 @@ Creating A Path Variable
^^^^^^^^^^^^^^^^^^^^^^^^
While a path can be created with care using an ordinary :command:`set`
command, it is recommended to use :ref:`cmake_path(SET) <cmake_path-SET>`
instead, as it automatically converts the path to the required form where
required. The :ref:`cmake_path(APPEND) <APPEND>` subcommand may
be another suitable alternative where a path needs to be constructed by
joining fragments. The following example compares the three methods for
constructing the same path:
command, it is recommended to use :command:`cmake_path(SET)` instead, as it
automatically converts the path to the required form where required. The
:command:`cmake_path(APPEND)` subcommand may be another suitable alternative
where a path needs to be constructed by joining fragments. The following
example compares the three methods for constructing the same path:
.. code-block:: cmake
@@ -224,21 +225,12 @@ Decomposition
^^^^^^^^^^^^^
.. _GET:
.. _GET_ROOT_NAME:
.. _GET_ROOT_DIRECTORY:
.. _GET_ROOT_PATH:
.. _GET_FILENAME:
.. _GET_EXTENSION:
.. _GET_STEM:
.. _GET_RELATIVE_PART:
.. _GET_PARENT_PATH:
The following forms of the ``GET`` subcommand each retrieve a different
component or group of components from a path. See
`Path Structure And Terminology`_ for the meaning of each path component.
.. code-block:: cmake
.. signature::
cmake_path(GET <path-var> ROOT_NAME <out-var>)
cmake_path(GET <path-var> ROOT_DIRECTORY <out-var>)
cmake_path(GET <path-var> ROOT_PATH <out-var>)
@@ -247,17 +239,26 @@ component or group of components from a path. See
cmake_path(GET <path-var> STEM [LAST_ONLY] <out-var>)
cmake_path(GET <path-var> RELATIVE_PART <out-var>)
cmake_path(GET <path-var> PARENT_PATH <out-var>)
:target:
GET ... ROOT_NAME
GET ... ROOT_DIRECTORY
GET ... ROOT_PATH
GET ... FILENAME
GET ... EXTENSION
GET ... STEM
GET ... RELATIVE_PART
GET ... PARENT_PATH
If a requested component is not present in the path, an empty string will be
stored in ``<out-var>``. For example, only Windows systems have the concept
of a ``root-name``, so when the host machine is non-Windows, the ``ROOT_NAME``
subcommand will always return an empty string.
If a requested component is not present in the path, an empty string will be
stored in ``<out-var>``. For example, only Windows systems have the concept
of a ``root-name``, so when the host machine is non-Windows, the ``ROOT_NAME``
subcommand will always return an empty string.
For ``PARENT_PATH``, if the `HAS_RELATIVE_PART`_ subcommand returns false,
the result is a copy of ``<path-var>``. Note that this implies that a root
directory is considered to have a parent, with that parent being itself.
Where `HAS_RELATIVE_PART`_ returns true, the result will essentially be
``<path-var>`` with one less element.
For ``PARENT_PATH``, if the :cref:`HAS_RELATIVE_PART` sub-command returns
false, the result is a copy of ``<path-var>``. Note that this implies that a
root directory is considered to have a parent, with that parent being itself.
Where :cref:`HAS_RELATIVE_PART` returns true, the result will essentially be
``<path-var>`` with one less element.
Root examples
"""""""""""""
@@ -394,22 +395,12 @@ Path traversal examples
Query
^^^^^
Each of the ``GET`` subcommands has a corresponding ``HAS_...``
subcommand which can be used to discover whether a particular path
Each of the `cmake_path(GET) <GET_>`_ subcommands has a corresponding
``HAS_...`` subcommand which can be used to discover whether a particular path
component is present. See `Path Structure And Terminology`_ for the
meaning of each path component.
.. _HAS_ROOT_NAME:
.. _HAS_ROOT_DIRECTORY:
.. _HAS_ROOT_PATH:
.. _HAS_FILENAME:
.. _HAS_EXTENSION:
.. _HAS_STEM:
.. _HAS_RELATIVE_PART:
.. _HAS_PARENT_PATH:
.. code-block:: cmake
.. signature::
cmake_path(HAS_ROOT_NAME <path-var> <out-var>)
cmake_path(HAS_ROOT_DIRECTORY <path-var> <out-var>)
cmake_path(HAS_ROOT_PATH <path-var> <out-var>)
@@ -419,88 +410,85 @@ meaning of each path component.
cmake_path(HAS_RELATIVE_PART <path-var> <out-var>)
cmake_path(HAS_PARENT_PATH <path-var> <out-var>)
Each of the above follows the predictable pattern of setting ``<out-var>``
to true if the path has the associated component, or false otherwise.
Note the following special cases:
Each of the above follows the predictable pattern of setting ``<out-var>``
to true if the path has the associated component, or false otherwise.
Note the following special cases:
* For ``HAS_ROOT_PATH``, a true result will only be returned if at least one
of ``root-name`` or ``root-directory`` is non-empty.
* For ``HAS_ROOT_PATH``, a true result will only be returned if at least one
of ``root-name`` or ``root-directory`` is non-empty.
* For ``HAS_PARENT_PATH``, the root directory is also considered to have a
parent, which will be itself. The result is true except if the path
consists of just a :ref:`filename <FILENAME_DEF>`.
.. _IS_ABSOLUTE:
.. code-block:: cmake
* For ``HAS_PARENT_PATH``, the root directory is also considered to have a
parent, which will be itself. The result is true except if the path
consists of just a :ref:`filename <FILENAME_DEF>`.
.. signature::
cmake_path(IS_ABSOLUTE <path-var> <out-var>)
Sets ``<out-var>`` to true if ``<path-var>`` is absolute. An absolute path
is a path that unambiguously identifies the location of a file without
reference to an additional starting location. On Windows, this means the
path must have both a ``root-name`` and a ``root-directory-separator`` to be
considered absolute. On other platforms, just a ``root-directory-separator``
is sufficient. Note that this means on Windows, ``IS_ABSOLUTE`` can be
false while ``HAS_ROOT_DIRECTORY`` can be true.
.. _IS_RELATIVE:
.. code-block:: cmake
Sets ``<out-var>`` to true if ``<path-var>`` is absolute. An absolute path
is a path that unambiguously identifies the location of a file without
reference to an additional starting location. On Windows, this means the
path must have both a ``root-name`` and a ``root-directory-separator`` to be
considered absolute. On other platforms, just a ``root-directory-separator``
is sufficient. Note that this means on Windows, ``IS_ABSOLUTE`` can be
false while :cref:`HAS_ROOT_DIRECTORY` can be true.
.. signature::
cmake_path(IS_RELATIVE <path-var> <out-var>)
This will store the opposite of ``IS_ABSOLUTE`` in ``<out-var>``.
.. _IS_PREFIX:
.. code-block:: cmake
This will store the opposite of :cref:`IS_ABSOLUTE` in ``<out-var>``.
.. signature::
cmake_path(IS_PREFIX <path-var> <input> [NORMALIZE] <out-var>)
Checks if ``<path-var>`` is the prefix of ``<input>``.
Checks if ``<path-var>`` is the prefix of ``<input>``.
When the ``NORMALIZE`` option is specified, ``<path-var>`` and ``<input>``
are :ref:`normalized <Normalization>` before the check.
When the ``NORMALIZE`` option is specified, ``<path-var>`` and ``<input>``
are :ref:`normalized <Normalization>` before the check.
.. code-block:: cmake
.. code-block:: cmake
set(path "/a/b/c")
cmake_path(IS_PREFIX path "/a/b/c/d" result) # result = true
cmake_path(IS_PREFIX path "/a/b" result) # result = false
cmake_path(IS_PREFIX path "/x/y/z" result) # result = false
set(path "/a/b/c")
cmake_path(IS_PREFIX path "/a/b/c/d" result) # result = true
cmake_path(IS_PREFIX path "/a/b" result) # result = false
cmake_path(IS_PREFIX path "/x/y/z" result) # result = false
set(path "/a/b")
cmake_path(IS_PREFIX path "/a/c/../b" NORMALIZE result) # result = true
set(path "/a/b")
cmake_path(IS_PREFIX path "/a/c/../b" NORMALIZE result) # result = true
.. _Path Comparison:
Comparison
^^^^^^^^^^
.. _Path COMPARE:
.. _COMPARE:
.. code-block:: cmake
.. signature::
cmake_path(COMPARE <input1> EQUAL <input2> <out-var>)
cmake_path(COMPARE <input1> NOT_EQUAL <input2> <out-var>)
:target:
COMPARE ... EQUAL
COMPARE ... NOT_EQUAL
Compares the lexical representations of two paths provided as string literals.
No normalization is performed on either path, except multiple consecutive
directory separators are effectively collapsed into a single separator.
Equality is determined according to the following pseudo-code logic:
Compares the lexical representations of two paths provided as string literals.
No normalization is performed on either path, except multiple consecutive
directory separators are effectively collapsed into a single separator.
Equality is determined according to the following pseudo-code logic:
::
::
if(NOT <input1>.root_name() STREQUAL <input2>.root_name())
return FALSE
if(NOT <input1>.root_name() STREQUAL <input2>.root_name())
return FALSE
if(<input1>.has_root_directory() XOR <input2>.has_root_directory())
return FALSE
if(<input1>.has_root_directory() XOR <input2>.has_root_directory())
return FALSE
Return FALSE if a relative portion of <input1> is not lexicographically
equal to the relative portion of <input2>. This comparison is performed path
component-wise. If all of the components compare equal, then return TRUE.
Return FALSE if a relative portion of <input1> is not lexicographically
equal to the relative portion of <input2>. This comparison is performed path
component-wise. If all of the components compare equal, then return TRUE.
.. note::
Unlike most other ``cmake_path()`` subcommands, the ``COMPARE`` subcommand
takes literal strings as input, not the names of variables.
.. note::
Unlike most other ``cmake_path()`` subcommands, the ``COMPARE`` subcommand
takes literal strings as input, not the names of variables.
.. _Path Modification:
@@ -508,150 +496,129 @@ Equality is determined according to the following pseudo-code logic:
Modification
^^^^^^^^^^^^
.. _cmake_path-SET:
.. code-block:: cmake
.. signature::
cmake_path(SET <path-var> [NORMALIZE] <input>)
Assign the ``<input>`` path to ``<path-var>``. If ``<input>`` is a native
path, it is converted into a cmake-style path with forward-slashes
(``/``). On Windows, the long filename marker is taken into account.
Assigns the ``<input>`` path to ``<path-var>``. If ``<input>`` is a native
path, it is converted into a cmake-style path with forward-slashes
(``/``). On Windows, the long filename marker is taken into account.
When the ``NORMALIZE`` option is specified, the path is :ref:`normalized
<Normalization>` after the conversion.
When the ``NORMALIZE`` option is specified, the path is :ref:`normalized
<Normalization>` after the conversion.
For example:
For example:
.. code-block:: cmake
.. code-block:: cmake
set(native_path "c:\\a\\b/..\\c")
cmake_path(SET path "${native_path}")
message("CMake path is \"${path}\"")
set(native_path "c:\\a\\b/..\\c")
cmake_path(SET path "${native_path}")
message("CMake path is \"${path}\"")
cmake_path(SET path NORMALIZE "${native_path}")
message("Normalized CMake path is \"${path}\"")
cmake_path(SET path NORMALIZE "${native_path}")
message("Normalized CMake path is \"${path}\"")
Output::
Output::
CMake path is "c:/a/b/../c"
Normalized CMake path is "c:/a/c"
.. _APPEND:
.. code-block:: cmake
CMake path is "c:/a/b/../c"
Normalized CMake path is "c:/a/c"
.. signature::
cmake_path(APPEND <path-var> [<input>...] [OUTPUT_VARIABLE <out-var>])
Append all the ``<input>`` arguments to the ``<path-var>`` using ``/`` as
the ``directory-separator``. Depending on the ``<input>``, the previous
contents of ``<path-var>`` may be discarded. For each ``<input>`` argument,
the following algorithm (pseudo-code) applies:
Appends all the ``<input>`` arguments to the ``<path-var>`` using ``/`` as
the ``directory-separator``. Depending on the ``<input>``, the previous
contents of ``<path-var>`` may be discarded. For each ``<input>`` argument,
the following algorithm (pseudo-code) applies:
::
::
# <path> is the contents of <path-var>
# <path> is the contents of <path-var>
if(<input>.is_absolute() OR
(<input>.has_root_name() AND
NOT <input>.root_name() STREQUAL <path>.root_name()))
replace <path> with <input>
return()
endif()
if(<input>.is_absolute() OR
(<input>.has_root_name() AND
NOT <input>.root_name() STREQUAL <path>.root_name()))
replace <path> with <input>
return()
endif()
if(<input>.has_root_directory())
remove any root-directory and the entire relative path from <path>
elseif(<path>.has_filename() OR
(NOT <path-var>.has_root_directory() OR <path>.is_absolute()))
append directory-separator to <path>
endif()
if(<input>.has_root_directory())
remove any root-directory and the entire relative path from <path>
elseif(<path>.has_filename() OR
(NOT <path-var>.has_root_directory() OR <path>.is_absolute()))
append directory-separator to <path>
endif()
append <input> omitting any root-name to <path>
.. _APPEND_STRING:
.. code-block:: cmake
append <input> omitting any root-name to <path>
.. signature::
cmake_path(APPEND_STRING <path-var> [<input>...] [OUTPUT_VARIABLE <out-var>])
Append all the ``<input>`` arguments to the ``<path-var>`` without adding any
``directory-separator``.
.. _REMOVE_FILENAME:
.. code-block:: cmake
Appends all the ``<input>`` arguments to the ``<path-var>`` without adding any
``directory-separator``.
.. signature::
cmake_path(REMOVE_FILENAME <path-var> [OUTPUT_VARIABLE <out-var>])
Removes the :ref:`filename <FILENAME_DEF>` component (as returned by
:ref:`GET ... FILENAME <GET_FILENAME>`) from ``<path-var>``. After removal,
any trailing ``directory-separator`` is left alone, if present.
Removes the :ref:`filename <FILENAME_DEF>` component (as returned by
:cref:`GET ... FILENAME`) from ``<path-var>``. After removal, any trailing
``directory-separator`` is left alone, if present.
If ``OUTPUT_VARIABLE`` is not given, then after this function returns,
`HAS_FILENAME`_ returns false for ``<path-var>``.
If ``OUTPUT_VARIABLE`` is not given, then after this function returns,
:cref:`HAS_FILENAME` returns false for ``<path-var>``.
For example:
For example:
.. code-block:: cmake
.. code-block:: cmake
set(path "/a/b")
cmake_path(REMOVE_FILENAME path)
message("First path is \"${path}\"")
set(path "/a/b")
cmake_path(REMOVE_FILENAME path)
message("First path is \"${path}\"")
# filename is now already empty, the following removes nothing
cmake_path(REMOVE_FILENAME path)
message("Second path is \"${path}\"")
# filename is now already empty, the following removes nothing
cmake_path(REMOVE_FILENAME path)
message("Second path is \"${path}\"")
Output::
Output::
First path is "/a/"
Second path is "/a/"
.. _REPLACE_FILENAME:
.. code-block:: cmake
First path is "/a/"
Second path is "/a/"
.. signature::
cmake_path(REPLACE_FILENAME <path-var> <input> [OUTPUT_VARIABLE <out-var>])
Replaces the :ref:`filename <FILENAME_DEF>` component from ``<path-var>``
with ``<input>``. If ``<path-var>`` has no filename component (i.e.
`HAS_FILENAME`_ returns false), the path is unchanged. The operation is
equivalent to the following:
Replaces the :ref:`filename <FILENAME_DEF>` component from ``<path-var>``
with ``<input>``. If ``<path-var>`` has no filename component (i.e.
:cref:`HAS_FILENAME` returns false), the path is unchanged. The operation is
equivalent to the following:
.. code-block:: cmake
.. code-block:: cmake
cmake_path(HAS_FILENAME path has_filename)
if(has_filename)
cmake_path(REMOVE_FILENAME path)
cmake_path(APPEND path "${input}")
endif()
.. _REMOVE_EXTENSION:
.. code-block:: cmake
cmake_path(HAS_FILENAME path has_filename)
if(has_filename)
cmake_path(REMOVE_FILENAME path)
cmake_path(APPEND path "${input}")
endif()
.. signature::
cmake_path(REMOVE_EXTENSION <path-var> [LAST_ONLY]
[OUTPUT_VARIABLE <out-var>])
Removes the :ref:`extension <EXTENSION_DEF>`, if any, from ``<path-var>``.
.. _REPLACE_EXTENSION:
.. code-block:: cmake
Removes the :ref:`extension <EXTENSION_DEF>`, if any, from ``<path-var>``.
.. signature::
cmake_path(REPLACE_EXTENSION <path-var> [LAST_ONLY] <input>
[OUTPUT_VARIABLE <out-var>])
Replaces the :ref:`extension <EXTENSION_DEF>` with ``<input>``. Its effect
is equivalent to the following:
Replaces the :ref:`extension <EXTENSION_DEF>` with ``<input>``. Its effect
is equivalent to the following:
.. code-block:: cmake
.. code-block:: cmake
cmake_path(REMOVE_EXTENSION path)
if(NOT input MATCHES "^\\.")
cmake_path(APPEND_STRING path ".")
endif()
cmake_path(APPEND_STRING path "${input}")
cmake_path(REMOVE_EXTENSION path)
if(NOT input MATCHES "^\\.")
cmake_path(APPEND_STRING path ".")
endif()
cmake_path(APPEND_STRING path "${input}")
.. _Path Generation:
@@ -659,50 +626,41 @@ is equivalent to the following:
Generation
^^^^^^^^^^
.. _NORMAL_PATH:
.. code-block:: cmake
.. signature::
cmake_path(NORMAL_PATH <path-var> [OUTPUT_VARIABLE <out-var>])
Normalize ``<path-var>`` according the steps described in :ref:`Normalization`.
.. _cmake_path-RELATIVE_PATH:
.. _RELATIVE_PATH:
.. code-block:: cmake
Normalizes ``<path-var>`` according the steps described in
:ref:`Normalization`.
.. signature::
cmake_path(RELATIVE_PATH <path-var> [BASE_DIRECTORY <input>]
[OUTPUT_VARIABLE <out-var>])
Modifies ``<path-var>`` to make it relative to the ``BASE_DIRECTORY`` argument.
If ``BASE_DIRECTORY`` is not specified, the default base directory will be
:variable:`CMAKE_CURRENT_SOURCE_DIR`.
Modifies ``<path-var>`` to make it relative to the ``BASE_DIRECTORY`` argument.
If ``BASE_DIRECTORY`` is not specified, the default base directory will be
:variable:`CMAKE_CURRENT_SOURCE_DIR`.
For reference, the algorithm used to compute the relative path is the same
as that used by C++
`std::filesystem::path::lexically_relative
<https://en.cppreference.com/w/cpp/filesystem/path/lexically_normal>`_.
.. _ABSOLUTE_PATH:
.. code-block:: cmake
For reference, the algorithm used to compute the relative path is the same
as that used by C++
`std::filesystem::path::lexically_relative
<https://en.cppreference.com/w/cpp/filesystem/path/lexically_normal>`_.
.. signature::
cmake_path(ABSOLUTE_PATH <path-var> [BASE_DIRECTORY <input>] [NORMALIZE]
[OUTPUT_VARIABLE <out-var>])
If ``<path-var>`` is a relative path (`IS_RELATIVE`_ is true), it is evaluated
relative to the given base directory specified by ``BASE_DIRECTORY`` option.
If ``BASE_DIRECTORY`` is not specified, the default base directory will be
:variable:`CMAKE_CURRENT_SOURCE_DIR`.
If ``<path-var>`` is a relative path (:cref:`IS_RELATIVE` is true), it is
evaluated relative to the given base directory specified by ``BASE_DIRECTORY``
option. If ``BASE_DIRECTORY`` is not specified, the default base directory
will be :variable:`CMAKE_CURRENT_SOURCE_DIR`.
When the ``NORMALIZE`` option is specified, the path is :ref:`normalized
<Normalization>` after the path computation.
When the ``NORMALIZE`` option is specified, the path is :ref:`normalized
<Normalization>` after the path computation.
Because ``cmake_path()`` does not access the filesystem, symbolic links are
not resolved and any leading tilde is not expanded. To compute a real path
with symbolic links resolved and leading tildes expanded, use the
:command:`file(REAL_PATH)` command instead.
Because ``cmake_path()`` does not access the filesystem, symbolic links are
not resolved and any leading tilde is not expanded. To compute a real path
with symbolic links resolved and leading tildes expanded, use the
:command:`file(REAL_PATH)` command instead.
Native Conversion
^^^^^^^^^^^^^^^^^
@@ -710,89 +668,79 @@ Native Conversion
For commands in this section, *native* refers to the host platform, not the
target platform when cross-compiling.
.. _cmake_path-NATIVE_PATH:
.. _NATIVE_PATH:
.. code-block:: cmake
.. signature::
cmake_path(NATIVE_PATH <path-var> [NORMALIZE] <out-var>)
Converts a cmake-style ``<path-var>`` into a native path with
platform-specific slashes (``\`` on Windows hosts and ``/`` elsewhere).
Converts a cmake-style ``<path-var>`` into a native path with
platform-specific slashes (``\`` on Windows hosts and ``/`` elsewhere).
When the ``NORMALIZE`` option is specified, the path is :ref:`normalized
<Normalization>` before the conversion.
When the ``NORMALIZE`` option is specified, the path is :ref:`normalized
<Normalization>` before the conversion.
.. _CONVERT:
.. _cmake_path-TO_CMAKE_PATH_LIST:
.. _TO_CMAKE_PATH_LIST:
.. code-block:: cmake
.. signature::
cmake_path(CONVERT <input> TO_CMAKE_PATH_LIST <out-var> [NORMALIZE])
:target:
CONVERT ... TO_CMAKE_PATH_LIST
Converts a native ``<input>`` path into a cmake-style path with forward
slashes (``/``). On Windows hosts, the long filename marker is taken into
account. The input can be a single path or a system search path like
``$ENV{PATH}``. A search path will be converted to a cmake-style list
separated by ``;`` characters (on non-Windows platforms, this essentially
means ``:`` separators are replaced with ``;``). The result of the
conversion is stored in the ``<out-var>`` variable.
Converts a native ``<input>`` path into a cmake-style path with forward
slashes (``/``). On Windows hosts, the long filename marker is taken into
account. The input can be a single path or a system search path like
``$ENV{PATH}``. A search path will be converted to a cmake-style list
separated by ``;`` characters (on non-Windows platforms, this essentially
means ``:`` separators are replaced with ``;``). The result of the
conversion is stored in the ``<out-var>`` variable.
When the ``NORMALIZE`` option is specified, the path is :ref:`normalized
<Normalization>` before the conversion.
When the ``NORMALIZE`` option is specified, the path is :ref:`normalized
<Normalization>` before the conversion.
.. note::
Unlike most other ``cmake_path()`` subcommands, the ``CONVERT`` subcommand
takes a literal string as input, not the name of a variable.
.. _cmake_path-TO_NATIVE_PATH_LIST:
.. _TO_NATIVE_PATH_LIST:
.. code-block:: cmake
.. note::
Unlike most other ``cmake_path()`` subcommands, the ``CONVERT`` subcommand
takes a literal string as input, not the name of a variable.
.. signature::
cmake_path(CONVERT <input> TO_NATIVE_PATH_LIST <out-var> [NORMALIZE])
:target:
CONVERT ... TO_NATIVE_PATH_LIST
Converts a cmake-style ``<input>`` path into a native path with
platform-specific slashes (``\`` on Windows hosts and ``/`` elsewhere).
The input can be a single path or a cmake-style list. A list will be
converted into a native search path (``;``-separated on Windows,
``:``-separated on other platforms). The result of the conversion is
stored in the ``<out-var>`` variable.
Converts a cmake-style ``<input>`` path into a native path with
platform-specific slashes (``\`` on Windows hosts and ``/`` elsewhere).
The input can be a single path or a cmake-style list. A list will be
converted into a native search path (``;``-separated on Windows,
``:``-separated on other platforms). The result of the conversion is
stored in the ``<out-var>`` variable.
When the ``NORMALIZE`` option is specified, the path is :ref:`normalized
<Normalization>` before the conversion.
When the ``NORMALIZE`` option is specified, the path is :ref:`normalized
<Normalization>` before the conversion.
.. note::
Unlike most other ``cmake_path()`` subcommands, the ``CONVERT`` subcommand
takes a literal string as input, not the name of a variable.
.. note::
Unlike most other ``cmake_path()`` subcommands, the ``CONVERT`` subcommand
takes a literal string as input, not the name of a variable.
For example:
For example:
.. code-block:: cmake
.. code-block:: cmake
set(paths "/a/b/c" "/x/y/z")
cmake_path(CONVERT "${paths}" TO_NATIVE_PATH_LIST native_paths)
message("Native path list is \"${native_paths}\"")
set(paths "/a/b/c" "/x/y/z")
cmake_path(CONVERT "${paths}" TO_NATIVE_PATH_LIST native_paths)
message("Native path list is \"${native_paths}\"")
Output on Windows::
Output on Windows::
Native path list is "\a\b\c;\x\y\z"
Native path list is "\a\b\c;\x\y\z"
Output on all other platforms::
Output on all other platforms::
Native path list is "/a/b/c:/x/y/z"
Native path list is "/a/b/c:/x/y/z"
Hashing
^^^^^^^
.. _HASH:
.. signature::
cmake_path(HASH <path-var> <out-var>)
.. code-block:: cmake
cmake_path(HASH <path-var> <out-var>)
Compute a hash value of ``<path-var>`` such that for two paths ``p1`` and
``p2`` that compare equal (:ref:`COMPARE ... EQUAL <COMPARE>`), the hash
value of ``p1`` is equal to the hash value of ``p2``. The path is always
:ref:`normalized <Normalization>` before the hash is computed.
Computes a hash value of ``<path-var>`` such that for two paths ``p1`` and
``p2`` that compare equal (:cref:`COMPARE ... EQUAL`), the hash value of
``p1`` is equal to the hash value of ``p2``. The path is always
:ref:`normalized <Normalization>` before the hash is computed.

View File

@@ -213,7 +213,7 @@ Check the `CDash test measurement documentation
<https://github.com/Kitware/CDash/blob/master/docs/test_measurements.md>`_
for more information on the types of test measurements that CDash recognizes.
.. versionadded: 3.22
.. versionadded:: 3.22
CTest can parse custom measurements from tags named
``<CTestMeasurement>`` or ``<CTestMeasurementFile>``. The older names
``<DartMeasurement>`` and ``<DartMeasurementFile>`` are still supported.

View File

@@ -75,7 +75,8 @@ Options:
``WORKING_DIRECTORY``
The named directory will be set as the current working directory of
the child processes.
the child processes. If not given, the child processes' working directory is
unspecified.
``TIMEOUT``
After the specified number of seconds (fractions allowed), all unfinished

View File

@@ -141,7 +141,9 @@ Exporting Targets to the |CPS|
[VERSION_SCHEMA <string>]]
[DEFAULT_TARGETS <target>...]
[DEFAULT_CONFIGURATIONS <config>...]
[DESCRIPTION <project-description-string>]
[LICENSE <license-string>]
[DEFAULT_LICENSE <license-string>]
[DESCRIPTION <description-string>]
[HOMEPAGE_URL <url-string>])
.. versionadded:: 4.1

View File

@@ -6,17 +6,16 @@ File manipulation command.
This command is dedicated to file and path manipulation requiring access to the
filesystem.
For other path manipulation, handling only syntactic aspects, have a look at
For other path manipulation, handling only syntactic aspects, see the
:command:`cmake_path` command.
.. note::
The sub-commands `RELATIVE_PATH`_, `TO_CMAKE_PATH`_ and `TO_NATIVE_PATH`_ has
been superseded, respectively, by sub-commands
:ref:`RELATIVE_PATH <cmake_path-RELATIVE_PATH>`,
:ref:`CONVERT ... TO_CMAKE_PATH_LIST <cmake_path-TO_CMAKE_PATH_LIST>` and
:ref:`CONVERT ... TO_NATIVE_PATH_LIST <cmake_path-TO_NATIVE_PATH_LIST>` of
:command:`cmake_path` command.
The sub-commands `RELATIVE_PATH`_, `TO_CMAKE_PATH`_, and `TO_NATIVE_PATH`_
have been superseded, respectively, by the sub-commands
:command:`cmake_path(RELATIVE_PATH)`,
:command:`cmake_path(CONVERT ... TO_CMAKE_PATH_LIST)`, and
:command:`cmake_path(CONVERT ... TO_NATIVE_PATH_LIST)`.
Synopsis
^^^^^^^^
@@ -616,7 +615,9 @@ Filesystem
emitted.
Specifying ``COPY_ON_ERROR`` enables copying the file as a fallback if
creating the link fails. It can be useful for handling situations such as
creating the link fails. If the source is a directory, the destination
directory will be created if it does not exist, but no files will be copied
the from source one. It can be useful for handling situations such as
``<original>`` and ``<linkname>`` being on different drives or mount points,
which would make them unable to support a hard link.

View File

@@ -4,7 +4,7 @@ find_file
.. |FIND_XXX| replace:: find_file
.. |NAMES| replace:: NAMES name1 [name2 ...]
.. |SEARCH_XXX| replace:: full path to a file
.. |SEARCH_XXX_DESC| replace:: full path to named file
.. |SEARCH_XXX_DESC| replace:: full path to a named file
.. |prefix_XXX_SUBDIR| replace:: ``<prefix>/include``
.. |entry_XXX_SUBDIR| replace:: ``<entry>/include``

View File

@@ -141,7 +141,8 @@ Basic Signature
[REGISTRY_VIEW (64|32|64_32|32_64|HOST|TARGET|BOTH)]
[GLOBAL]
[NO_POLICY_SCOPE]
[BYPASS_PROVIDER])
[BYPASS_PROVIDER]
[UNWIND_INCLUDE])
The basic signature is supported by both Module and Config modes.
The ``MODULE`` keyword implies that only Module mode can be used to find
@@ -249,6 +250,21 @@ of the ``NO_POLICY_SCOPE`` option.
itself. Future versions of CMake may detect attempts to use this keyword
from places other than a dependency provider and halt with a fatal error.
.. versionadded:: 4.2
The ``UNWIND_INCLUDE`` keyword is only allowed when ``find_package()`` is
being called within a parent call to ``find_package()``. When a call to
``find_package(UNWIND_INCLUDE)`` fails to find the desired package, it begins
an "unwind" state. In this state further calls to ``find_package()`` and
:command:`include()` are forbidden, and all parent :command:`include()`
commands will immediately invoke :command:`return()` when their scope is
reached. This "unwinding" will continue until the parent ``find_package()``
is returned to.
``UNWIND_INCLUDE`` is only intended to be used by calls to ``find_package()``
generated by :command:`install(EXPORT_PACKAGE_DEPENDENCIES)`, but may be
useful to those who wish to manually manage their dependencies in a similar
manner.
.. _`full signature`:
Full Signature
@@ -322,7 +338,9 @@ an error describing the problem unless the ``QUIET`` argument is
specified. If ``REQUIRED`` is specified and the package is not found, a
fatal error is generated and the configure step stops executing. If
``<PackageName>_DIR`` has been set to a directory not containing a
configuration file, CMake will ignore it and search from scratch.
configuration file, or if the requested version is not compatible
with the package found in that directory (see :ref:`version selection`),
CMake will ignore it and search from scratch.
Package maintainers providing package configuration files are encouraged to
name and install them such that the :ref:`search procedure` outlined below
@@ -581,12 +599,12 @@ Paths are searched in the order described above. The first viable package
configuration file found is used, even if a newer version of the package
resides later in the list of search paths.
For search paths which contain glob expressions (``*``), the order in which
directories matching the glob are searched is unspecified unless the
:variable:`CMAKE_FIND_PACKAGE_SORT_ORDER` variable is set. This variable,
along with the :variable:`CMAKE_FIND_PACKAGE_SORT_DIRECTION` variable,
determines the order in which CMake considers glob matches. For example, if
the file system contains the package configuration files
For search paths which contain glob expressions (``*``), directories matching
the glob are searched in natural, descending order by default. This behavior
can be overridden by setting variables :variable:`CMAKE_FIND_PACKAGE_SORT_ORDER`
and :variable:`CMAKE_FIND_PACKAGE_SORT_DIRECTION` accordingly. Those variables
determine the order in which CMake considers glob matches. For example, if the
file system contains the package configuration files
::
@@ -594,21 +612,21 @@ the file system contains the package configuration files
<prefix>/example-1.10/example-config.cmake
<prefix>/share/example-2.0/example-config.cmake
it is unspecified (when the aforementioned variables are unset) whether
``find_package(example)`` will find ``example-1.2`` or ``example-1.10``
(assuming that both are viable), but ``find_package`` will *not* find
``example-2.0``, because one of the other two will be found first.
then ``find_package(example)`` will (when the aforementioned variables are
unset) pick ``example-1.10`` (assuming both ``example-1.2`` and ``example-1.10``
are viable). Note however that ``find_package`` will *not* find ``example-2.0``,
because one of the other two will be found first.
To control the order in which ``find_package`` searches directories that match
a glob expression, use :variable:`CMAKE_FIND_PACKAGE_SORT_ORDER` and
:variable:`CMAKE_FIND_PACKAGE_SORT_DIRECTION`.
For instance, to cause the above example to select ``example-1.10``,
For instance, to cause the above example to select ``example-1.2``,
one can set
.. code-block:: cmake
set(CMAKE_FIND_PACKAGE_SORT_ORDER NATURAL)
set(CMAKE_FIND_PACKAGE_SORT_DIRECTION DEC)
set(CMAKE_FIND_PACKAGE_SORT_DIRECTION ASC)
before calling ``find_package``.
@@ -624,6 +642,15 @@ before calling ``find_package``.
and ``<prefix>/<name>.framework/Versions/*/Resources/CMake``. In previous
versions of CMake, this order was unspecified.
.. versionchanged:: 4.2
When encountering multiple viable matches, ``find_package`` now picks the
one with the most recent version by default. In previous versions of CMake,
the result was unspecified. Accordingly, the default of
:variable:`CMAKE_FIND_PACKAGE_SORT_ORDER` has changed from ``NONE`` to
``NATURAL`` and :variable:`CMAKE_FIND_PACKAGE_SORT_DIRECTION`
now defaults to ``DEC`` (descending) instead of ``ASC`` (ascending).
.. include:: include/FIND_XXX_ROOT.rst
.. include:: include/FIND_XXX_ORDER.rst

View File

@@ -58,7 +58,8 @@ command iterates over each item in each given list.
The ``<items>`` following the ``ITEMS`` keyword are processed
as in the first variant of the ``foreach`` command.
The forms ``LISTS A`` and ``ITEMS ${A}`` are
equivalent.
equivalent. If no ``<lists>`` or ``<items>`` are given, the body
of the loop will never be executed (i.e., it is processed as empty).
The following example shows how the ``LISTS`` option is
processed:
@@ -97,13 +98,18 @@ separated list of list-valued variables. The ``foreach``
command iterates over each list simultaneously setting the
iteration variables as follows:
- if the only ``loop_var`` given, then it sets a series of
- if a single ``loop_var`` is given, then it sets a series of
``loop_var_N`` variables to the current item from the
corresponding list;
- if multiple variable names passed, their count should match
the lists variables count;
- if any of the lists are shorter, the corresponding iteration
variable is not defined for the current iteration.
- if multiple variable names are passed, it sets each variable to the
current item from the corresponding list. The number of iteration
variables must match the number of list variables.
If no ``<lists>`` are given, the body of the loop will never be executed
(i.e., it is processed as empty).
The following example shows how the ``ZIP_LISTS`` option is
processed:
.. noqa: spellcheck off

View File

@@ -264,7 +264,7 @@ Comparisons
True if the given string or variable's value matches the given regular
expression. See :ref:`Regex Specification` for regex format.
.. versionadded:: 3.9
.. versionadded:: 2.6
``()`` groups are captured in :variable:`CMAKE_MATCH_<n>` variables.
.. signature:: if(<variable|string> LESS <variable|string>)
@@ -415,7 +415,7 @@ Path Comparisons
...
endif()
See :ref:`cmake_path(COMPARE) <Path COMPARE>` for more details.
See :ref:`cmake_path(COMPARE) <Path Comparison>` for more details.
Variable Expansion
^^^^^^^^^^^^^^^^^^

View File

@@ -32,11 +32,27 @@ The general signature is:
)
This command is used to find a |SEARCH_XXX_DESC|.
A cache entry, or a normal variable if ``NO_CACHE`` is specified,
named by ``<VAR>`` is created to store the result of this command.
If the |SEARCH_XXX| is found the result is stored in the variable
and the search will not be repeated unless the variable is cleared.
If nothing is found, the result will be ``<VAR>-NOTFOUND``.
Prior to searching, |FIND_XXX| checks if variable ``<VAR>`` is defined. If
the variable is not defined, the search will be performed. If the variable is
defined and its value is ``NOTFOUND``, or ends in ``-NOTFOUND``, the search
will be performed. If the variable contains any other value the search is not
performed.
.. note::
``VAR`` is considered defined if it is available in the current scope. See
the :ref:`cmake-language(7) variables <CMake Language Variables>`
documentation for details on scopes, and the interaction of normal
variables and cache entries.
The results of the search will be stored in a cache entry named ``<VAR>``.
Future calls to |FIND_XXX| will inspect this cache entry when specifying the
same ``<VAR>``. This optimization ensures successful searches will not be
repeated unless the cache entry is :command:`unset`.
If the |SEARCH_XXX| is found the recorded value in cache entry ``<VAR>`` will
be the result of the search. If nothing is found, the recorded value will be
``<VAR>-NOTFOUND``.
Options include:
@@ -103,8 +119,9 @@ Options include:
.. note::
If the variable is already set before the call (as a normal or cache
variable) then the search will not occur.
|FIND_XXX| will still check for ``<VAR>`` as usual, checking first for a
variable, and then a cache entry. If either indicate a previous successful
search, the search will not be performed.
.. warning::

Some files were not shown because too many files have changed in this diff Show More