+ stop tracking third party deps in main repo

+ add third party deps as a submodule

.gitignore

@@ -26,3 +26,5 @@ scripts/login_temp/
 scripts/**/__pycache__/
 scripts/generate_emu_config.spec
 scripts/my_login.txt
+
+third-party/

.gitmodules

@@ -0,0 +1,20 @@
+[submodule "third-party/build/linux"]
+	path = third-party/build/linux
+	url = git@github.com:otavepto/gbe_fork-deps.git
+	branch = build/linux
+[submodule "third-party/common/win"]
+	path = third-party/common/win
+	url = git@github.com:otavepto/gbe_fork-deps.git
+	branch = common/win
+[submodule "third-party/deps/common"]
+	path = third-party/deps/common
+	url = git@github.com:otavepto/gbe_fork-deps.git
+	branch = deps/common
+[submodule "third-party/deps/linux"]
+	path = third-party/deps/linux
+	url = git@github.com:otavepto/gbe_fork-deps.git
+	branch = deps/linux
+[submodule "third-party/deps/win"]
+	path = third-party/deps/win
+	url = git@github.com:otavepto/gbe_fork-deps.git
+	branch = deps/win

third-party/build/linux

@@ -0,0 +1 @@
+Subproject commit 29c508dd14df6a24a72edc305b3a10a910bba252

third-party/cmake-3.27.7-linux-x86_64/share/aclocal/cmake.m4

@@ -1,44 +0,0 @@
-dnl Distributed under the OSI-approved BSD 3-Clause License.  See accompanying
-dnl file Copyright.txt or https://cmake.org/licensing for details.
-
-AC_DEFUN([CMAKE_FIND_BINARY],
-[AC_ARG_VAR([CMAKE_BINARY], [path to the cmake binary])dnl
-
-if test "x$ac_cv_env_CMAKE_BINARY_set" != "xset"; then
-    AC_PATH_TOOL([CMAKE_BINARY], [cmake])dnl
-fi
-])dnl
-
-# $1: package name
-# $2: language (e.g. C/CXX/Fortran)
-# $3: The compiler ID, defaults to GNU.
-#     Possible values are: GNU, Intel, Clang, SunPro, HP, XL, VisualAge, PGI,
-#     PathScale, Cray, SCO, MSVC, LCC
-# $4: optional extra arguments to cmake, e.g. "-DCMAKE_SIZEOF_VOID_P=8"
-# $5: optional path to cmake binary
-AC_DEFUN([CMAKE_FIND_PACKAGE], [
-AC_REQUIRE([CMAKE_FIND_BINARY])dnl
-
-AC_ARG_VAR([$1][_][$2][FLAGS], [$2 compiler flags for $1. This overrides the cmake output])dnl
-AC_ARG_VAR([$1][_LIBS], [linker flags for $1. This overrides the cmake output])dnl
-
-failed=false
-AC_MSG_CHECKING([for $1])
-if test -z "${$1[]_$2[]FLAGS}"; then
-    $1[]_$2[]FLAGS=`$CMAKE_BINARY --find-package "-DNAME=$1" "-DCOMPILER_ID=m4_default([$3], [GNU])" "-DLANGUAGE=$2" -DMODE=COMPILE $4` || failed=true
-fi
-if test -z "${$1[]_LIBS}"; then
-    $1[]_LIBS=`$CMAKE_BINARY --find-package "-DNAME=$1" "-DCOMPILER_ID=m4_default([$3], [GNU])" "-DLANGUAGE=$2" -DMODE=LINK $4` || failed=true
-fi
-
-if $failed; then
-    unset $1[]_$2[]FLAGS
-    unset $1[]_LIBS
-
-    AC_MSG_RESULT([no])
-    $6
-else
-    AC_MSG_RESULT([yes])
-    $5
-fi[]dnl
-])

third-party/cmake-3.27.7-linux-x86_64/share/applications/cmake-gui.desktop

@@ -1,12 +0,0 @@
-[Desktop Entry]
-Version=1.0
-Name=CMake
-Comment=Cross-platform buildsystem
-Exec=cmake-gui %f
-Icon=CMakeSetup
-Terminal=false
-X-MultipleArgs=false
-Type=Application
-Categories=Development;Building;
-StartupNotify=true
-MimeType=application/x-cmakecache;

third-party/cmake-3.27.7-linux-x86_64/share/bash-completion/completions/cmake

@@ -1,202 +0,0 @@
-# bash completion for cmake(1)                             -*- shell-script -*-
-
-_cmake()
-{
-    local cur prev words cword split=false
-    if type -t _init_completion >/dev/null; then
-        _init_completion -n = || return
-    else
-        # manual initialization for older bash completion versions
-        COMPREPLY=()
-        cur="${COMP_WORDS[COMP_CWORD]}"
-        prev="${COMP_WORDS[COMP_CWORD-1]}"
-    fi
-
-    # Workaround for options like -DCMAKE_BUILD_TYPE=Release
-    local prefix=
-    if [[ $cur == -D* ]]; then
-        prev=-D
-        prefix=-D
-        cur="${cur#-D}"
-    elif [[ $cur == -U* ]]; then
-        prev=-U
-        prefix=-U
-        cur="${cur#-U}"
-    fi
-
-    case "$prev" in
-        -D)
-            if [[ $cur == *=* ]]; then
-            # complete values for variables
-                local var type value
-                var="${cur%%[:=]*}"
-                value="${cur#*=}"
-
-                if [[ $cur == CMAKE_BUILD_TYPE* ]]; then # most widely used case
-                    COMPREPLY=( $( compgen -W 'Debug Release RelWithDebInfo
-                        MinSizeRel' -- "$value" ) )
-                    return
-                fi
-
-                if [[ $cur == *:* ]]; then
-                    type="${cur#*:}"
-                    type="${type%%=*}"
-                else # get type from cache if it's not set explicitly
-                    type=$( cmake -LA -N 2>/dev/null | grep "$var:" \
-                        2>/dev/null )
-                    type="${type#*:}"
-                    type="${type%%=*}"
-                fi
-                case "$type" in
-                    FILEPATH)
-                        cur="$value"
-                        _filedir
-                        return
-                        ;;
-                    PATH)
-                        cur="$value"
-                        _filedir -d
-                        return
-                        ;;
-                    BOOL)
-                        COMPREPLY=( $( compgen -W 'ON OFF TRUE FALSE' -- \
-                            "$value" ) )
-                        return
-                        ;;
-                    STRING|INTERNAL)
-                        # no completion available
-                        return
-                        ;;
-                esac
-            elif [[ $cur == *:* ]]; then
-            # complete types
-                local type="${cur#*:}"
-                COMPREPLY=( $( compgen -W 'FILEPATH PATH STRING BOOL INTERNAL'\
-                    -S = -- "$type" ) )
-                compopt -o nospace
-            else
-            # complete variable names
-                COMPREPLY=( $( compgen -W '$( cmake -LA -N 2>/dev/null |
-                    tail -n +2 | cut -f1 -d: )' -P "$prefix" -- "$cur" ) )
-                compopt -o nospace
-            fi
-            return
-            ;;
-        -U)
-            COMPREPLY=( $( compgen -W '$( cmake -LA -N | tail -n +2 |
-                cut -f1 -d: )' -P "$prefix" -- "$cur" ) )
-            return
-            ;;
-    esac
-
-    _split_longopt && split=true
-
-    case "$prev" in
-        -C|-P|--graphviz|--system-information)
-            _filedir
-            return
-            ;;
-        --build)
-            # Seed the reply with non-directory arguments that we know are
-            # allowed to follow --build. _filedir will then prepend any valid
-            # directory matches to these.
-            COMPREPLY=( $( compgen -W "--preset --list-presets" -- "$cur" ) )
-            _filedir -d
-            return
-            ;;
-        --install|--open)
-            _filedir -d
-            return
-            ;;
-        -E)
-            COMPREPLY=( $( compgen -W "$( cmake -E help |& sed -n \
-                '/^  [^ ]/{s|^  \([^ ]\{1,\}\) .*$|\1|;p}' 2>/dev/null )" \
-                -- "$cur" ) )
-            return
-            ;;
-        -G)
-            local IFS=$'\n'
-            local quoted
-            printf -v quoted %q "$cur"
-            COMPREPLY=( $( compgen -W '$( cmake --help 2>/dev/null | sed -n \
-                -e "1,/^Generators/d" \
-                -e "/^  *[^ =]/{s|^ *\([^=]*[^ =]\).*$|\1|;s| |\\\\ |g;p}" \
-                2>/dev/null )' -- "$quoted" ) )
-            return
-            ;;
-        --loglevel)
-            COMPREPLY=( $(compgen -W 'error warning notice status verbose debug trace' -- $cur ) )
-            ;;
-        --help-command)
-            COMPREPLY=( $( compgen -W '$( cmake --help-command-list 2>/dev/null|
-                grep -v "^cmake version " )' -- "$cur" ) )
-            return
-            ;;
-        --help-manual)
-            COMPREPLY=( $( compgen -W '$( cmake --help-manual-list 2>/dev/null|
-                grep -v "^cmake version " | sed -e "s/([0-9])$//" )' -- "$cur" ) )
-            return
-            ;;
-        --help-module)
-            COMPREPLY=( $( compgen -W '$( cmake --help-module-list 2>/dev/null|
-                grep -v "^cmake version " )' -- "$cur" ) )
-            return
-            ;;
-         --help-policy)
-            COMPREPLY=( $( compgen -W '$( cmake --help-policy-list 2>/dev/null |
-                grep -v "^cmake version " )' -- "$cur" ) )
-            return
-            ;;
-         --help-property)
-            COMPREPLY=( $( compgen -W '$( cmake --help-property-list \
-                2>/dev/null | grep -v "^cmake version " )' -- "$cur" ) )
-            return
-            ;;
-         --help-variable)
-            COMPREPLY=( $( compgen -W '$( cmake --help-variable-list \
-                2>/dev/null | grep -v "^cmake version " )' -- "$cur" ) )
-            return
-            ;;
-        --list-presets)
-            local IFS=$'\n'
-            local quoted
-            printf -v quoted %q "$cur"
-
-            if [[ ! "${IFS}${COMP_WORDS[*]}${IFS}" =~ "${IFS}--build${IFS}" ]]; then
-                COMPREPLY=( $( compgen -W "configure${IFS}build${IFS}test${IFS}all" -- "$quoted" ) )
-            fi
-            return
-            ;;
-         --preset)
-            local IFS=$'\n'
-            local quoted
-            printf -v quoted %q "$cur"
-
-            local build_or_configure="configure"
-            if [[ "${IFS}${COMP_WORDS[*]}${IFS}" =~ "${IFS}--build${IFS}" ]]; then
-                build_or_configure="build"
-            fi
-
-            local presets=$( cmake --list-presets="$build_or_configure" 2>/dev/null |
-                grep -o "^  \".*\"" | sed \
-                -e "s/^  //g" \
-                -e "s/\"//g" \
-                -e 's/ /\\\\ /g' )
-            COMPREPLY=( $( compgen -W "$presets" -- "$quoted" ) )
-            return
-            ;;
-    esac
-
-    $split && return
-
-    if [[ "$cur" == -* ]]; then
-        COMPREPLY=( $(compgen -W '$( _parse_help "$1" --help )' -- ${cur}) )
-        [[ $COMPREPLY == *= ]] && compopt -o nospace
-        [[ $COMPREPLY ]] && return
-    fi
-
-    _filedir
-} &&
-complete -F _cmake cmake
-
-# ex: ts=4 sw=4 et filetype=sh

third-party/cmake-3.27.7-linux-x86_64/share/bash-completion/completions/cpack

@@ -1,88 +0,0 @@
-# bash completion for cpack(1)                             -*- shell-script -*-
-
-_cpack()
-{
-    local cur prev words cword
-    if type -t _init_completion >/dev/null; then
-        _init_completion -n = || return
-    else
-        # manual initialization for older bash completion versions
-        COMPREPLY=()
-        cur="${COMP_WORDS[COMP_CWORD]}"
-        prev="${COMP_WORDS[COMP_CWORD-1]}"
-    fi
-
-    case "$prev" in
-        -G)
-            COMPREPLY=( $( compgen -W '$( cpack --help 2>/dev/null |
-                sed -e "1,/^Generators/d" -e "s|^ *\([^ ]*\) .*$|\1|" \
-                2>/dev/null )' -- "$cur" ) )
-            return
-            ;;
-        -C)
-            COMPREPLY=( $( compgen -W 'Debug Release RelWithDebInfo
-                MinSizeRel' -- "$cur" ) )
-            return
-            ;;
-        -D)
-            [[ $cur == *=* ]] && return # no completion for values
-            COMPREPLY=( $( compgen -W '$( cpack --help-variable-list \
-                2>/dev/null | grep -v "^cpack version " )' -S = -- "$cur" ) )
-            compopt -o nospace
-            return
-            ;;
-        -P|-R|--vendor)
-            # argument required but no completions available
-            return
-            ;;
-        -B)
-            _filedir -d
-            return
-            ;;
-        --config)
-            _filedir
-            return
-            ;;
-        --help-command)
-            COMPREPLY=( $( compgen -W '$( cpack --help-command-list 2>/dev/null|
-                grep -v "^cpack version " )' -- "$cur" ) )
-            return
-            ;;
-        --help-manual)
-            COMPREPLY=( $( compgen -W '$( cpack --help-manual-list 2>/dev/null|
-                grep -v "^cpack version " | sed -e "s/([0-9])$//" )' -- "$cur" ) )
-            return
-            ;;
-        --help-module)
-            COMPREPLY=( $( compgen -W '$( cpack --help-module-list 2>/dev/null|
-                grep -v "^cpack version " )' -- "$cur" ) )
-            return
-            ;;
-        --help-policy)
-            COMPREPLY=( $( compgen -W '$( cpack --help-policy-list 2>/dev/null |
-                grep -v "^cpack version " )' -- "$cur" ) )
-            return
-            ;;
-        --help-property)
-            COMPREPLY=( $( compgen -W '$( cpack --help-property-list \
-                2>/dev/null | grep -v "^cpack version " )' -- "$cur" ) )
-            return
-            ;;
-        --help-variable)
-            COMPREPLY=( $( compgen -W '$( cpack --help-variable-list \
-                2>/dev/null | grep -v "^cpack version " )' -- "$cur" ) )
-            return
-            ;;
-    esac
-
-    if [[ "$cur" == -* ]]; then
-        COMPREPLY=( $(compgen -W '$( _parse_help "$1" --help )' -- ${cur}) )
-        [[ $COMPREPLY == *= ]] && compopt -o nospace
-        [[ $COMPREPLY ]] && return
-    fi
-
-    _filedir
-} &&
-complete -F _cpack cpack
-
-# ex: ts=4 sw=4 et filetype=sh

third-party/cmake-3.27.7-linux-x86_64/share/bash-completion/completions/ctest

@@ -1,129 +0,0 @@
-# bash completion for ctest(1)                             -*- shell-script -*-
-
-_ctest()
-{
-    local cur prev words cword
-    if type -t _init_completion >/dev/null; then
-        _init_completion -n = || return
-    else
-        # manual initialization for older bash completion versions
-        COMPREPLY=()
-        cur="${COMP_WORDS[COMP_CWORD]}"
-        prev="${COMP_WORDS[COMP_CWORD-1]}"
-    fi
-
-    case "$prev" in
-        -C|--build-config)
-            COMPREPLY=( $( compgen -W 'Debug Release RelWithDebInfo
-                MinSizeRel' -- "$cur" ) )
-            return
-            ;;
-        -j|--parallel)
-            COMPREPLY=( $( compgen -W "{1..$(( $(_ncpus)*2 ))}" -- "$cur" ) )
-            return
-            ;;
-        -O|--output-log|-A|--add-notes|--extra-submit)
-            _filedir
-            return
-            ;;
-        -L|--label-regex|-LE|--label-exclude)
-            COMPREPLY=( $( compgen -W '$( ctest --print-labels 2>/dev/null |
-                grep "^  " 2>/dev/null | cut -d" " -f 3 )' -- "$cur" ) )
-            return
-            ;;
-        --track|-I|--tests-information|--max-width|--timeout|--stop-time)
-            # argument required but no completions available
-            return
-            ;;
-        -R|--tests-regex|-E|--exclude-regex)
-            COMPREPLY=( $( compgen -W '$( ctest -N 2>/dev/null |
-                grep "^  Test" 2>/dev/null | cut -d: -f 2 )' -- "$cur" ) )
-            return
-            ;;
-        -D|--dashboard)
-            if [[ $cur == @(Experimental|Nightly|Continuous)* ]]; then
-                local model action
-                action=${cur#@(Experimental|Nightly|Continuous)}
-                model=${cur%"$action"}
-                COMPREPLY=( $( compgen -W 'Start Update Configure Build Test
-                    Coverage Submit MemCheck' -P "$model" -- "$action" ) )
-            else
-                COMPREPLY=( $( compgen -W 'Experimental Nightly Continuous' \
-                -- "$cur" ) )
-                compopt -o nospace
-            fi
-            return
-            ;;
-        -M|--test-model)
-            COMPREPLY=( $( compgen -W 'Experimental Nightly Continuous' -- \
-                "$cur" ) )
-            return
-            ;;
-        -T|--test-action)
-            COMPREPLY=( $( compgen -W 'Start Update Configure Build Test
-                Coverage Submit MemCheck' -- "$cur" ) )
-            return
-            ;;
-        -S|--script|-SP|--script-new-process)
-            _filedir '@(cmake|ctest)'
-            return
-            ;;
-        --interactive-debug-mode)
-            COMPREPLY=( $( compgen -W '0 1' -- "$cur" ) )
-            return
-            ;;
-
-        --help-command)
-            COMPREPLY=( $( compgen -W '$( ctest --help-command-list 2>/dev/null|
-                grep -v "^ctest version " )' -- "$cur" ) )
-            return
-            ;;
-        --help-manual)
-            COMPREPLY=( $( compgen -W '$( ctest --help-manual-list 2>/dev/null|
-                grep -v "^ctest version " | sed -e "s/([0-9])$//" )' -- "$cur" ) )
-            return
-            ;;
-        --help-module)
-            COMPREPLY=( $( compgen -W '$( ctest --help-module-list 2>/dev/null|
-                grep -v "^ctest version " )' -- "$cur" ) )
-            return
-            ;;
-        --help-policy)
-            COMPREPLY=( $( compgen -W '$( ctest --help-policy-list 2>/dev/null |
-                grep -v "^ctest version " )' -- "$cur" ) )
-            return
-            ;;
-        --help-property)
-            COMPREPLY=( $( compgen -W '$( ctest --help-property-list \
-                2>/dev/null | grep -v "^ctest version " )' -- "$cur" ) )
-            return
-            ;;
-        --help-variable)
-            COMPREPLY=( $( compgen -W '$( ctest --help-variable-list \
-                2>/dev/null | grep -v "^ctest version " )' -- "$cur" ) )
-            return
-            ;;
-         --preset)
-            local IFS=$'\n'
-            local quoted
-            printf -v quoted %q "$cur"
-            COMPREPLY=( $( compgen -W '$( ctest --list-presets 2>/dev/null |
-                grep -o "^  \".*\"" | sed \
-                -e "s/^  //g" \
-                -e "s/\"//g" \
-                -e "s/ /\\\\ /g" )' -- "$quoted" ) )
-            return
-            ;;
-    esac
-
-    if [[ "$cur" == -* ]]; then
-        COMPREPLY=( $(compgen -W '$( _parse_help "$1" --help )' -- ${cur}) )
-        [[ $COMPREPLY == *= ]] && compopt -o nospace
-        [[ $COMPREPLY ]] && return
-    fi
-
-    _filedir
-} &&
-complete -F _ctest ctest
-
-# ex: ts=4 sw=4 et filetype=sh

third-party/cmake-3.27.7-linux-x86_64/share/cmake-3.27/Help/command/DEPRECATED_POLICY_VERSIONS.txt

@@ -1,15 +0,0 @@
-.. versionchanged:: 3.27
-
-  Compatibility with versions of CMake older than 3.5 is deprecated.
-  Calls to :command:`cmake_minimum_required(VERSION)` or
-  :command:`cmake_policy(VERSION)` that do not specify at least
-  3.5 as their policy version (optionally via ``...<max>``)
-  will produce a deprecation warning in CMake 3.27 and above.
-
-.. versionchanged:: 3.19
-
-  Compatibility with versions of CMake older than 2.8.12 is deprecated.
-  Calls to :command:`cmake_minimum_required(VERSION)` or
-  :command:`cmake_policy(VERSION)` that do not specify at least
-  2.8.12 as their policy version (optionally via ``...<max>``)
-  will produce a deprecation warning in CMake 3.19 and above.

third-party/cmake-3.27.7-linux-x86_64/share/cmake-3.27/Help/command/DEVICE_LINK_OPTIONS.txt

@@ -1,12 +0,0 @@
-Host And Device Specific Link Options
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-.. versionadded:: 3.18
-  When a device link step is involved, which is controlled by
-  :prop_tgt:`CUDA_SEPARABLE_COMPILATION` and
-  :prop_tgt:`CUDA_RESOLVE_DEVICE_SYMBOLS` properties and policy :policy:`CMP0105`,
-  the raw options will be delivered to the host and device link steps (wrapped in
-  ``-Xcompiler`` or equivalent for device link). Options wrapped with
-  :genex:`$<DEVICE_LINK:...>` generator expression will be used
-  only for the device link step. Options wrapped with :genex:`$<HOST_LINK:...>`
-  generator expression will be used only for the host link step.

third-party/cmake-3.27.7-linux-x86_64/share/cmake-3.27/Help/command/FIND_XXX.txt

@@ -1,252 +0,0 @@
-A short-hand signature is:
-
-.. parsed-literal::
-
-   |FIND_XXX| (<VAR> name1 [path1 path2 ...])
-
-The general signature is:
-
-.. parsed-literal::
-
-   |FIND_XXX| (
-             <VAR>
-             name | |NAMES|
-             [HINTS [path | ENV var]... ]
-             [PATHS [path | ENV var]... ]
-             [REGISTRY_VIEW (64|32|64_32|32_64|HOST|TARGET|BOTH)]
-             [PATH_SUFFIXES suffix1 [suffix2 ...]]
-             [VALIDATOR function]
-             [DOC "cache documentation string"]
-             [NO_CACHE]
-             [REQUIRED]
-             [NO_DEFAULT_PATH]
-             [NO_PACKAGE_ROOT_PATH]
-             [NO_CMAKE_PATH]
-             [NO_CMAKE_ENVIRONMENT_PATH]
-             [NO_SYSTEM_ENVIRONMENT_PATH]
-             [NO_CMAKE_SYSTEM_PATH]
-             [NO_CMAKE_INSTALL_PREFIX]
-             [CMAKE_FIND_ROOT_PATH_BOTH |
-              ONLY_CMAKE_FIND_ROOT_PATH |
-              NO_CMAKE_FIND_ROOT_PATH]
-            )
-
-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``.
-
-Options include:
-
-``NAMES``
-  Specify one or more possible names for the |SEARCH_XXX|.
-
-  When using this to specify names with and without a version
-  suffix, we recommend specifying the unversioned name first
-  so that locally-built packages can be found before those
-  provided by distributions.
-
-``HINTS``, ``PATHS``
-  Specify directories to search in addition to the default locations.
-  The ``ENV var`` sub-option reads paths from a system environment
-  variable.
-
-  .. versionchanged:: 3.24
-    On ``Windows`` platform, it is possible to include registry queries as part
-    of the directories, using a :ref:`dedicated syntax <Find Using Windows Registry>`.
-    Such specifications will be ignored on all other platforms.
-
-``REGISTRY_VIEW``
-  .. versionadded:: 3.24
-
-  .. include:: FIND_XXX_REGISTRY_VIEW.txt
-
-``PATH_SUFFIXES``
-  Specify additional subdirectories to check below each directory
-  location otherwise considered.
-
-``VALIDATOR``
-  .. versionadded:: 3.25
-
-  Specify a :command:`function` to be called for each candidate item found
-  (a :command:`macro` cannot be provided, that will result in an error).
-  Two arguments will be passed to the validator function: the name of a
-  result variable, and the absolute path to the candidate item.  The item
-  will be accepted and the search will end unless the function sets the
-  value in the result variable to false in the calling scope.  The result
-  variable will hold a true value when the validator function is entered.
-
-  .. parsed-literal::
-
-     function(my_check validator_result_var item)
-       if(NOT item MATCHES ...)
-         set(${validator_result_var} FALSE PARENT_SCOPE)
-       endif()
-     endfunction()
-
-     |FIND_XXX| (result NAMES ... VALIDATOR my_check)
-
-  Note that if a cached result is used, the search is skipped and any
-  ``VALIDATOR`` is ignored.  The cached result is not required to pass the
-  validation function.
-
-``DOC``
-  Specify the documentation string for the ``<VAR>`` cache entry.
-
-``NO_CACHE``
-  .. versionadded:: 3.21
-
-  The result of the search will be stored in a normal variable rather than
-  a cache entry.
-
-  .. note::
-
-    If the variable is already set before the call (as a normal or cache
-    variable) then the search will not occur.
-
-  .. warning::
-
-    This option should be used with caution because it can greatly increase
-    the cost of repeated configure steps.
-
-``REQUIRED``
-  .. versionadded:: 3.18
-
-  Stop processing with an error message if nothing is found, otherwise
-  the search will be attempted again the next time |FIND_XXX| is invoked
-  with the same variable.
-
-If ``NO_DEFAULT_PATH`` is specified, then no additional paths are
-added to the search.
-If ``NO_DEFAULT_PATH`` is not specified, the search process is as follows:
-
-.. |FIND_PACKAGE_ROOT_PREFIX_PATH_XXX_SUBDIR| replace::
-   |prefix_XXX_SUBDIR| for each ``<prefix>`` in the
-   :variable:`<PackageName>_ROOT` CMake variable and the
-   :envvar:`<PackageName>_ROOT` environment variable if
-   called from within a find module loaded by
-   :command:`find_package(<PackageName>)`
-
-.. |CMAKE_PREFIX_PATH_XXX_SUBDIR| replace::
-   |prefix_XXX_SUBDIR| for each ``<prefix>`` in :variable:`CMAKE_PREFIX_PATH`
-
-.. |ENV_CMAKE_PREFIX_PATH_XXX_SUBDIR| replace::
-   |prefix_XXX_SUBDIR| for each ``<prefix>`` in :envvar:`CMAKE_PREFIX_PATH`
-
-.. |SYSTEM_ENVIRONMENT_PREFIX_PATH_XXX_SUBDIR| replace::
-   |prefix_XXX_SUBDIR| for each ``<prefix>/[s]bin`` in ``PATH``, and
-   |entry_XXX_SUBDIR| for other entries in ``PATH``
-
-.. |CMAKE_SYSTEM_PREFIX_PATH_XXX_SUBDIR| replace::
-   |prefix_XXX_SUBDIR| for each ``<prefix>`` in
-   :variable:`CMAKE_SYSTEM_PREFIX_PATH`
-
-1. If called from within a find module or any other script loaded by a call to
-   :command:`find_package(<PackageName>)`, search prefixes unique to the
-   current package being found.  See policy :policy:`CMP0074`.
-
-   .. versionadded:: 3.12
-
-   Specifically, search paths specified by the following variables, in order:
-
-   a. :variable:`<PackageName>_ROOT` CMake variable,
-      where ``<PackageName>`` is the case-preserved package name.
-
-   b. :variable:`<PACKAGENAME>_ROOT` CMake variable,
-      where ``<PACKAGENAME>`` is the upper-cased package name.
-      See policy :policy:`CMP0144`.
-
-      .. versionadded:: 3.27
-
-   c. :envvar:`<PackageName>_ROOT` environment variable,
-      where ``<PackageName>`` is the case-preserved package name.
-
-   d. :envvar:`<PACKAGENAME>_ROOT` environment variable,
-      where ``<PACKAGENAME>`` is the upper-cased package name.
-      See policy :policy:`CMP0144`.
-
-      .. versionadded:: 3.27
-
-   The package root variables are maintained as a stack, so if called from
-   nested find modules or config packages, root paths from the parent's find
-   module or config package will be searched after paths from the current
-   module or package.  In other words, the search order would be
-   ``<CurrentPackage>_ROOT``, ``ENV{<CurrentPackage>_ROOT}``,
-   ``<ParentPackage>_ROOT``, ``ENV{<ParentPackage>_ROOT}``, etc.
-   This can be skipped if ``NO_PACKAGE_ROOT_PATH`` is passed or by setting
-   the :variable:`CMAKE_FIND_USE_PACKAGE_ROOT_PATH` to ``FALSE``.
-
-   * |FIND_PACKAGE_ROOT_PREFIX_PATH_XXX|
-
-2. Search paths specified in cmake-specific cache variables.
-   These are intended to be used on the command line with a ``-DVAR=value``.
-   The values are interpreted as :ref:`semicolon-separated lists <CMake Language Lists>`.
-   This can be skipped if ``NO_CMAKE_PATH`` is passed or by setting the
-   :variable:`CMAKE_FIND_USE_CMAKE_PATH` to ``FALSE``.
-
-   * |CMAKE_PREFIX_PATH_XXX|
-   * |CMAKE_XXX_PATH|
-   * |CMAKE_XXX_MAC_PATH|
-
-3. Search paths specified in cmake-specific environment variables.
-   These are intended to be set in the user's shell configuration,
-   and therefore use the host's native path separator
-   (``;`` on Windows and ``:`` on UNIX).
-   This can be skipped if ``NO_CMAKE_ENVIRONMENT_PATH`` is passed or
-   by setting the :variable:`CMAKE_FIND_USE_CMAKE_ENVIRONMENT_PATH` to ``FALSE``.
-
-   * |ENV_CMAKE_PREFIX_PATH_XXX|
-   * |ENV_CMAKE_XXX_PATH|
-   * |ENV_CMAKE_XXX_MAC_PATH|
-
-4. Search the paths specified by the ``HINTS`` option.
-   These should be paths computed by system introspection, such as a
-   hint provided by the location of another item already found.
-   Hard-coded guesses should be specified with the ``PATHS`` option.
-
-5. Search the standard system environment variables.
-   This can be skipped if ``NO_SYSTEM_ENVIRONMENT_PATH`` is passed or by
-   setting the :variable:`CMAKE_FIND_USE_SYSTEM_ENVIRONMENT_PATH` to ``FALSE``.
-
-   * |SYSTEM_ENVIRONMENT_PATH_XXX|
-   * |SYSTEM_ENVIRONMENT_PATH_WINDOWS_XXX|
-
-6. Search cmake variables defined in the Platform files
-   for the current system.  The searching of ``CMAKE_INSTALL_PREFIX`` and
-   ``CMAKE_STAGING_PREFIX`` can be
-   skipped if ``NO_CMAKE_INSTALL_PREFIX`` is passed or by setting the
-   :variable:`CMAKE_FIND_USE_INSTALL_PREFIX` to ``FALSE``. All these locations
-   can be skipped if ``NO_CMAKE_SYSTEM_PATH`` is passed or by setting the
-   :variable:`CMAKE_FIND_USE_CMAKE_SYSTEM_PATH` to ``FALSE``.
-
-   * |CMAKE_SYSTEM_PREFIX_PATH_XXX|
-   * |CMAKE_SYSTEM_XXX_PATH|
-   * |CMAKE_SYSTEM_XXX_MAC_PATH|
-
-   The platform paths that these variables contain are locations that
-   typically include installed software. An example being ``/usr/local`` for
-   UNIX based platforms.
-
-7. Search the paths specified by the PATHS option
-   or in the short-hand version of the command.
-   These are typically hard-coded guesses.
-
-The :variable:`CMAKE_IGNORE_PATH`, :variable:`CMAKE_IGNORE_PREFIX_PATH`,
-:variable:`CMAKE_SYSTEM_IGNORE_PATH` and
-:variable:`CMAKE_SYSTEM_IGNORE_PREFIX_PATH` variables can also cause some
-of the above locations to be ignored.
-
-.. versionadded:: 3.16
-  Added ``CMAKE_FIND_USE_<CATEGORY>_PATH`` variables to globally disable
-  various search locations.
-
-.. |FIND_ARGS_XXX| replace:: <VAR> NAMES name
-
-On macOS the :variable:`CMAKE_FIND_FRAMEWORK` and
-:variable:`CMAKE_FIND_APPBUNDLE` variables determine the order of
-preference between Apple-style and unix-style package components.
-
-.. include:: FIND_XXX_ROOT.txt
-.. include:: FIND_XXX_ORDER.txt

third-party/cmake-3.27.7-linux-x86_64/share/cmake-3.27/Help/command/FIND_XXX_ORDER.txt

@@ -1,12 +0,0 @@
-The default search order is designed to be most-specific to
-least-specific for common use cases.
-Projects may override the order by simply calling the command
-multiple times and using the ``NO_*`` options:
-
-.. parsed-literal::
-
-   |FIND_XXX| (|FIND_ARGS_XXX| PATHS paths... NO_DEFAULT_PATH)
-   |FIND_XXX| (|FIND_ARGS_XXX|)
-
-Once one of the calls succeeds the result variable will be set
-and stored in the cache so that no call will search again.

third-party/cmake-3.27.7-linux-x86_64/share/cmake-3.27/Help/command/FIND_XXX_REGISTRY_VIEW.txt

@@ -1,41 +0,0 @@
-Specify which registry views must be queried. This option is only meaningful
-on ``Windows`` platforms and will be ignored on other ones. When not
-specified, the |FIND_XXX_REGISTRY_VIEW_DEFAULT| view is used when the
-:policy:`CMP0134` policy is ``NEW``. Refer to :policy:`CMP0134` for the
-default view when the policy is ``OLD``.
-
-``64``
-  Query the 64-bit registry. On 32-bit Windows, it always returns the string
-  ``/REGISTRY-NOTFOUND``.
-
-``32``
-  Query the 32-bit registry.
-
-``64_32``
-  Query both views (``64`` and ``32``) and generate a path for each.
-
-``32_64``
-  Query both views (``32`` and ``64``) and generate a path for each.
-
-``HOST``
-  Query the registry matching the architecture of the host: ``64`` on 64-bit
-  Windows and ``32`` on 32-bit Windows.
-
-``TARGET``
-  Query the registry matching the architecture specified by the
-  :variable:`CMAKE_SIZEOF_VOID_P` variable. If not defined, fall back to
-  ``HOST`` view.
-
-``BOTH``
-  Query both views (``32`` and ``64``). The order depends on the following
-  rules: If the :variable:`CMAKE_SIZEOF_VOID_P` variable is defined, use the
-  following view depending on the content of this variable:
-
-  * ``8``: ``64_32``
-  * ``4``: ``32_64``
-
-  If the :variable:`CMAKE_SIZEOF_VOID_P` variable is not defined, rely on the
-  architecture of the host:
-
-  * 64-bit: ``64_32``
-  * 32-bit: ``32``

third-party/cmake-3.27.7-linux-x86_64/share/cmake-3.27/Help/command/FIND_XXX_ROOT.txt

@@ -1,29 +0,0 @@
-The CMake variable :variable:`CMAKE_FIND_ROOT_PATH` specifies one or more
-directories to be prepended to all other search directories.  This
-effectively "re-roots" the entire search under given locations.
-Paths which are descendants of the :variable:`CMAKE_STAGING_PREFIX` are excluded
-from this re-rooting, because that variable is always a path on the host system.
-By default the :variable:`CMAKE_FIND_ROOT_PATH` is empty.
-
-The :variable:`CMAKE_SYSROOT` variable can also be used to specify exactly one
-directory to use as a prefix.  Setting :variable:`CMAKE_SYSROOT` also has other
-effects.  See the documentation for that variable for more.
-
-These variables are especially useful when cross-compiling to
-point to the root directory of the target environment and CMake will
-search there too.  By default at first the directories listed in
-:variable:`CMAKE_FIND_ROOT_PATH` are searched, then the :variable:`CMAKE_SYSROOT`
-directory is searched, and then the non-rooted directories will be
-searched.  The default behavior can be adjusted by setting
-|CMAKE_FIND_ROOT_PATH_MODE_XXX|.  This behavior can be manually
-overridden on a per-call basis using options:
-
-``CMAKE_FIND_ROOT_PATH_BOTH``
-  Search in the order described above.
-
-``NO_CMAKE_FIND_ROOT_PATH``
-  Do not use the :variable:`CMAKE_FIND_ROOT_PATH` variable.
-
-``ONLY_CMAKE_FIND_ROOT_PATH``
-  Search only the re-rooted directories and directories below
-  :variable:`CMAKE_STAGING_PREFIX`.

third-party/cmake-3.27.7-linux-x86_64/share/cmake-3.27/Help/command/GENEX_NOTE.txt

@@ -1,6 +0,0 @@
-.. |more_see_also| replace:: See the :manual:`cmake-buildsystem(7)` manual
-   for more on defining buildsystem properties.
-
-Arguments to |command_name| may use generator expressions
-with the syntax ``$<...>``. See the :manual:`cmake-generator-expressions(7)`
-manual for available expressions.  |more_see_also|

third-party/cmake-3.27.7-linux-x86_64/share/cmake-3.27/Help/command/LINK_OPTIONS_LINKER.txt

@@ -1,25 +0,0 @@
-Handling Compiler Driver Differences
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-To pass options to the linker tool, each compiler driver has its own syntax.
-The ``LINKER:`` prefix and ``,`` separator can be used to specify, in a portable
-way, options to pass to the linker tool. ``LINKER:`` is replaced by the
-appropriate driver option and ``,`` by the appropriate driver separator.
-The driver prefix and driver separator are given by the values of the
-:variable:`CMAKE_<LANG>_LINKER_WRAPPER_FLAG` and
-:variable:`CMAKE_<LANG>_LINKER_WRAPPER_FLAG_SEP` variables.
-
-For example, ``"LINKER:-z,defs"`` becomes ``-Xlinker -z -Xlinker defs`` for
-``Clang`` and ``-Wl,-z,defs`` for ``GNU GCC``.
-
-The ``LINKER:`` prefix can be specified as part of a ``SHELL:`` prefix
-expression.
-
-The ``LINKER:`` prefix supports, as an alternative syntax, specification of
-arguments using the ``SHELL:`` prefix and space as separator. The previous
-example then becomes ``"LINKER:SHELL:-z defs"``.
-
-.. note::
-
-  Specifying the ``SHELL:`` prefix anywhere other than at the beginning of the
-  ``LINKER:`` prefix is not supported.

third-party/cmake-3.27.7-linux-x86_64/share/cmake-3.27/Help/command/OPTIONS_SHELL.txt

@@ -1,15 +0,0 @@
-Option De-duplication
-^^^^^^^^^^^^^^^^^^^^^
-
-The final set of options used for a target is constructed by
-accumulating options from the current target and the usage requirements of
-its dependencies.  The set of options is de-duplicated to avoid repetition.
-
-.. versionadded:: 3.12
-  While beneficial for individual options, the de-duplication step can break
-  up option groups.  For example, ``-option A -option B`` becomes
-  ``-option A B``.  One may specify a group of options using shell-like
-  quoting along with a ``SHELL:`` prefix.  The ``SHELL:`` prefix is dropped,
-  and the rest of the option string is parsed using the
-  :command:`separate_arguments` ``UNIX_COMMAND`` mode. For example,
-  ``"SHELL:-option A" "SHELL:-option B"`` becomes ``-option A -option B``.

third-party/cmake-3.27.7-linux-x86_64/share/cmake-3.27/Help/command/SUPPORTED_LANGUAGES.txt

@@ -1,25 +0,0 @@
-
-Supported languages are ``C``, ``CXX`` (i.e.  C++), ``CSharp`` (i.e.  C#), ``CUDA``,
-``OBJC`` (i.e. Objective-C), ``OBJCXX`` (i.e. Objective-C++), ``Fortran``, ``HIP``,
-``ISPC``, ``Swift``, ``ASM``, ``ASM_NASM``, ``ASM_MARMASM``, ``ASM_MASM``, and ``ASM-ATT``.
-
-  .. versionadded:: 3.8
-    Added ``CSharp`` and ``CUDA`` support.
-
-  .. versionadded:: 3.15
-    Added ``Swift`` support.
-
-  .. versionadded:: 3.16
-    Added ``OBJC`` and ``OBJCXX`` support.
-
-  .. versionadded:: 3.18
-    Added ``ISPC`` support.
-
-  .. versionadded:: 3.21
-    Added ``HIP`` support.
-
-  .. versionadded:: 3.26
-    Added ``ASM_MARMASM`` support.
-
-If enabling ``ASM``, list it last so that CMake can check whether
-compilers for other languages like ``C`` work for assembly too.

third-party/cmake-3.27.7-linux-x86_64/share/cmake-3.27/Help/command/UNSET_NOTE.txt

@@ -1,9 +0,0 @@
-.. note::
-
-  When evaluating :ref:`Variable References` of the form ``${VAR}``, CMake
-  first searches for a normal variable with that name.  If no such normal
-  variable exists, CMake will then search for a cache entry with that name.
-  Because of this, **unsetting a normal variable can expose a cache variable
-  that was previously hidden**.  To force a variable reference of the form
-  ``${VAR}`` to return an empty string, use ``set(<variable> "")``, which
-  clears the normal variable but leaves it defined.

third-party/cmake-3.27.7-linux-x86_64/share/cmake-3.27/Help/command/add_compile_definitions.rst

@@ -1,33 +0,0 @@
-add_compile_definitions
------------------------
-
-.. versionadded:: 3.12
-
-Add preprocessor definitions to the compilation of source files.
-
-.. code-block:: cmake
-
-  add_compile_definitions(<definition> ...)
-
-Adds preprocessor definitions to the compiler command line.
-
-The preprocessor definitions are added to the :prop_dir:`COMPILE_DEFINITIONS`
-directory property for the current ``CMakeLists`` file. They are also added to
-the :prop_tgt:`COMPILE_DEFINITIONS` target property for each target in the
-current ``CMakeLists`` file.
-
-Definitions are specified using the syntax ``VAR`` or ``VAR=value``.
-Function-style definitions are not supported. CMake will automatically
-escape the value correctly for the native build system (note that CMake
-language syntax may require escapes to specify some values).
-
-.. versionadded:: 3.26
-  Any leading ``-D`` on an item will be removed.
-
-.. |command_name| replace:: ``add_compile_definitions``
-.. include:: GENEX_NOTE.txt
-
-See Also
-^^^^^^^^
-
-* The command :command:`target_compile_definitions` adds target-specific definitions.

third-party/cmake-3.27.7-linux-x86_64/share/cmake-3.27/Help/command/add_compile_options.rst

@@ -1,67 +0,0 @@
-add_compile_options
--------------------
-
-Add options to the compilation of source files.
-
-.. code-block:: cmake
-
-  add_compile_options(<option> ...)
-
-Adds options to the :prop_dir:`COMPILE_OPTIONS` directory property.
-These options are used when compiling targets from the current
-directory and below.
-
-.. note::
-
-  These options are not used when linking.
-  See the :command:`add_link_options` command for that.
-
-Arguments
-^^^^^^^^^
-
-.. |command_name| replace:: ``add_compile_options``
-.. include:: GENEX_NOTE.txt
-
-.. include:: OPTIONS_SHELL.txt
-
-Example
-^^^^^^^
-
-Since different compilers support different options, a typical use of
-this command is in a compiler-specific conditional clause:
-
-.. code-block:: cmake
-
-  if (MSVC)
-      # warning level 4
-      add_compile_options(/W4)
-  else()
-      # additional warnings
-      add_compile_options(-Wall -Wextra -Wpedantic)
-  endif()
-
-To set per-language options, use the :genex:`$<COMPILE_LANGUAGE>`
-or :genex:`$<COMPILE_LANGUAGE:languages>` generator expressions.
-
-See Also
-^^^^^^^^
-
-* This command can be used to add any options. However, for
-  adding preprocessor definitions and include directories it is recommended
-  to use the more specific commands :command:`add_compile_definitions`
-  and :command:`include_directories`.
-
-* The command :command:`target_compile_options` adds target-specific options.
-
-* This command adds compile options for all languages.
-  Use the :genex:`COMPILE_LANGUAGE` generator expression to specify
-  per-language compile options.
-
-* The source file property :prop_sf:`COMPILE_OPTIONS` adds options to one
-  source file.
-
-* :command:`add_link_options` adds options for linking.
-
-* :variable:`CMAKE_<LANG>_FLAGS` and :variable:`CMAKE_<LANG>_FLAGS_<CONFIG>`
-  add language-wide flags passed to all invocations of the compiler.
-  This includes invocations that drive compiling and those that drive linking.

third-party/cmake-3.27.7-linux-x86_64/share/cmake-3.27/Help/command/add_custom_command.rst

@@ -1,577 +0,0 @@
-add_custom_command
-------------------
-
-Add a custom build rule to the generated build system.
-
-There are two main signatures for ``add_custom_command``.
-
-Generating Files
-^^^^^^^^^^^^^^^^
-
-The first signature is for adding a custom command to produce an output:
-
-.. code-block:: cmake
-
-  add_custom_command(OUTPUT output1 [output2 ...]
-                     COMMAND command1 [ARGS] [args1...]
-                     [COMMAND command2 [ARGS] [args2...] ...]
-                     [MAIN_DEPENDENCY depend]
-                     [DEPENDS [depends...]]
-                     [BYPRODUCTS [files...]]
-                     [IMPLICIT_DEPENDS <lang1> depend1
-                                      [<lang2> depend2] ...]
-                     [WORKING_DIRECTORY dir]
-                     [COMMENT comment]
-                     [DEPFILE depfile]
-                     [JOB_POOL job_pool]
-                     [VERBATIM] [APPEND] [USES_TERMINAL]
-                     [COMMAND_EXPAND_LISTS]
-                     [DEPENDS_EXPLICIT_ONLY])
-
-This defines a command to generate specified ``OUTPUT`` file(s).
-A target created in the same directory (``CMakeLists.txt`` file)
-that specifies any output of the custom command as a source file
-is given a rule to generate the file using the command at build time.
-
-Do not list the output in more than one independent target that
-may build in parallel or the instances of the rule may conflict.
-Instead, use the :command:`add_custom_target` command to drive the
-command and make the other targets depend on that one.  See the
-`Example: Generating Files for Multiple Targets`_ below.
-
-The options are:
-
-``APPEND``
-  Append the ``COMMAND`` and ``DEPENDS`` option values to the custom
-  command for the first output specified.  There must have already
-  been a previous call to this command with the same output.
-
-  If the previous call specified the output via a generator expression,
-  the output specified by the current call must match in at least one
-  configuration after evaluating generator expressions.  In this case,
-  the appended commands and dependencies apply to all configurations.
-
-  The ``COMMENT``, ``MAIN_DEPENDENCY``, and ``WORKING_DIRECTORY``
-  options are currently ignored when APPEND is given, but may be
-  used in the future.
-
-``BYPRODUCTS``
-  .. versionadded:: 3.2
-
-  Specify the files the command is expected to produce but whose
-  modification time may or may not be newer than the dependencies.
-  If a byproduct name is a relative path it will be interpreted
-  relative to the build tree directory corresponding to the
-  current source directory.
-  Each byproduct file will be marked with the :prop_sf:`GENERATED`
-  source file property automatically.
-
-  *See policy* :policy:`CMP0058` *for the motivation behind this feature.*
-
-  Explicit specification of byproducts is supported by the
-  :generator:`Ninja` generator to tell the ``ninja`` build tool
-  how to regenerate byproducts when they are missing.  It is
-  also useful when other build rules (e.g. custom commands)
-  depend on the byproducts.  Ninja requires a build rule for any
-  generated file on which another rule depends even if there are
-  order-only dependencies to ensure the byproducts will be
-  available before their dependents build.
-
-  The :ref:`Makefile Generators` will remove ``BYPRODUCTS`` and other
-  :prop_sf:`GENERATED` files during ``make clean``.
-
-  .. versionadded:: 3.20
-    Arguments to ``BYPRODUCTS`` may use a restricted set of
-    :manual:`generator expressions <cmake-generator-expressions(7)>`.
-    :ref:`Target-dependent expressions <Target-Dependent Queries>` are not
-    permitted.
-
-``COMMAND``
-  Specify the command-line(s) to execute at build time.
-  If more than one ``COMMAND`` is specified they will be executed in order,
-  but *not* necessarily composed into a stateful shell or batch script.
-  (To run a full script, use the :command:`configure_file` command or the
-  :command:`file(GENERATE)` command to create it, and then specify
-  a ``COMMAND`` to launch it.)
-  The optional ``ARGS`` argument is for backward compatibility and
-  will be ignored.
-
-  If ``COMMAND`` specifies an executable target name (created by the
-  :command:`add_executable` command), it will automatically be replaced
-  by the location of the executable created at build time if either of
-  the following is true:
-
-  * The target is not being cross-compiled (i.e. the
-    :variable:`CMAKE_CROSSCOMPILING` variable is not set to true).
-  * .. versionadded:: 3.6
-      The target is being cross-compiled and an emulator is provided (i.e.
-      its :prop_tgt:`CROSSCOMPILING_EMULATOR` target property is set).
-      In this case, the contents of :prop_tgt:`CROSSCOMPILING_EMULATOR` will be
-      prepended to the command before the location of the target executable.
-
-  If neither of the above conditions are met, it is assumed that the
-  command name is a program to be found on the ``PATH`` at build time.
-
-  Arguments to ``COMMAND`` may use
-  :manual:`generator expressions <cmake-generator-expressions(7)>`.
-  Use the :genex:`TARGET_FILE` generator expression to refer to the location
-  of a target later in the command line (i.e. as a command argument rather
-  than as the command to execute).
-
-  Whenever one of the following target based generator expressions are used as
-  a command to execute or is mentioned in a command argument, a target-level
-  dependency will be added automatically so that the mentioned target will be
-  built before any target using this custom command
-  (see policy :policy:`CMP0112`).
-
-    * ``TARGET_FILE``
-    * ``TARGET_LINKER_FILE``
-    * ``TARGET_SONAME_FILE``
-    * ``TARGET_PDB_FILE``
-
-  This target-level dependency does NOT add a file-level dependency that would
-  cause the custom command to re-run whenever the executable is recompiled.
-  List target names with the ``DEPENDS`` option to add such file-level
-  dependencies.
-
-
-``COMMENT``
-  Display the given message before the commands are executed at
-  build time.
-
-  .. versionadded:: 3.26
-    Arguments to ``COMMENT`` may use
-    :manual:`generator expressions <cmake-generator-expressions(7)>`.
-
-``DEPENDS``
-  Specify files on which the command depends.  Each argument is converted
-  to a dependency as follows:
-
-  1. If the argument is the name of a target (created by the
-     :command:`add_custom_target`, :command:`add_executable`, or
-     :command:`add_library` command) a target-level dependency is
-     created to make sure the target is built before any target
-     using this custom command.  Additionally, if the target is an
-     executable or library, a file-level dependency is created to
-     cause the custom command to re-run whenever the target is
-     recompiled.
-
-  2. If the argument is an absolute path, a file-level dependency
-     is created on that path.
-
-  3. If the argument is the name of a source file that has been
-     added to a target or on which a source file property has been set,
-     a file-level dependency is created on that source file.
-
-  4. If the argument is a relative path and it exists in the current
-     source directory, a file-level dependency is created on that
-     file in the current source directory.
-
-  5. Otherwise, a file-level dependency is created on that path relative
-     to the current binary directory.
-
-  If any dependency is an ``OUTPUT`` of another custom command in the same
-  directory (``CMakeLists.txt`` file), CMake automatically brings the other
-  custom command into the target in which this command is built.
-
-  .. versionadded:: 3.16
-    A target-level dependency is added if any dependency is listed as
-    ``BYPRODUCTS`` of a target or any of its build events in the same
-    directory to ensure the byproducts will be available.
-
-  If ``DEPENDS`` is not specified, the command will run whenever
-  the ``OUTPUT`` is missing; if the command does not actually
-  create the ``OUTPUT``, the rule will always run.
-
-  .. versionadded:: 3.1
-    Arguments to ``DEPENDS`` may use
-    :manual:`generator expressions <cmake-generator-expressions(7)>`.
-
-``COMMAND_EXPAND_LISTS``
-  .. versionadded:: 3.8
-
-  Lists in ``COMMAND`` arguments will be expanded, including those
-  created with
-  :manual:`generator expressions <cmake-generator-expressions(7)>`,
-  allowing ``COMMAND`` arguments such as
-  ``${CC} "-I$<JOIN:$<TARGET_PROPERTY:foo,INCLUDE_DIRECTORIES>,;-I>" foo.cc``
-  to be properly expanded.
-
-``IMPLICIT_DEPENDS``
-  Request scanning of implicit dependencies of an input file.
-  The language given specifies the programming language whose
-  corresponding dependency scanner should be used.
-  Currently only ``C`` and ``CXX`` language scanners are supported.
-  The language has to be specified for every file in the
-  ``IMPLICIT_DEPENDS`` list.  Dependencies discovered from the
-  scanning are added to those of the custom command at build time.
-  Note that the ``IMPLICIT_DEPENDS`` option is currently supported
-  only for Makefile generators and will be ignored by other generators.
-
-  .. note::
-
-    This option cannot be specified at the same time as ``DEPFILE`` option.
-
-``JOB_POOL``
-  .. versionadded:: 3.15
-
-  Specify a :prop_gbl:`pool <JOB_POOLS>` for the :generator:`Ninja`
-  generator. Incompatible with ``USES_TERMINAL``, which implies
-  the ``console`` pool.
-  Using a pool that is not defined by :prop_gbl:`JOB_POOLS` causes
-  an error by ninja at build time.
-
-``MAIN_DEPENDENCY``
-  Specify the primary input source file to the command.  This is
-  treated just like any value given to the ``DEPENDS`` option
-  but also suggests to Visual Studio generators where to hang
-  the custom command. Each source file may have at most one command
-  specifying it as its main dependency. A compile command (i.e. for a
-  library or an executable) counts as an implicit main dependency which
-  gets silently overwritten by a custom command specification.
-
-``OUTPUT``
-  Specify the output files the command is expected to produce.
-  Each output file will be marked with the :prop_sf:`GENERATED`
-  source file property automatically.
-  If the output of the custom command is not actually created
-  as a file on disk it should be marked with the :prop_sf:`SYMBOLIC`
-  source file property.
-
-  If an output file name is a relative path, its absolute path is
-  determined by interpreting it relative to:
-
-  1. the build directory corresponding to the current source directory
-     (:variable:`CMAKE_CURRENT_BINARY_DIR`), or
-
-  2. the current source directory (:variable:`CMAKE_CURRENT_SOURCE_DIR`).
-
-  The path in the build directory is preferred unless the path in the
-  source tree is mentioned as an absolute source file path elsewhere
-  in the current directory.
-
-  .. versionadded:: 3.20
-    Arguments to ``OUTPUT`` may use a restricted set of
-    :manual:`generator expressions <cmake-generator-expressions(7)>`.
-    :ref:`Target-dependent expressions <Target-Dependent Queries>` are not
-    permitted.
-
-``USES_TERMINAL``
-  .. versionadded:: 3.2
-
-  The command will be given direct access to the terminal if possible.
-  With the :generator:`Ninja` generator, this places the command in
-  the ``console`` :prop_gbl:`pool <JOB_POOLS>`.
-
-``VERBATIM``
-  All arguments to the commands will be escaped properly for the
-  build tool so that the invoked command receives each argument
-  unchanged.  Note that one level of escapes is still used by the
-  CMake language processor before add_custom_command even sees the
-  arguments.  Use of ``VERBATIM`` is recommended as it enables
-  correct behavior.  When ``VERBATIM`` is not given the behavior
-  is platform specific because there is no protection of
-  tool-specific special characters.
-
-``WORKING_DIRECTORY``
-  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.
-
-  .. versionadded:: 3.13
-    Arguments to ``WORKING_DIRECTORY`` may use
-    :manual:`generator expressions <cmake-generator-expressions(7)>`.
-
-``DEPFILE``
-  .. versionadded:: 3.7
-
-  Specify a depfile which holds dependencies for the custom command. It is
-  usually emitted by the custom command itself.  This keyword may only be used
-  if the generator supports it, as detailed below.
-
-  The expected format, compatible with what is generated by ``gcc`` with the
-  option ``-M``, is independent of the generator or platform.
-
-  The formal syntax, as specified using
-  `BNF <https://en.wikipedia.org/wiki/Backus%E2%80%93Naur_form>`_ notation with
-  the regular extensions, is the following:
-
-  .. raw:: latex
-
-    \begin{small}
-
-  .. productionlist:: depfile
-    depfile: `rule`*
-    rule: `targets` (':' (`separator` `dependencies`?)?)? `eol`
-    targets: `target` (`separator` `target`)* `separator`*
-    target: `pathname`
-    dependencies: `dependency` (`separator` `dependency`)* `separator`*
-    dependency: `pathname`
-    separator: (`space` | `line_continue`)+
-    line_continue: '\' `eol`
-    space: ' ' | '\t'
-    pathname: `character`+
-    character: `std_character` | `dollar` | `hash` | `whitespace`
-    std_character: <any character except '$', '#' or ' '>
-    dollar: '$$'
-    hash: '\#'
-    whitespace: '\ '
-    eol: '\r'? '\n'
-
-  .. raw:: latex
-
-    \end{small}
-
-  .. note::
-
-    As part of ``pathname``, any slash and backslash is interpreted as
-    a directory separator.
-
-  .. versionadded:: 3.7
-    The :generator:`Ninja` generator supports ``DEPFILE`` since the keyword
-    was first added.
-
-  .. versionadded:: 3.17
-    Added the :generator:`Ninja Multi-Config` generator, which included
-    support for the ``DEPFILE`` keyword.
-
-  .. versionadded:: 3.20
-    Added support for :ref:`Makefile Generators`.
-
-    .. note::
-
-      ``DEPFILE`` cannot be specified at the same time as the
-      ``IMPLICIT_DEPENDS`` option for :ref:`Makefile Generators`.
-
-  .. versionadded:: 3.21
-    Added support for :ref:`Visual Studio Generators` with VS 2012 and above,
-    and for the :generator:`Xcode` generator.  Support for
-    :manual:`generator expressions <cmake-generator-expressions(7)>` was also
-    added.
-
-  Using ``DEPFILE`` with generators other than those listed above is an error.
-
-  If the ``DEPFILE`` argument is relative, it should be relative to
-  :variable:`CMAKE_CURRENT_BINARY_DIR`, and any relative paths inside the
-  ``DEPFILE`` should also be relative to :variable:`CMAKE_CURRENT_BINARY_DIR`.
-  See policy :policy:`CMP0116`, which is always ``NEW`` for
-  :ref:`Makefile Generators`, :ref:`Visual Studio Generators`,
-  and the :generator:`Xcode` generator.
-
-``DEPENDS_EXPLICIT_ONLY``
-
-  .. versionadded:: 3.27
-
-  Indicates that the command's ``DEPENDS`` argument represents all files
-  required by the command and implicit dependencies are not required.
-
-  Without this option, if any target uses the output of the custom command,
-  CMake will consider that target's dependencies as implicit dependencies for
-  the custom command in case this custom command requires files implicitly
-  created by those targets.
-
-  This option can be enabled on all custom commands by setting
-  :variable:`CMAKE_ADD_CUSTOM_COMMAND_DEPENDS_EXPLICIT_ONLY` to ``ON``.
-
-  Only the :ref:`Ninja Generators` actually use this information to remove
-  unnecessary implicit dependencies.
-
-  See also the :prop_tgt:`OPTIMIZE_DEPENDENCIES` target property, which may
-  provide another way for reducing the impact of target dependencies in some
-  scenarios.
-
-Examples: Generating Files
-^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Custom commands may be used to generate source files.
-For example, the code:
-
-.. code-block:: cmake
-
-  add_custom_command(
-    OUTPUT out.c
-    COMMAND someTool -i ${CMAKE_CURRENT_SOURCE_DIR}/in.txt
-                     -o out.c
-    DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/in.txt
-    VERBATIM)
-  add_library(myLib out.c)
-
-adds a custom command to run ``someTool`` to generate ``out.c`` and then
-compile the generated source as part of a library.  The generation rule
-will re-run whenever ``in.txt`` changes.
-
-.. versionadded:: 3.20
-  One may use generator expressions to specify per-configuration outputs.
-  For example, the code:
-
-  .. code-block:: cmake
-
-    add_custom_command(
-      OUTPUT "out-$<CONFIG>.c"
-      COMMAND someTool -i ${CMAKE_CURRENT_SOURCE_DIR}/in.txt
-                       -o "out-$<CONFIG>.c"
-                       -c "$<CONFIG>"
-      DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/in.txt
-      VERBATIM)
-    add_library(myLib "out-$<CONFIG>.c")
-
-  adds a custom command to run ``someTool`` to generate ``out-<config>.c``,
-  where ``<config>`` is the build configuration, and then compile the generated
-  source as part of a library.
-
-Example: Generating Files for Multiple Targets
-""""""""""""""""""""""""""""""""""""""""""""""
-
-If multiple independent targets need the same custom command output,
-it must be attached to a single custom target on which they all depend.
-Consider the following example:
-
-.. code-block:: cmake
-
-  add_custom_command(
-    OUTPUT table.csv
-    COMMAND makeTable -i ${CMAKE_CURRENT_SOURCE_DIR}/input.dat
-                      -o table.csv
-    DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/input.dat
-    VERBATIM)
-  add_custom_target(generate_table_csv DEPENDS table.csv)
-
-  add_custom_command(
-    OUTPUT foo.cxx
-    COMMAND genFromTable -i table.csv -case foo -o foo.cxx
-    DEPENDS table.csv           # file-level dependency
-            generate_table_csv  # target-level dependency
-    VERBATIM)
-  add_library(foo foo.cxx)
-
-  add_custom_command(
-    OUTPUT bar.cxx
-    COMMAND genFromTable -i table.csv -case bar -o bar.cxx
-    DEPENDS table.csv           # file-level dependency
-            generate_table_csv  # target-level dependency
-    VERBATIM)
-  add_library(bar bar.cxx)
-
-Output ``foo.cxx`` is needed only by target ``foo`` and output ``bar.cxx``
-is needed only by target ``bar``, but *both* targets need ``table.csv``,
-transitively.  Since ``foo`` and ``bar`` are independent targets that may
-build concurrently, we prevent them from racing to generate ``table.csv``
-by placing its custom command in a separate target, ``generate_table_csv``.
-The custom commands generating ``foo.cxx`` and ``bar.cxx`` each specify a
-target-level dependency on ``generate_table_csv``, so the targets using them,
-``foo`` and ``bar``, will not build until after target ``generate_table_csv``
-is built.
-
-.. _`add_custom_command(TARGET)`:
-
-Build Events
-^^^^^^^^^^^^
-
-The second signature adds a custom command to a target such as a
-library or executable.  This is useful for performing an operation
-before or after building the target.  The command becomes part of the
-target and will only execute when the target itself is built.  If the
-target is already built, the command will not execute.
-
-.. code-block:: cmake
-
-  add_custom_command(TARGET <target>
-                     PRE_BUILD | PRE_LINK | POST_BUILD
-                     COMMAND command1 [ARGS] [args1...]
-                     [COMMAND command2 [ARGS] [args2...] ...]
-                     [BYPRODUCTS [files...]]
-                     [WORKING_DIRECTORY dir]
-                     [COMMENT comment]
-                     [VERBATIM]
-                     [COMMAND_EXPAND_LISTS])
-
-This defines a new command that will be associated with building the
-specified ``<target>``.  The ``<target>`` must be defined in the current
-directory; targets defined in other directories may not be specified.
-
-When the command will happen is determined by which
-of the following is specified:
-
-``PRE_BUILD``
-  This option has unique behavior for the :ref:`Visual Studio Generators`.
-  When using one of the Visual Studio generators, the command will run before
-  any other rules are executed within the target.  With all other generators,
-  this option behaves the same as ``PRE_LINK`` instead.  Because of this,
-  it is recommended to avoid using ``PRE_BUILD`` except when it is known that
-  a Visual Studio generator is being used.
-``PRE_LINK``
-  Run after sources have been compiled but before linking the binary
-  or running the librarian or archiver tool of a static library.
-  This is not defined for targets created by the
-  :command:`add_custom_target` command.
-``POST_BUILD``
-  Run after all other rules within the target have been executed.
-
-Projects should always specify one of the above three keywords when using
-the ``TARGET`` form.  For backward compatibility reasons, ``POST_BUILD`` is
-assumed if no such keyword is given, but projects should explicitly provide
-one of the keywords to make clear the behavior they expect.
-
-.. note::
-  Because generator expressions can be used in custom commands,
-  it is possible to define ``COMMAND`` lines or whole custom commands
-  which evaluate to empty strings for certain configurations.
-  For **Visual Studio 11 2012 (and newer)** generators these command
-  lines or custom commands will be omitted for the specific
-  configuration and no "empty-string-command" will be added.
-
-  This allows to add individual build events for every configuration.
-
-.. versionadded:: 3.21
-  Support for target-dependent generator expressions.
-
-Examples: Build Events
-^^^^^^^^^^^^^^^^^^^^^^
-
-A ``POST_BUILD`` event may be used to post-process a binary after linking.
-For example, the code:
-
-.. code-block:: cmake
-
-  add_executable(myExe myExe.c)
-  add_custom_command(
-    TARGET myExe POST_BUILD
-    COMMAND someHasher -i "$<TARGET_FILE:myExe>"
-                       -o "$<TARGET_FILE:myExe>.hash"
-    VERBATIM)
-
-will run ``someHasher`` to produce a ``.hash`` file next to the executable
-after linking.
-
-.. versionadded:: 3.20
-  One may use generator expressions to specify per-configuration byproducts.
-  For example, the code:
-
-  .. code-block:: cmake
-
-    add_library(myPlugin MODULE myPlugin.c)
-    add_custom_command(
-      TARGET myPlugin POST_BUILD
-      COMMAND someHasher -i "$<TARGET_FILE:myPlugin>"
-                         --as-code "myPlugin-hash-$<CONFIG>.c"
-      BYPRODUCTS "myPlugin-hash-$<CONFIG>.c"
-      VERBATIM)
-    add_executable(myExe myExe.c "myPlugin-hash-$<CONFIG>.c")
-
-  will run ``someHasher`` after linking ``myPlugin``, e.g. to produce a ``.c``
-  file containing code to check the hash of ``myPlugin`` that the ``myExe``
-  executable can use to verify it before loading.
-
-Ninja Multi-Config
-^^^^^^^^^^^^^^^^^^
-
-.. versionadded:: 3.20
-
-  ``add_custom_command`` supports the :generator:`Ninja Multi-Config`
-  generator's cross-config capabilities. See the generator documentation
-  for more information.
-
-See Also
-^^^^^^^^
-
-* :command:`add_custom_target`

third-party/cmake-3.27.7-linux-x86_64/share/cmake-3.27/Help/command/add_custom_target.rst

@@ -1,192 +0,0 @@
-add_custom_target
------------------
-
-Add a target with no output so it will always be built.
-
-.. code-block:: cmake
-
-  add_custom_target(Name [ALL] [command1 [args1...]]
-                    [COMMAND command2 [args2...] ...]
-                    [DEPENDS depend depend depend ... ]
-                    [BYPRODUCTS [files...]]
-                    [WORKING_DIRECTORY dir]
-                    [COMMENT comment]
-                    [JOB_POOL job_pool]
-                    [VERBATIM] [USES_TERMINAL]
-                    [COMMAND_EXPAND_LISTS]
-                    [SOURCES src1 [src2...]])
-
-Adds a target with the given name that executes the given commands.
-The target has no output file and is *always considered out of date*
-even if the commands try to create a file with the name of the target.
-Use the :command:`add_custom_command` command to generate a file with
-dependencies.  By default nothing depends on the custom target.  Use
-the :command:`add_dependencies` command to add dependencies to or
-from other targets.
-
-The options are:
-
-``ALL``
-  Indicate that this target should be added to the default build
-  target so that it will be run every time (the command cannot be
-  called ``ALL``).
-
-``BYPRODUCTS``
-  .. versionadded:: 3.2
-
-  Specify the files the command is expected to produce but whose
-  modification time may or may not be updated on subsequent builds.
-  If a byproduct name is a relative path it will be interpreted
-  relative to the build tree directory corresponding to the
-  current source directory.
-  Each byproduct file will be marked with the :prop_sf:`GENERATED`
-  source file property automatically.
-
-  *See policy* :policy:`CMP0058` *for the motivation behind this feature.*
-
-  Explicit specification of byproducts is supported by the
-  :generator:`Ninja` generator to tell the ``ninja`` build tool
-  how to regenerate byproducts when they are missing.  It is
-  also useful when other build rules (e.g. custom commands)
-  depend on the byproducts.  Ninja requires a build rule for any
-  generated file on which another rule depends even if there are
-  order-only dependencies to ensure the byproducts will be
-  available before their dependents build.
-
-  The :ref:`Makefile Generators` will remove ``BYPRODUCTS`` and other
-  :prop_sf:`GENERATED` files during ``make clean``.
-
-  .. versionadded:: 3.20
-    Arguments to ``BYPRODUCTS`` may use a restricted set of
-    :manual:`generator expressions <cmake-generator-expressions(7)>`.
-    :ref:`Target-dependent expressions <Target-Dependent Queries>` are not
-    permitted.
-
-``COMMAND``
-  Specify the command-line(s) to execute at build time.
-  If more than one ``COMMAND`` is specified they will be executed in order,
-  but *not* necessarily composed into a stateful shell or batch script.
-  (To run a full script, use the :command:`configure_file` command or the
-  :command:`file(GENERATE)` command to create it, and then specify
-  a ``COMMAND`` to launch it.)
-
-  If ``COMMAND`` specifies an executable target name (created by the
-  :command:`add_executable` command), it will automatically be replaced
-  by the location of the executable created at build time if either of
-  the following is true:
-
-  * The target is not being cross-compiled (i.e. the
-    :variable:`CMAKE_CROSSCOMPILING` variable is not set to true).
-  * .. versionadded:: 3.6
-      The target is being cross-compiled and an emulator is provided (i.e.
-      its :prop_tgt:`CROSSCOMPILING_EMULATOR` target property is set).
-      In this case, the contents of :prop_tgt:`CROSSCOMPILING_EMULATOR` will be
-      prepended to the command before the location of the target executable.
-
-  If neither of the above conditions are met, it is assumed that the
-  command name is a program to be found on the ``PATH`` at build time.
-
-  Arguments to ``COMMAND`` may use
-  :manual:`generator expressions <cmake-generator-expressions(7)>`.
-  Use the :genex:`TARGET_FILE` generator expression to refer to the location
-  of a target later in the command line (i.e. as a command argument rather
-  than as the command to execute).
-
-  Whenever one of the following target based generator expressions are used as
-  a command to execute or is mentioned in a command argument, a target-level
-  dependency will be added automatically so that the mentioned target will be
-  built before this custom target (see policy :policy:`CMP0112`).
-
-    * ``TARGET_FILE``
-    * ``TARGET_LINKER_FILE``
-    * ``TARGET_SONAME_FILE``
-    * ``TARGET_PDB_FILE``
-
-  The command and arguments are optional and if not specified an empty
-  target will be created.
-
-``COMMENT``
-  Display the given message before the commands are executed at
-  build time.
-
-  .. versionadded:: 3.26
-    Arguments to ``COMMENT`` may use
-    :manual:`generator expressions <cmake-generator-expressions(7)>`.
-
-``DEPENDS``
-  Reference files and outputs of custom commands created with
-  :command:`add_custom_command` command calls in the same directory
-  (``CMakeLists.txt`` file).  They will be brought up to date when
-  the target is built.
-
-  .. versionchanged:: 3.16
-    A target-level dependency is added if any dependency is a byproduct
-    of a target or any of its build events in the same directory to ensure
-    the byproducts will be available before this target is built.
-
-  Use the :command:`add_dependencies` command to add dependencies
-  on other targets.
-
-``COMMAND_EXPAND_LISTS``
-  .. versionadded:: 3.8
-
-  Lists in ``COMMAND`` arguments will be expanded, including those
-  created with
-  :manual:`generator expressions <cmake-generator-expressions(7)>`,
-  allowing ``COMMAND`` arguments such as
-  ``${CC} "-I$<JOIN:$<TARGET_PROPERTY:foo,INCLUDE_DIRECTORIES>,;-I>" foo.cc``
-  to be properly expanded.
-
-``JOB_POOL``
-  .. versionadded:: 3.15
-
-  Specify a :prop_gbl:`pool <JOB_POOLS>` for the :generator:`Ninja`
-  generator. Incompatible with ``USES_TERMINAL``, which implies
-  the ``console`` pool.
-  Using a pool that is not defined by :prop_gbl:`JOB_POOLS` causes
-  an error by ninja at build time.
-
-``SOURCES``
-  Specify additional source files to be included in the custom target.
-  Specified source files will be added to IDE project files for
-  convenience in editing even if they have no build rules.
-
-``VERBATIM``
-  All arguments to the commands will be escaped properly for the
-  build tool so that the invoked command receives each argument
-  unchanged.  Note that one level of escapes is still used by the
-  CMake language processor before ``add_custom_target`` even sees
-  the arguments.  Use of ``VERBATIM`` is recommended as it enables
-  correct behavior.  When ``VERBATIM`` is not given the behavior
-  is platform specific because there is no protection of
-  tool-specific special characters.
-
-``USES_TERMINAL``
-  .. versionadded:: 3.2
-
-  The command will be given direct access to the terminal if possible.
-  With the :generator:`Ninja` generator, this places the command in
-  the ``console`` :prop_gbl:`pool <JOB_POOLS>`.
-
-``WORKING_DIRECTORY``
-  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.
-
-  .. versionadded:: 3.13
-    Arguments to ``WORKING_DIRECTORY`` may use
-    :manual:`generator expressions <cmake-generator-expressions(7)>`.
-
-Ninja Multi-Config
-^^^^^^^^^^^^^^^^^^
-
-.. versionadded:: 3.20
-
-  ``add_custom_target`` supports the :generator:`Ninja Multi-Config`
-  generator's cross-config capabilities. See the generator documentation
-  for more information.
-
-See Also
-^^^^^^^^
-
-* :command:`add_custom_command`

third-party/cmake-3.27.7-linux-x86_64/share/cmake-3.27/Help/command/add_definitions.rst

@@ -1,38 +0,0 @@
-add_definitions
----------------
-
-Add ``-D`` define flags to the compilation of source files.
-
-.. code-block:: cmake
-
-  add_definitions(-DFOO -DBAR ...)
-
-Adds definitions to the compiler command line for targets in the current
-directory, whether added before or after this command is invoked, and for
-the ones in sub-directories added after. This command can be used to add any
-flags, but it is intended to add preprocessor definitions.
-
-.. note::
-
-  This command has been superseded by alternatives:
-
-  * Use :command:`add_compile_definitions` to add preprocessor definitions.
-  * Use :command:`include_directories` to add include directories.
-  * Use :command:`add_compile_options` to add other options.
-
-Flags beginning in ``-D`` or ``/D`` that look like preprocessor definitions are
-automatically added to the :prop_dir:`COMPILE_DEFINITIONS` directory
-property for the current directory.  Definitions with non-trivial values
-may be left in the set of flags instead of being converted for reasons of
-backwards compatibility.  See documentation of the
-:prop_dir:`directory <COMPILE_DEFINITIONS>`,
-:prop_tgt:`target <COMPILE_DEFINITIONS>`,
-:prop_sf:`source file <COMPILE_DEFINITIONS>` ``COMPILE_DEFINITIONS``
-properties for details on adding preprocessor definitions to specific
-scopes and configurations.
-
-See Also
-^^^^^^^^
-
-* The :manual:`cmake-buildsystem(7)` manual for more on defining
-  buildsystem properties.

third-party/cmake-3.27.7-linux-x86_64/share/cmake-3.27/Help/command/add_dependencies.rst

@@ -1,31 +0,0 @@
-add_dependencies
-----------------
-
-Add a dependency between top-level targets.
-
-.. code-block:: cmake
-
-  add_dependencies(<target> [<target-dependency>]...)
-
-Makes a top-level ``<target>`` depend on other top-level targets to
-ensure that they build before ``<target>`` does.  A top-level target
-is one created by one of the :command:`add_executable`,
-:command:`add_library`, or :command:`add_custom_target` commands
-(but not targets generated by CMake like ``install``).
-
-Dependencies added to an :ref:`imported target <Imported Targets>`
-or an :ref:`interface library <Interface Libraries>` are followed
-transitively in its place since the target itself does not build.
-
-.. versionadded:: 3.3
-  Allow adding dependencies to interface libraries.
-
-See Also
-^^^^^^^^
-
-* The ``DEPENDS`` option of :command:`add_custom_target` and
-  :command:`add_custom_command` commands for adding file-level
-  dependencies in custom rules.
-
-* The :prop_sf:`OBJECT_DEPENDS` source file property to add
-  file-level dependencies to object files.

third-party/cmake-3.27.7-linux-x86_64/share/cmake-3.27/Help/command/add_executable.rst

@@ -1,114 +0,0 @@
-add_executable
---------------
-
-.. only:: html
-
-  .. contents::
-
-Add an executable to the project using the specified source files.
-
-Normal Executables
-^^^^^^^^^^^^^^^^^^
-
-.. code-block:: cmake
-
-  add_executable(<name> [WIN32] [MACOSX_BUNDLE]
-                 [EXCLUDE_FROM_ALL]
-                 [source1] [source2 ...])
-
-Adds an executable target called ``<name>`` to be built from the source
-files listed in the command invocation.  The
-``<name>`` corresponds to the logical target name and must be globally
-unique within a project.  The actual file name of the executable built is
-constructed based on conventions of the native platform (such as
-``<name>.exe`` or just ``<name>``).
-
-.. versionadded:: 3.1
-  Source arguments to ``add_executable`` may use "generator expressions" with
-  the syntax ``$<...>``.  See the :manual:`cmake-generator-expressions(7)`
-  manual for available expressions.
-
-.. versionadded:: 3.11
-  The source files can be omitted if they are added later using
-  :command:`target_sources`.
-
-By default the executable file will be created in the build tree
-directory corresponding to the source tree directory in which the
-command was invoked.  See documentation of the
-:prop_tgt:`RUNTIME_OUTPUT_DIRECTORY` target property to change this
-location.  See documentation of the :prop_tgt:`OUTPUT_NAME` target property
-to change the ``<name>`` part of the final file name.
-
-If ``WIN32`` is given the property :prop_tgt:`WIN32_EXECUTABLE` will be
-set on the target created.  See documentation of that target property for
-details.
-
-If ``MACOSX_BUNDLE`` is given the corresponding property will be set on
-the created target.  See documentation of the :prop_tgt:`MACOSX_BUNDLE`
-target property for details.
-
-If ``EXCLUDE_FROM_ALL`` is given the corresponding property will be set on
-the created target.  See documentation of the :prop_tgt:`EXCLUDE_FROM_ALL`
-target property for details.
-
-See the :manual:`cmake-buildsystem(7)` manual for more on defining
-buildsystem properties.
-
-See also :prop_sf:`HEADER_FILE_ONLY` on what to do if some sources are
-pre-processed, and you want to have the original sources reachable from
-within IDE.
-
-Imported Executables
-^^^^^^^^^^^^^^^^^^^^
-
-.. code-block:: cmake
-
-  add_executable(<name> IMPORTED [GLOBAL])
-
-An :ref:`IMPORTED executable target <Imported Targets>` references an
-executable file located outside the project.  No rules are generated to
-build it, and the :prop_tgt:`IMPORTED` target property is ``True``.  The
-target name has scope in the directory in which it is created and below, but
-the ``GLOBAL`` option extends visibility.  It may be referenced like any
-target built within the project.  ``IMPORTED`` executables are useful
-for convenient reference from commands like :command:`add_custom_command`.
-Details about the imported executable are specified by setting properties
-whose names begin in ``IMPORTED_``.  The most important such property is
-:prop_tgt:`IMPORTED_LOCATION` (and its per-configuration version
-:prop_tgt:`IMPORTED_LOCATION_<CONFIG>`) which specifies the location of
-the main executable file on disk.  See documentation of the ``IMPORTED_*``
-properties for more information.
-
-Alias Executables
-^^^^^^^^^^^^^^^^^
-
-.. code-block:: cmake
-
-  add_executable(<name> ALIAS <target>)
-
-Creates an :ref:`Alias Target <Alias Targets>`, such that ``<name>`` can
-be used to refer to ``<target>`` in subsequent commands.  The ``<name>``
-does not appear in the generated buildsystem as a make target.  The
-``<target>`` may not be an ``ALIAS``.
-
-.. versionadded:: 3.11
-  An ``ALIAS`` can target a ``GLOBAL`` :ref:`Imported Target <Imported Targets>`
-
-.. versionadded:: 3.18
-  An ``ALIAS`` can target a non-``GLOBAL`` Imported Target. Such alias is
-  scoped to the directory in which it is created and subdirectories.
-  The :prop_tgt:`ALIAS_GLOBAL` target property can be used to check if the
-  alias is global or not.
-
-``ALIAS`` targets can be used as targets to read properties
-from, executables for custom commands and custom targets.  They can also be
-tested for existence with the regular :command:`if(TARGET)` subcommand.
-The ``<name>`` may not be used to modify properties of ``<target>``, that
-is, it may not be used as the operand of :command:`set_property`,
-:command:`set_target_properties`, :command:`target_link_libraries` etc.
-An ``ALIAS`` target may not be installed or exported.
-
-See Also
-^^^^^^^^
-
-* :command:`add_library`

third-party/cmake-3.27.7-linux-x86_64/share/cmake-3.27/Help/command/add_library.rst

@@ -1,268 +0,0 @@
-add_library
------------
-
-.. only:: html
-
-   .. contents::
-
-Add a library to the project using the specified source files.
-
-Normal Libraries
-^^^^^^^^^^^^^^^^
-
-.. code-block:: cmake
-
-  add_library(<name> [STATIC | SHARED | MODULE]
-              [EXCLUDE_FROM_ALL]
-              [<source>...])
-
-Adds a library target called ``<name>`` to be built from the source files
-listed in the command invocation.  The ``<name>``
-corresponds to the logical target name and must be globally unique within
-a project.  The actual file name of the library built is constructed based
-on conventions of the native platform (such as ``lib<name>.a`` or
-``<name>.lib``).
-
-.. versionadded:: 3.1
-  Source arguments to ``add_library`` may use "generator expressions" with
-  the syntax ``$<...>``.  See the :manual:`cmake-generator-expressions(7)`
-  manual for available expressions.
-
-.. versionadded:: 3.11
-  The source files can be omitted if they are added later using
-  :command:`target_sources`.
-
-``STATIC``, ``SHARED``, or ``MODULE`` may be given to specify the type of
-library to be created.  ``STATIC`` libraries are archives of object files
-for use when linking other targets.  ``SHARED`` libraries are linked
-dynamically and loaded at runtime.  ``MODULE`` libraries are plugins that
-are not linked into other targets but may be loaded dynamically at runtime
-using dlopen-like functionality.  If no type is given explicitly the
-type is ``STATIC`` or ``SHARED`` based on whether the current value of the
-variable :variable:`BUILD_SHARED_LIBS` is ``ON``.  For ``SHARED`` and
-``MODULE`` libraries the :prop_tgt:`POSITION_INDEPENDENT_CODE` target
-property is set to ``ON`` automatically.
-A ``SHARED`` library may be marked with the :prop_tgt:`FRAMEWORK`
-target property to create an macOS Framework.
-
-.. versionadded:: 3.8
-  A ``STATIC`` library may be marked with the :prop_tgt:`FRAMEWORK`
-  target property to create a static Framework.
-
-If a library does not export any symbols, it must not be declared as a
-``SHARED`` library.  For example, a Windows resource DLL or a managed C++/CLI
-DLL that exports no unmanaged symbols would need to be a ``MODULE`` library.
-This is because CMake expects a ``SHARED`` library to always have an
-associated import library on Windows.
-
-By default the library file will be created in the build tree directory
-corresponding to the source tree directory in which the command was
-invoked.  See documentation of the :prop_tgt:`ARCHIVE_OUTPUT_DIRECTORY`,
-:prop_tgt:`LIBRARY_OUTPUT_DIRECTORY`, and
-:prop_tgt:`RUNTIME_OUTPUT_DIRECTORY` target properties to change this
-location.  See documentation of the :prop_tgt:`OUTPUT_NAME` target
-property to change the ``<name>`` part of the final file name.
-
-If ``EXCLUDE_FROM_ALL`` is given the corresponding property will be set on
-the created target.  See documentation of the :prop_tgt:`EXCLUDE_FROM_ALL`
-target property for details.
-
-See the :manual:`cmake-buildsystem(7)` manual for more on defining
-buildsystem properties.
-
-See also :prop_sf:`HEADER_FILE_ONLY` on what to do if some sources are
-pre-processed, and you want to have the original sources reachable from
-within IDE.
-
-Object Libraries
-^^^^^^^^^^^^^^^^
-
-.. code-block:: cmake
-
-  add_library(<name> OBJECT [<source>...])
-
-Creates an :ref:`Object Library <Object Libraries>`.  An object library
-compiles source files but does not archive or link their object files into a
-library.  Instead other targets created by ``add_library`` or
-:command:`add_executable` may reference the objects using an expression of the
-form :genex:`$\<TARGET_OBJECTS:objlib\> <TARGET_OBJECTS>` as a source, where
-``objlib`` is the object library name.  For example:
-
-.. code-block:: cmake
-
-  add_library(... $<TARGET_OBJECTS:objlib> ...)
-  add_executable(... $<TARGET_OBJECTS:objlib> ...)
-
-will include objlib's object files in a library and an executable
-along with those compiled from their own sources.  Object libraries
-may contain only sources that compile, header files, and other files
-that would not affect linking of a normal library (e.g. ``.txt``).
-They may contain custom commands generating such sources, but not
-``PRE_BUILD``, ``PRE_LINK``, or ``POST_BUILD`` commands.  Some native build
-systems (such as Xcode) may not like targets that have only object files, so
-consider adding at least one real source file to any target that references
-:genex:`$\<TARGET_OBJECTS:objlib\> <TARGET_OBJECTS>`.
-
-.. versionadded:: 3.12
-  Object libraries can be linked to with :command:`target_link_libraries`.
-
-Interface Libraries
-^^^^^^^^^^^^^^^^^^^
-
-.. code-block:: cmake
-
-  add_library(<name> INTERFACE)
-
-Creates an :ref:`Interface Library <Interface Libraries>`.
-An ``INTERFACE`` library target does not compile sources and does
-not produce a library artifact on disk.  However, it may have
-properties set on it and it may be installed and exported.
-Typically, ``INTERFACE_*`` properties are populated on an interface
-target using the commands:
-
-* :command:`set_property`,
-* :command:`target_link_libraries(INTERFACE)`,
-* :command:`target_link_options(INTERFACE)`,
-* :command:`target_include_directories(INTERFACE)`,
-* :command:`target_compile_options(INTERFACE)`,
-* :command:`target_compile_definitions(INTERFACE)`, and
-* :command:`target_sources(INTERFACE)`,
-
-and then it is used as an argument to :command:`target_link_libraries`
-like any other target.
-
-An interface library created with the above signature has no source files
-itself and is not included as a target in the generated buildsystem.
-
-.. versionadded:: 3.15
-  An interface library can have :prop_tgt:`PUBLIC_HEADER` and
-  :prop_tgt:`PRIVATE_HEADER` properties.  The headers specified by those
-  properties can be installed using the :command:`install(TARGETS)` command.
-
-.. versionadded:: 3.19
-  An interface library target may be created with source files:
-
-  .. code-block:: cmake
-
-    add_library(<name> INTERFACE [<source>...] [EXCLUDE_FROM_ALL])
-
-  Source files may be listed directly in the ``add_library`` call or added
-  later by calls to :command:`target_sources` with the ``PRIVATE`` or
-  ``PUBLIC`` keywords.
-
-  If an interface library has source files (i.e. the :prop_tgt:`SOURCES`
-  target property is set), or header sets (i.e. the :prop_tgt:`HEADER_SETS`
-  target property is set), it will appear in the generated buildsystem
-  as a build target much like a target defined by the
-  :command:`add_custom_target` command.  It does not compile any sources,
-  but does contain build rules for custom commands created by the
-  :command:`add_custom_command` command.
-
-.. note::
-  In most command signatures where the ``INTERFACE`` keyword appears,
-  the items listed after it only become part of that target's usage
-  requirements and are not part of the target's own settings.  However,
-  in this signature of ``add_library``, the ``INTERFACE`` keyword refers
-  to the library type only.  Sources listed after it in the ``add_library``
-  call are ``PRIVATE`` to the interface library and do not appear in its
-  :prop_tgt:`INTERFACE_SOURCES` target property.
-
-.. _`add_library imported libraries`:
-
-Imported Libraries
-^^^^^^^^^^^^^^^^^^
-
-.. code-block:: cmake
-
-  add_library(<name> <type> IMPORTED [GLOBAL])
-
-Creates an :ref:`IMPORTED library target <Imported Targets>` called ``<name>``.
-No rules are generated to build it, and the :prop_tgt:`IMPORTED` target
-property is ``True``.  The target name has scope in the directory in which
-it is created and below, but the ``GLOBAL`` option extends visibility.
-It may be referenced like any target built within the project.
-``IMPORTED`` libraries are useful for convenient reference from commands
-like :command:`target_link_libraries`.  Details about the imported library
-are specified by setting properties whose names begin in ``IMPORTED_`` and
-``INTERFACE_``.
-
-The ``<type>`` must be one of:
-
-``STATIC``, ``SHARED``, ``MODULE``, ``UNKNOWN``
-  References a library file located outside the project.  The
-  :prop_tgt:`IMPORTED_LOCATION` target property (or its per-configuration
-  variant :prop_tgt:`IMPORTED_LOCATION_<CONFIG>`) specifies the
-  location of the main library file on disk:
-
-  * For a ``SHARED`` library on most non-Windows platforms, the main library
-    file is the ``.so`` or ``.dylib`` file used by both linkers and dynamic
-    loaders.  If the referenced library file has a ``SONAME`` (or on macOS,
-    has a ``LC_ID_DYLIB`` starting in ``@rpath/``), the value of that field
-    should be set in the :prop_tgt:`IMPORTED_SONAME` target property.
-    If the referenced library file does not have a ``SONAME``, but the
-    platform supports it, then  the :prop_tgt:`IMPORTED_NO_SONAME` target
-    property should be set.
-
-  * For a ``SHARED`` library on Windows, the :prop_tgt:`IMPORTED_IMPLIB`
-    target property (or its per-configuration variant
-    :prop_tgt:`IMPORTED_IMPLIB_<CONFIG>`) specifies the location of the
-    DLL import library file (``.lib`` or ``.dll.a``) on disk, and the
-    ``IMPORTED_LOCATION`` is the location of the ``.dll`` runtime
-    library (and is optional, but needed by the :genex:`TARGET_RUNTIME_DLLS`
-    generator expression).
-
-  Additional usage requirements may be specified in ``INTERFACE_*`` properties.
-
-  An ``UNKNOWN`` library type is typically only used in the implementation of
-  :ref:`Find Modules`.  It allows the path to an imported library (often found
-  using the :command:`find_library` command) to be used without having to know
-  what type of library it is.  This is especially useful on Windows where a
-  static library and a DLL's import library both have the same file extension.
-
-``OBJECT``
-  References a set of object files located outside the project.
-  The :prop_tgt:`IMPORTED_OBJECTS` target property (or its per-configuration
-  variant :prop_tgt:`IMPORTED_OBJECTS_<CONFIG>`) specifies the locations of
-  object files on disk.
-  Additional usage requirements may be specified in ``INTERFACE_*`` properties.
-
-``INTERFACE``
-  Does not reference any library or object files on disk, but may
-  specify usage requirements in ``INTERFACE_*`` properties.
-
-See documentation of the ``IMPORTED_*`` and ``INTERFACE_*`` properties
-for more information.
-
-Alias Libraries
-^^^^^^^^^^^^^^^
-
-.. code-block:: cmake
-
-  add_library(<name> ALIAS <target>)
-
-Creates an :ref:`Alias Target <Alias Targets>`, such that ``<name>`` can be
-used to refer to ``<target>`` in subsequent commands.  The ``<name>`` does
-not appear in the generated buildsystem as a make target.  The ``<target>``
-may not be an ``ALIAS``.
-
-.. versionadded:: 3.11
-  An ``ALIAS`` can target a ``GLOBAL`` :ref:`Imported Target <Imported Targets>`
-
-.. versionadded:: 3.18
-  An ``ALIAS`` can target a non-``GLOBAL`` Imported Target. Such alias is
-  scoped to the directory in which it is created and below.
-  The :prop_tgt:`ALIAS_GLOBAL` target property can be used to check if the
-  alias is global or not.
-
-``ALIAS`` targets can be used as linkable targets and as targets to
-read properties from.  They can also be tested for existence with the
-regular :command:`if(TARGET)` subcommand.  The ``<name>`` may not be used
-to modify properties of ``<target>``, that is, it may not be used as the
-operand of :command:`set_property`, :command:`set_target_properties`,
-:command:`target_link_libraries` etc.  An ``ALIAS`` target may not be
-installed or exported.
-
-See Also
-^^^^^^^^
-
-* :command:`add_executable`

third-party/cmake-3.27.7-linux-x86_64/share/cmake-3.27/Help/command/add_link_options.rst

@@ -1,44 +0,0 @@
-add_link_options
-----------------
-
-.. versionadded:: 3.13
-
-Add options to the link step for executable, shared library or module
-library targets in the current directory and below that are added after
-this command is invoked.
-
-.. code-block:: cmake
-
-  add_link_options(<option> ...)
-
-This command can be used to add any link options, but alternative commands
-exist to add libraries (:command:`target_link_libraries` or
-:command:`link_libraries`).  See documentation of the
-:prop_dir:`directory <LINK_OPTIONS>` and
-:prop_tgt:`target <LINK_OPTIONS>` ``LINK_OPTIONS`` properties.
-
-.. note::
-
-  This command cannot be used to add options for static library targets,
-  since they do not use a linker.  To add archiver or MSVC librarian flags,
-  see the :prop_tgt:`STATIC_LIBRARY_OPTIONS` target property.
-
-.. |command_name| replace:: ``add_link_options``
-.. include:: GENEX_NOTE.txt
-
-.. include:: DEVICE_LINK_OPTIONS.txt
-
-.. include:: OPTIONS_SHELL.txt
-
-.. include:: LINK_OPTIONS_LINKER.txt
-
-See Also
-^^^^^^^^
-
-* :command:`link_libraries`
-* :command:`target_link_libraries`
-* :command:`target_link_options`
-
-* :variable:`CMAKE_<LANG>_FLAGS` and :variable:`CMAKE_<LANG>_FLAGS_<CONFIG>`
-  add language-wide flags passed to all invocations of the compiler.
-  This includes invocations that drive compiling and those that drive linking.

third-party/cmake-3.27.7-linux-x86_64/share/cmake-3.27/Help/command/add_subdirectory.rst

@@ -1,41 +0,0 @@
-add_subdirectory
-----------------
-
-Add a subdirectory to the build.
-
-.. code-block:: cmake
-
-  add_subdirectory(source_dir [binary_dir] [EXCLUDE_FROM_ALL] [SYSTEM])
-
-Adds a subdirectory to the build.  The ``source_dir`` specifies the
-directory in which the source ``CMakeLists.txt`` and code files are
-located.  If it is a relative path, it will be evaluated with respect
-to the current directory (the typical usage), but it may also be an
-absolute path.  The ``binary_dir`` specifies the directory in which to
-place the output files.  If it is a relative path, it will be evaluated
-with respect to the current output directory, but it may also be an
-absolute path.  If ``binary_dir`` is not specified, the value of
-``source_dir``, before expanding any relative path, will be used (the
-typical usage).  The ``CMakeLists.txt`` file in the specified source
-directory will be processed immediately by CMake before processing in
-the current input file continues beyond this command.
-
-If the ``EXCLUDE_FROM_ALL`` argument is provided then targets in the
-subdirectory will not be included in the ``ALL`` target of the parent
-directory by default, and will be excluded from IDE project files.
-Users must explicitly build targets in the subdirectory.  This is
-meant for use when the subdirectory contains a separate part of the
-project that is useful but not necessary, such as a set of examples.
-Typically the subdirectory should contain its own :command:`project`
-command invocation so that a full build system will be generated in the
-subdirectory (such as a Visual Studio IDE solution file).  Note that
-inter-target dependencies supersede this exclusion.  If a target built by
-the parent project depends on a target in the subdirectory, the dependee
-target will be included in the parent project build system to satisfy
-the dependency.
-
-.. versionadded:: 3.25
-  If the ``SYSTEM`` argument is provided, the :prop_dir:`SYSTEM` directory
-  property of the subdirectory will be set to true.  This property is
-  used to initialize the :prop_tgt:`SYSTEM` property of each non-imported
-  target created in that subdirectory.

third-party/cmake-3.27.7-linux-x86_64/share/cmake-3.27/Help/command/add_test.rst

@@ -1,89 +0,0 @@
-add_test
---------
-
-Add a test to the project to be run by :manual:`ctest(1)`.
-
-.. code-block:: cmake
-
-  add_test(NAME <name> COMMAND <command> [<arg>...]
-           [CONFIGURATIONS <config>...]
-           [WORKING_DIRECTORY <dir>]
-           [COMMAND_EXPAND_LISTS])
-
-Adds a test called ``<name>``.  The test name may contain arbitrary
-characters, expressed as a :ref:`Quoted Argument` or :ref:`Bracket Argument`
-if necessary.  See policy :policy:`CMP0110`.
-
-CMake only generates tests if the :command:`enable_testing` command has been
-invoked.  The :module:`CTest` module invokes ``enable_testing`` automatically
-unless ``BUILD_TESTING`` is set to ``OFF``.
-
-Tests added with the ``add_test(NAME)`` signature support using
-:manual:`generator expressions <cmake-generator-expressions(7)>`
-in test properties set by :command:`set_property(TEST)` or
-:command:`set_tests_properties`. Test properties may only be set in the
-directory the test is created in.
-
-``add_test`` options are:
-
-``COMMAND``
-  Specify the test command-line.  If ``<command>`` specifies an executable
-  target created by :command:`add_executable`, it will automatically be
-  replaced by the location of the executable created at build time.
-
-  The command may be specified using
-  :manual:`generator expressions <cmake-generator-expressions(7)>`.
-
-``CONFIGURATIONS``
-  Restrict execution of the test only to the named configurations.
-
-``WORKING_DIRECTORY``
-  Set the test property :prop_test:`WORKING_DIRECTORY` in which to execute the
-  test. If not specified, the test will be run in
-  :variable:`CMAKE_CURRENT_BINARY_DIR`. The working directory may be specified
-  using :manual:`generator expressions <cmake-generator-expressions(7)>`.
-
-``COMMAND_EXPAND_LISTS``
-  .. versionadded:: 3.16
-
-  Lists in ``COMMAND`` arguments will be expanded, including those created with
-  :manual:`generator expressions <cmake-generator-expressions(7)>`.
-
-If the test command exits with code ``0`` the test passes. Non-zero exit code
-is a "failed" test. The test property :prop_test:`WILL_FAIL` inverts this
-logic. Note that system-level test failures such as segmentation faults or
-heap errors will still fail the test even if ``WILL_FALL`` is true. Output
-written to stdout or stderr is captured by :manual:`ctest(1)` and only
-affects the pass/fail status via the :prop_test:`PASS_REGULAR_EXPRESSION`,
-:prop_test:`FAIL_REGULAR_EXPRESSION`, or :prop_test:`SKIP_REGULAR_EXPRESSION`
-test properties.
-
-.. versionadded:: 3.16
-  Added :prop_test:`SKIP_REGULAR_EXPRESSION` property.
-
-Example usage:
-
-.. code-block:: cmake
-
-  add_test(NAME mytest
-           COMMAND testDriver --config $<CONFIG>
-                              --exe $<TARGET_FILE:myexe>)
-
-This creates a test ``mytest`` whose command runs a ``testDriver`` tool
-passing the configuration name and the full path to the executable
-file produced by target ``myexe``.
-
----------------------------------------------------------------------
-
-The command syntax above is recommended over the older, less flexible form:
-
-.. code-block:: cmake
-
-  add_test(<name> <command> [<arg>...])
-
-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.

third-party/cmake-3.27.7-linux-x86_64/share/cmake-3.27/Help/command/aux_source_directory.rst

@@ -1,24 +0,0 @@
-aux_source_directory
---------------------
-
-Find all source files in a directory.
-
-.. code-block:: cmake
-
-  aux_source_directory(<dir> <variable>)
-
-Collects the names of all the source files in the specified directory
-and stores the list in the ``<variable>`` provided.  This command is
-intended to be used by projects that use explicit template
-instantiation.  Template instantiation files can be stored in a
-``Templates`` subdirectory and collected automatically using this
-command to avoid manually listing all instantiations.
-
-It is tempting to use this command to avoid writing the list of source
-files for a library or executable target.  While this seems to work,
-there is no way for CMake to generate a build system that knows when a
-new source file has been added.  Normally the generated build system
-knows when it needs to rerun CMake because the ``CMakeLists.txt`` file is
-modified to add a new source.  When the source is just added to the
-directory without modifying this file, one would have to manually
-rerun CMake to generate a build system incorporating the new file.

third-party/cmake-3.27.7-linux-x86_64/share/cmake-3.27/Help/command/block.rst

@@ -1,76 +0,0 @@
-block
------
-
-.. versionadded:: 3.25
-
-Evaluate a group of commands with a dedicated variable and/or policy scope.
-
-.. code-block:: cmake
-
-  block([SCOPE_FOR [POLICIES] [VARIABLES] ] [PROPAGATE <var-name>...])
-    <commands>
-  endblock()
-
-All commands between ``block()`` and the matching :command:`endblock` are
-recorded without being invoked.  Once the :command:`endblock` is evaluated, the
-recorded list of commands is invoked inside the requested scopes, then the
-scopes created by the ``block()`` command are removed.
-
-``SCOPE_FOR``
-  Specify which scopes must be created.
-
-  ``POLICIES``
-    Create a new policy scope. This is equivalent to
-    :command:`cmake_policy(PUSH)`.
-
-  ``VARIABLES``
-    Create a new variable scope.
-
-  If ``SCOPE_FOR`` is not specified, this is equivalent to:
-
-  .. code-block:: cmake
-
-    block(SCOPE_FOR VARIABLES POLICIES)
-
-``PROPAGATE``
-  When a variable scope is created by the :command:`block` command, this
-  option sets or unsets the specified variables in the parent scope. This is
-  equivalent to :command:`set(PARENT_SCOPE)` or :command:`unset(PARENT_SCOPE)`
-  commands.
-
-  .. code-block:: cmake
-
-    set(var1 "INIT1")
-    set(var2 "INIT2")
-
-    block(PROPAGATE var1 var2)
-      set(var1 "VALUE1")
-      unset(var2)
-    endblock()
-
-    # Now var1 holds VALUE1, and var2 is unset
-
-  This option is only allowed when a variable scope is created. An error will
-  be raised in the other cases.
-
-When the ``block()`` is inside a :command:`foreach` or :command:`while`
-command, the :command:`break` and :command:`continue` commands can be used
-inside the block.
-
-.. code-block:: cmake
-
-  while(TRUE)
-    block()
-       ...
-       # the break() command will terminate the while() command
-       break()
-    endblock()
-  endwhile()
-
-
-See Also
-^^^^^^^^
-
-* :command:`endblock`
-* :command:`return`
-* :command:`cmake_policy`

third-party/cmake-3.27.7-linux-x86_64/share/cmake-3.27/Help/command/break.rst

@@ -1,12 +0,0 @@
-break
------
-
-Break from an enclosing foreach or while loop.
-
-.. code-block:: cmake
-
-  break()
-
-Breaks from an enclosing :command:`foreach` or :command:`while` loop.
-
-See also the :command:`continue` command.

third-party/cmake-3.27.7-linux-x86_64/share/cmake-3.27/Help/command/build_command.rst

@@ -1,51 +0,0 @@
-build_command
--------------
-
-Get a command line to build the current project.
-This is mainly intended for internal use by the :module:`CTest` module.
-
-.. code-block:: cmake
-
-  build_command(<variable>
-                [CONFIGURATION <config>]
-                [PARALLEL_LEVEL <parallel>]
-                [TARGET <target>]
-                [PROJECT_NAME <projname>] # legacy, causes warning
-               )
-
-Sets the given ``<variable>`` to a command-line string of the form::
-
- <cmake> --build . [--config <config>] [--parallel <parallel>] [--target <target>...] [-- -i]
-
-where ``<cmake>`` is the location of the :manual:`cmake(1)` command-line
-tool, and ``<config>``, ``<parallel>`` and ``<target>`` are the values
-provided to the ``CONFIGURATION``, ``PARALLEL_LEVEL`` and ``TARGET``
-options, if any.  The trailing ``-- -i`` option is added for
-:ref:`Makefile Generators` if policy :policy:`CMP0061` is not set to
-``NEW``.
-
-When invoked, this :option:`cmake --build` command line will launch the
-underlying build system tool.
-
-.. versionadded:: 3.21
-  The ``PARALLEL_LEVEL`` argument can be used to set the
-  :option:`--parallel <cmake--build --parallel>` flag.
-
-.. code-block:: cmake
-
-  build_command(<cachevariable> <makecommand>)
-
-This second signature is deprecated, but still available for backwards
-compatibility.  Use the first signature instead.
-
-It sets the given ``<cachevariable>`` to a command-line string as
-above but without the :option:`--target <cmake--build --target>` option.
-The ``<makecommand>`` is ignored but should be the full path to
-devenv, nmake, make or one of the end user build tools
-for legacy invocations.
-
-.. note::
- In CMake versions prior to 3.0 this command returned a command
- line that directly invokes the native build tool for the current
- generator.  Their implementation of the ``PROJECT_NAME`` option
- had no useful effects, so CMake now warns on use of the option.

third-party/cmake-3.27.7-linux-x86_64/share/cmake-3.27/Help/command/build_name.rst

@@ -1,15 +0,0 @@
-build_name
-----------
-
-Disallowed since version 3.0.  See CMake Policy :policy:`CMP0036`.
-
-Use ``${CMAKE_SYSTEM}`` and ``${CMAKE_CXX_COMPILER}`` instead.
-
-.. code-block:: cmake
-
-  build_name(variable)
-
-Sets the specified variable to a string representing the platform and
-compiler settings.  These values are now available through the
-:variable:`CMAKE_SYSTEM` and
-:variable:`CMAKE_CXX_COMPILER <CMAKE_<LANG>_COMPILER>` variables.

third-party/cmake-3.27.7-linux-x86_64/share/cmake-3.27/Help/command/cmake_file_api.rst

@@ -1,78 +0,0 @@
-cmake_file_api
---------------
-
-.. versionadded:: 3.27
-
-Enables interacting with the :manual:`CMake file API <cmake-file-api(7)>`.
-
-.. signature::
-  cmake_file_api(QUERY ...)
-
-  The ``QUERY`` subcommand adds a file API query for the current CMake
-  invocation.
-
-  .. code-block:: cmake
-
-    cmake_file_api(
-      QUERY
-      API_VERSION <version>
-      [CODEMODEL <versions>...]
-      [CACHE <versions>...]
-      [CMAKEFILES <versions>...]
-      [TOOLCHAINS <versions>...]
-    )
-
-  The ``API_VERSION`` must always be given.  Currently, the only supported
-  value for ``<version>`` is 1.  See :ref:`file-api v1` for details of the
-  reply content and location.
-
-  Each of the optional keywords ``CODEMODEL``, ``CACHE``, ``CMAKEFILES`` and
-  ``TOOLCHAINS`` correspond to one of the object kinds that can be requested
-  by the project.  The ``configureLog`` object kind cannot be set with this
-  command, since it must be set before CMake starts reading the top level
-  ``CMakeLists.txt`` file.
-
-  For each of the optional keywords, the ``<versions>`` list must contain one
-  or more version values of the form ``major`` or ``major.minor``, where
-  ``major`` and ``minor`` are integers.  Projects should list the versions they
-  accept in their preferred order, as only the first supported value from the
-  list will be selected.  The command will ignore versions with a ``major``
-  version higher than any major version it supports for that object kind.
-  It will raise an error if it encounters an invalid version number, or if none
-  of the requested versions is supported.
-
-  For each type of object kind requested, a query equivalent to a shared,
-  stateless query will be added internally.  No query file will be created in
-  the file system.  The reply *will* be written to the file system at
-  generation time.
-
-  It is not an error to add a query for the same thing more than once, whether
-  from query files or from multiple calls to ``cmake_file_api(QUERY)``.
-  The final set of queries will be a merged combination of all queries
-  specified on disk and queries submitted by the project.
-
-Example
-^^^^^^^
-
-A project may want to use replies from the file API at build time to implement
-some form of verification task.  Instead of relying on something outside of
-CMake to create a query file, the project can use ``cmake_file_api(QUERY)``
-to request the required information for the current run.  It can then create
-a custom command to run at build time, knowing that the requested information
-should always be available.
-
-.. code-block:: cmake
-
-  cmake_file_api(
-    QUERY
-    API_VERSION 1
-    CODEMODEL 2.3
-    TOOLCHAINS 1
-  )
-
-  add_custom_target(verify_project
-    COMMAND ${CMAKE_COMMAND}
-      -D BUILD_DIR=${CMAKE_BINARY_DIR}
-      -D CONFIG=$<CONFIG>
-      -P ${CMAKE_CURRENT_SOURCE_DIR}/verify_project.cmake
-  )

third-party/cmake-3.27.7-linux-x86_64/share/cmake-3.27/Help/command/cmake_host_system_information.rst

@@ -1,396 +0,0 @@
-cmake_host_system_information
------------------------------
-
-Query various host system information.
-
-Synopsis
-^^^^^^^^
-
-.. parsed-literal::
-
-  `Query host system specific information`_
-    cmake_host_system_information(RESULT <variable> QUERY <key> ...)
-
-  `Query Windows registry`_
-    cmake_host_system_information(RESULT <variable> QUERY WINDOWS_REGISTRY <key> ...)
-
-Query host system specific information
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-.. code-block:: cmake
-
-  cmake_host_system_information(RESULT <variable> QUERY <key> ...)
-
-Queries system information of the host system on which cmake runs.
-One or more ``<key>`` can be provided to select the information to be
-queried.  The list of queried values is stored in ``<variable>``.
-
-``<key>`` can be one of the following values:
-
-``NUMBER_OF_LOGICAL_CORES``
-  Number of logical cores
-
-``NUMBER_OF_PHYSICAL_CORES``
-  Number of physical cores
-
-``HOSTNAME``
-  Hostname
-
-``FQDN``
-  Fully qualified domain name
-
-``TOTAL_VIRTUAL_MEMORY``
-  Total virtual memory in MiB [#mebibytes]_
-
-``AVAILABLE_VIRTUAL_MEMORY``
-  Available virtual memory in MiB [#mebibytes]_
-
-``TOTAL_PHYSICAL_MEMORY``
-  Total physical memory in MiB [#mebibytes]_
-
-``AVAILABLE_PHYSICAL_MEMORY``
-  Available physical memory in MiB [#mebibytes]_
-
-``IS_64BIT``
-  .. versionadded:: 3.10
-
-  One if processor is 64Bit
-
-``HAS_FPU``
-  .. versionadded:: 3.10
-
-  One if processor has floating point unit
-
-``HAS_MMX``
-  .. versionadded:: 3.10
-
-  One if processor supports MMX instructions
-
-``HAS_MMX_PLUS``
-  .. versionadded:: 3.10
-
-  One if processor supports Ext. MMX instructions
-
-``HAS_SSE``
-  .. versionadded:: 3.10
-
-  One if processor supports SSE instructions
-
-``HAS_SSE2``
-  .. versionadded:: 3.10
-
-  One if processor supports SSE2 instructions
-
-``HAS_SSE_FP``
-  .. versionadded:: 3.10
-
-  One if processor supports SSE FP instructions
-
-``HAS_SSE_MMX``
-  .. versionadded:: 3.10
-
-  One if processor supports SSE MMX instructions
-
-``HAS_AMD_3DNOW``
-  .. versionadded:: 3.10
-
-  One if processor supports 3DNow instructions
-
-``HAS_AMD_3DNOW_PLUS``
-  .. versionadded:: 3.10
-
-  One if processor supports 3DNow+ instructions
-
-``HAS_IA64``
-  .. versionadded:: 3.10
-
-  One if IA64 processor emulating x86
-
-``HAS_SERIAL_NUMBER``
-  .. versionadded:: 3.10
-
-  One if processor has serial number
-
-``PROCESSOR_SERIAL_NUMBER``
-  .. versionadded:: 3.10
-
-  Processor serial number
-
-``PROCESSOR_NAME``
-  .. versionadded:: 3.10
-
-  Human readable processor name
-
-``PROCESSOR_DESCRIPTION``
-  .. versionadded:: 3.10
-
-  Human readable full processor description
-
-``OS_NAME``
-  .. versionadded:: 3.10
-
-  See :variable:`CMAKE_HOST_SYSTEM_NAME`
-
-``OS_RELEASE``
-  .. versionadded:: 3.10
-
-  The OS sub-type e.g. on Windows ``Professional``
-
-``OS_VERSION``
-  .. versionadded:: 3.10
-
-  The OS build ID
-
-``OS_PLATFORM``
-  .. versionadded:: 3.10
-
-  See :variable:`CMAKE_HOST_SYSTEM_PROCESSOR`
-
-``DISTRIB_INFO``
-  .. versionadded:: 3.22
-
-  Read :file:`/etc/os-release` file and define the given ``<variable>``
-  into a list of read variables
-
-``DISTRIB_<name>``
-  .. versionadded:: 3.22
-
-  Get the ``<name>`` variable (see `man 5 os-release`_) if it exists in the
-  :file:`/etc/os-release` file
-
-  Example:
-
-  .. code-block:: cmake
-
-      cmake_host_system_information(RESULT PRETTY_NAME QUERY DISTRIB_PRETTY_NAME)
-      message(STATUS "${PRETTY_NAME}")
-
-      cmake_host_system_information(RESULT DISTRO QUERY DISTRIB_INFO)
-
-      foreach(VAR IN LISTS DISTRO)
-        message(STATUS "${VAR}=`${${VAR}}`")
-      endforeach()
-
-
-  Output::
-
-    -- Ubuntu 20.04.2 LTS
-    -- DISTRO_BUG_REPORT_URL=`https://bugs.launchpad.net/ubuntu/`
-    -- DISTRO_HOME_URL=`https://www.ubuntu.com/`
-    -- DISTRO_ID=`ubuntu`
-    -- DISTRO_ID_LIKE=`debian`
-    -- DISTRO_NAME=`Ubuntu`
-    -- DISTRO_PRETTY_NAME=`Ubuntu 20.04.2 LTS`
-    -- DISTRO_PRIVACY_POLICY_URL=`https://www.ubuntu.com/legal/terms-and-policies/privacy-policy`
-    -- DISTRO_SUPPORT_URL=`https://help.ubuntu.com/`
-    -- DISTRO_UBUNTU_CODENAME=`focal`
-    -- DISTRO_VERSION=`20.04.2 LTS (Focal Fossa)`
-    -- DISTRO_VERSION_CODENAME=`focal`
-    -- DISTRO_VERSION_ID=`20.04`
-
-If :file:`/etc/os-release` file is not found, the command tries to gather OS
-identification via fallback scripts.  The fallback script can use `various
-distribution-specific files`_ to collect OS identification data and map it
-into `man 5 os-release`_ variables.
-
-Fallback Interface Variables
-""""""""""""""""""""""""""""
-
-.. variable:: CMAKE_GET_OS_RELEASE_FALLBACK_SCRIPTS
-
-  In addition to the scripts shipped with CMake, a user may append full
-  paths to his script(s) to the this list.  The script filename has the
-  following format: ``NNN-<name>.cmake``, where ``NNN`` is three digits
-  used to apply collected scripts in a specific order.
-
-.. variable:: CMAKE_GET_OS_RELEASE_FALLBACK_RESULT_<varname>
-
-  Variables collected by the user provided fallback script
-  ought to be assigned to CMake variables using this naming
-  convention.  Example, the ``ID`` variable from the manual becomes
-  ``CMAKE_GET_OS_RELEASE_FALLBACK_RESULT_ID``.
-
-.. variable:: CMAKE_GET_OS_RELEASE_FALLBACK_RESULT
-
-  The fallback script ought to store names of all assigned
-  ``CMAKE_GET_OS_RELEASE_FALLBACK_RESULT_<varname>`` variables in this list.
-
-Example:
-
-.. code-block:: cmake
-
-  # Try to detect some old distribution
-  # See also
-  # - http://linuxmafia.com/faq/Admin/release-files.html
-  #
-  if(NOT EXISTS "${CMAKE_SYSROOT}/etc/foobar-release")
-    return()
-  endif()
-  # Get the first string only
-  file(
-      STRINGS "${CMAKE_SYSROOT}/etc/foobar-release" CMAKE_GET_OS_RELEASE_FALLBACK_CONTENT
-      LIMIT_COUNT 1
-    )
-  #
-  # Example:
-  #
-  #   Foobar distribution release 1.2.3 (server)
-  #
-  if(CMAKE_GET_OS_RELEASE_FALLBACK_CONTENT MATCHES "Foobar distribution release ([0-9\.]+) .*")
-    set(CMAKE_GET_OS_RELEASE_FALLBACK_RESULT_NAME Foobar)
-    set(CMAKE_GET_OS_RELEASE_FALLBACK_RESULT_PRETTY_NAME "${CMAKE_GET_OS_RELEASE_FALLBACK_CONTENT}")
-    set(CMAKE_GET_OS_RELEASE_FALLBACK_RESULT_ID foobar)
-    set(CMAKE_GET_OS_RELEASE_FALLBACK_RESULT_VERSION ${CMAKE_MATCH_1})
-    set(CMAKE_GET_OS_RELEASE_FALLBACK_RESULT_VERSION_ID ${CMAKE_MATCH_1})
-    list(
-        APPEND CMAKE_GET_OS_RELEASE_FALLBACK_RESULT
-        CMAKE_GET_OS_RELEASE_FALLBACK_RESULT_NAME
-        CMAKE_GET_OS_RELEASE_FALLBACK_RESULT_PRETTY_NAME
-        CMAKE_GET_OS_RELEASE_FALLBACK_RESULT_ID
-        CMAKE_GET_OS_RELEASE_FALLBACK_RESULT_VERSION
-        CMAKE_GET_OS_RELEASE_FALLBACK_RESULT_VERSION_ID
-      )
-  endif()
-  unset(CMAKE_GET_OS_RELEASE_FALLBACK_CONTENT)
-
-
-.. rubric:: Footnotes
-
-.. [#mebibytes] One MiB (mebibyte) is equal to 1024x1024 bytes.
-
-.. _man 5 os-release: https://www.freedesktop.org/software/systemd/man/os-release.html
-.. _various distribution-specific files: http://linuxmafia.com/faq/Admin/release-files.html
-
-.. _Query Windows registry:
-
-Query Windows registry
-^^^^^^^^^^^^^^^^^^^^^^
-
-.. versionadded:: 3.24
-
-::
-
-  cmake_host_system_information(RESULT <variable>
-                                QUERY WINDOWS_REGISTRY <key> [VALUE_NAMES|SUBKEYS|VALUE <name>]
-                                [VIEW (64|32|64_32|32_64|HOST|TARGET|BOTH)]
-                                [SEPARATOR <separator>]
-                                [ERROR_VARIABLE <result>])
-
-Performs query operations on local computer registry subkey. Returns a list of
-subkeys or value names that are located under the specified subkey in the
-registry or the data of the specified value name. The result of the queried
-entity is stored in ``<variable>``.
-
-.. note::
-
-  Querying registry for any other platforms than ``Windows``, including
-  ``CYGWIN``, will always returns an empty string and sets an error message in
-  the variable specified with sub-option ``ERROR_VARIABLE``.
-
-``<key>`` specify the full path of a subkey on the local computer. The
-``<key>`` must include a valid root key. Valid root keys for the local computer
-are:
-
-* ``HKLM`` or ``HKEY_LOCAL_MACHINE``
-* ``HKCU`` or ``HKEY_CURRENT_USER``
-* ``HKCR`` or ``HKEY_CLASSES_ROOT``
-* ``HKU`` or ``HKEY_USERS``
-* ``HKCC`` or ``HKEY_CURRENT_CONFIG``
-
-And, optionally, the path to a subkey under the specified root key. The path
-separator can be the slash or the backslash. ``<key>`` is not case sensitive.
-For example:
-
-.. code-block:: cmake
-
-  cmake_host_system_information(RESULT result QUERY WINDOWS_REGISTRY "HKLM")
-  cmake_host_system_information(RESULT result QUERY WINDOWS_REGISTRY "HKLM/SOFTWARE/Kitware")
-  cmake_host_system_information(RESULT result QUERY WINDOWS_REGISTRY "HKCU\\SOFTWARE\\Kitware")
-
-``VALUE_NAMES``
-  Request the list of value names defined under ``<key>``. If a default value
-  is defined, it will be identified with the special name ``(default)``.
-
-``SUBKEYS``
-  Request the list of subkeys defined under ``<key>``.
-
-``VALUE <name>``
-  Request the data stored in value named ``<name>``. If ``VALUE`` is not
-  specified or argument is the special name ``(default)``, the content of the
-  default value, if any, will be returned.
-
-  .. code-block:: cmake
-
-     # query default value for HKLM/SOFTWARE/Kitware key
-     cmake_host_system_information(RESULT result
-                                   QUERY WINDOWS_REGISTRY "HKLM/SOFTWARE/Kitware")
-
-     # query default value for HKLM/SOFTWARE/Kitware key using special value name
-     cmake_host_system_information(RESULT result
-                                   QUERY WINDOWS_REGISTRY "HKLM/SOFTWARE/Kitware"
-                                   VALUE "(default)")
-
-  Supported types are:
-
-  * ``REG_SZ``.
-  * ``REG_EXPAND_SZ``. The returned data is expanded.
-  * ``REG_MULTI_SZ``. The returned is expressed as a CMake list. See also
-    ``SEPARATOR`` sub-option.
-  * ``REG_DWORD``.
-  * ``REG_QWORD``.
-
-  For all other types, an empty string is returned.
-
-``VIEW``
-  Specify which registry views must be queried. When not specified, ``BOTH``
-  view is used.
-
-  ``64``
-    Query the 64bit registry. On ``32bit Windows``, returns always an empty
-    string.
-
-  ``32``
-    Query the 32bit registry.
-
-  ``64_32``
-    For ``VALUE`` sub-option or default value, query the registry using view
-    ``64``, and if the request failed, query the registry using view ``32``.
-    For ``VALUE_NAMES`` and ``SUBKEYS`` sub-options, query both views (``64``
-    and ``32``) and merge the results (sorted and duplicates removed).
-
-  ``32_64``
-    For ``VALUE`` sub-option or default value, query the registry using view
-    ``32``, and if the request failed, query the registry using view ``64``.
-    For ``VALUE_NAMES`` and ``SUBKEYS`` sub-options, query both views (``32``
-    and ``64``) and merge the results (sorted and duplicates removed).
-
-  ``HOST``
-    Query the registry matching the architecture of the host: ``64`` on ``64bit
-    Windows`` and ``32`` on ``32bit Windows``.
-
-  ``TARGET``
-    Query the registry matching the architecture specified by
-    :variable:`CMAKE_SIZEOF_VOID_P` variable. If not defined, fallback to
-    ``HOST`` view.
-
-  ``BOTH``
-    Query both views (``32`` and ``64``). The order depends of the following
-    rules: If :variable:`CMAKE_SIZEOF_VOID_P` variable is defined. Use the
-    following view depending of the content of this variable:
-
-    * ``8``: ``64_32``
-    * ``4``: ``32_64``
-
-    If :variable:`CMAKE_SIZEOF_VOID_P` variable is not defined, rely on
-    architecture of the host:
-
-    * ``64bit``: ``64_32``
-    * ``32bit``: ``32``
-
-``SEPARATOR``
-  Specify the separator character for ``REG_MULTI_SZ`` type. When not
-  specified, the character ``\0`` is used.
-
-``ERROR_VARIABLE <result>``
-  Returns any error raised during query operation. In case of success, the
-  variable holds an empty string.

third-party/cmake-3.27.7-linux-x86_64/share/cmake-3.27/Help/command/cmake_language.rst

@@ -1,508 +0,0 @@
-cmake_language
---------------
-
-.. versionadded:: 3.18
-
-Call meta-operations on CMake commands.
-
-Synopsis
-^^^^^^^^
-
-.. parsed-literal::
-
-  cmake_language(`CALL`_ <command> [<arg>...])
-  cmake_language(`EVAL`_ CODE <code>...)
-  cmake_language(`DEFER`_ <options>... CALL <command> [<arg>...])
-  cmake_language(`SET_DEPENDENCY_PROVIDER`_ <command> SUPPORTED_METHODS <methods>...)
-  cmake_language(`GET_MESSAGE_LOG_LEVEL`_ <out-var>)
-
-Introduction
-^^^^^^^^^^^^
-
-This command will call meta-operations on built-in CMake commands or
-those created via the :command:`macro` or :command:`function` commands.
-
-``cmake_language`` does not introduce a new variable or policy scope.
-
-Calling Commands
-^^^^^^^^^^^^^^^^
-
-.. signature::
-  cmake_language(CALL <command> [<arg>...])
-
-  Calls the named ``<command>`` with the given arguments (if any).
-  For example, the code:
-
-  .. code-block:: cmake
-
-    set(message_command "message")
-    cmake_language(CALL ${message_command} STATUS "Hello World!")
-
-  is equivalent to
-
-  .. code-block:: cmake
-
-    message(STATUS "Hello World!")
-
-  .. note::
-    To ensure consistency of the code, the following commands are not allowed:
-
-    * ``if`` / ``elseif`` / ``else`` / ``endif``
-    * ``block`` / ``endblock``
-    * ``while`` / ``endwhile``
-    * ``foreach`` / ``endforeach``
-    * ``function`` / ``endfunction``
-    * ``macro`` / ``endmacro``
-
-Evaluating Code
-^^^^^^^^^^^^^^^
-
-.. signature::
-  cmake_language(EVAL CODE <code>...)
-  :target: EVAL
-
-  Evaluates the ``<code>...`` as CMake code.
-
-  For example, the code:
-
-  .. code-block:: cmake
-
-    set(A TRUE)
-    set(B TRUE)
-    set(C TRUE)
-    set(condition "(A AND B) OR C")
-
-    cmake_language(EVAL CODE "
-      if (${condition})
-        message(STATUS TRUE)
-      else()
-        message(STATUS FALSE)
-      endif()"
-    )
-
-  is equivalent to
-
-  .. code-block:: cmake
-
-    set(A TRUE)
-    set(B TRUE)
-    set(C TRUE)
-    set(condition "(A AND B) OR C")
-
-    file(WRITE ${CMAKE_CURRENT_BINARY_DIR}/eval.cmake "
-      if (${condition})
-        message(STATUS TRUE)
-      else()
-        message(STATUS FALSE)
-      endif()"
-    )
-
-    include(${CMAKE_CURRENT_BINARY_DIR}/eval.cmake)
-
-Deferring Calls
-^^^^^^^^^^^^^^^
-
-.. versionadded:: 3.19
-
-.. signature::
-  cmake_language(DEFER <options>... CALL <command> [<arg>...])
-
-  Schedules a call to the named ``<command>`` with the given arguments (if any)
-  to occur at a later time.  By default, deferred calls are executed as if
-  written at the end of the current directory's ``CMakeLists.txt`` file,
-  except that they run even after a :command:`return` call.  Variable
-  references in arguments are evaluated at the time the deferred call is
-  executed.
-
-  The options are:
-
-  ``DIRECTORY <dir>``
-    Schedule the call for the end of the given directory instead of the
-    current directory.  The ``<dir>`` may reference either a source
-    directory or its corresponding binary directory.  Relative paths are
-    treated as relative to the current source directory.
-
-    The given directory must be known to CMake, being either the top-level
-    directory or one added by :command:`add_subdirectory`.  Furthermore,
-    the given directory must not yet be finished processing.  This means
-    it can be the current directory or one of its ancestors.
-
-  ``ID <id>``
-    Specify an identification for the deferred call.
-    The ``<id>`` may not be empty and may not begin with a capital letter ``A-Z``.
-    The ``<id>`` may begin with an underscore (``_``) only if it was generated
-    automatically by an earlier call that used ``ID_VAR`` to get the id.
-
-  ``ID_VAR <var>``
-    Specify a variable in which to store the identification for the
-    deferred call.  If ``ID <id>`` is not given, a new identification
-    will be generated and the generated id will start with an underscore (``_``).
-
-  The currently scheduled list of deferred calls may be retrieved:
-
-  .. code-block:: cmake
-
-    cmake_language(DEFER [DIRECTORY <dir>] GET_CALL_IDS <var>)
-
-  This will store in ``<var>`` a :ref:`semicolon-separated list <CMake Language
-  Lists>` of deferred call ids.  The ids are for the directory scope in which
-  the calls have been deferred to (i.e. where they will be executed), which can
-  be different to the scope in which they were created.  The ``DIRECTORY``
-  option can be used to specify the scope for which to retrieve the call ids.
-  If that option is not given, the call ids for the current directory scope
-  will be returned.
-
-  Details of a specific call may be retrieved from its id:
-
-  .. code-block:: cmake
-
-    cmake_language(DEFER [DIRECTORY <dir>] GET_CALL <id> <var>)
-
-  This will store in ``<var>`` a :ref:`semicolon-separated list <CMake Language
-  Lists>` in which the first element is the name of the command to be
-  called, and the remaining elements are its unevaluated arguments (any
-  contained ``;`` characters are included literally and cannot be distinguished
-  from multiple arguments).  If multiple calls are scheduled with the same id,
-  this retrieves the first one.  If no call is scheduled with the given id in
-  the specified ``DIRECTORY`` scope (or the current directory scope if no
-  ``DIRECTORY`` option is given), this stores an empty string in the variable.
-
-  Deferred calls may be canceled by their id:
-
-  .. code-block:: cmake
-
-    cmake_language(DEFER [DIRECTORY <dir>] CANCEL_CALL <id>...)
-
-  This cancels all deferred calls matching any of the given ids in the specified
-  ``DIRECTORY`` scope (or the current directory scope if no ``DIRECTORY`` option
-  is given).  Unknown ids are silently ignored.
-
-Deferred Call Examples
-""""""""""""""""""""""
-
-For example, the code:
-
-.. code-block:: cmake
-
-  cmake_language(DEFER CALL message "${deferred_message}")
-  cmake_language(DEFER ID_VAR id CALL message "Canceled Message")
-  cmake_language(DEFER CANCEL_CALL ${id})
-  message("Immediate Message")
-  set(deferred_message "Deferred Message")
-
-prints::
-
-  Immediate Message
-  Deferred Message
-
-The ``Cancelled Message`` is never printed because its command is
-canceled.  The ``deferred_message`` variable reference is not evaluated
-until the call site, so it can be set after the deferred call is scheduled.
-
-In order to evaluate variable references immediately when scheduling a
-deferred call, wrap it using ``cmake_language(EVAL)``.  However, note that
-arguments will be re-evaluated in the deferred call, though that can be
-avoided by using bracket arguments.  For example:
-
-.. code-block:: cmake
-
-  set(deferred_message "Deferred Message 1")
-  set(re_evaluated [[${deferred_message}]])
-  cmake_language(EVAL CODE "
-    cmake_language(DEFER CALL message [[${deferred_message}]])
-    cmake_language(DEFER CALL message \"${re_evaluated}\")
-  ")
-  message("Immediate Message")
-  set(deferred_message "Deferred Message 2")
-
-also prints::
-
-  Immediate Message
-  Deferred Message 1
-  Deferred Message 2
-
-.. _dependency_providers:
-
-Dependency Providers
-^^^^^^^^^^^^^^^^^^^^
-
-.. versionadded:: 3.24
-
-.. note:: A high-level introduction to this feature can be found in the
-          :ref:`Using Dependencies Guide <dependency_providers_overview>`.
-
-.. signature::
-  cmake_language(SET_DEPENDENCY_PROVIDER <command>
-                 SUPPORTED_METHODS <methods>...)
-
-  When a call is made to :command:`find_package` or
-  :command:`FetchContent_MakeAvailable`, the call may be forwarded to a
-  dependency provider which then has the opportunity to fulfill the request.
-  If the request is for one of the ``<methods>`` specified when the provider
-  was set, CMake calls the provider's ``<command>`` with a set of
-  method-specific arguments.  If the provider does not fulfill the request,
-  or if the provider doesn't support the request's method, or no provider
-  is set, the built-in :command:`find_package` or
-  :command:`FetchContent_MakeAvailable` implementation is used to fulfill
-  the request in the usual way.
-
-  One or more of the following values can be specified for the ``<methods>``
-  when setting the provider:
-
-  ``FIND_PACKAGE``
-    The provider command accepts :command:`find_package` requests.
-
-  ``FETCHCONTENT_MAKEAVAILABLE_SERIAL``
-    The provider command accepts :command:`FetchContent_MakeAvailable`
-    requests.  It expects each dependency to be fed to the provider command
-    one at a time, not the whole list in one go.
-
-  Only one provider can be set at any point in time.  If a provider is already
-  set when ``cmake_language(SET_DEPENDENCY_PROVIDER)`` is called, the new
-  provider replaces the previously set one.  The specified ``<command>`` must
-  already exist when ``cmake_language(SET_DEPENDENCY_PROVIDER)`` is called.
-  As a special case, providing an empty string for the ``<command>`` and no
-  ``<methods>`` will discard any previously set provider.
-
-  The dependency provider can only be set while processing one of the files
-  specified by the :variable:`CMAKE_PROJECT_TOP_LEVEL_INCLUDES` variable.
-  Thus, dependency providers can only be set as part of the first call to
-  :command:`project`.  Calling ``cmake_language(SET_DEPENDENCY_PROVIDER)``
-  outside of that context will result in an error.
-
-  .. note::
-    The choice of dependency provider should always be under the user's control.
-    As a convenience, a project may choose to provide a file that users can
-    list in their :variable:`CMAKE_PROJECT_TOP_LEVEL_INCLUDES` variable, but
-    the use of such a file should always be the user's choice.
-
-Provider commands
-"""""""""""""""""
-
-Providers define a single ``<command>`` to accept requests.  The name of
-the command should be specific to that provider, not something overly
-generic that another provider might also use.  This enables users to compose
-different providers in their own custom provider.  The recommended form is
-``xxx_provide_dependency()``, where ``xxx`` is the provider-specific part
-(e.g. ``vcpkg_provide_dependency()``, ``conan_provide_dependency()``,
-``ourcompany_provide_dependency()``, and so on).
-
-.. code-block:: cmake
-
-  xxx_provide_dependency(<method> [<method-specific-args>...])
-
-Because some methods expect certain variables to be set in the calling scope,
-the provider command should typically be implemented as a macro rather than a
-function.  This ensures it does not introduce a new variable scope.
-
-The arguments CMake passes to the dependency provider depend on the type of
-request.  The first argument is always the method, and it will only ever
-be one of the ``<methods>`` that was specified when setting the provider.
-
-``FIND_PACKAGE``
-  The ``<method-specific-args>`` will be everything passed to the
-  :command:`find_package` call that requested the dependency.  The first of
-  these ``<method-specific-args>`` will therefore always be the name of the
-  dependency.  Dependency names are case-sensitive for this method because
-  :command:`find_package` treats them case-sensitively too.
-
-  If the provider command fulfills the request, it must set the same variable
-  that :command:`find_package` expects to be set.  For a dependency named
-  ``depName``, the provider must set ``depName_FOUND`` to true if it fulfilled
-  the request.  If the provider returns without setting this variable, CMake
-  will assume the request was not fulfilled and will fall back to the
-  built-in implementation.
-
-  If the provider needs to call the built-in :command:`find_package`
-  implementation as part of its processing, it can do so by including the
-  ``BYPASS_PROVIDER`` keyword as one of the arguments.
-
-``FETCHCONTENT_MAKEAVAILABE_SERIAL``
-  The ``<method-specific-args>`` will be everything passed to the
-  :command:`FetchContent_Declare` call that corresponds to the requested
-  dependency, with the following exceptions:
-
-  * If ``SOURCE_DIR`` or ``BINARY_DIR`` were not part of the original
-    declared arguments, they will be added with their default values.
-  * If :variable:`FETCHCONTENT_TRY_FIND_PACKAGE_MODE` is set to ``NEVER``,
-    any ``FIND_PACKAGE_ARGS`` will be omitted.
-  * The ``OVERRIDE_FIND_PACKAGE`` keyword is always omitted.
-
-  The first of the ``<method-specific-args>`` will always be the name of the
-  dependency.  Dependency names are case-insensitive for this method because
-  :module:`FetchContent` also treats them case-insensitively.
-
-  If the provider fulfills the request, it should call
-  :command:`FetchContent_SetPopulated`, passing the name of the dependency as
-  the first argument.  The ``SOURCE_DIR`` and ``BINARY_DIR`` arguments to that
-  command should only be given if the provider makes the dependency's source
-  and build directories available in exactly the same way as the built-in
-  :command:`FetchContent_MakeAvailable` command.
-
-  If the provider returns without calling :command:`FetchContent_SetPopulated`
-  for the named dependency, CMake will assume the request was not fulfilled
-  and will fall back to the built-in implementation.
-
-  Note that empty arguments may be significant for this method (e.g. an empty
-  string following a ``GIT_SUBMODULES`` keyword).  Therefore, if forwarding
-  these arguments on to another command, extra care must be taken to avoid such
-  arguments being silently dropped.
-
-  If ``FETCHCONTENT_SOURCE_DIR_<uppercaseDepName>`` is set, then the
-  dependency provider will never see requests for the ``<depName>`` dependency
-  for this method. When the user sets such a variable, they are explicitly
-  overriding where to get that dependency from and are taking on the
-  responsibility that their overriding version meets any requirements for that
-  dependency and is compatible with whatever else in the project uses it.
-  Depending on the value of :variable:`FETCHCONTENT_TRY_FIND_PACKAGE_MODE`
-  and whether the ``OVERRIDE_FIND_PACKAGE`` option was given to
-  :command:`FetchContent_Declare`, having
-  ``FETCHCONTENT_SOURCE_DIR_<uppercaseDepName>`` set may also prevent the
-  dependency provider from seeing requests for a ``find_package(depName)``
-  call too.
-
-Provider Examples
-"""""""""""""""""
-
-This first example only intercepts :command:`find_package` calls.  The
-provider command runs an external tool which copies the relevant artifacts
-into a provider-specific directory, if that tool knows about the dependency.
-It then relies on the built-in implementation to then find those artifacts.
-:command:`FetchContent_MakeAvailable` calls would not go through the provider.
-
-.. code-block:: cmake
-  :caption: mycomp_provider.cmake
-
-  # Always ensure we have the policy settings this provider expects
-  cmake_minimum_required(VERSION 3.24)
-
-  set(MYCOMP_PROVIDER_INSTALL_DIR ${CMAKE_BINARY_DIR}/mycomp_packages
-    CACHE PATH "The directory this provider installs packages to"
-  )
-  # Tell the built-in implementation to look in our area first, unless
-  # the find_package() call uses NO_..._PATH options to exclude it
-  list(APPEND CMAKE_MODULE_PATH ${MYCOMP_PROVIDER_INSTALL_DIR}/cmake)
-  list(APPEND CMAKE_PREFIX_PATH ${MYCOMP_PROVIDER_INSTALL_DIR})
-
-  macro(mycomp_provide_dependency method package_name)
-    execute_process(
-      COMMAND some_tool ${package_name} --installdir ${MYCOMP_PROVIDER_INSTALL_DIR}
-      COMMAND_ERROR_IS_FATAL ANY
-    )
-  endmacro()
-
-  cmake_language(
-    SET_DEPENDENCY_PROVIDER mycomp_provide_dependency
-    SUPPORTED_METHODS FIND_PACKAGE
-  )
-
-The user would then typically use the above file like so::
-
-  cmake -DCMAKE_PROJECT_TOP_LEVEL_INCLUDES=/path/to/mycomp_provider.cmake ...
-
-The next example demonstrates a provider that accepts both methods, but
-only handles one specific dependency.  It enforces providing Google Test
-using :module:`FetchContent`, but leaves all other dependencies to be
-fulfilled by CMake's built-in implementation.  It accepts a few different
-names, which demonstrates one way of working around projects that hard-code
-an unusual or undesirable way of adding this particular dependency to the
-build.  The example also demonstrates how to use the :command:`list` command
-to preserve variables that may be overwritten by a call to
-:command:`FetchContent_MakeAvailable`.
-
-.. code-block:: cmake
-  :caption: mycomp_provider.cmake
-
-  cmake_minimum_required(VERSION 3.24)
-
-  # Because we declare this very early, it will take precedence over any
-  # details the project might declare later for the same thing
-  include(FetchContent)
-  FetchContent_Declare(
-    googletest
-    GIT_REPOSITORY https://github.com/google/googletest.git
-    GIT_TAG        e2239ee6043f73722e7aa812a459f54a28552929 # release-1.11.0
-  )
-
-  # Both FIND_PACKAGE and FETCHCONTENT_MAKEAVAILABLE_SERIAL methods provide
-  # the package or dependency name as the first method-specific argument.
-  macro(mycomp_provide_dependency method dep_name)
-    if("${dep_name}" MATCHES "^(gtest|googletest)$")
-      # Save our current command arguments in case we are called recursively
-      list(APPEND mycomp_provider_args ${method} ${dep_name})
-
-      # This will forward to the built-in FetchContent implementation,
-      # which detects a recursive call for the same thing and avoids calling
-      # the provider again if dep_name is the same as the current call.
-      FetchContent_MakeAvailable(googletest)
-
-      # Restore our command arguments
-      list(POP_BACK mycomp_provider_args dep_name method)
-
-      # Tell the caller we fulfilled the request
-      if("${method}" STREQUAL "FIND_PACKAGE")
-        # We need to set this if we got here from a find_package() call
-        # since we used a different method to fulfill the request.
-        # This example assumes projects only use the gtest targets,
-        # not any of the variables the FindGTest module may define.
-        set(${dep_name}_FOUND TRUE)
-      elseif(NOT "${dep_name}" STREQUAL "googletest")
-        # We used the same method, but were given a different name to the
-        # one we populated with. Tell the caller about the name it used.
-        FetchContent_SetPopulated(${dep_name}
-          SOURCE_DIR "${googletest_SOURCE_DIR}"
-          BINARY_DIR "${googletest_BINARY_DIR}"
-        )
-      endif()
-    endif()
-  endmacro()
-
-  cmake_language(
-    SET_DEPENDENCY_PROVIDER mycomp_provide_dependency
-    SUPPORTED_METHODS
-      FIND_PACKAGE
-      FETCHCONTENT_MAKEAVAILABLE_SERIAL
-  )
-
-The final example demonstrates how to modify arguments to a
-:command:`find_package` call.  It forces all such calls to have the
-``QUIET`` keyword.  It uses the ``BYPASS_PROVIDER`` keyword to prevent
-calling the provider command recursively for the same dependency.
-
-.. code-block:: cmake
-  :caption: mycomp_provider.cmake
-
-  cmake_minimum_required(VERSION 3.24)
-
-  macro(mycomp_provide_dependency method)
-    find_package(${ARGN} BYPASS_PROVIDER QUIET)
-  endmacro()
-
-  cmake_language(
-    SET_DEPENDENCY_PROVIDER mycomp_provide_dependency
-    SUPPORTED_METHODS FIND_PACKAGE
-  )
-
-Getting current message log level
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-.. versionadded:: 3.25
-
-.. _query_message_log_level:
-
-.. signature::
-  cmake_language(GET_MESSAGE_LOG_LEVEL <output_variable>)
-
-  Writes the current :command:`message` logging level
-  into the given ``<output_variable>``.
-
-  See :command:`message` for the possible logging levels.
-
-  The current message logging level can be set either using the
-  :option:`--log-level <cmake --log-level>`
-  command line option of the :manual:`cmake(1)` program or using
-  the :variable:`CMAKE_MESSAGE_LOG_LEVEL` variable.
-
-  If both the command line option and the variable are set, the command line
-  option takes precedence. If neither are set, the default logging level
-  is returned.

third-party/cmake-3.27.7-linux-x86_64/share/cmake-3.27/Help/command/cmake_minimum_required.rst

@@ -1,88 +0,0 @@
-cmake_minimum_required
-----------------------
-
-Require a minimum version of cmake.
-
-.. code-block:: cmake
-
-  cmake_minimum_required(VERSION <min>[...<policy_max>] [FATAL_ERROR])
-
-.. versionadded:: 3.12
-  The optional ``<policy_max>`` version.
-
-Sets the minimum required version of cmake for a project.
-Also updates the policy settings as explained below.
-
-``<min>`` and the optional ``<policy_max>`` are each CMake versions of the
-form ``major.minor[.patch[.tweak]]``, and the ``...`` is literal.
-
-If the running version of CMake is lower than the ``<min>`` required
-version it will stop processing the project and report an error.
-The optional ``<policy_max>`` version, if specified, must be at least the
-``<min>`` version and affects policy settings as described in `Policy Settings`_.
-If the running version of CMake is older than 3.12, the extra ``...``
-dots will be seen as version component separators, resulting in the
-``...<max>`` part being ignored and preserving the pre-3.12 behavior
-of basing policies on ``<min>``.
-
-This command will set the value of the
-:variable:`CMAKE_MINIMUM_REQUIRED_VERSION` variable to ``<min>``.
-
-The ``FATAL_ERROR`` option is accepted but ignored by CMake 2.6 and
-higher.  It should be specified so CMake versions 2.4 and lower fail
-with an error instead of just a warning.
-
-.. note::
-  Call the ``cmake_minimum_required()`` command at the beginning of
-  the top-level ``CMakeLists.txt`` file even before calling the
-  :command:`project` command.  It is important to establish version
-  and policy settings before invoking other commands whose behavior
-  they may affect.  See also policy :policy:`CMP0000`.
-
-  Calling ``cmake_minimum_required()`` inside a :command:`function`
-  limits some effects to the function scope when invoked.  For example,
-  the :variable:`CMAKE_MINIMUM_REQUIRED_VERSION` variable won't be set
-  in the calling scope.  Functions do not introduce their own policy
-  scope though, so policy settings of the caller *will* be affected
-  (see below).  Due to this mix of things that do and do not affect the
-  calling scope, calling ``cmake_minimum_required()`` inside a function
-  is generally discouraged.
-
-.. _`Policy Settings`:
-
-Policy Settings
-^^^^^^^^^^^^^^^
-
-The ``cmake_minimum_required(VERSION)`` command implicitly invokes the
-:command:`cmake_policy(VERSION)` command to specify that the current
-project code is written for the given range of CMake versions.
-All policies known to the running version of CMake and introduced
-in the ``<min>`` (or ``<max>``, if specified) version or earlier will
-be set to use ``NEW`` behavior.  All policies introduced in later
-versions will be unset.  This effectively requests behavior preferred
-as of a given CMake version and tells newer CMake versions to warn
-about their new policies.
-
-When a ``<min>`` version higher than 2.4 is specified the command
-implicitly invokes
-
-.. code-block:: cmake
-
-  cmake_policy(VERSION <min>[...<max>])
-
-which sets CMake policies based on the range of versions specified.
-When a ``<min>`` version 2.4 or lower is given the command implicitly
-invokes
-
-.. code-block:: cmake
-
-  cmake_policy(VERSION 2.4[...<max>])
-
-which enables compatibility features for CMake 2.4 and lower.
-
-.. include:: DEPRECATED_POLICY_VERSIONS.txt
-
-See Also
-^^^^^^^^
-
-* :command:`cmake_policy`

third-party/cmake-3.27.7-linux-x86_64/share/cmake-3.27/Help/command/cmake_parse_arguments.rst

@@ -1,121 +0,0 @@
-cmake_parse_arguments
----------------------
-
-Parse function or macro arguments.
-
-.. code-block:: cmake
-
-  cmake_parse_arguments(<prefix> <options> <one_value_keywords>
-                        <multi_value_keywords> <args>...)
-
-  cmake_parse_arguments(PARSE_ARGV <N> <prefix> <options>
-                        <one_value_keywords> <multi_value_keywords>)
-
-.. versionadded:: 3.5
-  This command is implemented natively.  Previously, it has been defined in the
-  module :module:`CMakeParseArguments`.
-
-This command is for use in macros or functions.
-It processes the arguments given to that macro or function,
-and defines a set of variables which hold the values of the
-respective options.
-
-The first signature reads processes arguments passed in the ``<args>...``.
-This may be used in either a :command:`macro` or a :command:`function`.
-
-.. versionadded:: 3.7
-  The ``PARSE_ARGV`` signature is only for use in a :command:`function`
-  body.  In this case the arguments that are parsed come from the
-  ``ARGV#`` variables of the calling function.  The parsing starts with
-  the ``<N>``-th argument, where ``<N>`` is an unsigned integer.
-  This allows for the values to have special characters like ``;`` in them.
-
-The ``<options>`` argument contains all options for the respective macro,
-i.e.  keywords which can be used when calling the macro without any value
-following, like e.g.  the ``OPTIONAL`` keyword of the :command:`install`
-command.
-
-The ``<one_value_keywords>`` argument contains all keywords for this macro
-which are followed by one value, like e.g. ``DESTINATION`` keyword of the
-:command:`install` command.
-
-The ``<multi_value_keywords>`` argument contains all keywords for this
-macro which can be followed by more than one value, like e.g. the
-``TARGETS`` or ``FILES`` keywords of the :command:`install` command.
-
-.. versionchanged:: 3.5
-  All keywords shall be unique. I.e. every keyword shall only be specified
-  once in either ``<options>``, ``<one_value_keywords>`` or
-  ``<multi_value_keywords>``. A warning will be emitted if uniqueness is
-  violated.
-
-When done, ``cmake_parse_arguments`` will consider for each of the
-keywords listed in ``<options>``, ``<one_value_keywords>`` and
-``<multi_value_keywords>`` a variable composed of the given ``<prefix>``
-followed by ``"_"`` and the name of the respective keyword.  These
-variables will then hold the respective value from the argument list
-or be undefined if the associated option could not be found.
-For the ``<options>`` keywords, these will always be defined,
-to ``TRUE`` or ``FALSE``, whether the option is in the argument list or not.
-
-All remaining arguments are collected in a variable
-``<prefix>_UNPARSED_ARGUMENTS`` that will be undefined if all arguments
-were recognized. This can be checked afterwards to see
-whether your macro was called with unrecognized parameters.
-
-.. versionadded:: 3.15
-   ``<one_value_keywords>`` and ``<multi_value_keywords>`` that were given no
-   values at all are collected in a variable
-   ``<prefix>_KEYWORDS_MISSING_VALUES`` that will be undefined if all keywords
-   received values. This can be checked to see if there were keywords without
-   any values given.
-
-Consider the following example macro, ``my_install()``, which takes similar
-arguments to the real :command:`install` command:
-
-.. code-block:: cmake
-
-   macro(my_install)
-       set(options OPTIONAL FAST)
-       set(oneValueArgs DESTINATION RENAME)
-       set(multiValueArgs TARGETS CONFIGURATIONS)
-       cmake_parse_arguments(MY_INSTALL "${options}" "${oneValueArgs}"
-                             "${multiValueArgs}" ${ARGN} )
-
-       # ...
-
-Assume ``my_install()`` has been called like this:
-
-.. code-block:: cmake
-
-   my_install(TARGETS foo bar DESTINATION bin OPTIONAL blub CONFIGURATIONS)
-
-After the ``cmake_parse_arguments`` call the macro will have set or undefined
-the following variables::
-
-   MY_INSTALL_OPTIONAL = TRUE
-   MY_INSTALL_FAST = FALSE # was not used in call to my_install
-   MY_INSTALL_DESTINATION = "bin"
-   MY_INSTALL_RENAME <UNDEFINED> # was not used
-   MY_INSTALL_TARGETS = "foo;bar"
-   MY_INSTALL_CONFIGURATIONS <UNDEFINED> # was not used
-   MY_INSTALL_UNPARSED_ARGUMENTS = "blub" # nothing expected after "OPTIONAL"
-   MY_INSTALL_KEYWORDS_MISSING_VALUES = "CONFIGURATIONS"
-            # No value for "CONFIGURATIONS" given
-
-You can then continue and process these variables.
-
-Keywords terminate lists of values, e.g. if directly after a
-``one_value_keyword`` another recognized keyword follows, this is
-interpreted as the beginning of the new option.  E.g.
-``my_install(TARGETS foo DESTINATION OPTIONAL)`` would result in
-``MY_INSTALL_DESTINATION`` set to ``"OPTIONAL"``, but as ``OPTIONAL``
-is a keyword itself ``MY_INSTALL_DESTINATION`` will be empty (but added
-to ``MY_INSTALL_KEYWORDS_MISSING_VALUES``) and ``MY_INSTALL_OPTIONAL`` will
-therefore be set to ``TRUE``.
-
-See Also
-^^^^^^^^
-
-* :command:`function`
-* :command:`macro`

third-party/cmake-3.27.7-linux-x86_64/share/cmake-3.27/Help/command/cmake_path.rst

@@ -1,798 +0,0 @@
-cmake_path
-----------
-
-.. versionadded:: 3.20
-
-This command is for the manipulation of paths.  Only syntactic aspects of
-paths are handled, there is no interaction of any kind with any underlying
-file system.  The path may represent a non-existing path or even one that
-is not allowed to exist on the current file system or platform.
-For operations that do interact with the filesystem, see the :command:`file`
-command.
-
-.. note::
-
-  The ``cmake_path`` command handles paths in the format of the build system
-  (i.e. the host platform), not the target system.  When cross-compiling,
-  if the path contains elements that are not representable on the host
-  platform (e.g. a drive letter when the host is not Windows), the results
-  will be unpredictable.
-
-Synopsis
-^^^^^^^^
-
-.. parsed-literal::
-
-  `Conventions`_
-
-  `Path Structure And Terminology`_
-
-  `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>)
-
-  `Query`_
-    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>)
-    cmake_path(`HAS_FILENAME`_ <path-var> <out-var>)
-    cmake_path(`HAS_EXTENSION`_ <path-var> <out-var>)
-    cmake_path(`HAS_STEM`_ <path-var> <out-var>)
-    cmake_path(`HAS_RELATIVE_PART`_ <path-var> <out-var>)
-    cmake_path(`HAS_PARENT_PATH`_ <path-var> <out-var>)
-    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>)
-
-  `Modification`_
-    cmake_path(:ref:`SET <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>])
-    cmake_path(`REPLACE_FILENAME`_ <path-var> <input> [OUTPUT_VARIABLE <out-var>])
-    cmake_path(`REMOVE_EXTENSION`_ <path-var> [LAST_ONLY] [OUTPUT_VARIABLE <out-var>])
-    cmake_path(`REPLACE_EXTENSION`_ <path-var> [LAST_ONLY] <input> [OUTPUT_VARIABLE <out-var>])
-
-  `Generation`_
-    cmake_path(`NORMAL_PATH`_ <path-var> [OUTPUT_VARIABLE <out-var>])
-    cmake_path(`RELATIVE_PATH`_ <path-var> [BASE_DIRECTORY <input>] [OUTPUT_VARIABLE <out-var>])
-    cmake_path(`ABSOLUTE_PATH`_ <path-var> [BASE_DIRECTORY <input>] [NORMALIZE] [OUTPUT_VARIABLE <out-var>])
-
-  `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])
-
-  `Hashing`_
-    cmake_path(`HASH`_ <path-var> <out-var>)
-
-Conventions
-^^^^^^^^^^^
-
-The following conventions are used in this command's documentation:
-
-``<path-var>``
-  Always the name of a variable.  For commands that expect a ``<path-var>``
-  as input, the variable must exist and it is expected to hold a single path.
-
-``<input>``
-  A string literal which may contain a path, path fragment, or multiple paths
-  with a special separator depending on the command.  See the description of
-  each command to see how this is interpreted.
-
-``<input>...``
-  Zero or more string literal arguments.
-
-``<out-var>``
-  The name of a variable into which the result of a command will be written.
-
-
-.. _Path Structure And Terminology:
-
-Path Structure And Terminology
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-A path has the following structure (all components are optional, with some
-constraints):
-
-::
-
-  root-name root-directory-separator (item-name directory-separator)* filename
-
-``root-name``
-  Identifies the root on a filesystem with multiple roots (such as ``"C:"``
-  or ``"//myserver"``). It is optional.
-
-``root-directory-separator``
-  A directory separator that, if present, indicates that this path is
-  absolute.  If it is missing and the first element other than the
-  ``root-name`` is an ``item-name``, then the path is relative.
-
-``item-name``
-  A sequence of characters that aren't directory separators.  This name may
-  identify a file, a hard link, a symbolic link, or a directory.  Two special
-  cases are recognized:
-
-    * The item name consisting of a single dot character ``.`` is a
-      directory name that refers to the current directory.
-
-    * The item name consisting of two dot characters ``..`` is a
-      directory name that refers to the parent directory.
-
-  The ``(...)*`` pattern shown above is to indicate that there can be zero
-  or more item names, with multiple items separated by a
-  ``directory-separator``.  The ``()*`` characters are not part of the path.
-
-``directory-separator``
-  The only recognized directory separator is a forward slash character ``/``.
-  If this character is repeated, it is treated as a single directory
-  separator.  In other words, ``/usr///////lib`` is the same as ``/usr/lib``.
-
-.. _FILENAME_DEF:
-.. _EXTENSION_DEF:
-.. _STEM_DEF:
-
-``filename``
-  A path has a ``filename`` if it does not end with a ``directory-separator``.
-  The ``filename`` is effectively the last ``item-name`` of the path, so it
-  can also be a hard link, symbolic link or a directory.
-
-  A ``filename`` can have an *extension*.  By default, the extension is
-  defined as the sub-string beginning at the left-most period (including
-  the period) and until the end of the ``filename``.  In commands that
-  accept a ``LAST_ONLY`` keyword, ``LAST_ONLY`` changes the interpretation
-  to the sub-string beginning at the right-most period.
-
-  The following exceptions apply to the above interpretation:
-
-    * If the first character in the ``filename`` is a period, that period is
-      ignored (i.e. a ``filename`` like ``".profile"`` is treated as having
-      no extension).
-
-    * If the ``filename`` is either ``.`` or ``..``, it has no extension.
-
-  The *stem* is the part of the ``filename`` before the extension.
-
-Some commands refer to a ``root-path``.  This is the concatenation of
-``root-name`` and ``root-directory-separator``, either or both of which can
-be empty.  A ``relative-part`` refers to the full path with any ``root-path``
-removed.
-
-
-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:
-
-.. code-block:: cmake
-
-  set(path1 "${CMAKE_CURRENT_SOURCE_DIR}/data")
-
-  cmake_path(SET path2 "${CMAKE_CURRENT_SOURCE_DIR}/data")
-
-  cmake_path(APPEND path3 "${CMAKE_CURRENT_SOURCE_DIR}" "data")
-
-`Modification`_ and `Generation`_ sub-commands can either store the result
-in-place, or in a separate variable named after an ``OUTPUT_VARIABLE``
-keyword.  All other sub-commands store the result in a mandatory ``<out-var>``
-variable.
-
-.. _Normalization:
-
-Normalization
-^^^^^^^^^^^^^
-
-Some sub-commands support *normalizing* a path.  The algorithm used to
-normalize a path is as follows:
-
-1. If the path is empty, stop (the normalized form of an empty path is
-   also an empty path).
-2. Replace each ``directory-separator``, which may consist of multiple
-   separators, with a single ``/`` (``/a///b  --> /a/b``).
-3. Remove each solitary period (``.``) and any immediately following
-   ``directory-separator`` (``/a/./b/. --> /a/b``).
-4. Remove each ``item-name`` (other than ``..``) that is immediately
-   followed by a ``directory-separator`` and a ``..``, along with any
-   immediately following ``directory-separator`` (``/a/b/../c --> a/c``).
-5. If there is a ``root-directory``, remove any ``..`` and any
-   ``directory-separators`` immediately following them.  The parent of the
-   root directory is treated as still the root directory (``/../a --> /a``).
-6. If the last ``item-name`` is ``..``, remove any trailing
-   ``directory-separator`` (``../ --> ..``).
-7. If the path is empty by this stage, add a ``dot`` (normal form of ``./``
-   is ``.``).
-
-
-.. _Path Decomposition:
-
-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
-
-  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>)
-  cmake_path(GET <path-var> FILENAME <out-var>)
-  cmake_path(GET <path-var> EXTENSION [LAST_ONLY] <out-var>)
-  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>)
-
-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.
-
-Root examples
-"""""""""""""
-
-.. code-block:: cmake
-
-  set(path "c:/a")
-
-  cmake_path(GET path ROOT_NAME rootName)
-  cmake_path(GET path ROOT_DIRECTORY rootDir)
-  cmake_path(GET path ROOT_PATH rootPath)
-
-  message("Root name is \"${rootName}\"")
-  message("Root directory is \"${rootDir}\"")
-  message("Root path is \"${rootPath}\"")
-
-::
-
-  Root name is "c:"
-  Root directory is "/"
-  Root path is "c:/"
-
-Filename examples
-"""""""""""""""""
-
-.. code-block:: cmake
-
-  set(path "/a/b")
-  cmake_path(GET path FILENAME filename)
-  message("First filename is \"${filename}\"")
-
-  # Trailing slash means filename is empty
-  set(path "/a/b/")
-  cmake_path(GET path FILENAME filename)
-  message("Second filename is \"${filename}\"")
-
-::
-
-  First filename is "b"
-  Second filename is ""
-
-Extension and stem examples
-"""""""""""""""""""""""""""
-
-.. code-block:: cmake
-
-  set(path "name.ext1.ext2")
-
-  cmake_path(GET path EXTENSION fullExt)
-  cmake_path(GET path STEM fullStem)
-  message("Full extension is \"${fullExt}\"")
-  message("Full stem is \"${fullStem}\"")
-
-  # Effect of LAST_ONLY
-  cmake_path(GET path EXTENSION LAST_ONLY lastExt)
-  cmake_path(GET path STEM LAST_ONLY lastStem)
-  message("Last extension is \"${lastExt}\"")
-  message("Last stem is \"${lastStem}\"")
-
-  # Special cases
-  set(dotPath "/a/.")
-  set(dotDotPath "/a/..")
-  set(someMorePath "/a/.some.more")
-  cmake_path(GET dotPath EXTENSION dotExt)
-  cmake_path(GET dotPath STEM dotStem)
-  cmake_path(GET dotDotPath EXTENSION dotDotExt)
-  cmake_path(GET dotDotPath STEM dotDotStem)
-  cmake_path(GET dotMorePath EXTENSION someMoreExt)
-  cmake_path(GET dotMorePath STEM someMoreStem)
-  message("Dot extension is \"${dotExt}\"")
-  message("Dot stem is \"${dotStem}\"")
-  message("Dot-dot extension is \"${dotDotExt}\"")
-  message("Dot-dot stem is \"${dotDotStem}\"")
-  message(".some.more extension is \"${someMoreExt}\"")
-  message(".some.more stem is \"${someMoreStem}\"")
-
-::
-
-  Full extension is ".ext1.ext2"
-  Full stem is "name"
-  Last extension is ".ext2"
-  Last stem is "name.ext1"
-  Dot extension is ""
-  Dot stem is "."
-  Dot-dot extension is ""
-  Dot-dot stem is ".."
-  .some.more extension is ".more"
-  .some.more stem is ".some"
-
-Relative part examples
-""""""""""""""""""""""
-
-.. code-block:: cmake
-
-  set(path "c:/a/b")
-  cmake_path(GET path RELATIVE_PART result)
-  message("Relative part is \"${result}\"")
-
-  set(path "c/d")
-  cmake_path(GET path RELATIVE_PART result)
-  message("Relative part is \"${result}\"")
-
-  set(path "/")
-  cmake_path(GET path RELATIVE_PART result)
-  message("Relative part is \"${result}\"")
-
-::
-
-  Relative part is "a/b"
-  Relative part is "c/d"
-  Relative part is ""
-
-Path traversal examples
-"""""""""""""""""""""""
-
-.. code-block:: cmake
-
-  set(path "c:/a/b")
-  cmake_path(GET path PARENT_PATH result)
-  message("Parent path is \"${result}\"")
-
-  set(path "c:/")
-  cmake_path(GET path PARENT_PATH result)
-  message("Parent path is \"${result}\"")
-
-::
-
-  Parent path is "c:/a"
-  Parent path is "c:/"
-
-
-.. _Path Query:
-
-Query
-^^^^^
-
-Each of the ``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
-
-  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>)
-  cmake_path(HAS_FILENAME <path-var> <out-var>)
-  cmake_path(HAS_EXTENSION <path-var> <out-var>)
-  cmake_path(HAS_STEM <path-var> <out-var>)
-  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:
-
-* 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
-
-  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
-
-  cmake_path(IS_RELATIVE <path-var> <out-var>)
-
-This will store the opposite of ``IS_ABSOLUTE`` in ``<out-var>``.
-
-.. _IS_PREFIX:
-
-.. code-block:: cmake
-
-  cmake_path(IS_PREFIX <path-var> <input> [NORMALIZE] <out-var>)
-
-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.
-
-.. 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")
-  cmake_path(IS_PREFIX path "/a/c/../b" NORMALIZE result)   # result = true
-
-.. _Path COMPARE:
-.. _COMPARE:
-
-.. code-block:: cmake
-
-  cmake_path(COMPARE <input1> EQUAL <input2> <out-var>)
-  cmake_path(COMPARE <input1> NOT_EQUAL <input2> <out-var>)
-
-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(<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.
-
-.. note::
-  Unlike most other ``cmake_path()`` subcommands, the ``COMPARE`` subcommand
-  takes literal strings as input, not the names of variables.
-
-
-.. _Path Modification:
-
-Modification
-^^^^^^^^^^^^
-
-.. _cmake_path-SET:
-
-.. code-block:: cmake
-
-  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.
-
-When the ``NORMALIZE`` option is specified, the path is :ref:`normalized
-<Normalization>` after the conversion.
-
-For example:
-
-.. code-block:: cmake
-
-  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}\"")
-
-Output::
-
-  CMake path is "c:/a/b/../c"
-  Normalized CMake path is "c:/a/c"
-
-.. _APPEND:
-
-.. code-block:: cmake
-
-  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:
-
-::
-
-  # <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>.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
-
-  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
-
-  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.
-
-If ``OUTPUT_VARIABLE`` is not given, then after this function returns,
-`HAS_FILENAME`_ returns false for ``<path-var>``.
-
-For example:
-
-.. code-block:: cmake
-
-  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 \"${result}\"")
-
-Output::
-
-  First path is "/a/"
-  Second path is "/a/"
-
-.. _REPLACE_FILENAME:
-
-.. code-block:: cmake
-
-  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:
-
-.. 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(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
-
-  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:
-
-.. code-block:: cmake
-
-  cmake_path(REMOVE_EXTENSION path)
-  if(NOT "input" MATCHES "^\\.")
-    cmake_path(APPEND_STRING path ".")
-  endif()
-  cmake_path(APPEND_STRING path "input")
-
-
-.. _Path Generation:
-
-Generation
-^^^^^^^^^^
-
-.. _NORMAL_PATH:
-
-.. code-block:: cmake
-
-  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
-
-  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`.
-
-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
-
-  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`.
-
-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.
-
-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
-
-  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).
-
-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
-
-  cmake_path(CONVERT <input> TO_CMAKE_PATH_LIST <out-var> [NORMALIZE])
-
-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.
-
-.. 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
-
-  cmake_path(CONVERT <input> TO_NATIVE_PATH_LIST <out-var> [NORMALIZE])
-
-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.
-
-.. note::
-  Unlike most other ``cmake_path()`` subcommands, the ``CONVERT`` subcommand
-  takes a literal string as input, not the name of a variable.
-
-For example:
-
-.. 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}\"")
-
-Output on Windows::
-
-  Native path list is "\a\b\c;\x\y\z"
-
-Output on all other platforms::
-
-  Native path list is "/a/b/c:/x/y/z"
-
-Hashing
-^^^^^^^
-
-.. _HASH:
-
-.. 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.

third-party/cmake-3.27.7-linux-x86_64/share/cmake-3.27/Help/command/cmake_policy.rst

@@ -1,159 +0,0 @@
-cmake_policy
-------------
-
-Manage CMake Policy settings.  See the :manual:`cmake-policies(7)`
-manual for defined policies.
-
-As CMake evolves it is sometimes necessary to change existing behavior
-in order to fix bugs or improve implementations of existing features.
-The CMake Policy mechanism is designed to help keep existing projects
-building as new versions of CMake introduce changes in behavior.  Each
-new policy (behavioral change) is given an identifier of the form
-``CMP<NNNN>`` where ``<NNNN>`` is an integer index.  Documentation
-associated with each policy describes the ``OLD`` and ``NEW`` behavior
-and the reason the policy was introduced.  Projects may set each policy
-to select the desired behavior.  When CMake needs to know which behavior
-to use it checks for a setting specified by the project.  If no
-setting is available the ``OLD`` behavior is assumed and a warning is
-produced requesting that the policy be set.
-
-Setting Policies by CMake Version
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-The ``cmake_policy`` command is used to set policies to ``OLD`` or ``NEW``
-behavior.  While setting policies individually is supported, we
-encourage projects to set policies based on CMake versions:
-
-.. code-block:: cmake
-
-  cmake_policy(VERSION <min>[...<max>])
-
-.. versionadded:: 3.12
-  The optional ``<max>`` version.
-
-``<min>`` and the optional ``<max>`` are each CMake versions of the form
-``major.minor[.patch[.tweak]]``, and the ``...`` is literal.  The ``<min>``
-version must be at least ``2.4`` and at most the running version of CMake.
-The ``<max>`` version, if specified, must be at least the ``<min>`` version
-but may exceed the running version of CMake.  If the running version of
-CMake is older than 3.12, the extra ``...`` dots will be seen as version
-component separators, resulting in the ``...<max>`` part being ignored and
-preserving the pre-3.12 behavior of basing policies on ``<min>``.
-
-This specifies that the current CMake code is written for the given
-range of CMake versions.  All policies known to the running version of CMake
-and introduced in the ``<min>`` (or ``<max>``, if specified) version
-or earlier will be set to use ``NEW`` behavior.  All policies
-introduced in later versions will be unset (unless the
-:variable:`CMAKE_POLICY_DEFAULT_CMP<NNNN>` variable sets a default).
-This effectively requests behavior preferred as of a given CMake
-version and tells newer CMake versions to warn about their new policies.
-
-Note that the :command:`cmake_minimum_required(VERSION)`
-command implicitly calls ``cmake_policy(VERSION)`` too.
-
-.. include:: DEPRECATED_POLICY_VERSIONS.txt
-
-Setting Policies Explicitly
-^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-.. code-block:: cmake
-
-  cmake_policy(SET CMP<NNNN> NEW)
-  cmake_policy(SET CMP<NNNN> OLD)
-
-Tell CMake to use the ``OLD`` or ``NEW`` behavior for a given policy.
-Projects depending on the old behavior of a given policy may silence a
-policy warning by setting the policy state to ``OLD``.  Alternatively
-one may fix the project to work with the new behavior and set the
-policy state to ``NEW``.
-
-.. include:: ../policy/DEPRECATED.txt
-
-Checking Policy Settings
-^^^^^^^^^^^^^^^^^^^^^^^^
-
-.. code-block:: cmake
-
-  cmake_policy(GET CMP<NNNN> <variable>)
-
-Check whether a given policy is set to ``OLD`` or ``NEW`` behavior.
-The output ``<variable>`` value will be ``OLD`` or ``NEW`` if the
-policy is set, and empty otherwise.
-
-CMake Policy Stack
-^^^^^^^^^^^^^^^^^^
-
-CMake keeps policy settings on a stack, so changes made by the
-``cmake_policy`` command affect only the top of the stack.  A new entry on
-the policy stack is managed automatically for each subdirectory to
-protect its parents and siblings.  CMake also manages a new entry for
-scripts loaded by :command:`include` and :command:`find_package` commands
-except when invoked with the ``NO_POLICY_SCOPE`` option
-(see also policy :policy:`CMP0011`).
-The ``cmake_policy`` command provides an interface to manage custom
-entries on the policy stack:
-
-.. code-block:: cmake
-
-  cmake_policy(PUSH)
-  cmake_policy(POP)
-
-Each ``PUSH`` must have a matching ``POP`` to erase any changes.
-This is useful to make temporary changes to policy settings.
-Calls to the :command:`cmake_minimum_required(VERSION)`,
-``cmake_policy(VERSION)``, or ``cmake_policy(SET)`` commands
-influence only the current top of the policy stack.
-
-.. versionadded:: 3.25
-  The :command:`block` and :command:`endblock` commands offer a more flexible
-  and more secure way to manage the policy stack. The pop action is done
-  automatically when the :command:`endblock` command is executed, so it avoid
-  to call the :command:`cmake_policy(POP)` command before each
-  :command:`return` command.
-
-  .. code-block:: cmake
-
-    # stack management with cmake_policy()
-    function(my_func)
-      cmake_policy(PUSH)
-      cmake_policy(SET ...)
-      if (<cond1>)
-        ...
-        cmake_policy(POP)
-        return()
-      elseif(<cond2>)
-        ...
-        cmake_policy(POP)
-        return()
-      endif()
-      ...
-      cmake_policy(POP)
-    endfunction()
-
-    # stack management with block()/endblock()
-    function(my_func)
-      block(SCOPE_FOR POLICIES)
-        cmake_policy(SET ...)
-        if (<cond1>)
-          ...
-          return()
-        elseif(<cond2>)
-          ...
-          return()
-        endif()
-        ...
-      endblock()
-    endfunction()
-
-Commands created by the :command:`function` and :command:`macro`
-commands record policy settings when they are created and
-use the pre-record policies when they are invoked.  If the function or
-macro implementation sets policies, the changes automatically
-propagate up through callers until they reach the closest nested
-policy stack entry.
-
-See Also
-^^^^^^^^
-
-* :command:`cmake_minimum_required`

third-party/cmake-3.27.7-linux-x86_64/share/cmake-3.27/Help/command/configure_file.rst

@@ -1,189 +0,0 @@
-configure_file
---------------
-
-Copy a file to another location and modify its contents.
-
-.. code-block:: cmake
-
-  configure_file(<input> <output>
-                 [NO_SOURCE_PERMISSIONS | USE_SOURCE_PERMISSIONS |
-                  FILE_PERMISSIONS <permissions>...]
-                 [COPYONLY] [ESCAPE_QUOTES] [@ONLY]
-                 [NEWLINE_STYLE [UNIX|DOS|WIN32|LF|CRLF] ])
-
-Copies an ``<input>`` file to an ``<output>`` file and substitutes
-variable values referenced as ``@VAR@``, ``${VAR}``, ``$CACHE{VAR}`` or
-``$ENV{VAR}`` in the input file content.  Each variable reference will be
-replaced with the current value of the variable, or the empty string if
-the variable is not defined.  Furthermore, input lines of the form
-
-.. code-block:: c
-
-  #cmakedefine VAR ...
-
-will be replaced with either
-
-.. code-block:: c
-
-  #define VAR ...
-
-or
-
-.. code-block:: c
-
-  /* #undef VAR */
-
-depending on whether ``VAR`` is set in CMake to any value not considered
-a false constant by the :command:`if` command.  The "..." content on the
-line after the variable name, if any, is processed as above.
-
-Unlike lines of the form ``#cmakedefine VAR ...``, in lines of the form
-``#cmakedefine01 VAR``, ``VAR`` itself will expand to ``VAR 0`` or ``VAR 1``
-rather than being assigned the value ``...``. Therefore, input lines of the form
-
-.. code-block:: c
-
-  #cmakedefine01 VAR
-
-will be replaced with either
-
-.. code-block:: c
-
-  #define VAR 0
-
-or
-
-.. code-block:: c
-
-  #define VAR 1
-
-Input lines of the form ``#cmakedefine01 VAR ...`` will expand
-as ``#cmakedefine01 VAR ... 0`` or ``#cmakedefine01 VAR ... 1``,
-which may lead to undefined behavior.
-
-.. versionadded:: 3.10
-  The result lines (with the exception of the ``#undef`` comments) can be
-  indented using spaces and/or tabs between the ``#`` character
-  and the ``cmakedefine`` or ``cmakedefine01`` words. This whitespace
-  indentation will be preserved in the output lines:
-
-  .. code-block:: c
-
-    #  cmakedefine VAR
-    #  cmakedefine01 VAR
-
-  will be replaced, if ``VAR`` is defined, with
-
-  .. code-block:: c
-
-    #  define VAR
-    #  define VAR 1
-
-If the input file is modified the build system will re-run CMake to
-re-configure the file and generate the build system again.
-The generated file is modified and its timestamp updated on subsequent
-cmake runs only if its content is changed.
-
-The arguments are:
-
-``<input>``
-  Path to the input file.  A relative path is treated with respect to
-  the value of :variable:`CMAKE_CURRENT_SOURCE_DIR`.  The input path
-  must be a file, not a directory.
-
-``<output>``
-  Path to the output file or directory.  A relative path is treated
-  with respect to the value of :variable:`CMAKE_CURRENT_BINARY_DIR`.
-  If the path names an existing directory the output file is placed
-  in that directory with the same file name as the input file.
-  If the path contains non-existent directories, they are created.
-
-``NO_SOURCE_PERMISSIONS``
-  .. versionadded:: 3.19
-
-  Do not transfer the permissions of the input file to the output file.
-  The copied file permissions default to the standard 644 value
-  (-rw-r--r--).
-
-``USE_SOURCE_PERMISSIONS``
-  .. versionadded:: 3.20
-
-  Transfer the permissions of the input file to the output file.
-  This is already the default behavior if none of the three permissions-related
-  keywords are given (``NO_SOURCE_PERMISSIONS``, ``USE_SOURCE_PERMISSIONS``
-  or ``FILE_PERMISSIONS``).  The ``USE_SOURCE_PERMISSIONS`` keyword mostly
-  serves as a way of making the intended behavior clearer at the call site.
-
-``FILE_PERMISSIONS <permissions>...``
-  .. versionadded:: 3.20
-
-  Ignore the input file's permissions and use the specified ``<permissions>``
-  for the output file instead.
-
-``COPYONLY``
-  Copy the file without replacing any variable references or other
-  content.  This option may not be used with ``NEWLINE_STYLE``.
-
-``ESCAPE_QUOTES``
-  Escape any substituted quotes with backslashes (C-style).
-
-``@ONLY``
-  Restrict variable replacement to references of the form ``@VAR@``.
-  This is useful for configuring scripts that use ``${VAR}`` syntax.
-
-``NEWLINE_STYLE <style>``
-  Specify the newline style for the output file.  Specify
-  ``UNIX`` or ``LF`` for ``\n`` newlines, or specify
-  ``DOS``, ``WIN32``, or ``CRLF`` for ``\r\n`` newlines.
-  This option may not be used with ``COPYONLY``.
-
-Example
-^^^^^^^
-
-Consider a source tree containing a ``foo.h.in`` file:
-
-.. code-block:: c
-
-  #cmakedefine FOO_ENABLE
-  #cmakedefine FOO_STRING "@FOO_STRING@"
-
-An adjacent ``CMakeLists.txt`` may use ``configure_file`` to
-configure the header:
-
-.. code-block:: cmake
-
-  option(FOO_ENABLE "Enable Foo" ON)
-  if(FOO_ENABLE)
-    set(FOO_STRING "foo")
-  endif()
-  configure_file(foo.h.in foo.h @ONLY)
-
-This creates a ``foo.h`` in the build directory corresponding to
-this source directory.  If the ``FOO_ENABLE`` option is on, the
-configured file will contain:
-
-.. code-block:: c
-
-  #define FOO_ENABLE
-  #define FOO_STRING "foo"
-
-Otherwise it will contain:
-
-.. code-block:: c
-
-  /* #undef FOO_ENABLE */
-  /* #undef FOO_STRING */
-
-One may then use the :command:`target_include_directories` command to
-specify the output directory as an include directory:
-
-.. code-block:: cmake
-
-  target_include_directories(<target> [SYSTEM] <INTERFACE|PUBLIC|PRIVATE> "${CMAKE_CURRENT_BINARY_DIR}")
-
-so that sources may include the header as ``#include <foo.h>``.
-
-See Also
-^^^^^^^^
-
-* :command:`file(GENERATE)`

third-party/cmake-3.27.7-linux-x86_64/share/cmake-3.27/Help/command/continue.rst

@@ -1,16 +0,0 @@
-continue
---------
-
-.. versionadded:: 3.2
-
-Continue to the top of enclosing foreach or while loop.
-
-.. code-block:: cmake
-
-  continue()
-
-The ``continue()`` command allows a cmake script to abort the rest of the
-current iteration of a :command:`foreach` or :command:`while` loop, and start
-at the top of the next iteration.
-
-See also the :command:`break` command.

third-party/cmake-3.27.7-linux-x86_64/share/cmake-3.27/Help/command/create_test_sourcelist.rst

@@ -1,30 +0,0 @@
-create_test_sourcelist
-----------------------
-
-Create a test driver and source list for building test programs.
-
-.. code-block:: cmake
-
-  create_test_sourcelist(sourceListName driverName
-                         test1 test2 test3
-                         EXTRA_INCLUDE include.h
-                         FUNCTION function)
-
-A test driver is a program that links together many small tests into a
-single executable.  This is useful when building static executables
-with large libraries to shrink the total required size.  The list of
-source files needed to build the test driver will be in
-``sourceListName``.  ``driverName`` is the name of the test driver program.
-The rest of the arguments consist of a list of test source files, can
-be semicolon separated.  Each test source file should have a function
-in it that is the same name as the file with no extension (foo.cxx
-should have int foo(int, char*[]);) ``driverName`` will be able to call
-each of the tests by name on the command line.  If ``EXTRA_INCLUDE`` is
-specified, then the next argument is included into the generated file.
-If ``FUNCTION`` is specified, then the next argument is taken as a
-function name that is passed a pointer to ac and av.  This can be used
-to add extra command line processing to each test.  The
-``CMAKE_TESTDRIVER_BEFORE_TESTMAIN`` cmake variable can be set to
-have code that will be placed directly before calling the test main function.
-``CMAKE_TESTDRIVER_AFTER_TESTMAIN`` can be set to have code that
-will be placed directly after the call to the test main function.

third-party/cmake-3.27.7-linux-x86_64/share/cmake-3.27/Help/command/ctest_build.rst

@@ -1,93 +0,0 @@
-ctest_build
------------
-
-Perform the :ref:`CTest Build Step` as a :ref:`Dashboard Client`.
-
-.. code-block:: cmake
-
-  ctest_build([BUILD <build-dir>] [APPEND]
-              [CONFIGURATION <config>]
-              [PARALLEL_LEVEL <parallel>]
-              [FLAGS <flags>]
-              [PROJECT_NAME <project-name>]
-              [TARGET <target-name>]
-              [NUMBER_ERRORS <num-err-var>]
-              [NUMBER_WARNINGS <num-warn-var>]
-              [RETURN_VALUE <result-var>]
-              [CAPTURE_CMAKE_ERROR <result-var>]
-              )
-
-Build the project and store results in ``Build.xml``
-for submission with the :command:`ctest_submit` command.
-
-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 options are:
-
-``BUILD <build-dir>``
-  Specify the top-level build directory.  If not given, the
-  :variable:`CTEST_BINARY_DIRECTORY` variable is used.
-
-``APPEND``
-  Mark ``Build.xml`` for append to results previously submitted to a
-  dashboard server since the last :command:`ctest_start` call.
-  Append semantics are defined by the dashboard server in use.
-  This does *not* cause results to be appended to a ``.xml`` file
-  produced by a previous call to this command.
-
-``CONFIGURATION <config>``
-  Specify the build configuration (e.g. ``Debug``).  If not
-  specified the ``CTEST_BUILD_CONFIGURATION`` variable will be checked.
-  Otherwise the :option:`-C \<cfg\> <ctest -C>` option given to the
-  :manual:`ctest(1)` command will be used, if any.
-
-``PARALLEL_LEVEL <parallel>``
-  .. versionadded:: 3.21
-
-  Specify the parallel level of the underlying build system.  If not
-  specified, the :envvar:`CMAKE_BUILD_PARALLEL_LEVEL` environment
-  variable will be checked.
-
-``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>``
-  Ignored since CMake 3.0.
-
-  .. versionchanged:: 3.14
-    This value is no longer required.
-
-``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.
-
-``CAPTURE_CMAKE_ERROR <result-var>``
-  .. versionadded:: 3.7
-
-  Store in the ``<result-var>`` variable -1 if there are any errors running
-  the command and prevent ctest from returning non-zero if an error occurs.
-
-``QUIET``
-  .. versionadded:: 3.3
-
-  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.

third-party/cmake-3.27.7-linux-x86_64/share/cmake-3.27/Help/command/ctest_configure.rst

@@ -1,50 +0,0 @@
-ctest_configure
----------------
-
-Perform the :ref:`CTest Configure Step` as a :ref:`Dashboard Client`.
-
-.. code-block:: cmake
-
-  ctest_configure([BUILD <build-dir>] [SOURCE <source-dir>] [APPEND]
-                  [OPTIONS <options>] [RETURN_VALUE <result-var>] [QUIET]
-                  [CAPTURE_CMAKE_ERROR <result-var>])
-
-Configure the project build tree and record results in ``Configure.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.
-
-``SOURCE <source-dir>``
-  Specify the source directory.  If not given, the
-  :variable:`CTEST_SOURCE_DIRECTORY` variable is used.
-
-``APPEND``
-  Mark ``Configure.xml`` for append to results previously submitted to a
-  dashboard server since the last :command:`ctest_start` call.
-  Append semantics are defined by the dashboard server in use.
-  This does *not* cause results to be appended to a ``.xml`` file
-  produced by a previous call to this command.
-
-``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.
-
-``CAPTURE_CMAKE_ERROR <result-var>``
-  .. versionadded:: 3.7
-
-  Store in the ``<result-var>`` variable -1 if there are any errors running
-  the command and prevent ctest from returning non-zero if an error occurs.
-
-``QUIET``
-  .. versionadded:: 3.3
-
-  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.

third-party/cmake-3.27.7-linux-x86_64/share/cmake-3.27/Help/command/ctest_coverage.rst

@@ -1,50 +0,0 @@
-ctest_coverage
---------------
-
-Perform the :ref:`CTest Coverage Step` as a :ref:`Dashboard Client`.
-
-.. code-block:: cmake
-
-  ctest_coverage([BUILD <build-dir>] [APPEND]
-                 [LABELS <label>...]
-                 [RETURN_VALUE <result-var>]
-                 [CAPTURE_CMAKE_ERROR <result-var>]
-                 [QUIET]
-                 )
-
-Collect coverage tool results and stores them in ``Coverage.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 ``Coverage.xml`` for append to results previously submitted to a
-  dashboard server since the last :command:`ctest_start` call.
-  Append semantics are defined by the dashboard server in use.
-  This does *not* cause results to be appended to a ``.xml`` file
-  produced by a previous call to this command.
-
-``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.
-
-``CAPTURE_CMAKE_ERROR <result-var>``
-  .. versionadded:: 3.7
-
-  Store in the ``<result-var>`` variable -1 if there are any errors running
-  the command and prevent ctest from returning non-zero if an error occurs.
-
-``QUIET``
-  .. versionadded:: 3.3
-
-  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.

third-party/cmake-3.27.7-linux-x86_64/share/cmake-3.27/Help/command/ctest_empty_binary_directory.rst

@@ -1,12 +0,0 @@
-ctest_empty_binary_directory
-----------------------------
-
-empties the binary directory
-
-.. code-block:: cmake
-
-  ctest_empty_binary_directory(<directory>)
-
-Removes a binary directory.  This command will perform some checks
-prior to deleting the directory in an attempt to avoid malicious or
-accidental directory deletion.

third-party/cmake-3.27.7-linux-x86_64/share/cmake-3.27/Help/command/ctest_memcheck.rst

@@ -1,45 +0,0 @@
-ctest_memcheck
---------------
-
-Perform the :ref:`CTest MemCheck Step` as a :ref:`Dashboard Client`.
-
-.. code-block:: cmake
-
-  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>]
-                 [EXCLUDE_FIXTURE <regex>]
-                 [EXCLUDE_FIXTURE_SETUP <regex>]
-                 [EXCLUDE_FIXTURE_CLEANUP <regex>]
-                 [PARALLEL_LEVEL <level>]
-                 [RESOURCE_SPEC_FILE <file>]
-                 [TEST_LOAD <threshold>]
-                 [SCHEDULE_RANDOM <ON|OFF>]
-                 [STOP_ON_FAILURE]
-                 [STOP_TIME <time-of-day>]
-                 [RETURN_VALUE <result-var>]
-                 [CAPTURE_CMAKE_ERROR <result-var>]
-                 [REPEAT <mode>:<n>]
-                 [OUTPUT_JUNIT <file>]
-                 [DEFECT_COUNT <defect-count-var>]
-                 [QUIET]
-                 )
-
-
-Run tests with a dynamic analysis tool and store results in
-``MemCheck.xml`` for submission with the :command:`ctest_submit`
-command.
-
-Most options are the same as those for the :command:`ctest_test` command.
-
-The options unique to this command are:
-
-``DEFECT_COUNT <defect-count-var>``
-  .. versionadded:: 3.8
-
-  Store in the ``<defect-count-var>`` the number of defects found.

third-party/cmake-3.27.7-linux-x86_64/share/cmake-3.27/Help/command/ctest_read_custom_files.rst

@@ -1,14 +0,0 @@
-ctest_read_custom_files
------------------------
-
-read CTestCustom files.
-
-.. code-block:: cmake
-
-  ctest_read_custom_files(<directory>...)
-
-Read all the CTestCustom.ctest or CTestCustom.cmake files from the
-given directory.
-
-By default, invoking :manual:`ctest(1)` without a script will read custom
-files from the binary directory.

third-party/cmake-3.27.7-linux-x86_64/share/cmake-3.27/Help/command/ctest_run_script.rst

@@ -1,15 +0,0 @@
-ctest_run_script
-----------------
-
-runs a :option:`ctest -S` script
-
-.. code-block:: cmake
-
-  ctest_run_script([NEW_PROCESS] script_file_name script_file_name1
-              script_file_name2 ... [RETURN_VALUE var])
-
-Runs a script or scripts much like if it was run from :option:`ctest -S`.
-If no argument is provided then the current script is run using the current
-settings of the variables.  If ``NEW_PROCESS`` is specified then each
-script will be run in a separate process.If ``RETURN_VALUE`` is specified
-the return value of the last script run will be put into ``var``.

third-party/cmake-3.27.7-linux-x86_64/share/cmake-3.27/Help/command/ctest_sleep.rst

@@ -1,16 +0,0 @@
-ctest_sleep
------------
-
-sleeps for some amount of time
-
-.. code-block:: cmake
-
-  ctest_sleep(<seconds>)
-
-Sleep for given number of seconds.
-
-.. code-block:: cmake
-
-  ctest_sleep(<time1> <duration> <time2>)
-
-Sleep for t=(time1 + duration - time2) seconds if t > 0.

third-party/cmake-3.27.7-linux-x86_64/share/cmake-3.27/Help/command/ctest_start.rst

@@ -1,88 +0,0 @@
-ctest_start
------------
-
-Starts the testing for a given model
-
-.. code-block:: cmake
-
-  ctest_start(<model> [<source> [<binary>]] [GROUP <group>] [QUIET])
-
-  ctest_start([<model> [<source> [<binary>]]] [GROUP <group>] APPEND [QUIET])
-
-Starts the testing for a given model.  The command should be called
-after the binary directory is initialized.
-
-The parameters are as follows:
-
-``<model>``
-  Set the dashboard model. Must be one of ``Experimental``, ``Continuous``, or
-  ``Nightly``. This parameter is required unless ``APPEND`` is specified.
-
-``<source>``
-  Set the source directory. If not specified, the value of
-  :variable:`CTEST_SOURCE_DIRECTORY` is used instead.
-
-``<binary>``
-  Set the binary directory. If not specified, the value of
-  :variable:`CTEST_BINARY_DIRECTORY` is used instead.
-
-``GROUP <group>``
-  If ``GROUP`` is used, the submissions will go to the specified group on the
-  CDash server. If no ``GROUP`` is specified, the name of the model is used by
-  default.
-
-  .. versionchanged:: 3.16
-    This replaces the deprecated option ``TRACK``. Despite the name
-    change its behavior is unchanged.
-
-``APPEND``
-  If ``APPEND`` is used, the existing ``TAG`` is used rather than creating a new
-  one based on the current time stamp. If you use ``APPEND``, you can omit the
-  ``<model>`` and ``GROUP <group>`` parameters, because they will be read from
-  the generated ``TAG`` file. For example:
-
-  .. code-block:: cmake
-
-    ctest_start(Experimental GROUP GroupExperimental)
-
-  Later, in another :option:`ctest -S` script:
-
-  .. code-block:: cmake
-
-    ctest_start(APPEND)
-
-  When the second script runs ``ctest_start(APPEND)``, it will read the
-  ``Experimental`` model and ``GroupExperimental`` group from the ``TAG`` file
-  generated by the first ``ctest_start()`` command. Please note that if you
-  call ``ctest_start(APPEND)`` and specify a different model or group than
-  in the first ``ctest_start()`` command, a warning will be issued, and the
-  new model and group will be used.
-
-``QUIET``
-  .. versionadded:: 3.3
-
-  If ``QUIET`` is used, CTest will suppress any non-error messages that it
-  otherwise would have printed to the console.
-
-The parameters for ``ctest_start()`` can be issued in any order, with the
-exception that ``<model>``, ``<source>``, and ``<binary>`` have to appear
-in that order with respect to each other. The following are all valid and
-equivalent:
-
-.. code-block:: cmake
-
-  ctest_start(Experimental path/to/source path/to/binary GROUP SomeGroup QUIET APPEND)
-
-  ctest_start(GROUP SomeGroup Experimental QUIET path/to/source APPEND path/to/binary)
-
-  ctest_start(APPEND QUIET Experimental path/to/source GROUP SomeGroup path/to/binary)
-
-However, for the sake of readability, it is recommended that you order your
-parameters in the order listed at the top of this page.
-
-If the :variable:`CTEST_CHECKOUT_COMMAND` variable (or the
-:variable:`CTEST_CVS_CHECKOUT` variable) is set, its content is treated as
-command-line.  The command is invoked with the current working directory set
-to the parent of the source directory, even if the source directory already
-exists.  This can be used to create the source tree from a version control
-repository.

third-party/cmake-3.27.7-linux-x86_64/share/cmake-3.27/Help/command/ctest_submit.rst

@@ -1,131 +0,0 @@
-ctest_submit
-------------
-
-Perform the :ref:`CTest Submit Step` as a :ref:`Dashboard Client`.
-
-.. code-block:: cmake
-
-  ctest_submit([PARTS <part>...] [FILES <file>...]
-               [SUBMIT_URL <url>]
-               [BUILD_ID <result-var>]
-               [HTTPHEADER <header>]
-               [RETRY_COUNT <count>]
-               [RETRY_DELAY <delay>]
-               [RETURN_VALUE <result-var>]
-               [CAPTURE_CMAKE_ERROR <result-var>]
-               [QUIET]
-               )
-
-Submit results to a dashboard server.
-By default all available parts are submitted.
-
-The options are:
-
-``PARTS <part>...``
-  Specify a subset of parts to submit.  Valid part names are::
-
-    Start      = nothing
-    Update     = ctest_update results, in Update.xml
-    Configure  = ctest_configure results, in Configure.xml
-    Build      = ctest_build results, in Build.xml
-    Test       = ctest_test results, in Test.xml
-    Coverage   = ctest_coverage results, in Coverage.xml
-    MemCheck   = ctest_memcheck results, in DynamicAnalysis.xml and
-                 DynamicAnalysis-Test.xml
-    Notes      = Files listed by CTEST_NOTES_FILES, in Notes.xml
-    ExtraFiles = Files listed by CTEST_EXTRA_SUBMIT_FILES
-    Upload     = Files prepared for upload by ctest_upload(), in Upload.xml
-    Submit     = nothing
-    Done       = Build is complete, in Done.xml
-
-``FILES <file>...``
-  Specify an explicit list of specific files to be submitted.
-  Each individual file must exist at the time of the call.
-
-``SUBMIT_URL <url>``
-  .. versionadded:: 3.14
-
-  The ``http`` or ``https`` URL of the dashboard server to send the submission
-  to.  If not given, the :variable:`CTEST_SUBMIT_URL` variable is used.
-
-``BUILD_ID <result-var>``
-  .. versionadded:: 3.15
-
-  Store in the ``<result-var>`` variable the ID assigned to this build by
-  CDash.
-
-``HTTPHEADER <HTTP-header>``
-  .. versionadded:: 3.9
-
-  Specify HTTP header to be included in the request to CDash during submission.
-  For example, CDash can be configured to only accept submissions from
-  authenticated clients. In this case, you should provide a bearer token in your
-  header:
-
-  .. code-block:: cmake
-
-    ctest_submit(HTTPHEADER "Authorization: Bearer <auth-token>")
-
-  This suboption can be repeated several times for multiple headers.
-
-``RETRY_COUNT <count>``
-  Specify how many times to retry a timed-out submission.
-
-``RETRY_DELAY <delay>``
-  Specify how long (in seconds) to wait after a timed-out submission
-  before attempting to re-submit.
-
-``RETURN_VALUE <result-var>``
-  Store in the ``<result-var>`` variable ``0`` for success and
-  non-zero on failure.
-
-``CAPTURE_CMAKE_ERROR <result-var>``
-  .. versionadded:: 3.13
-
-  Store in the ``<result-var>`` variable -1 if there are any errors running
-  the command and prevent ctest from returning non-zero if an error occurs.
-
-``QUIET``
-  .. versionadded:: 3.3
-
-  Suppress all non-error messages that would have otherwise been
-  printed to the console.
-
-Submit to CDash Upload API
-^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-.. versionadded:: 3.2
-
-.. code-block:: cmake
-
-  ctest_submit(CDASH_UPLOAD <file> [CDASH_UPLOAD_TYPE <type>]
-               [SUBMIT_URL <url>]
-               [BUILD_ID <result-var>]
-               [HTTPHEADER <header>]
-               [RETRY_COUNT <count>]
-               [RETRY_DELAY <delay>]
-               [RETURN_VALUE <result-var>]
-               [QUIET])
-
-This second signature is used to upload files to CDash via the CDash
-file upload API. The API first sends a request to upload to CDash along
-with a content hash of the file. If CDash does not already have the file,
-then it is uploaded. Along with the file, a CDash type string is specified
-to tell CDash which handler to use to process the data.
-
-This signature interprets options in the same way as the first one.
-
-.. versionadded:: 3.8
-  Added the ``RETRY_COUNT``, ``RETRY_DELAY``, ``QUIET`` options.
-
-.. versionadded:: 3.9
-  Added the ``HTTPHEADER`` option.
-
-.. versionadded:: 3.13
-  Added the ``RETURN_VALUE`` option.
-
-.. versionadded:: 3.14
-  Added the ``SUBMIT_URL`` option.
-
-.. versionadded:: 3.15
-  Added the ``BUILD_ID`` option.

third-party/cmake-3.27.7-linux-x86_64/share/cmake-3.27/Help/command/ctest_test.rst

@@ -1,312 +0,0 @@
-ctest_test
-----------
-
-Perform the :ref:`CTest Test Step` as a :ref:`Dashboard Client`.
-
-.. code-block:: cmake
-
-  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>]
-             [EXCLUDE_FIXTURE <regex>]
-             [EXCLUDE_FIXTURE_SETUP <regex>]
-             [EXCLUDE_FIXTURE_CLEANUP <regex>]
-             [PARALLEL_LEVEL <level>]
-             [RESOURCE_SPEC_FILE <file>]
-             [TEST_LOAD <threshold>]
-             [SCHEDULE_RANDOM <ON|OFF>]
-             [STOP_ON_FAILURE]
-             [STOP_TIME <time-of-day>]
-             [RETURN_VALUE <result-var>]
-             [CAPTURE_CMAKE_ERROR <result-var>]
-             [REPEAT <mode>:<n>]
-             [OUTPUT_JUNIT <file>]
-             [QUIET]
-             )
-
-..
-   NOTE If updating the argument list here, please also update the argument
-   list documentation for :command:`ctest_memcheck` as well.
-
-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 ``Test.xml`` for append to results previously submitted to a
-  dashboard server since the last :command:`ctest_start` call.
-  Append semantics are defined by the dashboard server in use.
-  This does *not* cause results to be appended to a ``.xml`` file
-  produced by a previous call to this command.
-
-``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 across 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.
-
-``EXCLUDE_FIXTURE <regex>``
-  .. versionadded:: 3.7
-
-  If a test in the set of tests to be executed requires a particular fixture,
-  that fixture's setup and cleanup tests would normally be added to the test
-  set automatically. This option prevents adding setup or cleanup tests for
-  fixtures matching the ``<regex>``. Note that all other fixture behavior is
-  retained, including test dependencies and skipping tests that have fixture
-  setup tests that fail.
-
-``EXCLUDE_FIXTURE_SETUP <regex>``
-  .. versionadded:: 3.7
-
-  Same as ``EXCLUDE_FIXTURE`` except only matching setup tests are excluded.
-
-``EXCLUDE_FIXTURE_CLEANUP <regex>``
-  .. versionadded:: 3.7
-
-  Same as ``EXCLUDE_FIXTURE`` except only matching cleanup tests are excluded.
-
-``PARALLEL_LEVEL <level>``
-  Specify a positive number representing the number of tests to
-  be run in parallel.
-
-``RESOURCE_SPEC_FILE <file>``
-  .. versionadded:: 3.16
-
-  Specify a
-  :ref:`resource specification file <ctest-resource-specification-file>`. See
-  :ref:`ctest-resource-allocation` for more information.
-
-``TEST_LOAD <threshold>``
-  .. versionadded:: 3.4
-
-  While running tests in parallel, try not to start tests when they
-  may cause the CPU load to pass above a given threshold.  If not
-  specified the :variable:`CTEST_TEST_LOAD` variable will be checked,
-  and then the :option:`--test-load <ctest --test-load>` command-line
-  argument to :manual:`ctest(1)`. See also the ``TestLoad`` setting
-  in the :ref:`CTest Test Step`.
-
-``REPEAT <mode>:<n>``
-  .. versionadded:: 3.17
-
-  Run tests repeatedly based on the given ``<mode>`` up to ``<n>`` times.
-  The modes are:
-
-  ``UNTIL_FAIL``
-    Require each test to run ``<n>`` times without failing in order to pass.
-    This is useful in finding sporadic failures in test cases.
-
-  ``UNTIL_PASS``
-    Allow each test to run up to ``<n>`` times in order to pass.
-    Repeats tests if they fail for any reason.
-    This is useful in tolerating sporadic failures in test cases.
-
-  ``AFTER_TIMEOUT``
-    Allow each test to run up to ``<n>`` times in order to pass.
-    Repeats tests only if they timeout.
-    This is useful in tolerating sporadic timeouts in test cases
-    on busy machines.
-
-``SCHEDULE_RANDOM <ON|OFF>``
-  Launch tests in a random order.  This may be useful for detecting
-  implicit test dependencies.
-
-``STOP_ON_FAILURE``
-  .. versionadded:: 3.18
-
-  Stop the execution of the tests once one has failed.
-
-``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.
-
-``CAPTURE_CMAKE_ERROR <result-var>``
-  .. versionadded:: 3.7
-
-  Store in the ``<result-var>`` variable -1 if there are any errors running
-  the command and prevent ctest from returning non-zero if an error occurs.
-
-``OUTPUT_JUNIT <file>``
-  .. versionadded:: 3.21
-
-  Write test results to ``<file>`` in JUnit XML format. If ``<file>`` is a
-  relative path, it will be placed in the build directory. If ``<file>``
-  already exists, it will be overwritten. Note that the resulting JUnit XML
-  file is **not** uploaded to CDash because it would be redundant with
-  CTest's ``Test.xml`` file.
-
-``QUIET``
-  .. versionadded:: 3.3
-
-  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.
-
-See also the :variable:`CTEST_CUSTOM_MAXIMUM_PASSED_TEST_OUTPUT_SIZE`,
-:variable:`CTEST_CUSTOM_MAXIMUM_FAILED_TEST_OUTPUT_SIZE` and
-:variable:`CTEST_CUSTOM_TEST_OUTPUT_TRUNCATION` variables, along with their
-corresponding :manual:`ctest(1)` command line options
-:option:`--test-output-size-passed <ctest --test-output-size-passed>`,
-:option:`--test-output-size-failed <ctest --test-output-size-failed>`, and
-:option:`--test-output-truncation <ctest --test-output-truncation>`.
-
-.. _`Additional Test Measurements`:
-
-Additional Test Measurements
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-CTest can parse the output of your tests for extra measurements to report
-to CDash.
-
-When run as a :ref:`Dashboard Client`, CTest will include these custom
-measurements in the ``Test.xml`` file that gets uploaded to CDash.
-
-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
-  CTest can parse custom measurements from tags named
-  ``<CTestMeasurement>`` or ``<CTestMeasurementFile>``. The older names
-  ``<DartMeasurement>`` and ``<DartMeasurementFile>`` are still supported.
-
-The following example demonstrates how to output a variety of custom test
-measurements.
-
-.. code-block:: c++
-
-   std::cout <<
-     "<CTestMeasurement type=\"numeric/double\" name=\"score\">28.3</CTestMeasurement>"
-     << std::endl;
-
-   std::cout <<
-     "<CTestMeasurement type=\"text/string\" name=\"color\">red</CTestMeasurement>"
-     << std::endl;
-
-   std::cout <<
-     "<CTestMeasurement type=\"text/link\" name=\"CMake URL\">https://cmake.org</CTestMeasurement>"
-     << std::endl;
-
-   std::cout <<
-     "<CTestMeasurement type=\"text/preformatted\" name=\"Console Output\">" <<
-     "line 1.\n" <<
-     "  \033[31;1m line 2. Bold red, and indented!\033[0;0ml\n" <<
-     "line 3. Not bold or indented...\n" <<
-     "</CTestMeasurement>" << std::endl;
-
-Image Measurements
-""""""""""""""""""
-
-The following example demonstrates how to upload test images to CDash.
-
-.. code-block:: c++
-
-   std::cout <<
-     "<CTestMeasurementFile type=\"image/jpg\" name=\"TestImage\">" <<
-     "/dir/to/test_img.jpg</CTestMeasurementFile>" << std::endl;
-
-   std::cout <<
-     "<CTestMeasurementFile type=\"image/gif\" name=\"ValidImage\">" <<
-     "/dir/to/valid_img.gif</CTestMeasurementFile>" << std::endl;
-
-   std::cout <<
-     "<CTestMeasurementFile type=\"image/png\" name=\"AlgoResult\">" <<
-     "/dir/to/img.png</CTestMeasurementFile>"
-     << std::endl;
-
-Images will be displayed together in an interactive comparison mode on CDash
-if they are provided with two or more of the following names.
-
-* ``TestImage``
-* ``ValidImage``
-* ``BaselineImage``
-* ``DifferenceImage2``
-
-By convention, ``TestImage`` is the image generated by your test, and
-``ValidImage`` (or ``BaselineImage``) is basis of comparison used to determine
-if the test passed or failed.
-
-If another image name is used it will be displayed by CDash as a static image
-separate from the interactive comparison UI.
-
-Attached Files
-""""""""""""""
-
-.. versionadded:: 3.21
-
-The following example demonstrates how to upload non-image files to CDash.
-
-.. code-block:: c++
-
-   std::cout <<
-     "<CTestMeasurementFile type=\"file\" name=\"TestInputData1\">" <<
-     "/dir/to/data1.csv</CTestMeasurementFile>\n"                   <<
-     "<CTestMeasurementFile type=\"file\" name=\"TestInputData2\">" <<
-     "/dir/to/data2.csv</CTestMeasurementFile>"                     << std::endl;
-
-If the name of the file to upload is known at configure time, you can use the
-:prop_test:`ATTACHED_FILES` or :prop_test:`ATTACHED_FILES_ON_FAIL` test
-properties instead.
-
-Custom Details
-""""""""""""""
-
-.. versionadded:: 3.21
-
-The following example demonstrates how to specify a custom value for the
-``Test Details`` field displayed on CDash.
-
-.. code-block:: c++
-
-   std::cout <<
-     "<CTestDetails>My Custom Details Value</CTestDetails>" << std::endl;
-
-.. _`Additional Labels`:
-
-Additional Labels
-"""""""""""""""""
-
-.. versionadded:: 3.22
-
-The following example demonstrates how to add additional labels to a test
-at runtime.
-
-.. code-block:: c++
-
-   std::cout <<
-     "<CTestLabel>Custom Label 1</CTestLabel>\n" <<
-     "<CTestLabel>Custom Label 2</CTestLabel>"   << std::endl;
-
-Use the :prop_test:`LABELS` test property instead for labels that can be
-determined at configure time.

third-party/cmake-3.27.7-linux-x86_64/share/cmake-3.27/Help/command/ctest_update.rst

@@ -1,43 +0,0 @@
-ctest_update
-------------
-
-Perform the :ref:`CTest Update Step` as a :ref:`Dashboard Client`.
-
-.. code-block:: cmake
-
-  ctest_update([SOURCE <source-dir>]
-               [RETURN_VALUE <result-var>]
-               [CAPTURE_CMAKE_ERROR <result-var>]
-               [QUIET])
-
-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.
-
-``CAPTURE_CMAKE_ERROR <result-var>``
-  .. versionadded:: 3.13
-
-  Store in the ``<result-var>`` variable -1 if there are any errors running
-  the command and prevent ctest from returning non-zero if an error occurs.
-
-``QUIET``
-  .. versionadded:: 3.3
-
-  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.
-
-The update always follows the version control branch currently checked
-out in the source directory.  See the :ref:`CTest Update Step`
-documentation for information about variables that change the behavior
-of ``ctest_update()``.

third-party/cmake-3.27.7-linux-x86_64/share/cmake-3.27/Help/command/ctest_upload.rst

@@ -1,26 +0,0 @@
-ctest_upload
-------------
-
-Upload files to a dashboard server as a :ref:`Dashboard Client`.
-
-.. code-block:: cmake
-
-  ctest_upload(FILES <file>... [QUIET] [CAPTURE_CMAKE_ERROR <result-var>])
-
-The options are:
-
-``FILES <file>...``
-  Specify a list of files to be sent along with the build results to the
-  dashboard server.
-
-``QUIET``
-  .. versionadded:: 3.3
-
-  Suppress any CTest-specific non-error output that would have been
-  printed to the console otherwise.
-
-``CAPTURE_CMAKE_ERROR <result-var>``
-  .. versionadded:: 3.7
-
-  Store in the ``<result-var>`` variable -1 if there are any errors running
-  the command and prevent ctest from returning non-zero if an error occurs.

third-party/cmake-3.27.7-linux-x86_64/share/cmake-3.27/Help/command/define_property.rst

@@ -1,81 +0,0 @@
-define_property
----------------
-
-Define and document custom properties.
-
-.. code-block:: cmake
-
-  define_property(<GLOBAL | DIRECTORY | TARGET | SOURCE |
-                   TEST | VARIABLE | CACHED_VARIABLE>
-                   PROPERTY <name> [INHERITED]
-                   [BRIEF_DOCS <brief-doc> [docs...]]
-                   [FULL_DOCS <full-doc> [docs...]]
-                   [INITIALIZE_FROM_VARIABLE <variable>])
-
-Defines one property in a scope for use with the :command:`set_property` and
-:command:`get_property` commands. It is mainly useful for defining the way
-a property is initialized or inherited. Historically, the command also
-associated documentation with a property, but that is no longer considered a
-primary use case.
-
-The first argument determines the kind of scope in which the property should
-be used.  It must be one of the following:
-
-::
-
-  GLOBAL    = associated with the global namespace
-  DIRECTORY = associated with one directory
-  TARGET    = associated with one target
-  SOURCE    = associated with one source file
-  TEST      = associated with a test named with add_test
-  VARIABLE  = documents a CMake language variable
-  CACHED_VARIABLE = documents a CMake cache variable
-
-Note that unlike :command:`set_property` and :command:`get_property` no
-actual scope needs to be given; only the kind of scope is important.
-
-The required ``PROPERTY`` option is immediately followed by the name of
-the property being defined.
-
-If the ``INHERITED`` option is given, then the :command:`get_property` command
-will chain up to the next higher scope when the requested property is not set
-in the scope given to the command.
-
-* ``DIRECTORY`` scope chains to its parent directory's scope, continuing the
-  walk up parent directories until a directory has the property set or there
-  are no more parents.  If still not found at the top level directory, it
-  chains to the ``GLOBAL`` scope.
-* ``TARGET``, ``SOURCE`` and ``TEST`` properties chain to ``DIRECTORY`` scope,
-  including further chaining up the directories, etc. as needed.
-
-Note that this scope chaining behavior only applies to calls to
-:command:`get_property`, :command:`get_directory_property`,
-:command:`get_target_property`, :command:`get_source_file_property` and
-:command:`get_test_property`.  There is no inheriting behavior when *setting*
-properties, so using ``APPEND`` or ``APPEND_STRING`` with the
-:command:`set_property` command will not consider inherited values when working
-out the contents to append to.
-
-The ``BRIEF_DOCS`` and ``FULL_DOCS`` options are followed by strings to be
-associated with the property as its brief and full documentation.
-CMake does not use this documentation other than making it available to the
-project via corresponding options to the :command:`get_property` command.
-
-.. versionchanged:: 3.23
-
-  The ``BRIEF_DOCS`` and ``FULL_DOCS`` options are optional.
-
-.. versionadded:: 3.23
-
-  The ``INITIALIZE_FROM_VARIABLE`` option specifies a variable from which the
-  property should be initialized. It can only be used with target properties.
-  The ``<variable>`` name must end with the property name and must not begin
-  with ``CMAKE_`` or ``_CMAKE_``. The property name must contain at least one
-  underscore. It is recommended that the property name have a prefix specific
-  to the project.
-
-See Also
-^^^^^^^^
-
-* :command:`get_property`
-* :command:`set_property`

third-party/cmake-3.27.7-linux-x86_64/share/cmake-3.27/Help/command/else.rst

@@ -1,10 +0,0 @@
-else
-----
-
-Starts the else portion of an if block.
-
-.. code-block:: cmake
-
-  else([<condition>])
-
-See the :command:`if` command.

third-party/cmake-3.27.7-linux-x86_64/share/cmake-3.27/Help/command/elseif.rst

@@ -1,11 +0,0 @@
-elseif
-------
-
-Starts an elseif portion of an if block.
-
-.. code-block:: cmake
-
-  elseif(<condition>)
-
-See the :command:`if` command, especially for the syntax and logic
-of the ``<condition>``.

third-party/cmake-3.27.7-linux-x86_64/share/cmake-3.27/Help/command/enable_language.rst

@@ -1,24 +0,0 @@
-enable_language
----------------
-
-Enable languages (CXX/C/OBJC/OBJCXX/Fortran/etc)
-
-.. code-block:: cmake
-
-  enable_language(<lang>... [OPTIONAL])
-
-Enables support for the named languages in CMake.  This is the same as
-the :command:`project` command but does not create any of the extra
-variables that are created by the project command.
-
-.. include:: SUPPORTED_LANGUAGES.txt
-
-This command must be called in file scope, not in a function call.
-Furthermore, it must be called in the highest directory common to all
-targets using the named language directly for compiling sources or
-indirectly through link dependencies.  It is simplest to enable all
-needed languages in the top-level directory of a project.
-
-The ``OPTIONAL`` keyword is a placeholder for future implementation and
-does not currently work. Instead you can use the :module:`CheckLanguage`
-module to verify support before enabling.

third-party/cmake-3.27.7-linux-x86_64/share/cmake-3.27/Help/command/enable_testing.rst

@@ -1,20 +0,0 @@
-enable_testing
---------------
-
-Enable testing for current directory and below.
-
-.. code-block:: cmake
-
-  enable_testing()
-
-Enables testing for this directory and below.
-
-This command should be in the source directory root
-because ctest expects to find a test file in the build
-directory root.
-
-This command is automatically invoked when the :module:`CTest`
-module is included, except if the ``BUILD_TESTING`` option is
-turned off.
-
-See also the :command:`add_test` command.

third-party/cmake-3.27.7-linux-x86_64/share/cmake-3.27/Help/command/endblock.rst

@@ -1,11 +0,0 @@
-endblock
---------
-
-.. versionadded:: 3.25
-
-Ends a list of commands in a :command:`block` and removes the scopes
-created by the :command:`block` command.
-
-.. code-block:: cmake
-
-  endblock()

third-party/cmake-3.27.7-linux-x86_64/share/cmake-3.27/Help/command/endforeach.rst

@@ -1,14 +0,0 @@
-endforeach
-----------
-
-Ends a list of commands in a foreach block.
-
-.. code-block:: cmake
-
-  endforeach([<loop_var>])
-
-See the :command:`foreach` command.
-
-The optional ``<loop_var>`` argument is supported for backward compatibility
-only. If used it must be a verbatim repeat of the ``<loop_var>`` argument of
-the opening ``foreach`` clause.

third-party/cmake-3.27.7-linux-x86_64/share/cmake-3.27/Help/command/endfunction.rst

@@ -1,14 +0,0 @@
-endfunction
------------
-
-Ends a list of commands in a function block.
-
-.. code-block:: cmake
-
-  endfunction([<name>])
-
-See the :command:`function` command.
-
-The optional ``<name>`` argument is supported for backward compatibility
-only. If used it must be a verbatim repeat of the ``<name>`` argument
-of the opening ``function`` command.

third-party/cmake-3.27.7-linux-x86_64/share/cmake-3.27/Help/command/endif.rst

@@ -1,14 +0,0 @@
-endif
------
-
-Ends a list of commands in an if block.
-
-.. code-block:: cmake
-
-  endif([<condition>])
-
-See the :command:`if` command.
-
-The optional ``<condition>`` argument is supported for backward compatibility
-only. If used it must be a verbatim repeat of the argument of the opening
-``if`` clause.

third-party/cmake-3.27.7-linux-x86_64/share/cmake-3.27/Help/command/endmacro.rst

@@ -1,14 +0,0 @@
-endmacro
---------
-
-Ends a list of commands in a macro block.
-
-.. code-block:: cmake
-
-  endmacro([<name>])
-
-See the :command:`macro` command.
-
-The optional ``<name>`` argument is supported for backward compatibility
-only. If used it must be a verbatim repeat of the ``<name>`` argument
-of the opening ``macro`` command.

third-party/cmake-3.27.7-linux-x86_64/share/cmake-3.27/Help/command/endwhile.rst

@@ -1,14 +0,0 @@
-endwhile
---------
-
-Ends a list of commands in a while block.
-
-.. code-block:: cmake
-
-  endwhile([<condition>])
-
-See the :command:`while` command.
-
-The optional ``<condition>`` argument is supported for backward compatibility
-only. If used it must be a verbatim repeat of the argument of the opening
-``while`` clause.

third-party/cmake-3.27.7-linux-x86_64/share/cmake-3.27/Help/command/exec_program.rst

@@ -1,26 +0,0 @@
-exec_program
-------------
-
-.. deprecated:: 3.0
-
-  Use the :command:`execute_process` command instead.
-
-Run an executable program during the processing of the CMakeList.txt
-file.
-
-.. code-block:: cmake
-
-  exec_program(Executable [directory in which to run]
-               [ARGS <arguments to executable>]
-               [OUTPUT_VARIABLE <var>]
-               [RETURN_VALUE <var>])
-
-The executable is run in the optionally specified directory.  The
-executable can include arguments if it is double quoted, but it is
-better to use the optional ``ARGS`` argument to specify arguments to the
-program.  This is because cmake will then be able to escape spaces in
-the executable path.  An optional argument ``OUTPUT_VARIABLE`` specifies a
-variable in which to store the output.  To capture the return value of
-the execution, provide a ``RETURN_VALUE``.  If ``OUTPUT_VARIABLE`` is
-specified, then no output will go to the stdout/stderr of the console
-running cmake.

third-party/cmake-3.27.7-linux-x86_64/share/cmake-3.27/Help/command/execute_process.rst

@@ -1,171 +0,0 @@
-execute_process
----------------
-
-Execute one or more child processes.
-
-.. code-block:: cmake
-
-  execute_process(COMMAND <cmd1> [<arguments>]
-                  [COMMAND <cmd2> [<arguments>]]...
-                  [WORKING_DIRECTORY <directory>]
-                  [TIMEOUT <seconds>]
-                  [RESULT_VARIABLE <variable>]
-                  [RESULTS_VARIABLE <variable>]
-                  [OUTPUT_VARIABLE <variable>]
-                  [ERROR_VARIABLE <variable>]
-                  [INPUT_FILE <file>]
-                  [OUTPUT_FILE <file>]
-                  [ERROR_FILE <file>]
-                  [OUTPUT_QUIET]
-                  [ERROR_QUIET]
-                  [COMMAND_ECHO <where>]
-                  [OUTPUT_STRIP_TRAILING_WHITESPACE]
-                  [ERROR_STRIP_TRAILING_WHITESPACE]
-                  [ENCODING <name>]
-                  [ECHO_OUTPUT_VARIABLE]
-                  [ECHO_ERROR_VARIABLE]
-                  [COMMAND_ERROR_IS_FATAL <ANY|LAST>])
-
-Runs the given sequence of one or more commands.
-
-Commands are executed concurrently as a pipeline, with the standard
-output of each process piped to the standard input of the next.
-A single standard error pipe is used for all processes.
-
-``execute_process`` runs commands while CMake is configuring the project,
-prior to build system generation.  Use the :command:`add_custom_target` and
-:command:`add_custom_command` commands to create custom commands that run
-at build time.
-
-Options:
-
-``COMMAND``
- A child process command line.
-
- CMake executes the child process using operating system APIs directly:
-
- * On POSIX platforms, the command line is passed to the
-   child process in an ``argv[]`` style array.
-
- * On Windows platforms, the command line is encoded as a string such
-   that child processes using ``CommandLineToArgvW`` will decode the
-   original arguments.
-
- No intermediate shell is used, so shell operators such as ``>``
- are treated as normal arguments.
- (Use the ``INPUT_*``, ``OUTPUT_*``, and ``ERROR_*`` options to
- redirect stdin, stdout, and stderr.)
-
- For **sequential execution** of multiple commands use multiple
- ``execute_process`` calls each with a single ``COMMAND`` argument.
-
-``WORKING_DIRECTORY``
- The named directory will be set as the current working directory of
- the child processes.
-
-``TIMEOUT``
- After the specified number of seconds (fractions allowed), all unfinished
- child processes will be terminated, and the ``RESULT_VARIABLE`` will be
- set to a string mentioning the "timeout".
-
-``RESULT_VARIABLE``
- The variable will be set to contain the result of last child process.
- This will be an integer return code from the last child or a string
- describing an error condition.
-
-``RESULTS_VARIABLE <variable>``
- .. versionadded:: 3.10
-
- The variable will be set to contain the result of all processes as a
- :ref:`semicolon-separated list <CMake Language Lists>`, in order of the
- given ``COMMAND`` arguments.  Each entry will be an integer return code
- from the corresponding child or a string describing an error condition.
-
-``INPUT_FILE <file>``
- ``<file>`` is attached to the standard input pipe of the *first* ``COMMAND``
- process.
-
-``OUTPUT_FILE <file>``
- ``<file>`` is attached to the standard output pipe of the *last* ``COMMAND``
- process.
-
-``ERROR_FILE <file>``
- ``<file>`` is attached to the standard error pipe of *all* ``COMMAND``
- processes.
-
-.. versionadded:: 3.3
-  If the same ``<file>`` is named for both ``OUTPUT_FILE`` and ``ERROR_FILE``
-  then it will be used for both standard output and standard error pipes.
-
-``OUTPUT_QUIET``, ``ERROR_QUIET``
- The standard output on ``OUTPUT_VARIABLE`` or standard error on
- ``ERROR_VARIABLE`` are not connected (no variable content).
- The  ``*_FILE`` and ``ECHO_*_VARIABLE`` options are not affected.
-
-``OUTPUT_VARIABLE``, ``ERROR_VARIABLE``
- The variable named will be set with the contents of the standard output
- and standard error pipes, respectively.  If the same variable is named
- for both pipes their output will be merged in the order produced.
-
-``ECHO_OUTPUT_VARIABLE``, ``ECHO_ERROR_VARIABLE``
-  .. versionadded:: 3.18
-
-  The standard output or standard error will not be exclusively redirected to
-  the specified variables.
-
-  The output will be duplicated into the specified variables and also onto
-  standard output or standard error analogous to the ``tee`` Unix command.
-
-.. note::
-  If more than one ``OUTPUT_*`` or ``ERROR_*`` option is given for the
-  same pipe the precedence is *not specified*.
-  If no ``OUTPUT_*`` or ``ERROR_*`` options are given the output will
-  be shared with the corresponding pipes of the CMake process itself.
-
-``COMMAND_ECHO <where>``
- .. versionadded:: 3.15
-
- The command being run will be echo'ed to ``<where>`` with ``<where>``
- being set to one of ``STDERR``, ``STDOUT`` or ``NONE``.
- See the :variable:`CMAKE_EXECUTE_PROCESS_COMMAND_ECHO` variable for a way
- to control the default behavior when this option is not present.
-
-``ENCODING <name>``
- .. versionadded:: 3.8
-
- On Windows, the encoding that is used to decode output from the process.
- Ignored on other platforms.
- Valid encoding names are:
-
- ``NONE``
-   Perform no decoding.  This assumes that the process output is encoded
-   in the same way as CMake's internal encoding (UTF-8).
-   This is the default.
- ``AUTO``
-   Use the current active console's codepage or if that isn't
-   available then use ANSI.
- ``ANSI``
-   Use the ANSI codepage.
- ``OEM``
-   Use the original equipment manufacturer (OEM) code page.
- ``UTF8`` or ``UTF-8``
-   Use the UTF-8 codepage.
-
-   .. versionadded:: 3.11
-     Accept ``UTF-8`` spelling for consistency with the
-     `UTF-8 RFC <https://www.ietf.org/rfc/rfc3629>`_ naming convention.
-
-``COMMAND_ERROR_IS_FATAL <ANY|LAST>``
-  .. versionadded:: 3.19
-
-  The option following ``COMMAND_ERROR_IS_FATAL`` determines the behavior when
-  an error is encountered:
-
-    ``ANY``
-    If any of the commands in the list of commands fail, the
-    ``execute_process()`` command halts with an error.
-
-    ``LAST``
-    If the last command in the list of commands fails, the
-    ``execute_process()`` command halts with an error.  Commands earlier in the
-    list will not cause a fatal error.

third-party/cmake-3.27.7-linux-x86_64/share/cmake-3.27/Help/command/export.rst

@@ -1,154 +0,0 @@
-export
-------
-
-Export targets or packages for outside projects to use them directly
-from the current project's build tree, without installation.
-
-See the :command:`install(EXPORT)` command to export targets from an
-install tree.
-
-Synopsis
-^^^^^^^^
-
-.. parsed-literal::
-
-  export(`TARGETS`_ <target>... [...])
-  export(`EXPORT`_ <export-name> [...])
-  export(`PACKAGE`_ <PackageName>)
-
-Exporting Targets
-^^^^^^^^^^^^^^^^^
-
-.. _`export(TARGETS)`:
-.. _TARGETS:
-
-.. code-block:: cmake
-
-  export(TARGETS <target>... [NAMESPACE <namespace>]
-         [APPEND] FILE <filename> [EXPORT_LINK_INTERFACE_LIBRARIES]
-         [CXX_MODULES_DIRECTORY <directory>])
-
-Creates a file ``<filename>`` that may be included by outside projects to
-import targets named by ``<target>...`` from the current project's build tree.
-This is useful during cross-compiling to build utility executables that can
-run on the host platform in one project and then import them into another
-project being compiled for the target platform.
-
-The file created by this command is specific to the build tree and
-should never be installed.  See the :command:`install(EXPORT)` command to
-export targets from an install tree.
-
-The options are:
-
-``NAMESPACE <namespace>``
-  Prepend the ``<namespace>`` string to all target names written to the file.
-
-``APPEND``
-  Append to the file instead of overwriting it.  This can be used to
-  incrementally export multiple targets to the same file.
-
-``EXPORT_LINK_INTERFACE_LIBRARIES``
-  Include the contents of the properties named with the pattern
-  ``(IMPORTED_)?LINK_INTERFACE_LIBRARIES(_<CONFIG>)?``
-  in the export, even when policy :policy:`CMP0022` is NEW.  This is useful
-  to support consumers using CMake versions older than 2.8.12.
-
-``CXX_MODULES_DIRECTORY <directory>``
-
-  .. note ::
-
-    Experimental. Gated by ``CMAKE_EXPERIMENTAL_CXX_MODULE_CMAKE_API``
-
-  Export C++ module properties to files under the given directory. Each file
-  will be named according to the target's export name (without any namespace).
-  These files will automatically be included from the export file.
-
-This signature requires all targets to be listed explicitly.  If a library
-target is included in the export, but a target to which it links is not
-included, the behavior is unspecified.  See the `export(EXPORT)`_ signature
-to automatically export the same targets from the build tree as
-:command:`install(EXPORT)` would from an install tree.
-
-.. note::
-
-  :ref:`Object Libraries` under :generator:`Xcode` have special handling if
-  multiple architectures are listed in :variable:`CMAKE_OSX_ARCHITECTURES`.
-  In this case they will be exported as :ref:`Interface Libraries` with
-  no object files available to clients.  This is sufficient to satisfy
-  transitive usage requirements of other targets that link to the
-  object libraries in their implementation.
-
-This command exports all :ref:`build configurations` from the build tree.
-See the :variable:`CMAKE_MAP_IMPORTED_CONFIG_<CONFIG>` variable to map
-configurations of dependent projects to the exported configurations.
-
-Exporting Targets to Android.mk
-"""""""""""""""""""""""""""""""
-
-.. code-block:: cmake
-
-  export(TARGETS <target>... ANDROID_MK <filename>)
-
-.. versionadded:: 3.7
-
-This signature exports cmake built targets to the android ndk build system
-by creating an ``Android.mk`` file that references the prebuilt targets. The
-Android NDK supports the use of prebuilt libraries, both static and shared.
-This allows cmake to build the libraries of a project and make them available
-to an ndk build system complete with transitive dependencies, include flags
-and defines required to use the libraries. The signature takes a list of
-targets and puts them in the ``Android.mk`` file specified by the
-``<filename>`` given. This signature can only be used if policy
-:policy:`CMP0022` is NEW for all targets given. A error will be issued if
-that policy is set to OLD for one of the targets.
-
-Exporting Targets matching install(EXPORT)
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-.. _`export(EXPORT)`:
-.. _EXPORT:
-
-.. code-block:: cmake
-
-  export(EXPORT <export-name> [NAMESPACE <namespace>] [FILE <filename>]
-         [CXX_MODULES_DIRECTORY <directory>])
-
-Creates a file ``<filename>`` that may be included by outside projects to
-import targets from the current project's build tree.  This is the same
-as the `export(TARGETS)`_ signature, except that the targets are not
-explicitly listed.  Instead, it exports the targets associated with
-the installation export ``<export-name>``.  Target installations may be
-associated with the export ``<export-name>`` using the ``EXPORT`` option
-of the :command:`install(TARGETS)` command.
-
-Exporting Packages
-^^^^^^^^^^^^^^^^^^
-
-.. _`export(PACKAGE)`:
-.. _PACKAGE:
-
-.. code-block:: cmake
-
-  export(PACKAGE <PackageName>)
-
-Store the current build directory in the CMake user package registry
-for package ``<PackageName>``.  The :command:`find_package` command may consider the
-directory while searching for package ``<PackageName>``.  This helps dependent
-projects find and use a package from the current project's build tree
-without help from the user.  Note that the entry in the package
-registry that this command creates works only in conjunction with a
-package configuration file (``<PackageName>Config.cmake``) that works with the
-build tree. In some cases, for example for packaging and for system
-wide installations, it is not desirable to write the user package
-registry.
-
-.. versionchanged:: 3.1
-  If the :variable:`CMAKE_EXPORT_NO_PACKAGE_REGISTRY` variable
-  is enabled, the ``export(PACKAGE)`` command will do nothing.
-
-.. versionchanged:: 3.15
-  By default the ``export(PACKAGE)`` command does nothing (see policy
-  :policy:`CMP0090`) because populating the user package registry has effects
-  outside the source and build trees.  Set the
-  :variable:`CMAKE_EXPORT_PACKAGE_REGISTRY` variable to add build directories
-  to the CMake user package registry.

third-party/cmake-3.27.7-linux-x86_64/share/cmake-3.27/Help/command/export_library_dependencies.rst

@@ -1,28 +0,0 @@
-export_library_dependencies
----------------------------
-
-Disallowed since version 3.0.  See CMake Policy :policy:`CMP0033`.
-
-Use :command:`install(EXPORT)` or :command:`export` command.
-
-This command generates an old-style library dependencies file.
-Projects requiring CMake 2.6 or later should not use the command.  Use
-instead the :command:`install(EXPORT)` command to help export targets from an
-installation tree and the :command:`export` command to export targets from a
-build tree.
-
-The old-style library dependencies file does not take into account
-per-configuration names of libraries or the
-:prop_tgt:`LINK_INTERFACE_LIBRARIES` target property.
-
-.. code-block:: cmake
-
-  export_library_dependencies(<file> [APPEND])
-
-Create a file named ``<file>`` that can be included into a CMake listfile
-with the INCLUDE command.  The file will contain a number of SET
-commands that will set all the variables needed for library dependency
-information.  This should be the last command in the top level
-CMakeLists.txt file of the project.  If the ``APPEND`` option is
-specified, the SET commands will be appended to the given file instead
-of replacing it.

third-party/cmake-3.27.7-linux-x86_64/share/cmake-3.27/Help/command/find_file.rst

@@ -1,46 +0,0 @@
-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
-.. |prefix_XXX_SUBDIR| replace:: ``<prefix>/include``
-.. |entry_XXX_SUBDIR| replace:: ``<entry>/include``
-
-.. |FIND_XXX_REGISTRY_VIEW_DEFAULT| replace:: ``TARGET``
-
-.. |FIND_PACKAGE_ROOT_PREFIX_PATH_XXX| replace::
-   ``<prefix>/include/<arch>`` if :variable:`CMAKE_LIBRARY_ARCHITECTURE`
-   is set, and |FIND_PACKAGE_ROOT_PREFIX_PATH_XXX_SUBDIR|
-.. |CMAKE_PREFIX_PATH_XXX| replace::
-   ``<prefix>/include/<arch>`` if :variable:`CMAKE_LIBRARY_ARCHITECTURE`
-   is set, and |CMAKE_PREFIX_PATH_XXX_SUBDIR|
-.. |CMAKE_XXX_PATH| replace:: :variable:`CMAKE_INCLUDE_PATH`
-.. |CMAKE_XXX_MAC_PATH| replace:: :variable:`CMAKE_FRAMEWORK_PATH`
-
-.. |ENV_CMAKE_PREFIX_PATH_XXX| replace::
-   ``<prefix>/include/<arch>`` if :variable:`CMAKE_LIBRARY_ARCHITECTURE` is set,
-   and |ENV_CMAKE_PREFIX_PATH_XXX_SUBDIR|
-.. |ENV_CMAKE_XXX_PATH| replace:: :envvar:`CMAKE_INCLUDE_PATH`
-.. |ENV_CMAKE_XXX_MAC_PATH| replace:: :envvar:`CMAKE_FRAMEWORK_PATH`
-
-
-.. |SYSTEM_ENVIRONMENT_PATH_XXX| replace:: The directories in ``INCLUDE``
-   and ``PATH``.
-.. |SYSTEM_ENVIRONMENT_PATH_WINDOWS_XXX| replace:: On Windows hosts:
-      ``<prefix>/include/<arch>`` if :variable:`CMAKE_LIBRARY_ARCHITECTURE`
-      is set, and |SYSTEM_ENVIRONMENT_PREFIX_PATH_XXX_SUBDIR|.
-
-.. |CMAKE_SYSTEM_PREFIX_PATH_XXX| replace::
-   ``<prefix>/include/<arch>`` if :variable:`CMAKE_LIBRARY_ARCHITECTURE`
-   is set, and |CMAKE_SYSTEM_PREFIX_PATH_XXX_SUBDIR|
-.. |CMAKE_SYSTEM_XXX_PATH| replace::
-   :variable:`CMAKE_SYSTEM_INCLUDE_PATH`
-.. |CMAKE_SYSTEM_XXX_MAC_PATH| replace::
-   :variable:`CMAKE_SYSTEM_FRAMEWORK_PATH`
-
-.. |CMAKE_FIND_ROOT_PATH_MODE_XXX| replace::
-   :variable:`CMAKE_FIND_ROOT_PATH_MODE_INCLUDE`
-
-.. include:: FIND_XXX.txt

third-party/cmake-3.27.7-linux-x86_64/share/cmake-3.27/Help/command/find_library.rst

@@ -1,90 +0,0 @@
-find_library
-------------
-
-.. |FIND_XXX| replace:: find_library
-.. |NAMES| replace:: NAMES name1 [name2 ...] [NAMES_PER_DIR]
-.. |SEARCH_XXX| replace:: library
-.. |SEARCH_XXX_DESC| replace:: library
-.. |prefix_XXX_SUBDIR| replace:: ``<prefix>/lib``
-.. |entry_XXX_SUBDIR| replace:: ``<entry>/lib``
-
-.. |FIND_XXX_REGISTRY_VIEW_DEFAULT| replace:: ``TARGET``
-
-.. |FIND_PACKAGE_ROOT_PREFIX_PATH_XXX| replace::
-   ``<prefix>/lib/<arch>`` if :variable:`CMAKE_LIBRARY_ARCHITECTURE` is set,
-   and |FIND_PACKAGE_ROOT_PREFIX_PATH_XXX_SUBDIR|
-.. |CMAKE_PREFIX_PATH_XXX| replace::
-   ``<prefix>/lib/<arch>`` if :variable:`CMAKE_LIBRARY_ARCHITECTURE` is set,
-   and |CMAKE_PREFIX_PATH_XXX_SUBDIR|
-.. |CMAKE_XXX_PATH| replace:: :variable:`CMAKE_LIBRARY_PATH`
-.. |CMAKE_XXX_MAC_PATH| replace:: :variable:`CMAKE_FRAMEWORK_PATH`
-
-.. |ENV_CMAKE_PREFIX_PATH_XXX| replace::
-   ``<prefix>/lib/<arch>`` if :variable:`CMAKE_LIBRARY_ARCHITECTURE` is set,
-   and |ENV_CMAKE_PREFIX_PATH_XXX_SUBDIR|
-.. |ENV_CMAKE_XXX_PATH| replace:: :envvar:`CMAKE_LIBRARY_PATH`
-.. |ENV_CMAKE_XXX_MAC_PATH| replace:: :envvar:`CMAKE_FRAMEWORK_PATH`
-
-.. |SYSTEM_ENVIRONMENT_PATH_XXX| replace:: The directories in ``LIB``
-   and ``PATH``.
-.. |SYSTEM_ENVIRONMENT_PATH_WINDOWS_XXX| replace:: On Windows hosts:
-      ``<prefix>/lib/<arch>`` if :variable:`CMAKE_LIBRARY_ARCHITECTURE`
-      is set, and |SYSTEM_ENVIRONMENT_PREFIX_PATH_XXX_SUBDIR|.
-
-.. |CMAKE_SYSTEM_PREFIX_PATH_XXX| replace::
-   ``<prefix>/lib/<arch>`` if :variable:`CMAKE_LIBRARY_ARCHITECTURE` is set,
-   and |CMAKE_SYSTEM_PREFIX_PATH_XXX_SUBDIR|
-.. |CMAKE_SYSTEM_XXX_PATH| replace::
-   :variable:`CMAKE_SYSTEM_LIBRARY_PATH`
-.. |CMAKE_SYSTEM_XXX_MAC_PATH| replace::
-   :variable:`CMAKE_SYSTEM_FRAMEWORK_PATH`
-
-.. |CMAKE_FIND_ROOT_PATH_MODE_XXX| replace::
-   :variable:`CMAKE_FIND_ROOT_PATH_MODE_LIBRARY`
-
-.. include:: FIND_XXX.txt
-
-When more than one value is given to the ``NAMES`` option this command by
-default will consider one name at a time and search every directory
-for it.  The ``NAMES_PER_DIR`` option tells this command to consider one
-directory at a time and search for all names in it.
-
-Each library name given to the ``NAMES`` option is first considered
-as a library file name and then considered with platform-specific
-prefixes (e.g. ``lib``) and suffixes (e.g. ``.so``).  Therefore one
-may specify library file names such as ``libfoo.a`` directly.
-This can be used to locate static libraries on UNIX-like systems.
-
-If the library found is a framework, then ``<VAR>`` will be set to the full
-path to the framework ``<fullPath>/A.framework``.  When a full path to a
-framework is used as a library, CMake will use a ``-framework A``, and a
-``-F<fullPath>`` to link the framework to the target.
-
-If the :variable:`CMAKE_FIND_LIBRARY_CUSTOM_LIB_SUFFIX` variable is set all
-search paths will be tested as normal, with the suffix appended, and with
-all matches of ``lib/`` replaced with
-``lib${CMAKE_FIND_LIBRARY_CUSTOM_LIB_SUFFIX}/``.  This variable overrides
-the :prop_gbl:`FIND_LIBRARY_USE_LIB32_PATHS`,
-:prop_gbl:`FIND_LIBRARY_USE_LIBX32_PATHS`,
-and :prop_gbl:`FIND_LIBRARY_USE_LIB64_PATHS` global properties.
-
-If the :prop_gbl:`FIND_LIBRARY_USE_LIB32_PATHS` global property is set
-all search paths will be tested as normal, with ``32/`` appended, and
-with all matches of ``lib/`` replaced with ``lib32/``.  This property is
-automatically set for the platforms that are known to need it if at
-least one of the languages supported by the :command:`project` command
-is enabled.
-
-If the :prop_gbl:`FIND_LIBRARY_USE_LIBX32_PATHS` global property is set
-all search paths will be tested as normal, with ``x32/`` appended, and
-with all matches of ``lib/`` replaced with ``libx32/``.  This property is
-automatically set for the platforms that are known to need it if at
-least one of the languages supported by the :command:`project` command
-is enabled.
-
-If the :prop_gbl:`FIND_LIBRARY_USE_LIB64_PATHS` global property is set
-all search paths will be tested as normal, with ``64/`` appended, and
-with all matches of ``lib/`` replaced with ``lib64/``.  This property is
-automatically set for the platforms that are known to need it if at
-least one of the languages supported by the :command:`project` command
-is enabled.

third-party/cmake-3.27.7-linux-x86_64/share/cmake-3.27/Help/command/find_package.rst

@@ -1,729 +0,0 @@
-find_package
-------------
-
-.. |FIND_XXX| replace:: find_package
-.. |FIND_ARGS_XXX| replace:: <PackageName>
-.. |FIND_XXX_REGISTRY_VIEW_DEFAULT| replace:: ``TARGET``
-.. |CMAKE_FIND_ROOT_PATH_MODE_XXX| replace::
-   :variable:`CMAKE_FIND_ROOT_PATH_MODE_PACKAGE`
-
-.. only:: html
-
-   .. contents::
-
-.. note:: The :guide:`Using Dependencies Guide` provides a high-level
-  introduction to this general topic. It provides a broader overview of
-  where the ``find_package()`` command fits into the bigger picture,
-  including its relationship to the :module:`FetchContent` module.
-  The guide is recommended pre-reading before moving on to the details below.
-
-Find a package (usually provided by something external to the project),
-and load its package-specific details.  Calls to this command can also
-be intercepted by :ref:`dependency providers <dependency_providers>`.
-
-Search Modes
-^^^^^^^^^^^^
-
-The command has a few modes by which it searches for packages:
-
-**Module mode**
-  In this mode, CMake searches for a file called ``Find<PackageName>.cmake``,
-  looking first in the locations listed in the :variable:`CMAKE_MODULE_PATH`,
-  then among the :ref:`Find Modules` provided by the CMake installation.
-  If the file is found, it is read and processed by CMake.  It is responsible
-  for finding the package, checking the version, and producing any needed
-  messages.  Some Find modules provide limited or no support for versioning;
-  check the Find module's documentation.
-
-  The ``Find<PackageName>.cmake`` file is not typically provided by the
-  package itself.  Rather, it is normally provided by something external to
-  the package, such as the operating system, CMake itself, or even the project
-  from which the ``find_package()`` command was called.  Being externally
-  provided, :ref:`Find Modules` tend to be heuristic in nature and are
-  susceptible to becoming out-of-date.  They typically search for certain
-  libraries, files and other package artifacts.
-
-  Module mode is only supported by the
-  :ref:`basic command signature <Basic Signature>`.
-
-**Config mode**
-  In this mode, CMake searches for a file called
-  ``<lowercasePackageName>-config.cmake`` or ``<PackageName>Config.cmake``.
-  It will also look for ``<lowercasePackageName>-config-version.cmake`` or
-  ``<PackageName>ConfigVersion.cmake`` if version details were specified
-  (see :ref:`version selection` for an explanation of how these separate
-  version files are used).
-
-  In config mode, the command can be given a list of names to search for
-  as package names.  The locations where CMake searches for the config and
-  version files is considerably more complicated than for Module mode
-  (see :ref:`search procedure`).
-
-  The config and version files are typically installed as part of the
-  package, so they tend to be more reliable than Find modules.  They usually
-  contain direct knowledge of the package contents, so no searching or
-  heuristics are needed within the config or version files themselves.
-
-  Config mode is supported by both the :ref:`basic <Basic Signature>` and
-  :ref:`full <Full Signature>` command signatures.
-
-**FetchContent redirection mode**
-  .. versionadded:: 3.24
-    A call to ``find_package()`` can be redirected internally to a package
-    provided by the :module:`FetchContent` module.  To the caller, the behavior
-    will appear similar to Config mode, except that the search logic is
-    by-passed and the component information is not used.  See
-    :command:`FetchContent_Declare` and :command:`FetchContent_MakeAvailable`
-    for further details.
-
-When not redirected to a package provided by :module:`FetchContent`, the
-command arguments determine whether Module or Config mode is used.  When the
-`basic signature`_ is used, the command searches in Module mode first.
-If the package is not found, the search falls back to Config mode.
-A user may set the :variable:`CMAKE_FIND_PACKAGE_PREFER_CONFIG` variable
-to true to reverse the priority and direct CMake to search using Config mode
-first before falling back to Module mode.  The basic signature can also be
-forced to use only Module mode with a ``MODULE`` keyword.  If the
-`full signature`_ is used, the command only searches in Config mode.
-
-Where possible, user code should generally look for packages using the
-`basic signature`_, since that allows the package to be found with any mode.
-Project maintainers wishing to provide a config package should understand
-the bigger picture, as explained in :ref:`Full Signature` and all subsequent
-sections on this page.
-
-.. _`basic signature`:
-
-Basic Signature
-^^^^^^^^^^^^^^^
-
-.. parsed-literal::
-
-  find_package(<PackageName> [version] [EXACT] [QUIET] [MODULE]
-               [REQUIRED] [[COMPONENTS] [components...]]
-               [OPTIONAL_COMPONENTS components...]
-               [REGISTRY_VIEW  (64|32|64_32|32_64|HOST|TARGET|BOTH)]
-               [GLOBAL]
-               [NO_POLICY_SCOPE]
-               [BYPASS_PROVIDER])
-
-The basic signature is supported by both Module and Config modes.
-The ``MODULE`` keyword implies that only Module mode can be used to find
-the package, with no fallback to Config mode.
-
-Regardless of the mode used, a ``<PackageName>_FOUND`` variable will be
-set to indicate whether the package was found.  When the package is found,
-package-specific information may be provided through other variables and
-:ref:`Imported Targets` documented by the package itself.  The
-``QUIET`` option disables informational messages, including those indicating
-that the package cannot be found if it is not ``REQUIRED``.  The ``REQUIRED``
-option stops processing with an error message if the package cannot be found.
-
-A package-specific list of required components may be listed after the
-``COMPONENTS`` keyword.  If any of these components are not able to be
-satisfied, the package overall is considered to be not found.  If the
-``REQUIRED`` option is also present, this is treated as a fatal error,
-otherwise execution still continues.  As a form of shorthand, if the
-``REQUIRED`` option is present, the ``COMPONENTS`` keyword can be omitted
-and the required components can be listed directly after ``REQUIRED``.
-
-Additional optional components may be listed after
-``OPTIONAL_COMPONENTS``.  If these cannot be satisfied, the package overall
-can still be considered found, as long as all required components are
-satisfied.
-
-The set of available components and their meaning are defined by the
-target package.  Formally, it is up to the target package how to
-interpret the component information given to it, but it should follow
-the expectations stated above.  For calls where no components are specified,
-there is no single expected behavior and target packages should clearly
-define what occurs in such cases.  Common arrangements include assuming it
-should find all components, no components or some well-defined subset of the
-available components.
-
-.. versionadded:: 3.24
-  The ``REGISTRY_VIEW`` keyword specifies which registry views should be
-  queried. This keyword is only meaningful on ``Windows`` platforms and will
-  be ignored on all others. Formally, it is up to the target package how to
-  interpret the registry view information given to it.
-
-.. versionadded:: 3.24
-  Specifying the ``GLOBAL`` keyword will promote all imported targets to
-  a global scope in the importing project. Alternatively, this functionality
-  can be enabled by setting the :variable:`CMAKE_FIND_PACKAGE_TARGETS_GLOBAL`
-  variable.
-
-.. _FIND_PACKAGE_VERSION_FORMAT:
-
-The ``[version]`` argument requests a version with which the package found
-should be compatible. There are two possible forms in which it may be
-specified:
-
-  * A single version with the format ``major[.minor[.patch[.tweak]]]``, where
-    each component is a numeric value.
-  * A version range with the format ``versionMin...[<]versionMax`` where
-    ``versionMin`` and ``versionMax`` have the same format and constraints
-    on components being integers as the single version.  By default, both end
-    points are included.  By specifying ``<``, the upper end point will be
-    excluded. Version ranges are only supported with CMake 3.19 or later.
-
-The ``EXACT`` option requests that the version be matched exactly. This option
-is incompatible with the specification of a version range.
-
-If no ``[version]`` and/or component list is given to a recursive invocation
-inside a find-module, the corresponding arguments are forwarded
-automatically from the outer call (including the ``EXACT`` flag for
-``[version]``).  Version support is currently provided only on a
-package-by-package basis (see the `Version Selection`_ section below).
-When a version range is specified but the package is only designed to expect
-a single version, the package will ignore the upper end point of the range and
-only take the single version at the lower end of the range into account.
-
-See the :command:`cmake_policy` command documentation for discussion
-of the ``NO_POLICY_SCOPE`` option.
-
-.. versionadded:: 3.24
-  The ``BYPASS_PROVIDER`` keyword is only allowed when ``find_package()`` is
-  being called by a :ref:`dependency provider <dependency_providers>`.
-  It can be used by providers to call the built-in ``find_package()``
-  implementation directly and prevent that call from being re-routed back to
-  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.
-
-.. _`full signature`:
-
-Full Signature
-^^^^^^^^^^^^^^
-
-.. parsed-literal::
-
-  find_package(<PackageName> [version] [EXACT] [QUIET]
-               [REQUIRED] [[COMPONENTS] [components...]]
-               [OPTIONAL_COMPONENTS components...]
-               [CONFIG|NO_MODULE]
-               [GLOBAL]
-               [NO_POLICY_SCOPE]
-               [BYPASS_PROVIDER]
-               [NAMES name1 [name2 ...]]
-               [CONFIGS config1 [config2 ...]]
-               [HINTS path1 [path2 ... ]]
-               [PATHS path1 [path2 ... ]]
-               [REGISTRY_VIEW  (64|32|64_32|32_64|HOST|TARGET|BOTH)]
-               [PATH_SUFFIXES suffix1 [suffix2 ...]]
-               [NO_DEFAULT_PATH]
-               [NO_PACKAGE_ROOT_PATH]
-               [NO_CMAKE_PATH]
-               [NO_CMAKE_ENVIRONMENT_PATH]
-               [NO_SYSTEM_ENVIRONMENT_PATH]
-               [NO_CMAKE_PACKAGE_REGISTRY]
-               [NO_CMAKE_BUILDS_PATH] # Deprecated; does nothing.
-               [NO_CMAKE_SYSTEM_PATH]
-               [NO_CMAKE_INSTALL_PREFIX]
-               [NO_CMAKE_SYSTEM_PACKAGE_REGISTRY]
-               [CMAKE_FIND_ROOT_PATH_BOTH |
-                ONLY_CMAKE_FIND_ROOT_PATH |
-                NO_CMAKE_FIND_ROOT_PATH])
-
-The ``CONFIG`` option, the synonymous ``NO_MODULE`` option, or the use
-of options not specified in the `basic signature`_ all enforce pure Config
-mode.  In pure Config mode, the command skips Module mode search and
-proceeds at once with Config mode search.
-
-Config mode search attempts to locate a configuration file provided by the
-package to be found.  A cache entry called ``<PackageName>_DIR`` is created to
-hold the directory containing the file.  By default, the command searches for
-a package with the name ``<PackageName>``.  If the ``NAMES`` option is given,
-the names following it are used instead of ``<PackageName>``.  The names are
-also considered when determining whether to redirect the call to a package
-provided by :module:`FetchContent`.
-
-The command searches for a file called ``<PackageName>Config.cmake`` or
-``<lowercasePackageName>-config.cmake`` for each name specified.
-A replacement set of possible configuration file names may be given
-using the ``CONFIGS`` option.  The :ref:`search procedure` is specified below.
-Once found, any :ref:`version constraint <version selection>` is checked,
-and if satisfied, the configuration file is read and processed by CMake.
-Since the file is provided by the package it already knows the
-location of package contents.  The full path to the configuration file
-is stored in the cmake variable ``<PackageName>_CONFIG``.
-
-All configuration files which have been considered by CMake while
-searching for the package with an appropriate version are stored in the
-``<PackageName>_CONSIDERED_CONFIGS`` variable, and the associated versions
-in the ``<PackageName>_CONSIDERED_VERSIONS`` variable.
-
-If the package configuration file cannot be found CMake will generate
-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.
-
-Package maintainers providing CMake package configuration files are
-encouraged to name and install them such that the :ref:`search procedure`
-outlined below will find them without requiring use of additional options.
-
-.. _`search procedure`:
-
-Config Mode Search Procedure
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-.. note::
-  When Config mode is used, this search procedure is applied regardless of
-  whether the :ref:`full <full signature>` or :ref:`basic <basic signature>`
-  signature was given.
-
-.. versionadded:: 3.24
-  All calls to ``find_package()`` (even in Module mode) first look for a config
-  package file in the :variable:`CMAKE_FIND_PACKAGE_REDIRECTS_DIR` directory.
-  The :module:`FetchContent` module, or even the project itself, may write files
-  to that location to redirect ``find_package()`` calls to content already
-  provided by the project.  If no config package file is found in that location,
-  the search proceeds with the logic described below.
-
-CMake constructs a set of possible installation prefixes for the
-package.  Under each prefix several directories are searched for a
-configuration file.  The tables below show the directories searched.
-Each entry is meant for installation trees following Windows (``W``), UNIX
-(``U``), or Apple (``A``) conventions:
-
-==================================================================== ==========
- Entry                                                               Convention
-==================================================================== ==========
- ``<prefix>/``                                                          W
- ``<prefix>/(cmake|CMake)/``                                            W
- ``<prefix>/<name>*/``                                                  W
- ``<prefix>/<name>*/(cmake|CMake)/``                                    W
- ``<prefix>/<name>*/(cmake|CMake)/<name>*/`` [#]_                       W
- ``<prefix>/(lib/<arch>|lib*|share)/cmake/<name>*/``                    U
- ``<prefix>/(lib/<arch>|lib*|share)/<name>*/``                          U
- ``<prefix>/(lib/<arch>|lib*|share)/<name>*/(cmake|CMake)/``            U
- ``<prefix>/<name>*/(lib/<arch>|lib*|share)/cmake/<name>*/``            W/U
- ``<prefix>/<name>*/(lib/<arch>|lib*|share)/<name>*/``                  W/U
- ``<prefix>/<name>*/(lib/<arch>|lib*|share)/<name>*/(cmake|CMake)/``    W/U
-==================================================================== ==========
-
-.. [#] .. versionadded:: 3.25
-
-On systems supporting macOS :prop_tgt:`FRAMEWORK` and :prop_tgt:`BUNDLE`, the
-following directories are searched for Frameworks or Application Bundles
-containing a configuration file:
-
-=========================================================== ==========
- Entry                                                      Convention
-=========================================================== ==========
- ``<prefix>/<name>.framework/Resources/``                      A
- ``<prefix>/<name>.framework/Resources/CMake/``                A
- ``<prefix>/<name>.framework/Versions/*/Resources/``           A
- ``<prefix>/<name>.framework/Versions/*/Resources/CMake/``     A
- ``<prefix>/<name>.app/Contents/Resources/``                   A
- ``<prefix>/<name>.app/Contents/Resources/CMake/``             A
-=========================================================== ==========
-
-In all cases the ``<name>`` is treated as case-insensitive and corresponds
-to any of the names specified (``<PackageName>`` or names given by ``NAMES``).
-
-Paths with ``lib/<arch>`` are enabled if the
-:variable:`CMAKE_LIBRARY_ARCHITECTURE` variable is set. ``lib*`` includes one
-or more of the values ``lib64``, ``lib32``, ``libx32`` or ``lib`` (searched in
-that order).
-
-* Paths with ``lib64`` are searched on 64 bit platforms if the
-  :prop_gbl:`FIND_LIBRARY_USE_LIB64_PATHS` property is set to ``TRUE``.
-* Paths with ``lib32`` are searched on 32 bit platforms if the
-  :prop_gbl:`FIND_LIBRARY_USE_LIB32_PATHS` property is set to ``TRUE``.
-* Paths with ``libx32`` are searched on platforms using the x32 ABI
-  if the :prop_gbl:`FIND_LIBRARY_USE_LIBX32_PATHS` property is set to ``TRUE``.
-* The ``lib`` path is always searched.
-
-.. versionchanged:: 3.24
-  On ``Windows`` platform, it is possible to include registry queries as part
-  of the directories specified through ``HINTS`` and ``PATHS`` keywords, using
-  a :ref:`dedicated syntax <Find Using Windows Registry>`. Such specifications
-  will be ignored on all other platforms.
-
-.. versionadded:: 3.24
-  ``REGISTRY_VIEW`` can be specified to manage ``Windows`` registry queries
-  specified as part of ``PATHS`` and ``HINTS``.
-
-.. include:: FIND_XXX_REGISTRY_VIEW.txt
-
-If ``PATH_SUFFIXES`` is specified, the suffixes are appended to each
-(``W``) or (``U``) directory entry one-by-one.
-
-This set of directories is intended to work in cooperation with
-projects that provide configuration files in their installation trees.
-Directories above marked with (``W``) are intended for installations on
-Windows where the prefix may point at the top of an application's
-installation directory.  Those marked with (``U``) are intended for
-installations on UNIX platforms where the prefix is shared by multiple
-packages.  This is merely a convention, so all (``W``) and (``U``) directories
-are still searched on all platforms.  Directories marked with (``A``) are
-intended for installations on Apple platforms.  The
-:variable:`CMAKE_FIND_FRAMEWORK` and :variable:`CMAKE_FIND_APPBUNDLE`
-variables determine the order of preference.
-
-The set of installation prefixes is constructed using the following
-steps.  If ``NO_DEFAULT_PATH`` is specified all ``NO_*`` options are
-enabled.
-
-1. Search prefixes unique to the current ``<PackageName>`` being found.
-   See policy :policy:`CMP0074`.
-
-   .. versionadded:: 3.12
-
-   Specifically, search prefixes specified by the following variables,
-   in order:
-
-   a. :variable:`<PackageName>_ROOT` CMake variable,
-      where ``<PackageName>`` is the case-preserved package name.
-
-   b. :variable:`<PACKAGENAME>_ROOT` CMake variable,
-      where ``<PACKAGENAME>`` is the upper-cased package name.
-      See policy :policy:`CMP0144`.
-
-      .. versionadded:: 3.27
-
-   c. :envvar:`<PackageName>_ROOT` environment variable,
-      where ``<PackageName>`` is the case-preserved package name.
-
-   d. :envvar:`<PACKAGENAME>_ROOT` environment variable,
-      where ``<PACKAGENAME>`` is the upper-cased package name.
-      See policy :policy:`CMP0144`.
-
-      .. versionadded:: 3.27
-
-   The package root variables are maintained as a stack so if
-   called from within a find module, root paths from the parent's find
-   module will also be searched after paths for the current package.
-   This can be skipped if ``NO_PACKAGE_ROOT_PATH`` is passed or by setting
-   the :variable:`CMAKE_FIND_USE_PACKAGE_ROOT_PATH` to ``FALSE``.
-
-2. Search paths specified in cmake-specific cache variables.  These
-   are intended to be used on the command line with a :option:`-DVAR=VALUE <cmake -D>`.
-   The values are interpreted as :ref:`semicolon-separated lists <CMake Language Lists>`.
-   This can be skipped if ``NO_CMAKE_PATH`` is passed or by setting the
-   :variable:`CMAKE_FIND_USE_CMAKE_PATH` to ``FALSE``:
-
-   * :variable:`CMAKE_PREFIX_PATH`
-   * :variable:`CMAKE_FRAMEWORK_PATH`
-   * :variable:`CMAKE_APPBUNDLE_PATH`
-
-3. Search paths specified in cmake-specific environment variables.
-   These are intended to be set in the user's shell configuration,
-   and therefore use the host's native path separator
-   (``;`` on Windows and ``:`` on UNIX).
-   This can be skipped if ``NO_CMAKE_ENVIRONMENT_PATH`` is passed or by setting
-   the :variable:`CMAKE_FIND_USE_CMAKE_ENVIRONMENT_PATH` to ``FALSE``:
-
-   * ``<PackageName>_DIR``
-   * :envvar:`CMAKE_PREFIX_PATH`
-   * :envvar:`CMAKE_FRAMEWORK_PATH`
-   * :envvar:`CMAKE_APPBUNDLE_PATH`
-
-4. Search paths specified by the ``HINTS`` option.  These should be paths
-   computed by system introspection, such as a hint provided by the
-   location of another item already found.  Hard-coded guesses should
-   be specified with the ``PATHS`` option.
-
-5. Search the standard system environment variables.  This can be
-   skipped if ``NO_SYSTEM_ENVIRONMENT_PATH`` is passed  or by setting the
-   :variable:`CMAKE_FIND_USE_SYSTEM_ENVIRONMENT_PATH` to ``FALSE``. Path entries
-   ending in ``/bin`` or ``/sbin`` are automatically converted to their
-   parent directories:
-
-   * ``PATH``
-
-6. Search paths stored in the CMake :ref:`User Package Registry`.
-   This can be skipped if ``NO_CMAKE_PACKAGE_REGISTRY`` is passed or by
-   setting the variable :variable:`CMAKE_FIND_USE_PACKAGE_REGISTRY`
-   to ``FALSE`` or the deprecated variable
-   :variable:`CMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY` to ``TRUE``.
-
-   See the :manual:`cmake-packages(7)` manual for details on the user
-   package registry.
-
-7. Search cmake variables defined in the Platform files for the
-   current system. The searching of :variable:`CMAKE_INSTALL_PREFIX` and
-   :variable:`CMAKE_STAGING_PREFIX` can be
-   skipped if ``NO_CMAKE_INSTALL_PREFIX`` is passed or by setting the
-   :variable:`CMAKE_FIND_USE_INSTALL_PREFIX` to ``FALSE``. All these locations
-   can be skipped if ``NO_CMAKE_SYSTEM_PATH`` is passed or by setting the
-   :variable:`CMAKE_FIND_USE_CMAKE_SYSTEM_PATH` to ``FALSE``:
-
-   * :variable:`CMAKE_SYSTEM_PREFIX_PATH`
-   * :variable:`CMAKE_SYSTEM_FRAMEWORK_PATH`
-   * :variable:`CMAKE_SYSTEM_APPBUNDLE_PATH`
-
-   The platform paths that these variables contain are locations that
-   typically include installed software. An example being ``/usr/local`` for
-   UNIX based platforms.
-
-8. Search paths stored in the CMake :ref:`System Package Registry`.
-   This can be skipped if ``NO_CMAKE_SYSTEM_PACKAGE_REGISTRY`` is passed
-   or by setting the :variable:`CMAKE_FIND_USE_SYSTEM_PACKAGE_REGISTRY`
-   variable to ``FALSE`` or the deprecated variable
-   :variable:`CMAKE_FIND_PACKAGE_NO_SYSTEM_PACKAGE_REGISTRY` to ``TRUE``.
-
-   See the :manual:`cmake-packages(7)` manual for details on the system
-   package registry.
-
-9. Search paths specified by the ``PATHS`` option.  These are typically
-   hard-coded guesses.
-
-The :variable:`CMAKE_IGNORE_PATH`, :variable:`CMAKE_IGNORE_PREFIX_PATH`,
-:variable:`CMAKE_SYSTEM_IGNORE_PATH` and
-:variable:`CMAKE_SYSTEM_IGNORE_PREFIX_PATH` variables can also cause some
-of the above locations to be ignored.
-
-.. versionadded:: 3.16
-   Added the ``CMAKE_FIND_USE_<CATEGORY>`` variables to globally disable
-   various search locations.
-
-.. include:: FIND_XXX_ROOT.txt
-.. include:: FIND_XXX_ORDER.txt
-
-By default the value stored in the result variable will be the path at
-which the file is found.  The :variable:`CMAKE_FIND_PACKAGE_RESOLVE_SYMLINKS`
-variable may be set to ``TRUE`` before calling ``find_package`` in order
-to resolve symbolic links and store the real path to the file.
-
-Every non-REQUIRED ``find_package`` call can be disabled or made REQUIRED:
-
-* Setting the :variable:`CMAKE_DISABLE_FIND_PACKAGE_<PackageName>` variable
-  to ``TRUE`` disables the package.  This also disables redirection to a
-  package provided by :module:`FetchContent`.
-
-* Setting the :variable:`CMAKE_REQUIRE_FIND_PACKAGE_<PackageName>` variable
-  to ``TRUE`` makes the package REQUIRED.
-
-Setting both variables to ``TRUE`` simultaneously is an error.
-
-.. _`version selection`:
-
-Config Mode Version Selection
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-.. note::
-  When Config mode is used, this version selection process is applied
-  regardless of whether the :ref:`full <full signature>` or
-  :ref:`basic <basic signature>` signature was given.
-
-When the ``[version]`` argument is given, Config mode will only find a
-version of the package that claims compatibility with the requested
-version (see :ref:`format specification <FIND_PACKAGE_VERSION_FORMAT>`). If the
-``EXACT`` option is given, only a version of the package claiming an exact match
-of the requested version may be found.  CMake does not establish any
-convention for the meaning of version numbers.  Package version
-numbers are checked by "version" files provided by the packages themselves
-or by :module:`FetchContent`.  For a candidate package configuration file
-``<config-file>.cmake`` the corresponding version file is located next
-to it and named either ``<config-file>-version.cmake`` or
-``<config-file>Version.cmake``.  If no such version file is available
-then the configuration file is assumed to not be compatible with any
-requested version.  A basic version file containing generic version
-matching code can be created using the
-:module:`CMakePackageConfigHelpers` module.  When a version file
-is found it is loaded to check the requested version number.  The
-version file is loaded in a nested scope in which the following
-variables have been defined:
-
-``PACKAGE_FIND_NAME``
-  The ``<PackageName>``
-``PACKAGE_FIND_VERSION``
-  Full requested version string
-``PACKAGE_FIND_VERSION_MAJOR``
-  Major version if requested, else 0
-``PACKAGE_FIND_VERSION_MINOR``
-  Minor version if requested, else 0
-``PACKAGE_FIND_VERSION_PATCH``
-  Patch version if requested, else 0
-``PACKAGE_FIND_VERSION_TWEAK``
-  Tweak version if requested, else 0
-``PACKAGE_FIND_VERSION_COUNT``
-  Number of version components, 0 to 4
-
-When a version range is specified, the above version variables will hold
-values based on the lower end of the version range.  This is to preserve
-compatibility with packages that have not been implemented to expect version
-ranges.  In addition, the version range will be described by the following
-variables:
-
-``PACKAGE_FIND_VERSION_RANGE``
-  Full requested version range string
-``PACKAGE_FIND_VERSION_RANGE_MIN``
-  This specifies whether the lower end point of the version range should be
-  included or excluded.  Currently, the only supported value for this variable
-  is ``INCLUDE``.
-``PACKAGE_FIND_VERSION_RANGE_MAX``
-  This specifies whether the upper end point of the version range should be
-  included or excluded.  The supported values for this variable are
-  ``INCLUDE`` and ``EXCLUDE``.
-
-``PACKAGE_FIND_VERSION_MIN``
-  Full requested version string of the lower end point of the range
-``PACKAGE_FIND_VERSION_MIN_MAJOR``
-  Major version of the lower end point if requested, else 0
-``PACKAGE_FIND_VERSION_MIN_MINOR``
-  Minor version of the lower end point if requested, else 0
-``PACKAGE_FIND_VERSION_MIN_PATCH``
-  Patch version of the lower end point if requested, else 0
-``PACKAGE_FIND_VERSION_MIN_TWEAK``
-  Tweak version of the lower end point if requested, else 0
-``PACKAGE_FIND_VERSION_MIN_COUNT``
-  Number of version components of the lower end point, 0 to 4
-
-``PACKAGE_FIND_VERSION_MAX``
-  Full requested version string of the upper end point of the range
-``PACKAGE_FIND_VERSION_MAX_MAJOR``
-  Major version of the upper end point if requested, else 0
-``PACKAGE_FIND_VERSION_MAX_MINOR``
-  Minor version of the upper end point if requested, else 0
-``PACKAGE_FIND_VERSION_MAX_PATCH``
-  Patch version of the upper end point if requested, else 0
-``PACKAGE_FIND_VERSION_MAX_TWEAK``
-  Tweak version of the upper end point if requested, else 0
-``PACKAGE_FIND_VERSION_MAX_COUNT``
-  Number of version components of the upper end point, 0 to 4
-
-Regardless of whether a single version or a version range is specified, the
-variable ``PACKAGE_FIND_VERSION_COMPLETE`` will be defined and will hold
-the full requested version string as specified.
-
-The version file checks whether it satisfies the requested version and
-sets these variables:
-
-``PACKAGE_VERSION``
-  Full provided version string
-``PACKAGE_VERSION_EXACT``
-  True if version is exact match
-``PACKAGE_VERSION_COMPATIBLE``
-  True if version is compatible
-``PACKAGE_VERSION_UNSUITABLE``
-  True if unsuitable as any version
-
-These variables are checked by the ``find_package`` command to determine
-whether the configuration file provides an acceptable version.  They
-are not available after the ``find_package`` call returns.  If the version
-is acceptable the following variables are set:
-
-``<PackageName>_VERSION``
-  Full provided version string
-``<PackageName>_VERSION_MAJOR``
-  Major version if provided, else 0
-``<PackageName>_VERSION_MINOR``
-  Minor version if provided, else 0
-``<PackageName>_VERSION_PATCH``
-  Patch version if provided, else 0
-``<PackageName>_VERSION_TWEAK``
-  Tweak version if provided, else 0
-``<PackageName>_VERSION_COUNT``
-  Number of version components, 0 to 4
-
-and the corresponding package configuration file is loaded.
-When multiple package configuration files are available whose version files
-claim compatibility with the version requested it is unspecified which
-one is chosen: unless the variable :variable:`CMAKE_FIND_PACKAGE_SORT_ORDER`
-is set no attempt is made to choose a highest or closest version number.
-
-To control the order in which ``find_package`` checks for compatibility use
-the two variables :variable:`CMAKE_FIND_PACKAGE_SORT_ORDER` and
-:variable:`CMAKE_FIND_PACKAGE_SORT_DIRECTION`.
-For instance in order to select the highest version one can set
-
-.. code-block:: cmake
-
-  SET(CMAKE_FIND_PACKAGE_SORT_ORDER NATURAL)
-  SET(CMAKE_FIND_PACKAGE_SORT_DIRECTION DEC)
-
-before calling ``find_package``.
-
-Package File Interface Variables
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-When loading a find module or package configuration file ``find_package``
-defines variables to provide information about the call arguments (and
-restores their original state before returning):
-
-``CMAKE_FIND_PACKAGE_NAME``
-  The ``<PackageName>`` which is searched for
-``<PackageName>_FIND_REQUIRED``
-  True if ``REQUIRED`` option was given
-``<PackageName>_FIND_QUIETLY``
-  True if ``QUIET`` option was given
-``<PackageName>_FIND_REGISTRY_VIEW``
-  The requested view if ``REGISTRY_VIEW`` option was given
-``<PackageName>_FIND_VERSION``
-  Full requested version string
-``<PackageName>_FIND_VERSION_MAJOR``
-  Major version if requested, else 0
-``<PackageName>_FIND_VERSION_MINOR``
-  Minor version if requested, else 0
-``<PackageName>_FIND_VERSION_PATCH``
-  Patch version if requested, else 0
-``<PackageName>_FIND_VERSION_TWEAK``
-  Tweak version if requested, else 0
-``<PackageName>_FIND_VERSION_COUNT``
-  Number of version components, 0 to 4
-``<PackageName>_FIND_VERSION_EXACT``
-  True if ``EXACT`` option was given
-``<PackageName>_FIND_COMPONENTS``
-  List of specified components (required and optional)
-``<PackageName>_FIND_REQUIRED_<c>``
-  True if component ``<c>`` is required,
-  false if component ``<c>`` is optional
-
-When a version range is specified, the above version variables will hold
-values based on the lower end of the version range.  This is to preserve
-compatibility with packages that have not been implemented to expect version
-ranges.  In addition, the version range will be described by the following
-variables:
-
-``<PackageName>_FIND_VERSION_RANGE``
-  Full requested version range string
-``<PackageName>_FIND_VERSION_RANGE_MIN``
-  This specifies whether the lower end point of the version range is
-  included or excluded.  Currently, ``INCLUDE`` is the only supported value.
-``<PackageName>_FIND_VERSION_RANGE_MAX``
-  This specifies whether the upper end point of the version range is
-  included or excluded.  The possible values for this variable are
-  ``INCLUDE`` or ``EXCLUDE``.
-
-``<PackageName>_FIND_VERSION_MIN``
-  Full requested version string of the lower end point of the range
-``<PackageName>_FIND_VERSION_MIN_MAJOR``
-  Major version of the lower end point if requested, else 0
-``<PackageName>_FIND_VERSION_MIN_MINOR``
-  Minor version of the lower end point if requested, else 0
-``<PackageName>_FIND_VERSION_MIN_PATCH``
-  Patch version of the lower end point if requested, else 0
-``<PackageName>_FIND_VERSION_MIN_TWEAK``
-  Tweak version of the lower end point if requested, else 0
-``<PackageName>_FIND_VERSION_MIN_COUNT``
-  Number of version components of the lower end point, 0 to 4
-
-``<PackageName>_FIND_VERSION_MAX``
-  Full requested version string of the upper end point of the range
-``<PackageName>_FIND_VERSION_MAX_MAJOR``
-  Major version of the upper end point if requested, else 0
-``<PackageName>_FIND_VERSION_MAX_MINOR``
-  Minor version of the upper end point if requested, else 0
-``<PackageName>_FIND_VERSION_MAX_PATCH``
-  Patch version of the upper end point if requested, else 0
-``<PackageName>_FIND_VERSION_MAX_TWEAK``
-  Tweak version of the upper end point if requested, else 0
-``<PackageName>_FIND_VERSION_MAX_COUNT``
-  Number of version components of the upper end point, 0 to 4
-
-Regardless of whether a single version or a version range is specified, the
-variable ``<PackageName>_FIND_VERSION_COMPLETE`` will be defined and will hold
-the full requested version string as specified.
-
-In Module mode the loaded find module is responsible to honor the
-request detailed by these variables; see the find module for details.
-In Config mode ``find_package`` handles ``REQUIRED``, ``QUIET``, and
-``[version]`` options automatically but leaves it to the package
-configuration file to handle components in a way that makes sense
-for the package.  The package configuration file may set
-``<PackageName>_FOUND`` to false to tell ``find_package`` that component
-requirements are not satisfied.

third-party/cmake-3.27.7-linux-x86_64/share/cmake-3.27/Help/command/find_path.rst

@@ -1,50 +0,0 @@
-find_path
----------
-
-.. |FIND_XXX| replace:: find_path
-.. |NAMES| replace:: NAMES name1 [name2 ...]
-.. |SEARCH_XXX| replace:: file in a directory
-.. |SEARCH_XXX_DESC| replace:: directory containing the named file
-.. |prefix_XXX_SUBDIR| replace:: ``<prefix>/include``
-.. |entry_XXX_SUBDIR| replace:: ``<entry>/include``
-
-.. |FIND_XXX_REGISTRY_VIEW_DEFAULT| replace:: ``TARGET``
-
-.. |FIND_PACKAGE_ROOT_PREFIX_PATH_XXX| replace::
-   ``<prefix>/include/<arch>`` if :variable:`CMAKE_LIBRARY_ARCHITECTURE`
-   is set, and |FIND_PACKAGE_ROOT_PREFIX_PATH_XXX_SUBDIR|
-.. |CMAKE_PREFIX_PATH_XXX| replace::
-   ``<prefix>/include/<arch>`` if :variable:`CMAKE_LIBRARY_ARCHITECTURE`
-   is set, and |CMAKE_PREFIX_PATH_XXX_SUBDIR|
-.. |CMAKE_XXX_PATH| replace:: :variable:`CMAKE_INCLUDE_PATH`
-.. |CMAKE_XXX_MAC_PATH| replace:: :variable:`CMAKE_FRAMEWORK_PATH`
-
-.. |ENV_CMAKE_PREFIX_PATH_XXX| replace::
-   ``<prefix>/include/<arch>`` if :variable:`CMAKE_LIBRARY_ARCHITECTURE` is set,
-   and |ENV_CMAKE_PREFIX_PATH_XXX_SUBDIR|
-.. |ENV_CMAKE_XXX_PATH| replace:: :envvar:`CMAKE_INCLUDE_PATH`
-.. |ENV_CMAKE_XXX_MAC_PATH| replace:: :envvar:`CMAKE_FRAMEWORK_PATH`
-
-.. |SYSTEM_ENVIRONMENT_PATH_XXX| replace:: The directories in ``INCLUDE``
-   and ``PATH``.
-.. |SYSTEM_ENVIRONMENT_PATH_WINDOWS_XXX| replace:: On Windows hosts:
-      ``<prefix>/include/<arch>`` if :variable:`CMAKE_LIBRARY_ARCHITECTURE`
-      is set, and |SYSTEM_ENVIRONMENT_PREFIX_PATH_XXX_SUBDIR|.
-
-.. |CMAKE_SYSTEM_PREFIX_PATH_XXX| replace::
-   ``<prefix>/include/<arch>`` if :variable:`CMAKE_LIBRARY_ARCHITECTURE`
-   is set, and |CMAKE_SYSTEM_PREFIX_PATH_XXX_SUBDIR|
-.. |CMAKE_SYSTEM_XXX_PATH| replace::
-   :variable:`CMAKE_SYSTEM_INCLUDE_PATH`
-.. |CMAKE_SYSTEM_XXX_MAC_PATH| replace::
-   :variable:`CMAKE_SYSTEM_FRAMEWORK_PATH`
-
-.. |CMAKE_FIND_ROOT_PATH_MODE_XXX| replace::
-   :variable:`CMAKE_FIND_ROOT_PATH_MODE_INCLUDE`
-
-.. include:: FIND_XXX.txt
-
-When searching for frameworks, if the file is specified as ``A/b.h``, then
-the framework search will look for ``A.framework/Headers/b.h``.  If that
-is found the path will be set to the path to the framework.  CMake
-will convert this to the correct ``-F`` option to include the file.

third-party/cmake-3.27.7-linux-x86_64/share/cmake-3.27/Help/command/find_program.rst

@@ -1,43 +0,0 @@
-find_program
-------------
-
-.. |FIND_XXX| replace:: find_program
-.. |NAMES| replace:: NAMES name1 [name2 ...] [NAMES_PER_DIR]
-.. |SEARCH_XXX| replace:: program
-.. |SEARCH_XXX_DESC| replace:: program
-.. |prefix_XXX_SUBDIR| replace:: ``<prefix>/[s]bin``
-.. |entry_XXX_SUBDIR| replace:: ``<entry>/[s]bin``
-
-.. |FIND_XXX_REGISTRY_VIEW_DEFAULT| replace:: ``BOTH``
-
-.. |FIND_PACKAGE_ROOT_PREFIX_PATH_XXX| replace::
-   |FIND_PACKAGE_ROOT_PREFIX_PATH_XXX_SUBDIR|
-.. |CMAKE_PREFIX_PATH_XXX| replace::
-   |CMAKE_PREFIX_PATH_XXX_SUBDIR|
-.. |CMAKE_XXX_PATH| replace:: :variable:`CMAKE_PROGRAM_PATH`
-.. |CMAKE_XXX_MAC_PATH| replace:: :variable:`CMAKE_APPBUNDLE_PATH`
-
-.. |ENV_CMAKE_PREFIX_PATH_XXX| replace::
-   |ENV_CMAKE_PREFIX_PATH_XXX_SUBDIR|
-.. |ENV_CMAKE_XXX_PATH| replace:: :envvar:`CMAKE_PROGRAM_PATH`
-.. |ENV_CMAKE_XXX_MAC_PATH| replace:: :envvar:`CMAKE_APPBUNDLE_PATH`
-
-.. |SYSTEM_ENVIRONMENT_PATH_XXX| replace:: The directories in ``PATH`` itself.
-.. |SYSTEM_ENVIRONMENT_PATH_WINDOWS_XXX| replace:: On Windows hosts no extra search paths are included
-
-.. |CMAKE_SYSTEM_PREFIX_PATH_XXX| replace::
-   |CMAKE_SYSTEM_PREFIX_PATH_XXX_SUBDIR|
-.. |CMAKE_SYSTEM_XXX_PATH| replace::
-   :variable:`CMAKE_SYSTEM_PROGRAM_PATH`
-.. |CMAKE_SYSTEM_XXX_MAC_PATH| replace::
-   :variable:`CMAKE_SYSTEM_APPBUNDLE_PATH`
-
-.. |CMAKE_FIND_ROOT_PATH_MODE_XXX| replace::
-   :variable:`CMAKE_FIND_ROOT_PATH_MODE_PROGRAM`
-
-.. include:: FIND_XXX.txt
-
-When more than one value is given to the ``NAMES`` option this command by
-default will consider one name at a time and search every directory
-for it.  The ``NAMES_PER_DIR`` option tells this command to consider one
-directory at a time and search for all names in it.

third-party/cmake-3.27.7-linux-x86_64/share/cmake-3.27/Help/command/fltk_wrap_ui.rst

@@ -1,14 +0,0 @@
-fltk_wrap_ui
-------------
-
-Create FLTK user interfaces Wrappers.
-
-.. code-block:: cmake
-
-  fltk_wrap_ui(resultingLibraryName source1
-               source2 ... sourceN )
-
-Produce .h and .cxx files for all the .fl and .fld files listed.  The
-resulting .h and .cxx files will be added to a variable named
-``resultingLibraryName_FLTK_UI_SRCS`` which should be added to your
-library.

third-party/cmake-3.27.7-linux-x86_64/share/cmake-3.27/Help/command/foreach.rst

@@ -1,138 +0,0 @@
-foreach
--------
-
-Evaluate a group of commands for each value in a list.
-
-.. code-block:: cmake
-
-  foreach(<loop_var> <items>)
-    <commands>
-  endforeach()
-
-where ``<items>`` is a list of items that are separated by
-semicolon or whitespace.
-All commands between ``foreach`` and the matching ``endforeach`` are recorded
-without being invoked.  Once the ``endforeach`` is evaluated, the recorded
-list of commands is invoked once for each item in ``<items>``.
-At the beginning of each iteration the variable ``<loop_var>`` will be set
-to the value of the current item.
-
-The scope of ``<loop_var>`` is restricted to the loop scope. See policy
-:policy:`CMP0124` for details.
-
-The commands :command:`break` and :command:`continue` provide means to
-escape from the normal control flow.
-
-Per legacy, the :command:`endforeach` command admits
-an optional ``<loop_var>`` argument.
-If used, it must be a verbatim
-repeat of the argument of the opening
-``foreach`` command.
-
-.. code-block:: cmake
-
-  foreach(<loop_var> RANGE <stop>)
-
-In this variant, ``foreach`` iterates over the numbers
-0, 1, ... up to (and including) the nonnegative integer ``<stop>``.
-
-.. code-block:: cmake
-
-  foreach(<loop_var> RANGE <start> <stop> [<step>])
-
-In this variant, ``foreach`` iterates over the numbers from
-``<start>`` up to at most ``<stop>`` in steps of ``<step>``.
-If ``<step>`` is not specified, then the step size is 1.
-The three arguments ``<start>`` ``<stop>`` ``<step>`` must
-all be nonnegative integers, and ``<stop>`` must not be
-smaller than ``<start>``; otherwise you enter the danger zone
-of undocumented behavior that may change in future releases.
-
-.. code-block:: cmake
-
-  foreach(<loop_var> IN [LISTS [<lists>]] [ITEMS [<items>]])
-
-In this variant, ``<lists>`` is a whitespace or semicolon
-separated list of list-valued variables. The ``foreach``
-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.
-
-The following example shows how the ``LISTS`` option is
-processed:
-
-.. code-block:: cmake
-
-  set(A 0;1)
-  set(B 2 3)
-  set(C "4 5")
-  set(D 6;7 8)
-  set(E "")
-  foreach(X IN LISTS A B C D E)
-      message(STATUS "X=${X}")
-  endforeach()
-
-yields::
-
-  -- X=0
-  -- X=1
-  -- X=2
-  -- X=3
-  -- X=4 5
-  -- X=6
-  -- X=7
-  -- X=8
-
-
-.. code-block:: cmake
-
-  foreach(<loop_var>... IN ZIP_LISTS <lists>)
-
-.. versionadded:: 3.17
-
-In this variant, ``<lists>`` is a whitespace or semicolon
-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
-  ``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.
-
-.. code-block:: cmake
-
-  list(APPEND English one two three four)
-  list(APPEND Bahasa satu dua tiga)
-
-  foreach(num IN ZIP_LISTS English Bahasa)
-      message(STATUS "num_0=${num_0}, num_1=${num_1}")
-  endforeach()
-
-  foreach(en ba IN ZIP_LISTS English Bahasa)
-      message(STATUS "en=${en}, ba=${ba}")
-  endforeach()
-
-yields::
-
-  -- num_0=one, num_1=satu
-  -- num_0=two, num_1=dua
-  -- num_0=three, num_1=tiga
-  -- num_0=four, num_1=
-  -- en=one, ba=satu
-  -- en=two, ba=dua
-  -- en=three, ba=tiga
-  -- en=four, ba=
-
-See Also
-^^^^^^^^
-
-* :command:`break`
-* :command:`continue`
-* :command:`endforeach`
-* :command:`while`

third-party/cmake-3.27.7-linux-x86_64/share/cmake-3.27/Help/command/function.rst

@@ -1,82 +0,0 @@
-function
---------
-
-Start recording a function for later invocation as a command.
-
-.. code-block:: cmake
-
-  function(<name> [<arg1> ...])
-    <commands>
-  endfunction()
-
-Defines a function named ``<name>`` that takes arguments named
-``<arg1>``, ...  The ``<commands>`` in the function definition
-are recorded; they are not executed until the function is invoked.
-
-Per legacy, the :command:`endfunction` command admits an optional
-``<name>`` argument. If used, it must be a verbatim repeat of the
-argument of the opening ``function`` command.
-
-A function opens a new scope: see :command:`set(var PARENT_SCOPE)` for
-details.
-
-See the :command:`cmake_policy()` command documentation for the behavior
-of policies inside functions.
-
-See the :command:`macro()` command documentation for differences
-between CMake functions and macros.
-
-Invocation
-^^^^^^^^^^
-
-The function invocation is case-insensitive. A function defined as
-
-.. code-block:: cmake
-
-  function(foo)
-    <commands>
-  endfunction()
-
-can be invoked through any of
-
-.. code-block:: cmake
-
-  foo()
-  Foo()
-  FOO()
-  cmake_language(CALL foo)
-
-and so on. However, it is strongly recommended to stay with the
-case chosen in the function definition. Typically functions use
-all-lowercase names.
-
-.. versionadded:: 3.18
-  The :command:`cmake_language(CALL ...)` command can also be used to
-  invoke the function.
-
-Arguments
-^^^^^^^^^
-
-When the function is invoked, the recorded ``<commands>`` are first
-modified by replacing formal parameters (``${arg1}``, ...) with the
-arguments passed, and then invoked as normal commands.
-
-In addition to referencing the formal parameters you can reference the
-``ARGC`` variable which will be set to the number of arguments passed
-into the function as well as ``ARGV0``, ``ARGV1``, ``ARGV2``, ...  which
-will have the actual values of the arguments passed in.  This facilitates
-creating functions with optional arguments.
-
-Furthermore, ``ARGV`` holds the list of all arguments given to the
-function and ``ARGN`` holds the list of arguments past the last expected
-argument.  Referencing to ``ARGV#`` arguments beyond ``ARGC`` have
-undefined behavior.  Checking that ``ARGC`` is greater than ``#`` is
-the only way to ensure that ``ARGV#`` was passed to the function as an
-extra argument.
-
-See Also
-^^^^^^^^
-
-* :command:`cmake_parse_arguments`
-* :command:`endfunction`
-* :command:`return`

third-party/cmake-3.27.7-linux-x86_64/share/cmake-3.27/Help/command/get_cmake_property.rst

@@ -1,23 +0,0 @@
-get_cmake_property
-------------------
-
-Get a global property of the CMake instance.
-
-.. code-block:: cmake
-
-  get_cmake_property(<var> <property>)
-
-Gets a global property from the CMake instance.  The value of
-the ``<property>`` is stored in the variable ``<var>``.
-If the property is not found, ``<var>`` will be set to ``NOTFOUND``.
-See the :manual:`cmake-properties(7)` manual for available properties.
-
-In addition to global properties, this command (for historical reasons)
-also supports the :prop_dir:`VARIABLES` and :prop_dir:`MACROS` directory
-properties.  It also supports a special ``COMPONENTS`` global property that
-lists the components given to the :command:`install` command.
-
-See Also
-^^^^^^^^
-
-* the :command:`get_property` command ``GLOBAL`` option

third-party/cmake-3.27.7-linux-x86_64/share/cmake-3.27/Help/command/get_directory_property.rst

@@ -1,41 +0,0 @@
-get_directory_property
-----------------------
-
-Get a property of ``DIRECTORY`` scope.
-
-.. code-block:: cmake
-
-  get_directory_property(<variable> [DIRECTORY <dir>] <prop-name>)
-
-Stores a property of directory scope in the named ``<variable>``.
-
-The ``DIRECTORY`` argument specifies another directory from which
-to retrieve the property value instead of the current directory.
-Relative paths are treated as relative to the
-current source directory.  CMake must already know about the directory,
-either by having added it through a call to :command:`add_subdirectory`
-or being the top level directory.
-
-.. versionadded:: 3.19
-  ``<dir>`` may reference a binary directory.
-
-If the property is not defined for the nominated directory scope,
-an empty string is returned.  In the case of ``INHERITED`` properties,
-if the property is not found for the nominated directory scope,
-the search will chain to a parent scope as described for the
-:command:`define_property` command.
-
-.. code-block:: cmake
-
-  get_directory_property(<variable> [DIRECTORY <dir>]
-                         DEFINITION <var-name>)
-
-Get a variable definition from a directory.  This form is useful to
-get a variable definition from another directory.
-
-
-See Also
-^^^^^^^^
-
-* :command:`define_property`
-* the more general :command:`get_property` command

third-party/cmake-3.27.7-linux-x86_64/share/cmake-3.27/Help/command/get_filename_component.rst

@@ -1,76 +0,0 @@
-get_filename_component
-----------------------
-
-Get a specific component of a full filename.
-
-.. versionchanged:: 3.20
-  This command has been superseded by the :command:`cmake_path` command, except
-  for ``REALPATH``, which is now offered by :command:`file(REAL_PATH)`, and
-  ``PROGRAM``, now available in :command:`separate_arguments(PROGRAM)`.
-
-.. versionchanged:: 3.24
-  The undocumented feature offering the capability to query the ``Windows``
-  registry is superseded by
-  :ref:`cmake_host_system_information(QUERY WINDOWS_REGISTRY)<Query Windows registry>`
-  command.
-
-.. code-block:: cmake
-
-  get_filename_component(<var> <FileName> <mode> [CACHE])
-
-Sets ``<var>`` to a component of ``<FileName>``, where ``<mode>`` is one of:
-
-::
-
- DIRECTORY = Directory without file name
- NAME      = File name without directory
- EXT       = File name longest extension (.b.c from d/a.b.c)
- NAME_WE   = File name with neither the directory nor the longest extension
- LAST_EXT  = File name last extension (.c from d/a.b.c)
- NAME_WLE  = File name with neither the directory nor the last extension
- PATH      = Legacy alias for DIRECTORY (use for CMake <= 2.8.11)
-
-.. versionadded:: 3.14
-  Added the ``LAST_EXT`` and ``NAME_WLE`` modes.
-
-Paths are returned with forward slashes and have no trailing slashes.
-If the optional ``CACHE`` argument is specified, the result variable is
-added to the cache.
-
-.. code-block:: cmake
-
-  get_filename_component(<var> <FileName> <mode> [BASE_DIR <dir>] [CACHE])
-
-.. versionadded:: 3.4
-
-Sets ``<var>`` to the absolute path of ``<FileName>``, where ``<mode>`` is one
-of:
-
-::
-
- ABSOLUTE  = Full path to file
- REALPATH  = Full path to existing file with symlinks resolved
-
-If the provided ``<FileName>`` is a relative path, it is evaluated relative
-to the given base directory ``<dir>``.  If no base directory is
-provided, the default base directory will be
-:variable:`CMAKE_CURRENT_SOURCE_DIR`.
-
-Paths are returned with forward slashes and have no trailing slashes.  If the
-optional ``CACHE`` argument is specified, the result variable is added to the
-cache.
-
-.. code-block:: cmake
-
-  get_filename_component(<var> <FileName> PROGRAM [PROGRAM_ARGS <arg_var>] [CACHE])
-
-The program in ``<FileName>`` will be found in the system search path or
-left as a full path.  If ``PROGRAM_ARGS`` is present with ``PROGRAM``, then
-any command-line arguments present in the ``<FileName>`` string are split
-from the program name and stored in ``<arg_var>``.  This is used to
-separate a program name from its arguments in a command line string.
-
-See Also
-^^^^^^^^
-
-* :command:`cmake_path`

third-party/cmake-3.27.7-linux-x86_64/share/cmake-3.27/Help/command/get_property.rst

@@ -1,107 +0,0 @@
-get_property
-------------
-
-Get a property.
-
-.. code-block:: cmake
-
-  get_property(<variable>
-               <GLOBAL             |
-                DIRECTORY [<dir>]  |
-                TARGET    <target> |
-                SOURCE    <source>
-                          [DIRECTORY <dir> | TARGET_DIRECTORY <target>] |
-                INSTALL   <file>   |
-                TEST      <test>   |
-                CACHE     <entry>  |
-                VARIABLE           >
-               PROPERTY <name>
-               [SET | DEFINED | BRIEF_DOCS | FULL_DOCS])
-
-Gets one property from one object in a scope.
-
-The first argument specifies the variable in which to store the result.
-The second argument determines the scope from which to get the property.
-It must be one of the following:
-
-``GLOBAL``
-  Scope is unique and does not accept a name.
-
-``DIRECTORY``
-  Scope defaults to the current directory but another
-  directory (already processed by CMake) may be named by the
-  full or relative path ``<dir>``.
-  Relative paths are treated as relative to the current source directory.
-  See also the :command:`get_directory_property` command.
-
-  .. versionadded:: 3.19
-    ``<dir>`` may reference a binary directory.
-
-``TARGET``
-  Scope must name one existing target.
-  See also the :command:`get_target_property` command.
-
-``SOURCE``
-  Scope must name one source file.  By default, the source file's property
-  will be read from the current source directory's scope.
-
-  .. versionadded:: 3.18
-    Directory scope can be overridden with one of the following sub-options:
-
-    ``DIRECTORY <dir>``
-      The source file property will be read from the ``<dir>`` directory's
-      scope.  CMake must already know about
-      the directory, either by having added it through a call
-      to :command:`add_subdirectory` or ``<dir>`` being the top level directory.
-      Relative paths are treated as relative to the current source directory.
-
-      .. versionadded:: 3.19
-        ``<dir>`` may reference a binary directory.
-
-    ``TARGET_DIRECTORY <target>``
-      The source file property will be read from the directory scope in which
-      ``<target>`` was created (``<target>`` must therefore already exist).
-
-  See also the :command:`get_source_file_property` command.
-
-``INSTALL``
-  .. versionadded:: 3.1
-
-  Scope must name one installed file path.
-
-``TEST``
-  Scope must name one existing test.
-  See also the :command:`get_test_property` command.
-
-``CACHE``
-  Scope must name one cache entry.
-
-``VARIABLE``
-  Scope is unique and does not accept a name.
-
-The required ``PROPERTY`` option is immediately followed by the name of
-the property to get.  If the property is not set an empty value is
-returned, although some properties support inheriting from a parent scope
-if defined to behave that way (see :command:`define_property`).
-
-If the ``SET`` option is given the variable is set to a boolean
-value indicating whether the property has been set.  If the ``DEFINED``
-option is given the variable is set to a boolean value indicating
-whether the property has been defined such as with the
-:command:`define_property` command.
-
-If ``BRIEF_DOCS`` or ``FULL_DOCS`` is given then the variable is set to a
-string containing documentation for the requested property.  If
-documentation is requested for a property that has not been defined
-``NOTFOUND`` is returned.
-
-.. note::
-
-  The :prop_sf:`GENERATED` source file property may be globally visible.
-  See its documentation for details.
-
-See Also
-^^^^^^^^
-
-* :command:`define_property`
-* :command:`set_property`

third-party/cmake-3.27.7-linux-x86_64/share/cmake-3.27/Help/command/get_source_file_property.rst

@@ -1,52 +0,0 @@
-get_source_file_property
-------------------------
-
-Get a property for a source file.
-
-.. code-block:: cmake
-
-  get_source_file_property(<variable> <file>
-                           [DIRECTORY <dir> | TARGET_DIRECTORY <target>]
-                           <property>)
-
-Gets a property from a source file.  The value of the property is
-stored in the specified ``<variable>``.  If the source property is not found,
-the behavior depends on whether it has been defined to be an ``INHERITED``
-property or not (see :command:`define_property`).  Non-inherited properties
-will set ``variable`` to ``NOTFOUND``, whereas inherited properties will search
-the relevant parent scope as described for the :command:`define_property`
-command and if still unable to find the property, ``variable`` will be set to
-an empty string.
-
-By default, the source file's property will be read from the current source
-directory's scope.
-
-.. versionadded:: 3.18
-  Directory scope can be overridden with one of the following sub-options:
-
-  ``DIRECTORY <dir>``
-    The source file property will be read from the ``<dir>`` directory's
-    scope.  CMake must already know about that source directory, either by
-    having added it through a call to :command:`add_subdirectory` or ``<dir>``
-    being the top level source directory.  Relative paths are treated as
-    relative to the current source directory.
-
-  ``TARGET_DIRECTORY <target>``
-    The source file property will be read from the directory scope in which
-    ``<target>`` was created (``<target>`` must therefore already exist).
-
-Use :command:`set_source_files_properties` to set property values.  Source
-file properties usually control how the file is built. One property that is
-always there is :prop_sf:`LOCATION`.
-
-.. note::
-
-  The :prop_sf:`GENERATED` source file property may be globally visible.
-  See its documentation for details.
-
-See Also
-^^^^^^^^
-
-* :command:`define_property`
-* the more general :command:`get_property` command
-* :command:`set_source_files_properties`

third-party/cmake-3.27.7-linux-x86_64/share/cmake-3.27/Help/command/get_target_property.rst

@@ -1,31 +0,0 @@
-get_target_property
--------------------
-
-Get a property from a target.
-
-.. code-block:: cmake
-
-  get_target_property(<VAR> target property)
-
-Get a property from a target.  The value of the property is stored in
-the variable ``<VAR>``.  If the target property is not found, the behavior
-depends on whether it has been defined to be an ``INHERITED`` property
-or not (see :command:`define_property`).  Non-inherited properties will
-set ``<VAR>`` to ``<VAR>-NOTFOUND``, whereas inherited properties will search
-the relevant parent scope as described for the :command:`define_property`
-command and if still unable to find the property, ``<VAR>`` will be set to
-an empty string.
-
-Use :command:`set_target_properties` to set target property values.
-Properties are usually used to control how a target is built, but some
-query the target instead.  This command can get properties for any
-target so far created.  The targets do not need to be in the current
-``CMakeLists.txt`` file.
-
-See Also
-^^^^^^^^
-
-* :command:`define_property`
-* the more general :command:`get_property` command
-* :command:`set_target_properties`
-* :ref:`Target Properties` for the list of properties known to CMake

third-party/cmake-3.27.7-linux-x86_64/share/cmake-3.27/Help/command/get_test_property.rst

@@ -1,26 +0,0 @@
-get_test_property
------------------
-
-Get a property of the test.
-
-.. code-block:: cmake
-
-  get_test_property(test property VAR)
-
-Get a property from the test.  The value of the property is stored in
-the variable ``VAR``.  If the test property is not found, the behavior
-depends on whether it has been defined to be an ``INHERITED`` property
-or not (see :command:`define_property`).  Non-inherited properties will
-set ``VAR`` to "NOTFOUND", whereas inherited properties will search the
-relevant parent scope as described for the :command:`define_property`
-command and if still unable to find the property, ``VAR`` will be set to
-an empty string.
-
-For a list of standard properties you can type
-:option:`cmake --help-property-list`.
-
-See Also
-^^^^^^^^
-
-* :command:`define_property`
-* the more general :command:`get_property` command

third-party/cmake-3.27.7-linux-x86_64/share/cmake-3.27/Help/command/if.rst

@@ -1,459 +0,0 @@
-if
---
-
-Conditionally execute a group of commands.
-
-Synopsis
-^^^^^^^^
-
-.. code-block:: cmake
-
-  if(<condition>)
-    <commands>
-  elseif(<condition>) # optional block, can be repeated
-    <commands>
-  else()              # optional block
-    <commands>
-  endif()
-
-Evaluates the ``condition`` argument of the ``if`` clause according to the
-`Condition syntax`_ described below. If the result is true, then the
-``commands`` in the ``if`` block are executed.
-Otherwise, optional ``elseif`` blocks are processed in the same way.
-Finally, if no ``condition`` is true, ``commands`` in the optional ``else``
-block are executed.
-
-Per legacy, the :command:`else` and :command:`endif` commands admit
-an optional ``<condition>`` argument.
-If used, it must be a verbatim
-repeat of the argument of the opening
-``if`` command.
-
-.. _`Condition Syntax`:
-
-Condition Syntax
-^^^^^^^^^^^^^^^^
-
-The following syntax applies to the ``condition`` argument of
-the ``if``, ``elseif`` and :command:`while` clauses.
-
-Compound conditions are evaluated in the following order of precedence:
-
-1. `Parentheses`_.
-
-2. Unary tests such as `EXISTS`_, `COMMAND`_, and `DEFINED`_.
-
-3. Binary tests such as `EQUAL`_, `LESS`_, `LESS_EQUAL`_, `GREATER`_,
-   `GREATER_EQUAL`_, `STREQUAL`_, `STRLESS`_, `STRLESS_EQUAL`_,
-   `STRGREATER`_, `STRGREATER_EQUAL`_, `VERSION_EQUAL`_, `VERSION_LESS`_,
-   `VERSION_LESS_EQUAL`_, `VERSION_GREATER`_, `VERSION_GREATER_EQUAL`_,
-   `PATH_EQUAL`_, and `MATCHES`_.
-
-4. Unary logical operator `NOT`_.
-
-5. Binary logical operators `AND`_ and `OR`_, from left to right,
-   without any short-circuit.
-
-Basic Expressions
-"""""""""""""""""
-
-.. signature:: if(<constant>)
-  :target: constant
-
-  True if the constant is ``1``, ``ON``, ``YES``, ``TRUE``, ``Y``,
-  or a non-zero number (including floating point numbers).
-  False if the constant is ``0``, ``OFF``,
-  ``NO``, ``FALSE``, ``N``, ``IGNORE``, ``NOTFOUND``, the empty string,
-  or ends in the suffix ``-NOTFOUND``.  Named boolean constants are
-  case-insensitive.  If the argument is not one of these specific
-  constants, it is treated as a variable or string (see `Variable Expansion`_
-  further below) and one of the following two forms applies.
-
-.. signature:: if(<variable>)
-  :target: variable
-
-  True if given a variable that is defined to a value that is not a false
-  constant.  False otherwise, including if the variable is undefined.
-  Note that macro arguments are not variables.
-  :ref:`Environment Variables <CMake Language Environment Variables>` also
-  cannot be tested this way, e.g. ``if(ENV{some_var})`` will always evaluate
-  to false.
-
-.. signature:: if(<string>)
-  :target: string
-
-  A quoted string always evaluates to false unless:
-
-  * The string's value is one of the true constants, or
-  * Policy :policy:`CMP0054` is not set to ``NEW`` and the string's value
-    happens to be a variable name that is affected by :policy:`CMP0054`'s
-    behavior.
-
-Logic Operators
-"""""""""""""""
-
-.. signature:: if(NOT <condition>)
-
-  True if the condition is not true.
-
-.. signature:: if(<cond1> AND <cond2>)
-  :target: AND
-
-  True if both conditions would be considered true individually.
-
-.. signature:: if(<cond1> OR <cond2>)
-  :target: OR
-
-  True if either condition would be considered true individually.
-
-.. signature:: if((condition) AND (condition OR (condition)))
-  :target: parentheses
-
-  The conditions inside the parenthesis are evaluated first and then
-  the remaining condition is evaluated as in the other examples.
-  Where there are nested parenthesis the innermost are evaluated as part
-  of evaluating the condition that contains them.
-
-Existence Checks
-""""""""""""""""
-
-.. signature:: if(COMMAND <command-name>)
-
-  True if the given name is a command, macro or function that can be
-  invoked.
-
-.. signature:: if(POLICY <policy-id>)
-
-  True if the given name is an existing policy (of the form ``CMP<NNNN>``).
-
-.. signature:: if(TARGET <target-name>)
-
-  True if the given name is an existing logical target name created
-  by a call to the :command:`add_executable`, :command:`add_library`,
-  or :command:`add_custom_target` command that has already been invoked
-  (in any directory).
-
-.. signature:: if(TEST <test-name>)
-
-  .. versionadded:: 3.3
-
-  True if the given name is an existing test name created by the
-  :command:`add_test` command.
-
-.. signature:: if(DEFINED <name>|CACHE{<name>}|ENV{<name>})
-
-  True if a variable, cache variable or environment variable
-  with given ``<name>`` is defined. The value of the variable
-  does not matter. Note the following caveats:
-
-  * Macro arguments are not variables.
-  * It is not possible to test directly whether a `<name>` is a non-cache
-    variable.  The expression ``if(DEFINED someName)`` will evaluate to true
-    if either a cache or non-cache variable ``someName`` exists.  In
-    comparison, the expression ``if(DEFINED CACHE{someName})`` will only
-    evaluate to true if a cache variable ``someName`` exists.  Both expressions
-    need to be tested if you need to know whether a non-cache variable exists:
-    ``if(DEFINED someName AND NOT DEFINED CACHE{someName})``.
-
- .. versionadded:: 3.14
-  Added support for ``CACHE{<name>}`` variables.
-
-.. signature:: if(<variable|string> IN_LIST <variable>)
-  :target: IN_LIST
-
-  .. versionadded:: 3.3
-
-  True if the given element is contained in the named list variable.
-
-File Operations
-"""""""""""""""
-
-.. signature:: if(EXISTS <path-to-file-or-directory>)
-
-  True if the named file or directory exists and is readable.  Behavior
-  is well-defined only for explicit full paths (a leading ``~/`` is not
-  expanded as a home directory and is considered a relative path).
-  Resolves symbolic links, i.e. if the named file or directory is a
-  symbolic link, returns true if the target of the symbolic link exists.
-
-  False if the given path is an empty string.
-
-.. signature:: if(<file1> IS_NEWER_THAN <file2>)
-  :target: IS_NEWER_THAN
-
-  True if ``file1`` is newer than ``file2`` or if one of the two files doesn't
-  exist.  Behavior is well-defined only for full paths.  If the file
-  time stamps are exactly the same, an ``IS_NEWER_THAN`` comparison returns
-  true, so that any dependent build operations will occur in the event
-  of a tie.  This includes the case of passing the same file name for
-  both file1 and file2.
-
-.. signature:: if(IS_DIRECTORY <path>)
-
-  True if ``path`` is a directory.  Behavior is well-defined only
-  for full paths.
-
-  False if the given path is an empty string.
-
-.. signature:: if(IS_SYMLINK <path>)
-
-  True if the given path is a symbolic link.  Behavior is well-defined
-  only for full paths.
-
-.. signature:: if(IS_ABSOLUTE <path>)
-
-  True if the given path is an absolute path.  Note the following special
-  cases:
-
-  * An empty ``path`` evaluates to false.
-  * On Windows hosts, any ``path`` that begins with a drive letter and colon
-    (e.g. ``C:``), a forward slash or a backslash will evaluate to true.
-    This means a path like ``C:no\base\dir`` will evaluate to true, even
-    though the non-drive part of the path is relative.
-  * On non-Windows hosts, any ``path`` that begins with a tilde (``~``)
-    evaluates to true.
-
-Comparisons
-"""""""""""
-
-.. signature:: if(<variable|string> MATCHES <regex>)
-  :target: MATCHES
-
-  True if the given string or variable's value matches the given regular
-  expression.  See :ref:`Regex Specification` for regex format.
-
-  .. versionadded:: 3.9
-   ``()`` groups are captured in :variable:`CMAKE_MATCH_<n>` variables.
-
-.. signature:: if(<variable|string> LESS <variable|string>)
-  :target: LESS
-
-  True if the given string or variable's value is a valid number and less
-  than that on the right.
-
-.. signature:: if(<variable|string> GREATER <variable|string>)
-  :target: GREATER
-
-  True if the given string or variable's value is a valid number and greater
-  than that on the right.
-
-.. signature:: if(<variable|string> EQUAL <variable|string>)
-  :target: EQUAL
-
-  True if the given string or variable's value is a valid number and equal
-  to that on the right.
-
-.. signature:: if(<variable|string> LESS_EQUAL <variable|string>)
-  :target: LESS_EQUAL
-
-  .. versionadded:: 3.7
-
-  True if the given string or variable's value is a valid number and less
-  than or equal to that on the right.
-
-.. signature:: if(<variable|string> GREATER_EQUAL <variable|string>)
-  :target: GREATER_EQUAL
-
-  .. versionadded:: 3.7
-
-  True if the given string or variable's value is a valid number and greater
-  than or equal to that on the right.
-
-.. signature:: if(<variable|string> STRLESS <variable|string>)
-  :target: STRLESS
-
-  True if the given string or variable's value is lexicographically less
-  than the string or variable on the right.
-
-.. signature:: if(<variable|string> STRGREATER <variable|string>)
-  :target: STRGREATER
-
-  True if the given string or variable's value is lexicographically greater
-  than the string or variable on the right.
-
-.. signature:: if(<variable|string> STREQUAL <variable|string>)
-  :target: STREQUAL
-
-  True if the given string or variable's value is lexicographically equal
-  to the string or variable on the right.
-
-.. signature:: if(<variable|string> STRLESS_EQUAL <variable|string>)
-  :target: STRLESS_EQUAL
-
-  .. versionadded:: 3.7
-
-  True if the given string or variable's value is lexicographically less
-  than or equal to the string or variable on the right.
-
-.. signature:: if(<variable|string> STRGREATER_EQUAL <variable|string>)
-  :target: STRGREATER_EQUAL
-
-  .. versionadded:: 3.7
-
-  True if the given string or variable's value is lexicographically greater
-  than or equal to the string or variable on the right.
-
-Version Comparisons
-"""""""""""""""""""
-
-.. signature:: if(<variable|string> VERSION_LESS <variable|string>)
-  :target: VERSION_LESS
-
-  Component-wise integer version number comparison (version format is
-  ``major[.minor[.patch[.tweak]]]``, omitted components are treated as zero).
-  Any non-integer version component or non-integer trailing part of a version
-  component effectively truncates the string at that point.
-
-.. signature:: if(<variable|string> VERSION_GREATER <variable|string>)
-  :target: VERSION_GREATER
-
-  Component-wise integer version number comparison (version format is
-  ``major[.minor[.patch[.tweak]]]``, omitted components are treated as zero).
-  Any non-integer version component or non-integer trailing part of a version
-  component effectively truncates the string at that point.
-
-.. signature:: if(<variable|string> VERSION_EQUAL <variable|string>)
-  :target: VERSION_EQUAL
-
-  Component-wise integer version number comparison (version format is
-  ``major[.minor[.patch[.tweak]]]``, omitted components are treated as zero).
-  Any non-integer version component or non-integer trailing part of a version
-  component effectively truncates the string at that point.
-
-.. signature:: if(<variable|string> VERSION_LESS_EQUAL <variable|string>)
-  :target: VERSION_LESS_EQUAL
-
-  .. versionadded:: 3.7
-
-  Component-wise integer version number comparison (version format is
-  ``major[.minor[.patch[.tweak]]]``, omitted components are treated as zero).
-  Any non-integer version component or non-integer trailing part of a version
-  component effectively truncates the string at that point.
-
-.. signature:: if(<variable|string> VERSION_GREATER_EQUAL <variable|string>)
-  :target: VERSION_GREATER_EQUAL
-
-  .. versionadded:: 3.7
-
-  Component-wise integer version number comparison (version format is
-  ``major[.minor[.patch[.tweak]]]``, omitted components are treated as zero).
-  Any non-integer version component or non-integer trailing part of a version
-  component effectively truncates the string at that point.
-
-Path Comparisons
-""""""""""""""""
-
-.. signature:: if(<variable|string> PATH_EQUAL <variable|string>)
-  :target: PATH_EQUAL
-
-  .. versionadded:: 3.24
-
-  Compares the two paths component-by-component.  Only if every component of
-  both paths match will the two paths compare equal.  Multiple path separators
-  are effectively collapsed into a single separator, but note that backslashes
-  are not converted to forward slashes.  No other
-  :ref:`path normalization <Normalization>` is performed.
-
-  Component-wise comparison is superior to string-based comparison due to the
-  handling of multiple path separators.  In the following example, the
-  expression evaluates to true using ``PATH_EQUAL``, but false with
-  ``STREQUAL``:
-
-  .. code-block:: cmake
-
-    # comparison is TRUE
-    if ("/a//b/c" PATH_EQUAL "/a/b/c")
-       ...
-    endif()
-
-    # comparison is FALSE
-    if ("/a//b/c" STREQUAL "/a/b/c")
-       ...
-    endif()
-
-  See :ref:`cmake_path(COMPARE) <Path COMPARE>` for more details.
-
-Variable Expansion
-^^^^^^^^^^^^^^^^^^
-
-The if command was written very early in CMake's history, predating
-the ``${}`` variable evaluation syntax, and for convenience evaluates
-variables named by its arguments as shown in the above signatures.
-Note that normal variable evaluation with ``${}`` applies before the if
-command even receives the arguments.  Therefore code like
-
-.. code-block:: cmake
-
- set(var1 OFF)
- set(var2 "var1")
- if(${var2})
-
-appears to the if command as
-
-.. code-block:: cmake
-
-  if(var1)
-
-and is evaluated according to the ``if(<variable>)`` case documented
-above.  The result is ``OFF`` which is false.  However, if we remove the
-``${}`` from the example then the command sees
-
-.. code-block:: cmake
-
-  if(var2)
-
-which is true because ``var2`` is defined to ``var1`` which is not a false
-constant.
-
-Automatic evaluation applies in the other cases whenever the
-above-documented condition syntax accepts ``<variable|string>``:
-
-* The left hand argument to `MATCHES`_ is first checked to see if it is
-  a defined variable.  If so, the variable's value is used, otherwise the
-  original value is used.
-
-* If the left hand argument to `MATCHES`_ is missing it returns false
-  without error
-
-* Both left and right hand arguments to `LESS`_, `GREATER`_, `EQUAL`_,
-  `LESS_EQUAL`_, and `GREATER_EQUAL`_, are independently tested to see if
-  they are defined variables.  If so, their defined values are used otherwise
-  the original value is used.
-
-* Both left and right hand arguments to `STRLESS`_, `STRGREATER`_,
-  `STREQUAL`_, `STRLESS_EQUAL`_, and `STRGREATER_EQUAL`_ are independently
-  tested to see if they are defined variables.  If so, their defined values are
-  used otherwise the original value is used.
-
-* Both left and right hand arguments to `VERSION_LESS`_,
-  `VERSION_GREATER`_, `VERSION_EQUAL`_, `VERSION_LESS_EQUAL`_, and
-  `VERSION_GREATER_EQUAL`_ are independently tested to see if they are defined
-  variables.  If so, their defined values are used otherwise the original value
-  is used.
-
-* The right hand argument to `NOT`_ is tested to see if it is a boolean
-  constant.  If so, the value is used, otherwise it is assumed to be a
-  variable and it is dereferenced.
-
-* The left and right hand arguments to `AND`_ and `OR`_ are independently
-  tested to see if they are boolean constants.  If so, they are used as
-  such, otherwise they are assumed to be variables and are dereferenced.
-
-.. versionchanged:: 3.1
-  To prevent ambiguity, potential variable or keyword names can be
-  specified in a :ref:`Quoted Argument` or a :ref:`Bracket Argument`.
-  A quoted or bracketed variable or keyword will be interpreted as a
-  string and not dereferenced or interpreted.
-  See policy :policy:`CMP0054`.
-
-There is no automatic evaluation for environment or cache
-:ref:`Variable References`.  Their values must be referenced as
-``$ENV{<name>}`` or ``$CACHE{<name>}`` wherever the above-documented
-condition syntax accepts ``<variable|string>``.
-
-See also
-^^^^^^^^
-
-* :command:`else`
-* :command:`elseif`
-* :command:`endif`

third-party/cmake-3.27.7-linux-x86_64/share/cmake-3.27/Help/command/include.rst

@@ -1,25 +0,0 @@
-include
--------
-
-Load and run CMake code from a file or module.
-
-.. code-block:: cmake
-
-  include(<file|module> [OPTIONAL] [RESULT_VARIABLE <var>]
-                        [NO_POLICY_SCOPE])
-
-Loads and runs CMake code from the file given.  Variable reads and
-writes access the scope of the caller (dynamic scoping).  If ``OPTIONAL``
-is present, then no error is raised if the file does not exist.  If
-``RESULT_VARIABLE`` is given the variable ``<var>`` will be set to the
-full filename which has been included or ``NOTFOUND`` if it failed.
-
-If a module is specified instead of a file, the file with name
-``<modulename>.cmake`` is searched first in :variable:`CMAKE_MODULE_PATH`,
-then in the CMake module directory.  There is one exception to this: if
-the file which calls ``include()`` is located itself in the CMake builtin
-module directory, then first the CMake builtin module directory is searched and
-:variable:`CMAKE_MODULE_PATH` afterwards.  See also policy :policy:`CMP0017`.
-
-See the :command:`cmake_policy` command documentation for discussion of the
-``NO_POLICY_SCOPE`` option.

third-party/cmake-3.27.7-linux-x86_64/share/cmake-3.27/Help/command/include_directories.rst

@@ -1,44 +0,0 @@
-include_directories
--------------------
-
-Add include directories to the build.
-
-.. code-block:: cmake
-
-  include_directories([AFTER|BEFORE] [SYSTEM] dir1 [dir2 ...])
-
-Add the given directories to those the compiler uses to search for
-include files.  Relative paths are interpreted as relative to the
-current source directory.
-
-The include directories are added to the :prop_dir:`INCLUDE_DIRECTORIES`
-directory property for the current ``CMakeLists`` file.  They are also
-added to the :prop_tgt:`INCLUDE_DIRECTORIES` target property for each
-target in the current ``CMakeLists`` file.  The target property values
-are the ones used by the generators.
-
-By default the directories specified are appended onto the current list of
-directories.  This default behavior can be changed by setting
-:variable:`CMAKE_INCLUDE_DIRECTORIES_BEFORE` to ``ON``.  By using
-``AFTER`` or ``BEFORE`` explicitly, you can select between appending and
-prepending, independent of the default.
-
-If the ``SYSTEM`` option is given, the compiler will be told the
-directories are meant as system include directories on some platforms.
-Signaling this setting might achieve effects such as the compiler
-skipping warnings, or these fixed-install system files not being
-considered in dependency calculations - see compiler docs.
-
-.. |command_name| replace:: ``include_directories``
-.. include:: GENEX_NOTE.txt
-
-.. note::
-
-  Prefer the :command:`target_include_directories` command to add include
-  directories to individual targets and optionally propagate/export them
-  to dependents.
-
-See Also
-^^^^^^^^
-
-* :command:`target_include_directories`

third-party/cmake-3.27.7-linux-x86_64/share/cmake-3.27/Help/command/include_external_msproject.rst

@@ -1,27 +0,0 @@
-include_external_msproject
---------------------------
-
-Include an external Microsoft project file in a workspace.
-
-.. code-block:: cmake
-
-  include_external_msproject(projectname location
-                             [TYPE projectTypeGUID]
-                             [GUID projectGUID]
-                             [PLATFORM platformName]
-                             dep1 dep2 ...)
-
-Includes an external Microsoft project in the generated workspace
-file.  Currently does nothing on UNIX.  This will create a target
-named ``[projectname]``.  This can be used in the :command:`add_dependencies`
-command to make things depend on the external project.
-
-``TYPE``, ``GUID`` and ``PLATFORM`` are optional parameters that allow one to
-specify the type of project, id (``GUID``) of the project and the name of
-the target platform.  This is useful for projects requiring values
-other than the default (e.g.  WIX projects).
-
-.. versionadded:: 3.9
-  If the imported project has different configuration names than the
-  current project, set the :prop_tgt:`MAP_IMPORTED_CONFIG_<CONFIG>`
-  target property to specify the mapping.

third-party/cmake-3.27.7-linux-x86_64/share/cmake-3.27/Help/command/include_guard.rst

@@ -1,48 +0,0 @@
-include_guard
--------------
-
-.. versionadded:: 3.10
-
-Provides an include guard for the file currently being processed by CMake.
-
-.. code-block:: cmake
-
-  include_guard([DIRECTORY|GLOBAL])
-
-Sets up an include guard for the current CMake file (see the
-:variable:`CMAKE_CURRENT_LIST_FILE` variable documentation).
-
-CMake will end its processing of the current file at the location of the
-``include_guard`` command if the current file has already been
-processed for the applicable scope (see below). This provides functionality
-similar to the include guards commonly used in source headers or to the
-``#pragma once`` directive. If the current file has been processed previously
-for the applicable scope, the effect is as though :command:`return` had been
-called. Do not call this command from inside a function being defined within
-the current file.
-
-An optional argument specifying the scope of the guard may be provided.
-Possible values for the option are:
-
-``DIRECTORY``
-  The include guard applies within the current directory and below. The file
-  will only be included once within this directory scope, but may be included
-  again by other files outside of this directory (i.e. a parent directory or
-  another directory not pulled in by :command:`add_subdirectory` or
-  :command:`include` from the current file or its children).
-
-``GLOBAL``
-  The include guard applies globally to the whole build. The current file
-  will only be included once regardless of the scope.
-
-If no arguments given, ``include_guard`` has the same scope as a variable,
-meaning that the include guard effect is isolated by the most recent
-function scope or current directory if no inner function scopes exist.
-In this case the command behavior is the same as:
-
-.. code-block:: cmake
-
-  if(__CURRENT_FILE_VAR__)
-    return()
-  endif()
-  set(__CURRENT_FILE_VAR__ TRUE)

third-party/cmake-3.27.7-linux-x86_64/share/cmake-3.27/Help/command/include_regular_expression.rst

@@ -1,18 +0,0 @@
-include_regular_expression
---------------------------
-
-Set the regular expression used for dependency checking.
-
-.. code-block:: cmake
-
-  include_regular_expression(regex_match [regex_complain])
-
-Sets the regular expressions used in dependency checking.  Only files
-matching ``regex_match`` will be traced as dependencies.  Only files
-matching ``regex_complain`` will generate warnings if they cannot be found
-(standard header paths are not searched).  The defaults are:
-
-::
-
-  regex_match    = "^.*$" (match everything)
-  regex_complain = "^$" (match empty string only)