Update upstream source from tag 'upstream/3.21.2'
Update to upstream version '3.21.2' with Debian dir b27bd7be248c7d08c70eed4668064fb881d7fe25
This commit is contained in:
commit
1f305b0624
@ -20,6 +20,8 @@ SortUsingDeclarations: false
|
||||
SpaceAfterTemplateKeyword: true
|
||||
IncludeBlocks: Regroup
|
||||
IncludeCategories:
|
||||
- Regex: '^[<"]cmSTL\.hxx'
|
||||
Priority: -2
|
||||
- Regex: '^[<"]cmConfigure\.h'
|
||||
Priority: -1
|
||||
- Regex: '^<queue>'
|
||||
|
@ -7,6 +7,7 @@ bugprone-*,\
|
||||
-bugprone-too-small-loop-variable,\
|
||||
google-readability-casting,\
|
||||
misc-*,\
|
||||
-misc-no-recursion,\
|
||||
-misc-non-private-member-variables-in-classes,\
|
||||
-misc-static-assert,\
|
||||
modernize-*,\
|
||||
@ -18,6 +19,7 @@ modernize-*,\
|
||||
performance-*,\
|
||||
readability-*,\
|
||||
-readability-convert-member-functions-to-static,\
|
||||
-readability-function-cognitive-complexity,\
|
||||
-readability-function-size,\
|
||||
-readability-identifier-naming,\
|
||||
-readability-implicit-bool-conversion,\
|
||||
|
@ -27,6 +27,9 @@
|
||||
;; cmake-command-help Written by James Bigler
|
||||
;;
|
||||
|
||||
(require 'rst)
|
||||
(require 'rx)
|
||||
|
||||
(defcustom cmake-mode-cmake-executable "cmake"
|
||||
"*The name of the cmake executable.
|
||||
|
||||
@ -188,6 +191,61 @@ the indentation. Otherwise it retains the same position on the line"
|
||||
)
|
||||
)
|
||||
|
||||
|
||||
;------------------------------------------------------------------------------
|
||||
|
||||
;;
|
||||
;; Navigation / marking by function or macro
|
||||
;;
|
||||
|
||||
(defconst cmake--regex-defun-start
|
||||
(rx line-start
|
||||
(zero-or-more space)
|
||||
(or "function" "macro")
|
||||
(zero-or-more space)
|
||||
"("))
|
||||
|
||||
(defconst cmake--regex-defun-end
|
||||
(rx line-start
|
||||
(zero-or-more space)
|
||||
"end"
|
||||
(or "function" "macro")
|
||||
(zero-or-more space)
|
||||
"(" (zero-or-more (not-char ")")) ")"))
|
||||
|
||||
(defun cmake-beginning-of-defun ()
|
||||
"Move backward to the beginning of a CMake function or macro.
|
||||
|
||||
Return t unless search stops due to beginning of buffer."
|
||||
(interactive)
|
||||
(when (not (region-active-p))
|
||||
(push-mark))
|
||||
(let ((case-fold-search t))
|
||||
(when (re-search-backward cmake--regex-defun-start nil 'move)
|
||||
t)))
|
||||
|
||||
(defun cmake-end-of-defun ()
|
||||
"Move forward to the end of a CMake function or macro.
|
||||
|
||||
Return t unless search stops due to end of buffer."
|
||||
(interactive)
|
||||
(when (not (region-active-p))
|
||||
(push-mark))
|
||||
(let ((case-fold-search t))
|
||||
(when (re-search-forward cmake--regex-defun-end nil 'move)
|
||||
(forward-line)
|
||||
t)))
|
||||
|
||||
(defun cmake-mark-defun ()
|
||||
"Mark the current CMake function or macro.
|
||||
|
||||
This puts the mark at the end, and point at the beginning."
|
||||
(interactive)
|
||||
(cmake-end-of-defun)
|
||||
(push-mark nil :nomsg :activate)
|
||||
(cmake-beginning-of-defun))
|
||||
|
||||
|
||||
;------------------------------------------------------------------------------
|
||||
|
||||
;;
|
||||
@ -240,6 +298,12 @@ the indentation. Otherwise it retains the same position on the line"
|
||||
; Setup comment syntax.
|
||||
(set (make-local-variable 'comment-start) "#"))
|
||||
|
||||
;; Default cmake-mode key bindings
|
||||
(define-key cmake-mode-map "\e\C-a" #'cmake-beginning-of-defun)
|
||||
(define-key cmake-mode-map "\e\C-e" #'cmake-end-of-defun)
|
||||
(define-key cmake-mode-map "\e\C-h" #'cmake-mark-defun)
|
||||
|
||||
|
||||
; Help mode starts here
|
||||
|
||||
|
||||
@ -258,7 +322,27 @@ optional argument topic will be appended to the argument list."
|
||||
(save-selected-window
|
||||
(select-window (display-buffer buffer 'not-this-window))
|
||||
(cmake-mode)
|
||||
(read-only-mode 1))
|
||||
(read-only-mode 1)
|
||||
(view-mode 1))
|
||||
)
|
||||
)
|
||||
|
||||
;;;###autoload
|
||||
(defun cmake-command-run-help (type &optional topic buffer)
|
||||
"`cmake-command-run' but rendered in `rst-mode'."
|
||||
(interactive "s")
|
||||
(let* ((bufname (if buffer buffer (concat "*CMake" type (if topic "-") topic "*")))
|
||||
(buffer (if (get-buffer bufname) (get-buffer bufname) (generate-new-buffer bufname)))
|
||||
(command (concat cmake-mode-cmake-executable " " type " " topic))
|
||||
;; Turn of resizing of mini-windows for shell-command.
|
||||
(resize-mini-windows nil)
|
||||
)
|
||||
(shell-command command buffer)
|
||||
(save-selected-window
|
||||
(select-window (display-buffer buffer 'not-this-window))
|
||||
(rst-mode)
|
||||
(read-only-mode 1)
|
||||
(view-mode 1))
|
||||
)
|
||||
)
|
||||
|
||||
@ -266,7 +350,7 @@ optional argument topic will be appended to the argument list."
|
||||
(defun cmake-help-list-commands ()
|
||||
"Prints out a list of the cmake commands."
|
||||
(interactive)
|
||||
(cmake-command-run "--help-command-list")
|
||||
(cmake-command-run-help "--help-command-list")
|
||||
)
|
||||
|
||||
(defvar cmake-commands '() "List of available topics for --help-command.")
|
||||
@ -292,7 +376,7 @@ and store the result as a list in LISTVAR."
|
||||
(if (not (symbol-value listvar))
|
||||
(let ((temp-buffer-name "*CMake Temporary*"))
|
||||
(save-window-excursion
|
||||
(cmake-command-run (concat "--help-" listname "-list") nil temp-buffer-name)
|
||||
(cmake-command-run-help (concat "--help-" listname "-list") nil temp-buffer-name)
|
||||
(with-current-buffer temp-buffer-name
|
||||
; FIXME: Ignore first line if it is "cmake version ..." from CMake < 3.0.
|
||||
(set listvar (split-string (buffer-substring-no-properties (point-min) (point-max)) "\n" t)))))
|
||||
@ -326,25 +410,25 @@ and store the result as a list in LISTVAR."
|
||||
(defun cmake-help-command ()
|
||||
"Prints out the help message for the command the cursor is on."
|
||||
(interactive)
|
||||
(cmake-command-run "--help-command" (cmake-help-type "command") "*CMake Help*"))
|
||||
(cmake-command-run-help "--help-command" (cmake-help-type "command") "*CMake Help*"))
|
||||
|
||||
;;;###autoload
|
||||
(defun cmake-help-module ()
|
||||
"Prints out the help message for the module the cursor is on."
|
||||
(interactive)
|
||||
(cmake-command-run "--help-module" (cmake-help-type "module") "*CMake Help*"))
|
||||
(cmake-command-run-help "--help-module" (cmake-help-type "module") "*CMake Help*"))
|
||||
|
||||
;;;###autoload
|
||||
(defun cmake-help-variable ()
|
||||
"Prints out the help message for the variable the cursor is on."
|
||||
(interactive)
|
||||
(cmake-command-run "--help-variable" (cmake-help-type "variable") "*CMake Help*"))
|
||||
(cmake-command-run-help "--help-variable" (cmake-help-type "variable") "*CMake Help*"))
|
||||
|
||||
;;;###autoload
|
||||
(defun cmake-help-property ()
|
||||
"Prints out the help message for the property the cursor is on."
|
||||
(interactive)
|
||||
(cmake-command-run "--help-property" (cmake-help-type "property") "*CMake Help*"))
|
||||
(cmake-command-run-help "--help-property" (cmake-help-type "property") "*CMake Help*"))
|
||||
|
||||
;;;###autoload
|
||||
(defun cmake-help ()
|
||||
@ -367,13 +451,13 @@ and store the result as a list in LISTVAR."
|
||||
(if (string= input "")
|
||||
(error "No argument given")
|
||||
(if (member input command-list)
|
||||
(cmake-command-run "--help-command" input "*CMake Help*")
|
||||
(cmake-command-run-help "--help-command" input "*CMake Help*")
|
||||
(if (member input variable-list)
|
||||
(cmake-command-run "--help-variable" input "*CMake Help*")
|
||||
(cmake-command-run-help "--help-variable" input "*CMake Help*")
|
||||
(if (member input module-list)
|
||||
(cmake-command-run "--help-module" input "*CMake Help*")
|
||||
(cmake-command-run-help "--help-module" input "*CMake Help*")
|
||||
(if (member input property-list)
|
||||
(cmake-command-run "--help-property" input "*CMake Help*")
|
||||
(cmake-command-run-help "--help-property" input "*CMake Help*")
|
||||
(error "Not a know help topic.") ; this really should not happen
|
||||
))))))
|
||||
)
|
||||
|
@ -9,7 +9,7 @@
|
||||
" Former Maintainer: Karthik Krishnan <karthik.krishnan@kitware.com>
|
||||
" Last Change: @DATE@
|
||||
"
|
||||
" Licence: The CMake license applies to this file. See
|
||||
" License: The CMake license applies to this file. See
|
||||
" https://cmake.org/licensing
|
||||
" This implies that distribution with Vim is allowed
|
||||
|
||||
|
@ -3,6 +3,8 @@
|
||||
use strict;
|
||||
use warnings;
|
||||
use POSIX qw(strftime);
|
||||
use JSON;
|
||||
use File::Basename;
|
||||
|
||||
#my $cmake = "/home/pboettch/devel/upstream/cmake/build/bin/cmake";
|
||||
my $cmake = "cmake";
|
||||
@ -96,6 +98,28 @@ close(CMAKE);
|
||||
# transform all properties in a hash
|
||||
my %properties = map { $_ => 1 } @properties;
|
||||
|
||||
# read in manually written files
|
||||
my $modules_dir = dirname(__FILE__) . "/modules";
|
||||
opendir(DIR, $modules_dir) || die "can't opendir $modules_dir: $!";
|
||||
my @json_files = grep { /\.json$/ && -f "$modules_dir/$_" } readdir(DIR);
|
||||
closedir DIR;
|
||||
|
||||
foreach my $file (@json_files) {
|
||||
local $/; # Enable 'slurp' mode
|
||||
open my $fh, "<", $modules_dir."/".$file;
|
||||
my $json = <$fh>;
|
||||
close $fh;
|
||||
|
||||
my $mod = decode_json($json);
|
||||
foreach my $var (@{$mod->{variables}}) {
|
||||
$variables{$var} = 1;
|
||||
}
|
||||
|
||||
while (my ($cmd, $keywords) = each %{$mod->{commands}}) {
|
||||
$keywords{$cmd} = [ sort @{$keywords} ];
|
||||
}
|
||||
}
|
||||
|
||||
# version
|
||||
open(CMAKE, "$cmake --version|");
|
||||
my $version = 'unknown';
|
||||
|
@ -5,7 +5,7 @@
|
||||
" Former Maintainer: Karthik Krishnan <karthik.krishnan@kitware.com>
|
||||
" Last Change: 2017 Aug 30
|
||||
"
|
||||
" Licence: The CMake license applies to this file. See
|
||||
" License: The CMake license applies to this file. See
|
||||
" https://cmake.org/licensing
|
||||
" This implies that distribution with Vim is allowed
|
||||
|
||||
|
File diff suppressed because it is too large
Load Diff
@ -133,6 +133,9 @@ if(CMake_INSTALL_COMPONENTS)
|
||||
if(SPHINX_QTHELP)
|
||||
list(APPEND _CPACK_IFW_COMPONENTS_ALL sphinx-qthelp)
|
||||
endif()
|
||||
if(SPHINX_LATEXPDF)
|
||||
list(APPEND _CPACK_IFW_COMPONENTS_ALL sphinx-latexpdf)
|
||||
endif()
|
||||
if(CMake_BUILD_DEVELOPER_REFERENCE)
|
||||
if(CMake_BUILD_DEVELOPER_REFERENCE_HTML)
|
||||
list(APPEND _CPACK_IFW_COMPONENTS_ALL cmake-developer-reference-html)
|
||||
|
@ -1,7 +1,7 @@
|
||||
# Distributed under the OSI-approved BSD 3-Clause License. See accompanying
|
||||
# file Copyright.txt or https://cmake.org/licensing for details.
|
||||
|
||||
cmake_minimum_required(VERSION 3.1...3.15 FATAL_ERROR)
|
||||
cmake_minimum_required(VERSION 3.1...3.19 FATAL_ERROR)
|
||||
set(CMAKE_USER_MAKE_RULES_OVERRIDE_C ${CMAKE_CURRENT_SOURCE_DIR}/Source/Modules/OverrideC.cmake)
|
||||
set(CMAKE_USER_MAKE_RULES_OVERRIDE_CXX ${CMAKE_CURRENT_SOURCE_DIR}/Source/Modules/OverrideCXX.cmake)
|
||||
project(CMake)
|
||||
@ -108,6 +108,11 @@ if(NOT CMake_TEST_EXTERNAL_CMAKE)
|
||||
endif()
|
||||
endif()
|
||||
|
||||
# Inform STL library header wrappers whether to use system versions.
|
||||
configure_file(${CMake_SOURCE_DIR}/Utilities/std/cmSTL.hxx.in
|
||||
${CMake_BINARY_DIR}/Utilities/cmSTL.hxx
|
||||
@ONLY)
|
||||
|
||||
# set the internal encoding of CMake to UTF-8
|
||||
set(KWSYS_ENCODING_DEFAULT_CODEPAGE CP_UTF8)
|
||||
|
||||
@ -356,6 +361,9 @@ macro (CMAKE_BUILD_UTILITIES)
|
||||
if(CMake_NO_CXX_STANDARD)
|
||||
set(KWSYS_CXX_STANDARD "")
|
||||
endif()
|
||||
if(CMake_NO_SELF_BACKTRACE)
|
||||
set(KWSYS_NO_EXECINFO 1)
|
||||
endif()
|
||||
if(WIN32)
|
||||
# FIXME: Teach KWSys to hard-code these checks on Windows.
|
||||
set(KWSYS_C_HAS_CLOCK_GETTIME_MONOTONIC_COMPILED 0)
|
||||
@ -574,6 +582,7 @@ macro (CMAKE_BUILD_UTILITIES)
|
||||
set(LIBLZMA_INCLUDE_DIR
|
||||
"${CMAKE_CURRENT_SOURCE_DIR}/Utilities/cmliblzma/liblzma/api")
|
||||
set(LIBLZMA_LIBRARY cmliblzma)
|
||||
set(HAVE_LZMA_STREAM_ENCODER_MT 1)
|
||||
endif()
|
||||
endif()
|
||||
|
||||
@ -638,7 +647,11 @@ macro (CMAKE_BUILD_UTILITIES)
|
||||
#---------------------------------------------------------------------
|
||||
# Build libuv library.
|
||||
if(CMAKE_USE_SYSTEM_LIBUV)
|
||||
find_package(LibUV 1.10.0)
|
||||
if(WIN32)
|
||||
find_package(LibUV 1.38.0)
|
||||
else()
|
||||
find_package(LibUV 1.10.0)
|
||||
endif()
|
||||
if(NOT LIBUV_FOUND)
|
||||
message(FATAL_ERROR
|
||||
"CMAKE_USE_SYSTEM_LIBUV is ON but a libuv is not found!")
|
||||
|
@ -38,7 +38,7 @@ To contribute patches:
|
||||
#. Push the topic branch to a personal repository fork on GitLab.
|
||||
#. Create a GitLab Merge Request targeting the upstream ``master`` branch
|
||||
(even if the change is intended for merge to the ``release`` branch).
|
||||
Check the box labelled "Allow commits from members who can merge to the
|
||||
Check the box labeled "Allow commits from members who can merge to the
|
||||
target branch". This will allow maintainers to make minor edits on your
|
||||
behalf.
|
||||
|
||||
|
@ -6,7 +6,9 @@
|
||||
set(CTEST_PROJECT_NAME "CMake")
|
||||
set(CTEST_NIGHTLY_START_TIME "1:00:00 UTC")
|
||||
|
||||
set(CTEST_DROP_METHOD "http")
|
||||
if(NOT CTEST_DROP_METHOD STREQUAL "https")
|
||||
set(CTEST_DROP_METHOD "http")
|
||||
endif()
|
||||
set(CTEST_DROP_SITE "open.cdash.org")
|
||||
set(CTEST_DROP_LOCATION "/submit.php?project=CMake")
|
||||
set(CTEST_DROP_SITE_CDASH TRUE)
|
||||
|
@ -7,6 +7,7 @@ list(APPEND CTEST_CUSTOM_WARNING_EXCEPTION
|
||||
"warning LNK4221"
|
||||
"warning LNK4204" # Occurs by race condition with objects in small libs
|
||||
"variable .var_args[2]*. is used before its value is set"
|
||||
"warning: variable .__d[01]. was set but never used" # FD_ZERO on NVHPC
|
||||
"jobserver unavailable"
|
||||
"warning: \\(Long double usage is reported only once for each file"
|
||||
"warning: To disable this warning use"
|
||||
@ -82,28 +83,21 @@ list(APPEND CTEST_CUSTOM_WARNING_EXCEPTION
|
||||
"compilation completed with warnings" # PGI
|
||||
"[0-9]+ Warning\\(s\\) detected" # SunPro
|
||||
|
||||
# scanbuild exceptions
|
||||
"char_traits.h:.*: warning: Null pointer argument in call to string length function"
|
||||
"stl_construct.h:.*: warning: Forming reference to null pointer"
|
||||
".*stl_uninitialized.h:75:19: warning: Forming reference to null pointer.*"
|
||||
".*stl_vector.h:.*: warning: Returning null reference.*"
|
||||
"warning: Value stored to 'yymsg' is never read"
|
||||
"warning: Value stored to 'yytoken' is never read"
|
||||
"index_encoder.c.241.2. warning: Value stored to .out_start. is never read"
|
||||
"index.c.*warning: Access to field.*results in a dereference of a null pointer.*loaded from variable.*"
|
||||
"cmCommandArgumentLexer.cxx:[0-9]+:[0-9]+: warning: Call to 'realloc' has an allocation size of 0 bytes"
|
||||
"cmDependsJavaLexer.cxx:[0-9]+:[0-9]+: warning: Call to 'realloc' has an allocation size of 0 bytes"
|
||||
"cmExprLexer.cxx:[0-9]+:[0-9]+: warning: Call to 'realloc' has an allocation size of 0 bytes"
|
||||
"cmListFileLexer.c:[0-9]+:[0-9]+: warning: Call to 'realloc' has an allocation size of 0 bytes"
|
||||
"cmFortranLexer.cxx:[0-9]+:[0-9]+: warning: Call to 'realloc' has an allocation size of 0 bytes"
|
||||
"testProcess.*warning: Dereference of null pointer .loaded from variable .invalidAddress.."
|
||||
# clang-analyzer exceptions
|
||||
"cmListFileLexer.c:[0-9]+:[0-9]+: warning: Array subscript is undefined"
|
||||
"jsoncpp/src/.*:[0-9]+:[0-9]+: warning: Value stored to .* is never read"
|
||||
"liblzma/common/index_encoder.c:[0-9]+:[0-9]+: warning: Value stored to '[^']+' during its initialization is never read"
|
||||
"liblzma/liblzma/common/index.c:[0-9]+:[0-9]+: warning: Access to field '[^']+' results in a dereference of a null pointer"
|
||||
"liblzma/simple/x86.c:[0-9]+:[0-9]+: warning: The result of the '<<' expression is undefined"
|
||||
"liblzma/common/index_encoder.c:[0-9]+:[0-9]+: warning: Value stored to .* during its initialization is never read"
|
||||
"libuv/src/.*:[0-9]+:[0-9]+: warning: Dereference of null pointer"
|
||||
"libuv/src/.*:[0-9]+:[0-9]+: warning: The left operand of '==' is a garbage value"
|
||||
"librhash/librhash/.*:[0-9]+:[0-9]+: warning: The left operand of '[^']+' is a garbage value"
|
||||
"libuv/src/.*:[0-9]+:[0-9]+: warning: 1st function call argument is an uninitialized value"
|
||||
"libuv/src/.*:[0-9]+:[0-9]+: warning: Dereference of null pointer"
|
||||
"libuv/src/.*:[0-9]+:[0-9]+: warning: The left operand of '[^']+' is a garbage value"
|
||||
"nghttp2/lib/.*:[0-9]+:[0-9]+: warning: Access to field '[^']+' results in a dereference of a null pointer"
|
||||
"nghttp2/lib/.*:[0-9]+:[0-9]+: warning: Dereference of null pointer"
|
||||
"nghttp2/lib/.*:[0-9]+:[0-9]+: warning: Value stored to .* is never read"
|
||||
"nghttp2/lib/.*:[0-9]+:[0-9]+: warning: Value stored to '[^']+' is never read"
|
||||
"zstd/lib/.*:[0-9]+:[0-9]+: warning: Assigned value is garbage or undefined"
|
||||
"zstd/lib/.*:[0-9]+:[0-9]+: warning: Dereference of null pointer"
|
||||
)
|
||||
|
||||
if(NOT "@CMAKE_GENERATOR@" MATCHES "Xcode")
|
||||
|
@ -26,6 +26,12 @@ if(MSVC)
|
||||
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -stack:10000000")
|
||||
endif()
|
||||
|
||||
# MSVC 14.28 enables C5105, but the Windows SDK 10.0.18362.0 triggers it.
|
||||
if(CMAKE_C_COMPILER_ID STREQUAL "MSVC" AND NOT CMAKE_C_COMPILER_VERSION VERSION_LESS 19.28)
|
||||
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -wd5105")
|
||||
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -wd5105")
|
||||
endif()
|
||||
|
||||
if(_CLANG_MSVC_WINDOWS AND "x${CMAKE_CXX_COMPILER_FRONTEND_VARIANT}" STREQUAL "xGNU")
|
||||
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -Xlinker -stack:20000000")
|
||||
endif()
|
||||
@ -53,6 +59,12 @@ if(CMAKE_SYSTEM_PROCESSOR MATCHES "^parisc")
|
||||
endif()
|
||||
endif()
|
||||
|
||||
# Use 64-bit off_t on 32-bit Linux
|
||||
if (CMAKE_SYSTEM_NAME STREQUAL "Linux" AND CMAKE_SIZEOF_VOID_P EQUAL 4)
|
||||
# ensure 64bit offsets are used for filesystem accesses for 32bit compilation
|
||||
add_definitions(-D_FILE_OFFSET_BITS=64)
|
||||
endif()
|
||||
|
||||
# Workaround for TOC Overflow on ppc64
|
||||
set(bigTocFlag "")
|
||||
if(CMAKE_SYSTEM_NAME STREQUAL "AIX" AND
|
||||
|
@ -1,5 +1,5 @@
|
||||
CMake - Cross Platform Makefile Generator
|
||||
Copyright 2000-2020 Kitware, Inc. and Contributors
|
||||
Copyright 2000-2021 Kitware, Inc. and Contributors
|
||||
All rights reserved.
|
||||
|
||||
Redistribution and use in source and binary forms, with or without
|
||||
@ -65,8 +65,8 @@ The following individuals and institutions are among the Contributors:
|
||||
* Jan Woetzel
|
||||
* Julien Schueller
|
||||
* Kelly Thompson <kgt@lanl.gov>
|
||||
* Laurent Montel <montel@kde.org>
|
||||
* Konstantin Podsvirov <konstantin@podsvirov.pro>
|
||||
* Laurent Montel <montel@kde.org>
|
||||
* Mario Bensi <mbensi@ipsquad.net>
|
||||
* Martin Gräßlin <mgraesslin@kde.org>
|
||||
* Mathieu Malaterre <mathieu.malaterre@gmail.com>
|
||||
|
@ -1,11 +1,14 @@
|
||||
Host And Device Specific Link Options
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
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
|
||||
``$<DEVICE_LINK:...>``
|
||||
:manual:`generator expression <cmake-generator-expressions(7)>` will be used
|
||||
only for the device link step. Options wrapped with ``$<HOST_LINK:...>``
|
||||
:manual:`generator expression <cmake-generator-expressions(7)>` will be used
|
||||
only for the host link step.
|
||||
.. 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
|
||||
``$<DEVICE_LINK:...>``
|
||||
:manual:`generator expression <cmake-generator-expressions(7)>` will be used
|
||||
only for the device link step. Options wrapped with ``$<HOST_LINK:...>``
|
||||
:manual:`generator expression <cmake-generator-expressions(7)>` will be used
|
||||
only for the host link step.
|
||||
|
@ -11,10 +11,11 @@ The general signature is:
|
||||
|FIND_XXX| (
|
||||
<VAR>
|
||||
name | |NAMES|
|
||||
[HINTS path1 [path2 ... ENV var]]
|
||||
[PATHS path1 [path2 ... ENV var]]
|
||||
[HINTS [path | ENV var]... ]
|
||||
[PATHS [path | ENV var]... ]
|
||||
[PATH_SUFFIXES suffix1 [suffix2 ...]]
|
||||
[DOC "cache documentation string"]
|
||||
[NO_CACHE]
|
||||
[REQUIRED]
|
||||
[NO_DEFAULT_PATH]
|
||||
[NO_PACKAGE_ROOT_PATH]
|
||||
@ -28,14 +29,11 @@ The general signature is:
|
||||
)
|
||||
|
||||
This command is used to find a |SEARCH_XXX_DESC|.
|
||||
A cache entry named by ``<VAR>`` is created to store the result
|
||||
of this command.
|
||||
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``.
|
||||
The ``REQUIRED`` option stops 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.
|
||||
|
||||
Options include:
|
||||
|
||||
@ -59,8 +57,28 @@ Options include:
|
||||
``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``
|
||||
Stop processing with an error message if nothing is found.
|
||||
.. 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.
|
||||
@ -84,20 +102,21 @@ If ``NO_DEFAULT_PATH`` is not specified, the search process is as follows:
|
||||
|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. Specifically, look in the
|
||||
:variable:`<PackageName>_ROOT` CMake variable and the
|
||||
:envvar:`<PackageName>_ROOT` environment variable.
|
||||
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``.
|
||||
See policy :policy:`CMP0074`.
|
||||
1. .. versionadded:: 3.12
|
||||
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. Specifically, look in the
|
||||
:variable:`<PackageName>_ROOT` CMake variable and the
|
||||
:envvar:`<PackageName>_ROOT` environment variable.
|
||||
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``.
|
||||
See policy :policy:`CMP0074`.
|
||||
|
||||
* |FIND_PACKAGE_ROOT_PREFIX_PATH_XXX|
|
||||
|
||||
@ -151,6 +170,10 @@ If ``NO_DEFAULT_PATH`` is not specified, the search process is as follows:
|
||||
or in the short-hand version of the command.
|
||||
These are typically hard-coded guesses.
|
||||
|
||||
.. 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
|
||||
|
@ -1,3 +1,6 @@
|
||||
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
|
||||
|
@ -1,9 +1,15 @@
|
||||
The final set of compile or link options used for a target is constructed by
|
||||
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.
|
||||
While beneficial for individual options, the de-duplication step can break
|
||||
up option groups. For example, ``-D A -D B`` becomes ``-D 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:-D A" "SHELL:-D B"`` becomes ``-D A -D B``.
|
||||
|
||||
.. 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``.
|
||||
|
@ -1,6 +1,8 @@
|
||||
add_compile_definitions
|
||||
-----------------------
|
||||
|
||||
.. versionadded:: 3.12
|
||||
|
||||
Add preprocessor definitions to the compilation of source files.
|
||||
|
||||
.. code-block:: cmake
|
||||
|
@ -46,11 +46,19 @@ The options are:
|
||||
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
|
||||
@ -71,6 +79,12 @@ The options are:
|
||||
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,
|
||||
@ -88,27 +102,37 @@ The options are:
|
||||
|
||||
* The target is not being cross-compiled (i.e. the
|
||||
:variable:`CMAKE_CROSSCOMPILING` variable is not set to true).
|
||||
* 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.
|
||||
* .. 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 ``TARGET_FILE`` generator expression to refer to the location of
|
||||
a target later in the command line (i.e. as a command argument rather
|
||||
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 a target is used as a command to execute or is mentioned in a
|
||||
generator expression as 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. However this 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.
|
||||
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
|
||||
@ -144,18 +168,23 @@ The options are:
|
||||
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.
|
||||
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.
|
||||
|
||||
.. 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.
|
||||
|
||||
Arguments to ``DEPENDS`` may use
|
||||
:manual:`generator expressions <cmake-generator-expressions(7)>`.
|
||||
.. 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)>`,
|
||||
@ -174,7 +203,13 @@ The options are:
|
||||
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.
|
||||
@ -201,7 +236,15 @@ The options are:
|
||||
as a file on disk it should be marked with the :prop_sf:`SYMBOLIC`
|
||||
source file property.
|
||||
|
||||
.. 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>`.
|
||||
@ -221,14 +264,88 @@ The options are:
|
||||
If it is a relative path it will be interpreted relative to the
|
||||
build tree directory corresponding to the current source directory.
|
||||
|
||||
Arguments to ``WORKING_DIRECTORY`` may use
|
||||
:manual:`generator expressions <cmake-generator-expressions(7)>`.
|
||||
.. versionadded:: 3.13
|
||||
Arguments to ``WORKING_DIRECTORY`` may use
|
||||
:manual:`generator expressions <cmake-generator-expressions(7)>`.
|
||||
|
||||
``DEPFILE``
|
||||
Specify a ``.d`` depfile for the :generator:`Ninja` generator.
|
||||
A ``.d`` file holds dependencies usually emitted by the custom
|
||||
command itself.
|
||||
Using ``DEPFILE`` with other generators than Ninja is an error.
|
||||
.. versionadded:: 3.7
|
||||
|
||||
Specify a ``.d`` 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.
|
||||
|
||||
.. 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.
|
||||
|
||||
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.
|
||||
|
||||
.. _`add_custom_command(TARGET)`:
|
||||
|
||||
Build Events
|
||||
^^^^^^^^^^^^
|
||||
@ -279,3 +396,52 @@ of the following is specified:
|
||||
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.
|
||||
|
@ -32,6 +32,8 @@ The options are:
|
||||
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
|
||||
@ -52,6 +54,12 @@ The options are:
|
||||
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,
|
||||
@ -67,24 +75,30 @@ The options are:
|
||||
|
||||
* The target is not being cross-compiled (i.e. the
|
||||
:variable:`CMAKE_CROSSCOMPILING` variable is not set to true).
|
||||
* 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.
|
||||
* .. 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 ``TARGET_FILE`` generator expression to refer to the location of
|
||||
a target later in the command line (i.e. as a command argument rather
|
||||
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 a target is used as a command to execute or is mentioned in a
|
||||
generator expression as a command argument, a target-level dependency
|
||||
will be added automatically so that the mentioned target will be built
|
||||
before this custom target.
|
||||
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.
|
||||
@ -98,14 +112,18 @@ The options are:
|
||||
: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.
|
||||
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.
|
||||
|
||||
.. 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)>`,
|
||||
@ -114,6 +132,8 @@ The options are:
|
||||
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.
|
||||
@ -136,6 +156,8 @@ The options are:
|
||||
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>`.
|
||||
@ -145,5 +167,15 @@ The options are:
|
||||
If it is a relative path it will be interpreted relative to the
|
||||
build tree directory corresponding to the current source directory.
|
||||
|
||||
Arguments to ``WORKING_DIRECTORY`` may use
|
||||
:manual:`generator expressions <cmake-generator-expressions(7)>`.
|
||||
.. 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.
|
||||
|
@ -17,6 +17,9 @@ 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 the ``DEPENDS`` option of :command:`add_custom_target` and
|
||||
:command:`add_custom_command` commands for adding file-level
|
||||
dependencies in custom rules. See the :prop_sf:`OBJECT_DEPENDS`
|
||||
|
@ -17,13 +17,21 @@ Normal Executables
|
||||
[source1] [source2 ...])
|
||||
|
||||
Adds an executable target called ``<name>`` to be built from the source
|
||||
files listed in the command invocation. (The source files can be omitted
|
||||
here if they are added later using :command:`target_sources`.) The
|
||||
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
|
||||
@ -43,10 +51,8 @@ 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.
|
||||
|
||||
Source arguments to ``add_executable`` may use "generator expressions" with
|
||||
the syntax ``$<...>``. See the :manual:`cmake-generator-expressions(7)`
|
||||
manual for available expressions. See the :manual:`cmake-buildsystem(7)`
|
||||
manual for more on defining buildsystem properties.
|
||||
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
|
||||
@ -85,10 +91,14 @@ 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``.
|
||||
|
||||
An ``ALIAS`` to a non-``GLOBAL`` :ref:`Imported Target <Imported Targets>`
|
||||
has scope in the directory in which the alias is created and below.
|
||||
The :prop_tgt:`ALIAS_GLOBAL` target property can be used to check if the
|
||||
alias is global or not.
|
||||
.. 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
|
||||
|
@ -14,16 +14,24 @@ Normal Libraries
|
||||
|
||||
add_library(<name> [STATIC | SHARED | MODULE]
|
||||
[EXCLUDE_FROM_ALL]
|
||||
[source1] [source2 ...])
|
||||
[<source>...])
|
||||
|
||||
Adds a library target called ``<name>`` to be built from the source files
|
||||
listed in the command invocation. (The source files can be omitted here
|
||||
if they are added later using :command:`target_sources`.) The ``<name>``
|
||||
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
|
||||
@ -34,9 +42,13 @@ 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`` or ``STATIC`` library may be marked with the :prop_tgt:`FRAMEWORK`
|
||||
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.
|
||||
@ -55,57 +67,19 @@ 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.
|
||||
|
||||
Source arguments to ``add_library`` may use "generator expressions" with
|
||||
the syntax ``$<...>``. See the :manual:`cmake-generator-expressions(7)`
|
||||
manual for available expressions. See the :manual:`cmake-buildsystem(7)`
|
||||
manual for more on defining buildsystem properties.
|
||||
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 Libraries
|
||||
^^^^^^^^^^^^^^^^^^
|
||||
|
||||
.. code-block:: cmake
|
||||
|
||||
add_library(<name> <SHARED|STATIC|MODULE|OBJECT|UNKNOWN> IMPORTED
|
||||
[GLOBAL])
|
||||
|
||||
An :ref:`IMPORTED library target <Imported Targets>` references a library
|
||||
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`` 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 most important properties are:
|
||||
|
||||
* :prop_tgt:`IMPORTED_LOCATION` (and its per-configuration
|
||||
variant :prop_tgt:`IMPORTED_LOCATION_<CONFIG>`) which specifies the
|
||||
location of the main library file on disk.
|
||||
* :prop_tgt:`IMPORTED_OBJECTS` (and :prop_tgt:`IMPORTED_OBJECTS_<CONFIG>`)
|
||||
for object libraries, specifies the locations of object files on disk.
|
||||
* :prop_tgt:`PUBLIC_HEADER` files to be installed during :command:`install` invocation
|
||||
|
||||
See documentation of the ``IMPORTED_*`` and ``INTERFACE_*`` properties
|
||||
for more information.
|
||||
|
||||
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 Libraries
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
.. code-block:: cmake
|
||||
|
||||
add_library(<name> OBJECT <src>...)
|
||||
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
|
||||
@ -129,43 +103,22 @@ 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
|
||||
``$<TARGET_OBJECTS:objlib>``.
|
||||
|
||||
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``.
|
||||
|
||||
An ``ALIAS`` to a non-``GLOBAL`` :ref:`Imported Target <Imported Targets>`
|
||||
has scope in the directory in which the alias 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.
|
||||
.. versionadded:: 3.12
|
||||
Object libraries can be linked to with :command:`target_link_libraries`.
|
||||
|
||||
Interface Libraries
|
||||
^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
.. code-block:: cmake
|
||||
|
||||
add_library(<name> INTERFACE [IMPORTED [GLOBAL]])
|
||||
add_library(<name> INTERFACE)
|
||||
|
||||
Creates an :ref:`Interface Library <Interface Libraries>`. An ``INTERFACE``
|
||||
library target does not directly create build output, though it may
|
||||
have properties set on it and it may be installed, exported and
|
||||
imported. Typically the ``INTERFACE_*`` properties are populated on
|
||||
the interface target using the commands:
|
||||
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)`,
|
||||
@ -178,10 +131,129 @@ the interface target using the commands:
|
||||
and then it is used as an argument to :command:`target_link_libraries`
|
||||
like any other target.
|
||||
|
||||
An ``INTERFACE`` :ref:`Imported Target <Imported Targets>` may also be
|
||||
created with this signature. An ``IMPORTED`` library target references a
|
||||
library defined outside the project. 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`.
|
||||
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), 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.
|
||||
|
||||
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).
|
||||
|
||||
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.
|
||||
|
@ -1,6 +1,8 @@
|
||||
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.
|
||||
|
@ -10,8 +10,9 @@ Add a test to the project to be run by :manual:`ctest(1)`.
|
||||
[WORKING_DIRECTORY <dir>]
|
||||
[COMMAND_EXPAND_LISTS])
|
||||
|
||||
Adds a test called ``<name>``. The test name may not contain spaces,
|
||||
quotes, or other characters special in CMake syntax. The options are:
|
||||
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`. The options are:
|
||||
|
||||
``COMMAND``
|
||||
Specify the test command-line. If ``<command>`` specifies an
|
||||
@ -30,6 +31,8 @@ quotes, or other characters special in CMake syntax. The options are:
|
||||
current source directory.
|
||||
|
||||
``COMMAND_EXPAND_LISTS``
|
||||
.. versionadded:: 3.16
|
||||
|
||||
Lists in ``COMMAND`` arguments will be expanded, including those
|
||||
created with
|
||||
:manual:`generator expressions <cmake-generator-expressions(7)>`.
|
||||
@ -42,6 +45,9 @@ unless the :prop_test:`PASS_REGULAR_EXPRESSION`,
|
||||
:prop_test:`FAIL_REGULAR_EXPRESSION` or
|
||||
:prop_test:`SKIP_REGULAR_EXPRESSION` test property is used.
|
||||
|
||||
.. versionadded:: 3.16
|
||||
Added :prop_test:`SKIP_REGULAR_EXPRESSION` property.
|
||||
|
||||
The ``COMMAND`` and ``WORKING_DIRECTORY`` options may use "generator
|
||||
expressions" with the syntax ``$<...>``. See the
|
||||
:manual:`cmake-generator-expressions(7)` manual for available expressions.
|
||||
@ -51,7 +57,7 @@ Example usage:
|
||||
.. code-block:: cmake
|
||||
|
||||
add_test(NAME mytest
|
||||
COMMAND testDriver --config $<CONFIGURATION>
|
||||
COMMAND testDriver --config $<CONFIG>
|
||||
--exe $<TARGET_FILE:myexe>)
|
||||
|
||||
This creates a test ``mytest`` whose command runs a ``testDriver`` tool
|
||||
|
@ -8,23 +8,29 @@ This is mainly intended for internal use by the :module:`CTest` module.
|
||||
|
||||
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>] [--target <target>...] [-- -i]
|
||||
<cmake> --build . [--config <config>] [--parallel <parallel>] [--target <target>...] [-- -i]
|
||||
|
||||
where ``<cmake>`` is the location of the :manual:`cmake(1)` command-line
|
||||
tool, and ``<config>`` and ``<target>`` are the values provided to the
|
||||
``CONFIGURATION`` and ``TARGET`` options, if any. The trailing ``-- -i``
|
||||
option is added for :ref:`Makefile Generators` if policy :policy:`CMP0061`
|
||||
is not set to ``NEW``.
|
||||
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 ``cmake --build`` command line will launch the
|
||||
underlying build system tool.
|
||||
|
||||
.. versionadded:: 3.21
|
||||
The ``PARALLEL_LEVEL`` argument can be used to set the ``--parallel``
|
||||
flag.
|
||||
|
||||
.. code-block:: cmake
|
||||
|
||||
build_command(<cachevariable> <makecommand>)
|
||||
|
@ -24,6 +24,14 @@ Key Description
|
||||
``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]_
|
||||
============================= ================================================
|
||||
|
||||
.. versionadded:: 3.10
|
||||
Additional ``<key>`` values are available:
|
||||
|
||||
============================= ================================================
|
||||
Key Description
|
||||
============================= ================================================
|
||||
``IS_64BIT`` One if processor is 64Bit
|
||||
``HAS_FPU`` One if processor has floating point unit
|
||||
``HAS_MMX`` One if processor supports MMX instructions
|
||||
|
@ -1,6 +1,8 @@
|
||||
cmake_language
|
||||
--------------
|
||||
|
||||
.. versionadded:: 3.18
|
||||
|
||||
Call meta-operations on CMake commands.
|
||||
|
||||
Synopsis
|
||||
@ -8,8 +10,9 @@ Synopsis
|
||||
|
||||
.. parsed-literal::
|
||||
|
||||
cmake_language(`CALL`_ <command> [<args>...])
|
||||
cmake_language(`CALL`_ <command> [<arg>...])
|
||||
cmake_language(`EVAL`_ CODE <code>...)
|
||||
cmake_language(`DEFER`_ <options>... CALL <command> [<arg>...])
|
||||
|
||||
Introduction
|
||||
^^^^^^^^^^^^
|
||||
@ -26,7 +29,7 @@ Calling Commands
|
||||
|
||||
.. code-block:: cmake
|
||||
|
||||
cmake_language(CALL <command> [<args>...])
|
||||
cmake_language(CALL <command> [<arg>...])
|
||||
|
||||
Calls the named ``<command>`` with the given arguments (if any).
|
||||
For example, the code:
|
||||
@ -97,3 +100,128 @@ is equivalent to
|
||||
)
|
||||
|
||||
include(${CMAKE_CURRENT_BINARY_DIR}/eval.cmake)
|
||||
|
||||
Deferring Calls
|
||||
^^^^^^^^^^^^^^^
|
||||
|
||||
.. versionadded:: 3.19
|
||||
|
||||
.. _DEFER:
|
||||
|
||||
.. code-block:: cmake
|
||||
|
||||
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
|
||||
|
@ -5,23 +5,29 @@ Require a minimum version of cmake.
|
||||
|
||||
.. code-block:: cmake
|
||||
|
||||
cmake_minimum_required(VERSION <min>[...<max>] [FATAL_ERROR])
|
||||
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 ``<max>`` are each CMake versions of the form
|
||||
``major.minor[.patch[.tweak]]``, and the ``...`` is literal.
|
||||
``<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 ``<max>`` version, if specified, must be at least the
|
||||
``<min>`` version and affects policy settings as described below.
|
||||
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.
|
||||
@ -34,8 +40,15 @@ with an error instead of just a warning.
|
||||
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. Such calls
|
||||
should not be made with the intention of having global effects.
|
||||
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
|
||||
^^^^^^^^^^^^^^^
|
||||
|
@ -11,6 +11,10 @@ Parse function or macro arguments.
|
||||
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
|
||||
@ -19,11 +23,12 @@ 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`.
|
||||
|
||||
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.
|
||||
.. 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
|
||||
@ -38,12 +43,11 @@ 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.
|
||||
|
||||
.. note::
|
||||
|
||||
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.
|
||||
.. 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
|
||||
@ -59,10 +63,12 @@ All remaining arguments are collected in a variable
|
||||
were recognized. This can be checked afterwards to see
|
||||
whether your macro was called with unrecognized parameters.
|
||||
|
||||
``<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.
|
||||
.. 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:
|
||||
|
786
Help/command/cmake_path.rst
Normal file
786
Help/command/cmake_path.rst
Normal file
@ -0,0 +1,786 @@
|
||||
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
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
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 ``.``).
|
||||
|
||||
|
||||
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.
|
||||
|
||||
::
|
||||
|
||||
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:/"
|
||||
|
||||
|
||||
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:
|
||||
|
||||
::
|
||||
|
||||
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:
|
||||
|
||||
::
|
||||
|
||||
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:
|
||||
|
||||
::
|
||||
|
||||
cmake_path(IS_RELATIVE <path-var> <out-var>)
|
||||
|
||||
This will store the opposite of ``IS_ABSOLUTE`` in ``<out-var>``.
|
||||
|
||||
.. _IS_PREFIX:
|
||||
|
||||
::
|
||||
|
||||
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
|
||||
|
||||
.. _COMPARE:
|
||||
|
||||
::
|
||||
|
||||
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. 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.
|
||||
|
||||
|
||||
Modification
|
||||
^^^^^^^^^^^^
|
||||
|
||||
.. _cmake_path-SET:
|
||||
|
||||
::
|
||||
|
||||
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>` before 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:
|
||||
|
||||
::
|
||||
|
||||
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:
|
||||
|
||||
::
|
||||
|
||||
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:
|
||||
|
||||
::
|
||||
|
||||
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:
|
||||
|
||||
::
|
||||
|
||||
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:
|
||||
|
||||
::
|
||||
|
||||
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:
|
||||
|
||||
::
|
||||
|
||||
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")
|
||||
|
||||
|
||||
Generation
|
||||
^^^^^^^^^^
|
||||
|
||||
.. _NORMAL_PATH:
|
||||
|
||||
::
|
||||
|
||||
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:
|
||||
|
||||
::
|
||||
|
||||
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:
|
||||
|
||||
::
|
||||
|
||||
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:
|
||||
|
||||
::
|
||||
|
||||
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:
|
||||
|
||||
::
|
||||
|
||||
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:
|
||||
|
||||
::
|
||||
|
||||
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:
|
||||
|
||||
::
|
||||
|
||||
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.
|
@ -28,6 +28,9 @@ encourage projects to set policies based on CMake versions:
|
||||
|
||||
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.
|
||||
|
@ -6,6 +6,8 @@ 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] ])
|
||||
|
||||
@ -34,24 +36,48 @@ or
|
||||
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.
|
||||
Input file lines of the form ``#cmakedefine01 VAR`` will be replaced with
|
||||
either ``#define VAR 1`` or ``#define VAR 0`` similarly.
|
||||
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:
|
||||
|
||||
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
|
||||
|
||||
# cmakedefine VAR
|
||||
# cmakedefine01 VAR
|
||||
#cmakedefine01 VAR
|
||||
|
||||
will be replaced, if ``VAR`` is defined, with
|
||||
will be replaced with either
|
||||
|
||||
.. code-block:: c
|
||||
|
||||
# define VAR
|
||||
# define VAR 1
|
||||
#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 ... 0``,
|
||||
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.
|
||||
@ -71,6 +97,28 @@ The arguments are:
|
||||
If the path names an existing directory the output file is placed
|
||||
in that directory with the same file name as the input file.
|
||||
|
||||
``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``.
|
||||
|
@ -1,6 +1,8 @@
|
||||
continue
|
||||
--------
|
||||
|
||||
.. versionadded:: 3.2
|
||||
|
||||
Continue to the top of enclosing foreach or while loop.
|
||||
|
||||
.. code-block:: cmake
|
||||
|
@ -7,6 +7,7 @@ Perform the :ref:`CTest Build Step` as a :ref:`Dashboard Client`.
|
||||
|
||||
ctest_build([BUILD <build-dir>] [APPEND]
|
||||
[CONFIGURATION <config>]
|
||||
[PARALLEL_LEVEL <parallel>]
|
||||
[FLAGS <flags>]
|
||||
[PROJECT_NAME <project-name>]
|
||||
[TARGET <target-name>]
|
||||
@ -42,6 +43,13 @@ The options are:
|
||||
Otherwise the ``-C <cfg>`` 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.
|
||||
@ -50,7 +58,10 @@ The options are:
|
||||
for an example.
|
||||
|
||||
``PROJECT_NAME <project-name>``
|
||||
Ignored. This was once used but is no longer needed.
|
||||
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
|
||||
@ -68,10 +79,14 @@ The options are:
|
||||
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
|
||||
|
@ -37,10 +37,14 @@ The options are:
|
||||
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.
|
||||
|
@ -37,10 +37,14 @@ The options are:
|
||||
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.
|
||||
|
@ -17,10 +17,15 @@ Perform the :ref:`CTest MemCheck Step` as a :ref:`Dashboard Client`.
|
||||
[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]
|
||||
)
|
||||
@ -35,4 +40,6 @@ 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.
|
||||
|
@ -29,8 +29,11 @@ The parameters are as follows:
|
||||
``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. This replaces the deprecated option ``TRACK``. Despite the name
|
||||
change its behavior is unchanged.
|
||||
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
|
||||
@ -56,6 +59,8 @@ The parameters are as follows:
|
||||
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.
|
||||
|
||||
|
@ -42,14 +42,20 @@ The options are:
|
||||
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
|
||||
@ -73,20 +79,27 @@ The options are:
|
||||
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
|
||||
|
||||
::
|
||||
|
||||
ctest_submit(CDASH_UPLOAD <file> [CDASH_UPLOAD_TYPE <type>]
|
||||
[SUBMIT_URL <url>]
|
||||
[BUILD_ID <result-var>]
|
||||
[HTTPHEADER <header>]
|
||||
[RETRY_COUNT <count>]
|
||||
[RETRY_DELAY <delay>]
|
||||
@ -99,6 +112,19 @@ 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 accepts the ``SUBMIT_URL``, ``BUILD_ID``, ``HTTPHEADER``,
|
||||
``RETRY_COUNT``, ``RETRY_DELAY``, ``RETURN_VALUE`` and ``QUIET`` options
|
||||
as described above.
|
||||
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.
|
||||
|
@ -25,9 +25,14 @@ Perform the :ref:`CTest Test Step` as a :ref:`Dashboard Client`.
|
||||
[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.
|
||||
|
||||
@ -68,6 +73,8 @@ The options are:
|
||||
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
|
||||
@ -76,9 +83,13 @@ The options are:
|
||||
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>``
|
||||
@ -86,11 +97,15 @@ The options are:
|
||||
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,
|
||||
@ -98,6 +113,8 @@ The options are:
|
||||
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:
|
||||
|
||||
@ -121,6 +138,8 @@ The options are:
|
||||
implicit test dependencies.
|
||||
|
||||
``STOP_ON_FAILURE``
|
||||
.. versionadded:: 3.18
|
||||
|
||||
Stop the execution of the tests once one has failed.
|
||||
|
||||
``STOP_TIME <time-of-day>``
|
||||
@ -131,10 +150,23 @@ The options are:
|
||||
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
|
||||
@ -142,3 +174,103 @@ The options are:
|
||||
|
||||
See also the :variable:`CTEST_CUSTOM_MAXIMUM_PASSED_TEST_OUTPUT_SIZE`
|
||||
and :variable:`CTEST_CUSTOM_MAXIMUM_FAILED_TEST_OUTPUT_SIZE` variables.
|
||||
|
||||
.. _`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.
|
||||
|
||||
The following example demonstrates how to output a variety of custom test
|
||||
measurements.
|
||||
|
||||
.. code-block:: c++
|
||||
|
||||
std::cout <<
|
||||
"<DartMeasurement type=\"numeric/double\" name=\"score\">28.3</DartMeasurement>"
|
||||
<< std::endl;
|
||||
|
||||
std::cout <<
|
||||
"<DartMeasurement type=\"text/string\" name=\"color\">red</DartMeasurement>"
|
||||
<< std::endl;
|
||||
|
||||
std::cout <<
|
||||
"<DartMeasurement type=\"text/link\" name=\"CMake URL\">https://cmake.org</DartMeasurement>"
|
||||
<< std::endl;
|
||||
|
||||
std::cout <<
|
||||
"<DartMeasurement 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" <<
|
||||
"</DartMeasurement>" << std::endl;
|
||||
|
||||
Image Measurements
|
||||
""""""""""""""""""
|
||||
|
||||
The following example demonstrates how to upload test images to CDash.
|
||||
|
||||
.. code-block:: c++
|
||||
|
||||
std::cout <<
|
||||
"<DartMeasurementFile type=\"image/jpg\" name=\"TestImage\">" <<
|
||||
"/dir/to/test_img.jpg</DartMeasurementFile>" << std::endl;
|
||||
|
||||
std::cout <<
|
||||
"<DartMeasurementFile type=\"image/gif\" name=\"ValidImage\">" <<
|
||||
"/dir/to/valid_img.gif</DartMeasurementFile>" << std::endl;
|
||||
|
||||
std::cout <<
|
||||
"<DartMeasurementFile type=\"image/png\" name=\"AlgoResult\"> <<
|
||||
"/dir/to/img.png</DartMeasurementFile>"
|
||||
<< 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
|
||||
""""""""""""""
|
||||
|
||||
The following example demonstrates how to upload non-image files to CDash.
|
||||
|
||||
.. code-block:: c++
|
||||
|
||||
std::cout <<
|
||||
"<DartMeasurementFile type=\"file\" name=\"MyTestInputData\">" <<
|
||||
"/dir/to/data.csv</DartMeasurementFile>" << 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
|
||||
""""""""""""""
|
||||
|
||||
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;
|
||||
|
@ -24,10 +24,14 @@ The options are:
|
||||
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
|
||||
|
@ -14,9 +14,13 @@ The options are:
|
||||
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.
|
||||
|
@ -9,7 +9,20 @@ Enable a language (CXX/C/OBJC/OBJCXX/Fortran/etc)
|
||||
Enables support for the named language 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. Example languages
|
||||
are ``CXX``, ``C``, ``CUDA``, ``OBJC``, ``OBJCXX``, ``Fortran``, and ``ASM``.
|
||||
are ``CXX``, ``C``, ``CUDA``, ``OBJC``, ``OBJCXX``, ``Fortran``,
|
||||
``HIP``, ``ISPC``, and ``ASM``.
|
||||
|
||||
.. versionadded:: 3.8
|
||||
Added ``CUDA`` support.
|
||||
|
||||
.. versionadded:: 3.16
|
||||
Added ``OBJC`` and ``OBJCXX`` support.
|
||||
|
||||
.. versionadded:: 3.18
|
||||
Added ``ISPC`` support.
|
||||
|
||||
.. versionadded:: 3.21
|
||||
Added ``HIP`` support.
|
||||
|
||||
If enabling ``ASM``, enable it last so that CMake can check whether
|
||||
compilers for other languages like ``C`` work for assembly too.
|
||||
|
@ -23,7 +23,8 @@ Execute one or more child processes.
|
||||
[ERROR_STRIP_TRAILING_WHITESPACE]
|
||||
[ENCODING <name>]
|
||||
[ECHO_OUTPUT_VARIABLE]
|
||||
[ECHO_ERROR_VARIABLE])
|
||||
[ECHO_ERROR_VARIABLE]
|
||||
[COMMAND_ERROR_IS_FATAL <ANY|LAST>])
|
||||
|
||||
Runs the given sequence of one or more commands.
|
||||
|
||||
@ -61,6 +62,8 @@ Options:
|
||||
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
|
||||
@ -74,19 +77,26 @@ Options:
|
||||
``INPUT_FILE, OUTPUT_FILE``, ``ERROR_FILE``
|
||||
The file named will be attached to the standard input of the first
|
||||
process, standard output of the last process, or standard error of
|
||||
all processes, respectively. If the same file is named for both
|
||||
output and error then it will be used for both.
|
||||
all processes, respectively.
|
||||
|
||||
.. versionadded:: 3.3
|
||||
If the same file is named for both output and error then it will be used
|
||||
for both.
|
||||
|
||||
``OUTPUT_QUIET``, ``ERROR_QUIET``
|
||||
The standard output or standard error results will be quietly ignored.
|
||||
|
||||
``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:
|
||||
@ -103,11 +113,15 @@ Options:
|
||||
``OEM``
|
||||
Use the original equipment manufacturer (OEM) code page.
|
||||
``UTF8`` or ``UTF-8``
|
||||
Use the UTF-8 codepage. Prior to CMake 3.11.0, only ``UTF8`` was accepted
|
||||
for this encoding. In CMake 3.11.0, ``UTF-8`` was added for consistency with
|
||||
the `UTF-8 RFC <https://www.ietf.org/rfc/rfc3629>`_ naming convention.
|
||||
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.
|
||||
|
||||
``ECHO_OUTPUT_VARIABLE``, ``ECHO_ERROR_VARIABLE``
|
||||
.. versionadded:: 3.18
|
||||
|
||||
The standard output or standard error will not be exclusively redirected to
|
||||
the configured variables.
|
||||
|
||||
@ -116,6 +130,21 @@ Options:
|
||||
|
||||
This is analogous to the ``tee`` Unix command.
|
||||
|
||||
``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.
|
||||
|
||||
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
|
||||
|
@ -64,16 +64,23 @@ build tree. In some cases, for example for packaging and for system
|
||||
wide installations, it is not desirable to write the user package
|
||||
registry.
|
||||
|
||||
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.
|
||||
.. 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.
|
||||
|
||||
.. code-block:: cmake
|
||||
|
||||
export(TARGETS [target1 [target2 [...]]] [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.
|
||||
|
@ -3,6 +3,21 @@ file
|
||||
|
||||
File manipulation command.
|
||||
|
||||
This command is dedicated to file and path manipulation requiring access to the
|
||||
filesystem.
|
||||
|
||||
For other path manipulation, handling only syntactic aspects, have a look at
|
||||
:command:`cmake_path` command.
|
||||
|
||||
.. note::
|
||||
|
||||
The sub-commands `RELATIVE_PATH`_, `TO_CMAKE_PATH`_ and `TO_NATIVE_PATH`_ has
|
||||
been superseded, respectively, by sub-commands
|
||||
:ref:`RELATIVE_PATH <cmake_path-RELATIVE_PATH>`,
|
||||
:ref:`CONVERT ... TO_CMAKE_PATH_LIST <cmake_path-TO_CMAKE_PATH_LIST>` and
|
||||
:ref:`CONVERT ... TO_NATIVE_PATH_LIST <cmake_path-TO_NATIVE_PATH_LIST>` of
|
||||
:command:`cmake_path` command.
|
||||
|
||||
Synopsis
|
||||
^^^^^^^^
|
||||
|
||||
@ -23,20 +38,24 @@ Synopsis
|
||||
|
||||
`Filesystem`_
|
||||
file({`GLOB`_ | `GLOB_RECURSE`_} <out-var> [...] [<globbing-expr>...])
|
||||
file(`RENAME`_ <oldname> <newname>)
|
||||
file({`REMOVE`_ | `REMOVE_RECURSE`_ } [<files>...])
|
||||
file(`MAKE_DIRECTORY`_ [<dir>...])
|
||||
file({`REMOVE`_ | `REMOVE_RECURSE`_ } [<files>...])
|
||||
file(`RENAME`_ <oldname> <newname> [...])
|
||||
file(`COPY_FILE`_ <oldname> <newname> [...])
|
||||
file({`COPY`_ | `INSTALL`_} <file>... DESTINATION <dir> [...])
|
||||
file(`SIZE`_ <filename> <out-var>)
|
||||
file(`READ_SYMLINK`_ <linkname> <out-var>)
|
||||
file(`CREATE_LINK`_ <original> <linkname> [...])
|
||||
file(`CHMOD`_ <files>... <directories>... PERMISSIONS <permissions>... [...])
|
||||
file(`CHMOD_RECURSE`_ <files>... <directories>... PERMISSIONS <permissions>... [...])
|
||||
|
||||
`Path Conversion`_
|
||||
file(`REAL_PATH`_ <path> <out-var> [BASE_DIRECTORY <dir>] [EXPAND_TILDE])
|
||||
file(`RELATIVE_PATH`_ <out-var> <directory> <file>)
|
||||
file({`TO_CMAKE_PATH`_ | `TO_NATIVE_PATH`_} <path> <out-var>)
|
||||
|
||||
`Transfer`_
|
||||
file(`DOWNLOAD`_ <url> <file> [...])
|
||||
file(`DOWNLOAD`_ <url> [<file>] [...])
|
||||
file(`UPLOAD`_ <file> <url> [...])
|
||||
|
||||
`Locking`_
|
||||
@ -97,13 +116,19 @@ Parse a list of ASCII strings from ``<filename>`` and store it in
|
||||
binary while reading unless this option is given.
|
||||
|
||||
``REGEX <regex>``
|
||||
Consider only strings that match the given regular expression.
|
||||
Consider only strings that match the given regular expression,
|
||||
as described under :ref:`string(REGEX) <Regex Specification>`.
|
||||
|
||||
``ENCODING <encoding-type>``
|
||||
.. versionadded:: 3.1
|
||||
|
||||
Consider strings of a given encoding. Currently supported encodings are:
|
||||
UTF-8, UTF-16LE, UTF-16BE, UTF-32LE, UTF-32BE. If the ENCODING option
|
||||
is not provided and the file has a Byte Order Mark, the ENCODING option
|
||||
will be defaulted to respect the Byte Order Mark.
|
||||
``UTF-8``, ``UTF-16LE``, ``UTF-16BE``, ``UTF-32LE``, ``UTF-32BE``.
|
||||
If the ``ENCODING`` option is not provided and the file has a Byte Order Mark,
|
||||
the ``ENCODING`` option will be defaulted to respect the Byte Order Mark.
|
||||
|
||||
.. versionadded:: 3.2
|
||||
Added the ``UTF-16LE``, ``UTF-16BE``, ``UTF-32LE``, ``UTF-32BE`` encodings.
|
||||
|
||||
For example, the code
|
||||
|
||||
@ -155,13 +180,19 @@ the ``<format>`` and ``UTC`` options.
|
||||
[PRE_EXCLUDE_REGEXES [<regexes>...]]
|
||||
[POST_INCLUDE_REGEXES [<regexes>...]]
|
||||
[POST_EXCLUDE_REGEXES [<regexes>...]]
|
||||
[POST_INCLUDE_FILES [<files>...]]
|
||||
[POST_EXCLUDE_FILES [<files>...]]
|
||||
)
|
||||
|
||||
.. versionadded:: 3.16
|
||||
|
||||
Recursively get the list of libraries depended on by the given files.
|
||||
|
||||
Please note that this sub-command is not intended to be used in project mode.
|
||||
Instead, use it in an :command:`install(CODE)` or :command:`install(SCRIPT)`
|
||||
block. For example:
|
||||
It is intended for use at install time, either from code generated by the
|
||||
:command:`install(RUNTIME_DEPENDENCY_SET)` command, or from code provided by
|
||||
the project via :command:`install(CODE)` or :command:`install(SCRIPT)`.
|
||||
For example:
|
||||
|
||||
.. code-block:: cmake
|
||||
|
||||
@ -250,6 +281,18 @@ be resolved. See below for a full description of how they work.
|
||||
List of post-exclude regexes through which to filter the names of resolved
|
||||
dependencies.
|
||||
|
||||
``POST_INCLUDE_FILES <files>``
|
||||
.. versionadded:: 3.21
|
||||
|
||||
List of post-include filenames through which to filter the names of resolved
|
||||
dependencies. Symlinks are resolved when attempting to match these filenames.
|
||||
|
||||
``POST_EXCLUDE_FILES <files>``
|
||||
.. versionadded:: 3.21
|
||||
|
||||
List of post-exclude filenames through which to filter the names of resolved
|
||||
dependencies. Symlinks are resolved when attempting to match these filenames.
|
||||
|
||||
These arguments can be used to exclude unwanted system libraries when
|
||||
resolving the dependencies, or to include libraries from a specific
|
||||
directory. The filtering works as follows:
|
||||
@ -263,16 +306,18 @@ directory. The filtering works as follows:
|
||||
4. ``file(GET_RUNTIME_DEPENDENCIES)`` searches for the dependency according to
|
||||
the linking rules of the platform (see below).
|
||||
5. If the dependency is found, and its full path matches one of the
|
||||
``POST_INCLUDE_REGEXES``, the full path is added to the resolved
|
||||
dependencies, and ``file(GET_RUNTIME_DEPENDENCIES)`` recursively resolves
|
||||
that library's own dependencies. Otherwise, resolution proceeds to step 6.
|
||||
6. If the dependency is found, but its full path matches one of the
|
||||
``POST_EXCLUDE_REGEXES``, it is not added to the resolved dependencies, and
|
||||
dependency resolution stops for that dependency.
|
||||
7. If the dependency is found, and its full path does not match either
|
||||
``POST_INCLUDE_REGEXES`` or ``POST_EXCLUDE_REGEXES``, the full path is added
|
||||
``POST_INCLUDE_REGEXES`` or ``POST_INCLUDE_FILES``, the full path is added
|
||||
to the resolved dependencies, and ``file(GET_RUNTIME_DEPENDENCIES)``
|
||||
recursively resolves that library's own dependencies.
|
||||
recursively resolves that library's own dependencies. Otherwise, resolution
|
||||
proceeds to step 6.
|
||||
6. If the dependency is found, but its full path matches one of the
|
||||
``POST_EXCLUDE_REGEXES`` or ``POST_EXCLUDE_FILES``, it is not added to the
|
||||
resolved dependencies, and dependency resolution stops for that dependency.
|
||||
7. If the dependency is found, and its full path does not match either
|
||||
``POST_INCLUDE_REGEXES``, ``POST_INCLUDE_FILES``, ``POST_EXCLUDE_REGEXES``,
|
||||
or ``POST_EXCLUDE_FILES``, the full path is added to the resolved
|
||||
dependencies, and ``file(GET_RUNTIME_DEPENDENCIES)`` recursively resolves
|
||||
that library's own dependencies.
|
||||
|
||||
Different platforms have different rules for how dependencies are resolved.
|
||||
These specifics are described here.
|
||||
@ -405,6 +450,9 @@ dependency resolution:
|
||||
If this variable is not specified, it is determined by the value of
|
||||
``CMAKE_OBJDUMP`` if set, else by system introspection.
|
||||
|
||||
.. versionadded:: 3.18
|
||||
Use ``CMAKE_OBJDUMP`` if set.
|
||||
|
||||
Writing
|
||||
^^^^^^^
|
||||
|
||||
@ -433,6 +481,8 @@ to update the file only when its content changes.
|
||||
file(TOUCH [<files>...])
|
||||
file(TOUCH_NOCREATE [<files>...])
|
||||
|
||||
.. versionadded:: 3.12
|
||||
|
||||
Create a file with no content if it does not yet exist. If the file already
|
||||
exists, its access and/or modification will be updated to the time when the
|
||||
function call is executed.
|
||||
@ -449,7 +499,10 @@ modified.
|
||||
|
||||
file(GENERATE OUTPUT output-file
|
||||
<INPUT input-file|CONTENT content>
|
||||
[CONDITION expression])
|
||||
[CONDITION expression] [TARGET target]
|
||||
[NO_SOURCE_PERMISSIONS | USE_SOURCE_PERMISSIONS |
|
||||
FILE_PERMISSIONS <permissions>...]
|
||||
[NEWLINE_STYLE [UNIX|DOS|WIN32|LF|CRLF] ])
|
||||
|
||||
Generate an output file for each build configuration supported by the current
|
||||
:manual:`CMake Generator <cmake-generators(7)>`. Evaluate
|
||||
@ -466,8 +519,10 @@ from the input content to produce the output content. The options are:
|
||||
|
||||
``INPUT <input-file>``
|
||||
Use the content from a given file as input.
|
||||
A relative path is treated with respect to the value of
|
||||
:variable:`CMAKE_CURRENT_SOURCE_DIR`. See policy :policy:`CMP0070`.
|
||||
|
||||
.. versionchanged:: 3.10
|
||||
A relative path is treated with respect to the value of
|
||||
:variable:`CMAKE_CURRENT_SOURCE_DIR`. See policy :policy:`CMP0070`.
|
||||
|
||||
``OUTPUT <output-file>``
|
||||
Specify the output file name to generate. Use generator expressions
|
||||
@ -475,9 +530,46 @@ from the input content to produce the output content. The options are:
|
||||
name. Multiple configurations may generate the same output file only
|
||||
if the generated content is identical. Otherwise, the ``<output-file>``
|
||||
must evaluate to an unique name for each configuration.
|
||||
A relative path (after evaluating generator expressions) is treated
|
||||
with respect to the value of :variable:`CMAKE_CURRENT_BINARY_DIR`.
|
||||
See policy :policy:`CMP0070`.
|
||||
|
||||
.. versionchanged:: 3.10
|
||||
A relative path (after evaluating generator expressions) is treated
|
||||
with respect to the value of :variable:`CMAKE_CURRENT_BINARY_DIR`.
|
||||
See policy :policy:`CMP0070`.
|
||||
|
||||
``TARGET <target>``
|
||||
.. versionadded:: 3.19
|
||||
|
||||
Specify which target to use when evaluating generator expressions that
|
||||
require a target for evaluation (e.g. ``$<COMPILE_FEATURES:...>``,
|
||||
``$<TARGET_PROPERTY:prop>``).
|
||||
|
||||
``NO_SOURCE_PERMISSIONS``
|
||||
.. versionadded:: 3.20
|
||||
|
||||
The generated file permissions default to the standard 644 value
|
||||
(-rw-r--r--).
|
||||
|
||||
``USE_SOURCE_PERMISSIONS``
|
||||
.. versionadded:: 3.20
|
||||
|
||||
Transfer the file permissions of the ``INPUT`` file to the generated 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.
|
||||
It is an error to specify this option without ``INPUT``.
|
||||
|
||||
``FILE_PERMISSIONS <permissions>...``
|
||||
.. versionadded:: 3.20
|
||||
|
||||
Use the specified permissions for the generated file.
|
||||
|
||||
``NEWLINE_STYLE <style>``
|
||||
.. versionadded:: 3.20
|
||||
|
||||
Specify the newline style for the generated file. Specify
|
||||
``UNIX`` or ``LF`` for ``\n`` newlines, or specify
|
||||
``DOS``, ``WIN32``, or ``CRLF`` for ``\r\n`` newlines.
|
||||
|
||||
Exactly one ``CONTENT`` or ``INPUT`` option must be given. A specific
|
||||
``OUTPUT`` file may be named by at most one invocation of ``file(GENERATE)``.
|
||||
@ -498,6 +590,8 @@ of a project's ``CMakeLists.txt`` files.
|
||||
[ESCAPE_QUOTES] [@ONLY]
|
||||
[NEWLINE_STYLE [UNIX|DOS|WIN32|LF|CRLF] ])
|
||||
|
||||
.. versionadded:: 3.18
|
||||
|
||||
Generate an output file using the input given by ``CONTENT`` and substitute
|
||||
variable values referenced as ``@VAR@`` or ``${VAR}`` contained therein. The
|
||||
substitution rules behave the same as the :command:`configure_file` command.
|
||||
@ -546,20 +640,25 @@ Generate a list of files that match the ``<globbing-expressions>`` and
|
||||
store it into the ``<variable>``. Globbing expressions are similar to
|
||||
regular expressions, but much simpler. If ``RELATIVE`` flag is
|
||||
specified, the results will be returned as relative paths to the given
|
||||
path. The results will be ordered lexicographically.
|
||||
path.
|
||||
|
||||
.. versionchanged:: 3.6
|
||||
The results will be ordered lexicographically.
|
||||
|
||||
On Windows and macOS, globbing is case-insensitive even if the underlying
|
||||
filesystem is case-sensitive (both filenames and globbing expressions are
|
||||
converted to lowercase before matching). On other platforms, globbing is
|
||||
case-sensitive.
|
||||
|
||||
If the ``CONFIGURE_DEPENDS`` flag is specified, CMake will add logic
|
||||
to the main build system check target to rerun the flagged ``GLOB`` commands
|
||||
at build time. If any of the outputs change, CMake will regenerate the build
|
||||
system.
|
||||
.. versionadded:: 3.3
|
||||
By default ``GLOB`` lists directories - directories are omitted in result if
|
||||
``LIST_DIRECTORIES`` is set to false.
|
||||
|
||||
By default ``GLOB`` lists directories - directories are omitted in result if
|
||||
``LIST_DIRECTORIES`` is set to false.
|
||||
.. versionadded:: 3.12
|
||||
If the ``CONFIGURE_DEPENDS`` flag is specified, CMake will add logic
|
||||
to the main build system check target to rerun the flagged ``GLOB`` commands
|
||||
at build time. If any of the outputs change, CMake will regenerate the build
|
||||
system.
|
||||
|
||||
.. note::
|
||||
We do not recommend using GLOB to collect a list of source files from
|
||||
@ -582,23 +681,23 @@ matched directory and match the files. Subdirectories that are symlinks
|
||||
are only traversed if ``FOLLOW_SYMLINKS`` is given or policy
|
||||
:policy:`CMP0009` is not set to ``NEW``.
|
||||
|
||||
By default ``GLOB_RECURSE`` omits directories from result list - setting
|
||||
``LIST_DIRECTORIES`` to true adds directories to result list.
|
||||
If ``FOLLOW_SYMLINKS`` is given or policy :policy:`CMP0009` is not set to
|
||||
``NEW`` then ``LIST_DIRECTORIES`` treats symlinks as directories.
|
||||
.. versionadded:: 3.3
|
||||
By default ``GLOB_RECURSE`` omits directories from result list - setting
|
||||
``LIST_DIRECTORIES`` to true adds directories to result list.
|
||||
If ``FOLLOW_SYMLINKS`` is given or policy :policy:`CMP0009` is not set to
|
||||
``NEW`` then ``LIST_DIRECTORIES`` treats symlinks as directories.
|
||||
|
||||
Examples of recursive globbing include::
|
||||
|
||||
/dir/*.py - match all python files in /dir and subdirectories
|
||||
|
||||
.. _RENAME:
|
||||
.. _MAKE_DIRECTORY:
|
||||
|
||||
.. code-block:: cmake
|
||||
|
||||
file(RENAME <oldname> <newname>)
|
||||
file(MAKE_DIRECTORY [<directories>...])
|
||||
|
||||
Move a file or directory within a filesystem from ``<oldname>`` to
|
||||
``<newname>``, replacing the destination atomically.
|
||||
Create the given directories and their parents as needed.
|
||||
|
||||
.. _REMOVE:
|
||||
.. _REMOVE_RECURSE:
|
||||
@ -611,15 +710,71 @@ Move a file or directory within a filesystem from ``<oldname>`` to
|
||||
Remove the given files. The ``REMOVE_RECURSE`` mode will remove the given
|
||||
files and directories, also non-empty directories. No error is emitted if a
|
||||
given file does not exist. Relative input paths are evaluated with respect
|
||||
to the current source directory. Empty input paths are ignored with a warning.
|
||||
to the current source directory.
|
||||
|
||||
.. _MAKE_DIRECTORY:
|
||||
.. versionchanged:: 3.15
|
||||
Empty input paths are ignored with a warning. Previous versions of CMake
|
||||
interpreted empty strings as a relative path with respect to the current
|
||||
directory and removed its contents.
|
||||
|
||||
.. _RENAME:
|
||||
|
||||
.. code-block:: cmake
|
||||
|
||||
file(MAKE_DIRECTORY [<directories>...])
|
||||
file(RENAME <oldname> <newname>
|
||||
[RESULT <result>]
|
||||
[NO_REPLACE])
|
||||
|
||||
Create the given directories and their parents as needed.
|
||||
Move a file or directory within a filesystem from ``<oldname>`` to
|
||||
``<newname>``, replacing the destination atomically.
|
||||
|
||||
The options are:
|
||||
|
||||
``RESULT <result>``
|
||||
.. versionadded:: 3.21
|
||||
|
||||
Set ``<result>`` variable to ``0`` on success or an error message otherwise.
|
||||
If ``RESULT`` is not specified and the operation fails, an error is emitted.
|
||||
|
||||
``NO_REPLACE``
|
||||
.. versionadded:: 3.21
|
||||
|
||||
If the ``<newname>`` path already exists, do not replace it.
|
||||
If ``RESULT <result>`` is used, the result variable will be
|
||||
set to ``NO_REPLACE``. Otherwise, an error is emitted.
|
||||
|
||||
.. _COPY_FILE:
|
||||
|
||||
.. code-block:: cmake
|
||||
|
||||
file(COPY_FILE <oldname> <newname>
|
||||
[RESULT <result>]
|
||||
[ONLY_IF_DIFFERENT])
|
||||
|
||||
.. versionadded:: 3.21
|
||||
|
||||
Copy a file from ``<oldname>`` to ``<newname>``. Directories are not
|
||||
supported. Symlinks are ignored and ``<oldfile>``'s content is read and
|
||||
written to ``<newname>`` as a new file.
|
||||
|
||||
The options are:
|
||||
|
||||
``RESULT <result>``
|
||||
Set ``<result>`` variable to ``0`` on success or an error message otherwise.
|
||||
If ``RESULT`` is not specified and the operation fails, an error is emitted.
|
||||
|
||||
``ONLY_IF_DIFFERENT``
|
||||
If the ``<newname>`` path already exists, do not replace it if the file's
|
||||
contents are already the same as ``<oldname>`` (this avoids updating
|
||||
``<newname>``'s timestamp).
|
||||
|
||||
This sub-command has some similarities to :command:`configure_file` with the
|
||||
``COPYONLY`` option. An important difference is that :command:`configure_file`
|
||||
creates a dependency on the source file, so CMake will be re-run if it changes.
|
||||
The ``file(COPY_FILE)`` sub-command does not create such a dependency.
|
||||
|
||||
See also the ``file(COPY)`` sub-command just below which provides
|
||||
further file-copying capabilities.
|
||||
|
||||
.. _COPY:
|
||||
.. _INSTALL:
|
||||
@ -627,14 +782,19 @@ Create the given directories and their parents as needed.
|
||||
.. code-block:: cmake
|
||||
|
||||
file(<COPY|INSTALL> <files>... DESTINATION <dir>
|
||||
[NO_SOURCE_PERMISSIONS | USE_SOURCE_PERMISSIONS]
|
||||
[FILE_PERMISSIONS <permissions>...]
|
||||
[DIRECTORY_PERMISSIONS <permissions>...]
|
||||
[NO_SOURCE_PERMISSIONS] [USE_SOURCE_PERMISSIONS]
|
||||
[FOLLOW_SYMLINK_CHAIN]
|
||||
[FILES_MATCHING]
|
||||
[[PATTERN <pattern> | REGEX <regex>]
|
||||
[EXCLUDE] [PERMISSIONS <permissions>...]] [...])
|
||||
|
||||
.. note::
|
||||
|
||||
For a simple file copying operation, the ``file(COPY_FILE)`` sub-command
|
||||
just above may be easier to use.
|
||||
|
||||
The ``COPY`` signature copies files, directories, and symlinks to a
|
||||
destination folder. Relative input paths are evaluated with respect
|
||||
to the current source directory, and a relative destination is
|
||||
@ -644,17 +804,18 @@ at the destination with the same timestamp. Copying preserves input
|
||||
permissions unless explicit permissions or ``NO_SOURCE_PERMISSIONS``
|
||||
are given (default is ``USE_SOURCE_PERMISSIONS``).
|
||||
|
||||
If ``FOLLOW_SYMLINK_CHAIN`` is specified, ``COPY`` will recursively resolve
|
||||
the symlinks at the paths given until a real file is found, and install
|
||||
a corresponding symlink in the destination for each symlink encountered. For
|
||||
each symlink that is installed, the resolution is stripped of the directory,
|
||||
leaving only the filename, meaning that the new symlink points to a file in
|
||||
the same directory as the symlink. This feature is useful on some Unix systems,
|
||||
where libraries are installed as a chain of symlinks with version numbers, with
|
||||
less specific versions pointing to more specific versions.
|
||||
``FOLLOW_SYMLINK_CHAIN`` will install all of these symlinks and the library
|
||||
itself into the destination directory. For example, if you have the following
|
||||
directory structure:
|
||||
.. versionadded:: 3.15
|
||||
If ``FOLLOW_SYMLINK_CHAIN`` is specified, ``COPY`` will recursively resolve
|
||||
the symlinks at the paths given until a real file is found, and install
|
||||
a corresponding symlink in the destination for each symlink encountered. For
|
||||
each symlink that is installed, the resolution is stripped of the directory,
|
||||
leaving only the filename, meaning that the new symlink points to a file in
|
||||
the same directory as the symlink. This feature is useful on some Unix systems,
|
||||
where libraries are installed as a chain of symlinks with version numbers, with
|
||||
less specific versions pointing to more specific versions.
|
||||
``FOLLOW_SYMLINK_CHAIN`` will install all of these symlinks and the library
|
||||
itself into the destination directory. For example, if you have the following
|
||||
directory structure:
|
||||
|
||||
* ``/opt/foo/lib/libfoo.so.1.2.3``
|
||||
* ``/opt/foo/lib/libfoo.so.1.2 -> libfoo.so.1.2.3``
|
||||
@ -688,6 +849,8 @@ use this signature (with some undocumented options for internal use).
|
||||
|
||||
file(SIZE <filename> <variable>)
|
||||
|
||||
.. versionadded:: 3.14
|
||||
|
||||
Determine the file size of the ``<filename>`` and put the result in
|
||||
``<variable>`` variable. Requires that ``<filename>`` is a valid path
|
||||
pointing to a file and is readable.
|
||||
@ -698,6 +861,8 @@ pointing to a file and is readable.
|
||||
|
||||
file(READ_SYMLINK <linkname> <variable>)
|
||||
|
||||
.. versionadded:: 3.14
|
||||
|
||||
This subcommand queries the symlink ``<linkname>`` and stores the path it
|
||||
points to in the result ``<variable>``. If ``<linkname>`` does not exist or
|
||||
is not a symlink, CMake issues a fatal error.
|
||||
@ -722,6 +887,8 @@ absolute path is obtained:
|
||||
file(CREATE_LINK <original> <linkname>
|
||||
[RESULT <result>] [COPY_ON_ERROR] [SYMBOLIC])
|
||||
|
||||
.. versionadded:: 3.14
|
||||
|
||||
Create a link ``<linkname>`` that points to ``<original>``.
|
||||
It will be a hard link by default, but providing the ``SYMBOLIC`` option
|
||||
results in a symbolic link instead. Hard links require that ``original``
|
||||
@ -737,9 +904,86 @@ creating the link fails. It can be useful for handling situations such as
|
||||
``<original>`` and ``<linkname>`` being on different drives or mount points,
|
||||
which would make them unable to support a hard link.
|
||||
|
||||
.. _CHMOD:
|
||||
|
||||
.. code-block:: cmake
|
||||
|
||||
file(CHMOD <files>... <directories>...
|
||||
[PERMISSIONS <permissions>...]
|
||||
[FILE_PERMISSIONS <permissions>...]
|
||||
[DIRECTORY_PERMISSIONS <permissions>...])
|
||||
|
||||
.. versionadded:: 3.19
|
||||
|
||||
Set the permissions for the ``<files>...`` and ``<directories>...`` specified.
|
||||
Valid permissions are ``OWNER_READ``, ``OWNER_WRITE``, ``OWNER_EXECUTE``,
|
||||
``GROUP_READ``, ``GROUP_WRITE``, ``GROUP_EXECUTE``, ``WORLD_READ``,
|
||||
``WORLD_WRITE``, ``WORLD_EXECUTE``, ``SETUID``, ``SETGID``.
|
||||
|
||||
Valid combination of keywords are:
|
||||
|
||||
``PERMISSIONS``
|
||||
All items are changed.
|
||||
|
||||
``FILE_PERMISSIONS``
|
||||
Only files are changed.
|
||||
|
||||
``DIRECTORY_PERMISSIONS``
|
||||
Only directories are changed.
|
||||
|
||||
``PERMISSIONS`` and ``FILE_PERMISSIONS``
|
||||
``FILE_PERMISSIONS`` overrides ``PERMISSIONS`` for files.
|
||||
|
||||
``PERMISSIONS`` and ``DIRECTORY_PERMISSIONS``
|
||||
``DIRECTORY_PERMISSIONS`` overrides ``PERMISSIONS`` for directories.
|
||||
|
||||
``FILE_PERMISSIONS`` and ``DIRECTORY_PERMISSIONS``
|
||||
Use ``FILE_PERMISSIONS`` for files and ``DIRECTORY_PERMISSIONS`` for
|
||||
directories.
|
||||
|
||||
|
||||
.. _CHMOD_RECURSE:
|
||||
|
||||
.. code-block:: cmake
|
||||
|
||||
file(CHMOD_RECURSE <files>... <directories>...
|
||||
[PERMISSIONS <permissions>...]
|
||||
[FILE_PERMISSIONS <permissions>...]
|
||||
[DIRECTORY_PERMISSIONS <permissions>...])
|
||||
|
||||
.. versionadded:: 3.19
|
||||
|
||||
Same as `CHMOD`_, but change the permissions of files and directories present in
|
||||
the ``<directories>...`` recursively.
|
||||
|
||||
Path Conversion
|
||||
^^^^^^^^^^^^^^^
|
||||
|
||||
.. _REAL_PATH:
|
||||
|
||||
.. code-block:: cmake
|
||||
|
||||
file(REAL_PATH <path> <out-var> [BASE_DIRECTORY <dir>] [EXPAND_TILDE])
|
||||
|
||||
.. versionadded:: 3.19
|
||||
|
||||
Compute the absolute path to an existing file or directory with symlinks
|
||||
resolved.
|
||||
|
||||
``BASE_DIRECTORY <dir>``
|
||||
If the provided ``<path>`` 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`.
|
||||
|
||||
``EXPAND_TILDE``
|
||||
.. versionadded:: 3.21
|
||||
|
||||
If the ``<path>`` is ``~`` or starts with ``~/``, the ``~`` is replaced by
|
||||
the user's home directory. The path to the home directory is obtained from
|
||||
environment variables. On Windows, the ``USERPROFILE`` environment variable
|
||||
is used, falling back to the ``HOME`` environment variable if ``USERPROFILE``
|
||||
is not defined. On all other platforms, only ``HOME`` is used.
|
||||
|
||||
.. _RELATIVE_PATH:
|
||||
|
||||
.. code-block:: cmake
|
||||
@ -763,7 +1007,8 @@ system search path like ``$ENV{PATH}``. A search path will be converted
|
||||
to a cmake-style list separated by ``;`` characters.
|
||||
|
||||
The ``TO_NATIVE_PATH`` mode converts a cmake-style ``<path>`` into a native
|
||||
path with platform-specific slashes (``\`` on Windows and ``/`` elsewhere).
|
||||
path with platform-specific slashes (``\`` on Windows hosts and ``/``
|
||||
elsewhere).
|
||||
|
||||
Always use double quotes around the ``<path>`` to be sure it is treated
|
||||
as a single argument to this command.
|
||||
@ -776,12 +1021,17 @@ Transfer
|
||||
|
||||
.. code-block:: cmake
|
||||
|
||||
file(DOWNLOAD <url> <file> [<options>...])
|
||||
file(DOWNLOAD <url> [<file>] [<options>...])
|
||||
file(UPLOAD <file> <url> [<options>...])
|
||||
|
||||
The ``DOWNLOAD`` mode downloads the given ``<url>`` to a local ``<file>``.
|
||||
The ``DOWNLOAD`` subcommand downloads the given ``<url>`` to a local ``<file>``.
|
||||
The ``UPLOAD`` mode uploads a local ``<file>`` to a given ``<url>``.
|
||||
|
||||
.. versionadded:: 3.19
|
||||
If ``<file>`` is not specified for ``file(DOWNLOAD)``, the file is not saved.
|
||||
This can be useful if you want to know if a file can be downloaded (for example,
|
||||
to check that it exists) without actually saving it anywhere.
|
||||
|
||||
Options to both ``DOWNLOAD`` and ``UPLOAD`` are:
|
||||
|
||||
``INACTIVITY_TIMEOUT <seconds>``
|
||||
@ -805,12 +1055,18 @@ Options to both ``DOWNLOAD`` and ``UPLOAD`` are:
|
||||
Terminate the operation after a given total time has elapsed.
|
||||
|
||||
``USERPWD <username>:<password>``
|
||||
.. versionadded:: 3.7
|
||||
|
||||
Set username and password for operation.
|
||||
|
||||
``HTTPHEADER <HTTP-header>``
|
||||
.. versionadded:: 3.7
|
||||
|
||||
HTTP header for operation. Suboption can be repeated several times.
|
||||
|
||||
``NETRC <level>``
|
||||
.. versionadded:: 3.11
|
||||
|
||||
Specify whether the .netrc file is to be used for operation. If this
|
||||
option is not specified, the value of the ``CMAKE_NETRC`` variable
|
||||
will be used instead.
|
||||
@ -827,6 +1083,8 @@ Options to both ``DOWNLOAD`` and ``UPLOAD`` are:
|
||||
The .netrc file is required, and information in the URL is ignored.
|
||||
|
||||
``NETRC_FILE <file>``
|
||||
.. versionadded:: 3.11
|
||||
|
||||
Specify an alternative .netrc file to the one in your home directory,
|
||||
if the ``NETRC`` level is ``OPTIONAL`` or ``REQUIRED``. If this option
|
||||
is not specified, the value of the ``CMAKE_NETRC_FILE`` variable will
|
||||
@ -839,13 +1097,19 @@ If neither ``NETRC`` option is given CMake will check variables
|
||||
Specify whether to verify the server certificate for ``https://`` URLs.
|
||||
The default is to *not* verify.
|
||||
|
||||
.. versionadded:: 3.18
|
||||
Added support to ``file(UPLOAD)``.
|
||||
|
||||
``TLS_CAINFO <file>``
|
||||
Specify a custom Certificate Authority file for ``https://`` URLs.
|
||||
|
||||
.. versionadded:: 3.18
|
||||
Added support to ``file(UPLOAD)``.
|
||||
|
||||
For ``https://`` URLs CMake must be built with OpenSSL support. ``TLS/SSL``
|
||||
certificates are not checked by default. Set ``TLS_VERIFY`` to ``ON`` to
|
||||
check certificates. If neither ``TLS`` option is given CMake will check
|
||||
variables ``CMAKE_TLS_VERIFY`` and ``CMAKE_TLS_CAINFO``, respectively.
|
||||
variables :variable:`CMAKE_TLS_VERIFY` and ``CMAKE_TLS_CAINFO``, respectively.
|
||||
|
||||
Additional options to ``DOWNLOAD`` are:
|
||||
|
||||
@ -853,10 +1117,12 @@ Additional options to ``DOWNLOAD`` are:
|
||||
|
||||
Verify that the downloaded content hash matches the expected value, where
|
||||
``ALGO`` is one of the algorithms supported by ``file(<HASH>)``.
|
||||
If it does not match, the operation fails with an error.
|
||||
If it does not match, the operation fails with an error. It is an error to
|
||||
specify this if ``DOWNLOAD`` is not given a ``<file>``.
|
||||
|
||||
``EXPECTED_MD5 <value>``
|
||||
Historical short-hand for ``EXPECTED_HASH MD5=<value>``.
|
||||
Historical short-hand for ``EXPECTED_HASH MD5=<value>``. It is an error to
|
||||
specify this if ``DOWNLOAD`` is not given a ``<file>``.
|
||||
|
||||
Locking
|
||||
^^^^^^^
|
||||
@ -870,6 +1136,8 @@ Locking
|
||||
[RESULT_VARIABLE <variable>]
|
||||
[TIMEOUT <seconds>])
|
||||
|
||||
.. versionadded:: 3.2
|
||||
|
||||
Lock a file specified by ``<path>`` if no ``DIRECTORY`` option present and file
|
||||
``<path>/cmake.lock`` otherwise. File will be locked for scope defined by
|
||||
``GUARD`` option (default value is ``PROCESS``). ``RELEASE`` option can be used
|
||||
@ -901,10 +1169,12 @@ Archiving
|
||||
file(ARCHIVE_CREATE OUTPUT <archive>
|
||||
PATHS <paths>...
|
||||
[FORMAT <format>]
|
||||
[COMPRESSION <compression>]
|
||||
[COMPRESSION <compression> [COMPRESSION_LEVEL <compression-level>]]
|
||||
[MTIME <mtime>]
|
||||
[VERBOSE])
|
||||
|
||||
.. versionadded:: 3.18
|
||||
|
||||
Creates the specified ``<archive>`` file with the files and directories
|
||||
listed in ``<paths>``. Note that ``<paths>`` must list actual files or
|
||||
directories, wildcards are not supported.
|
||||
@ -919,6 +1189,11 @@ compression. The other formats use no compression by default, but can be
|
||||
directed to do so with the ``COMPRESSION`` option. Valid values for
|
||||
``<compression>`` are ``None``, ``BZip2``, ``GZip``, ``XZ``, and ``Zstd``.
|
||||
|
||||
.. versionadded:: 3.19
|
||||
The compression level can be specified with the ``COMPRESSION_LEVEL`` option.
|
||||
The ``<compression-level>`` should be between 0-9, with the default being 0.
|
||||
The ``COMPRESSION`` option must be present when ``COMPRESSION_LEVEL`` is given.
|
||||
|
||||
.. note::
|
||||
With ``FORMAT`` set to ``raw`` only one file will be compressed with the
|
||||
compression type specified by ``COMPRESSION``.
|
||||
@ -938,6 +1213,8 @@ the ``MTIME`` option.
|
||||
[LIST_ONLY]
|
||||
[VERBOSE])
|
||||
|
||||
.. versionadded:: 3.18
|
||||
|
||||
Extracts or lists the content of the specified ``<archive>``.
|
||||
|
||||
The directory where the content of the archive will be extracted to can
|
||||
|
@ -17,7 +17,8 @@ find_file
|
||||
.. |CMAKE_XXX_PATH| replace:: :variable:`CMAKE_INCLUDE_PATH`
|
||||
.. |CMAKE_XXX_MAC_PATH| replace:: :variable:`CMAKE_FRAMEWORK_PATH`
|
||||
|
||||
.. |SYSTEM_ENVIRONMENT_PATH_XXX| replace:: The directories in ``PATH`` and ``INCLUDE``.
|
||||
.. |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|.
|
||||
|
@ -17,7 +17,8 @@ find_library
|
||||
.. |CMAKE_XXX_PATH| replace:: :variable:`CMAKE_LIBRARY_PATH`
|
||||
.. |CMAKE_XXX_MAC_PATH| replace:: :variable:`CMAKE_FRAMEWORK_PATH`
|
||||
|
||||
.. |SYSTEM_ENVIRONMENT_PATH_XXX| replace:: The directories in ``PATH`` and ``INCLUDE``.
|
||||
.. |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|.
|
||||
|
@ -34,14 +34,30 @@ Additional optional components may be listed after
|
||||
whether a package is considered to be found are defined by the target
|
||||
package.
|
||||
|
||||
.. _FIND_PACKAGE_VERSION_FORMAT:
|
||||
|
||||
The ``[version]`` argument requests a version with which the package found
|
||||
should be compatible (format is ``major[.minor[.patch[.tweak]]]``). The
|
||||
``EXACT`` option requests that the version be matched exactly. If no
|
||||
``[version]`` and/or component list is given to a recursive invocation
|
||||
should be compatible. There are two possible forms in which it may be
|
||||
specified:
|
||||
|
||||
* A single version with the format ``major[.minor[.patch[.tweak]]]``.
|
||||
* A version range with the format ``versionMin...[<]versionMax`` where
|
||||
``versionMin`` and ``versionMax`` have the same format 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.
|
||||
@ -140,10 +156,10 @@ outlined below will find them without requiring use of additional options.
|
||||
Version Selection
|
||||
^^^^^^^^^^^^^^^^^
|
||||
|
||||
When the ``[version]`` argument is given Config mode will only find a
|
||||
When the ``[version]`` argument is given, Config mode will only find a
|
||||
version of the package that claims compatibility with the requested
|
||||
version (format is ``major[.minor[.patch[.tweak]]]``). If the ``EXACT``
|
||||
option is given only a version of the package claiming an exact match
|
||||
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
|
||||
@ -160,31 +176,78 @@ version file is loaded in a nested scope in which the following
|
||||
variables have been defined:
|
||||
|
||||
``PACKAGE_FIND_NAME``
|
||||
the ``<PackageName>``
|
||||
The ``<PackageName>``
|
||||
``PACKAGE_FIND_VERSION``
|
||||
full requested version string
|
||||
Full requested version string
|
||||
``PACKAGE_FIND_VERSION_MAJOR``
|
||||
major version if requested, else 0
|
||||
Major version if requested, else 0
|
||||
``PACKAGE_FIND_VERSION_MINOR``
|
||||
minor version if requested, else 0
|
||||
Minor version if requested, else 0
|
||||
``PACKAGE_FIND_VERSION_PATCH``
|
||||
patch version if requested, else 0
|
||||
Patch version if requested, else 0
|
||||
``PACKAGE_FIND_VERSION_TWEAK``
|
||||
tweak version if requested, else 0
|
||||
Tweak version if requested, else 0
|
||||
``PACKAGE_FIND_VERSION_COUNT``
|
||||
number of version components, 0 to 4
|
||||
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
|
||||
Full provided version string
|
||||
``PACKAGE_VERSION_EXACT``
|
||||
true if version is exact match
|
||||
True if version is exact match
|
||||
``PACKAGE_VERSION_COMPATIBLE``
|
||||
true if version is compatible
|
||||
True if version is compatible
|
||||
``PACKAGE_VERSION_UNSUITABLE``
|
||||
true if unsuitable as any version
|
||||
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
|
||||
@ -192,17 +255,17 @@ 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
|
||||
Full provided version string
|
||||
``<PackageName>_VERSION_MAJOR``
|
||||
major version if provided, else 0
|
||||
Major version if provided, else 0
|
||||
``<PackageName>_VERSION_MINOR``
|
||||
minor version if provided, else 0
|
||||
Minor version if provided, else 0
|
||||
``<PackageName>_VERSION_PATCH``
|
||||
patch version if provided, else 0
|
||||
Patch version if provided, else 0
|
||||
``<PackageName>_VERSION_TWEAK``
|
||||
tweak version if provided, else 0
|
||||
Tweak version if provided, else 0
|
||||
``<PackageName>_VERSION_COUNT``
|
||||
number of version components, 0 to 4
|
||||
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
|
||||
@ -288,15 +351,16 @@ The set of installation prefixes is constructed using the following
|
||||
steps. If ``NO_DEFAULT_PATH`` is specified all ``NO_*`` options are
|
||||
enabled.
|
||||
|
||||
1. Search paths specified in the :variable:`<PackageName>_ROOT` CMake
|
||||
variable and the :envvar:`<PackageName>_ROOT` environment variable,
|
||||
where ``<PackageName>`` is the package to be found.
|
||||
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``.
|
||||
See policy :policy:`CMP0074`.
|
||||
1. .. versionadded:: 3.12
|
||||
Search paths specified in the :variable:`<PackageName>_ROOT` CMake
|
||||
variable and the :envvar:`<PackageName>_ROOT` environment variable,
|
||||
where ``<PackageName>`` is the package to be found.
|
||||
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``.
|
||||
See policy :policy:`CMP0074`.
|
||||
|
||||
2. Search paths specified in cmake-specific cache variables. These
|
||||
are intended to be used on the command line with a ``-DVAR=value``.
|
||||
@ -367,6 +431,10 @@ enabled.
|
||||
9. Search paths specified by the ``PATHS`` option. These are typically
|
||||
hard-coded guesses.
|
||||
|
||||
.. versionadded:: 3.16
|
||||
Added the ``CMAKE_FIND_USE_<CATEGORY>_PATH`` variables to globally disable
|
||||
various search locations.
|
||||
|
||||
.. |FIND_XXX| replace:: find_package
|
||||
.. |FIND_ARGS_XXX| replace:: <PackageName>
|
||||
.. |CMAKE_FIND_ROOT_PATH_MODE_XXX| replace::
|
||||
@ -391,31 +459,77 @@ 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
|
||||
The ``<PackageName>`` which is searched for
|
||||
``<PackageName>_FIND_REQUIRED``
|
||||
true if ``REQUIRED`` option was given
|
||||
True if ``REQUIRED`` option was given
|
||||
``<PackageName>_FIND_QUIETLY``
|
||||
true if ``QUIET`` option was given
|
||||
True if ``QUIET`` option was given
|
||||
``<PackageName>_FIND_VERSION``
|
||||
full requested version string
|
||||
Full requested version string
|
||||
``<PackageName>_FIND_VERSION_MAJOR``
|
||||
major version if requested, else 0
|
||||
Major version if requested, else 0
|
||||
``<PackageName>_FIND_VERSION_MINOR``
|
||||
minor version if requested, else 0
|
||||
Minor version if requested, else 0
|
||||
``<PackageName>_FIND_VERSION_PATCH``
|
||||
patch version if requested, else 0
|
||||
Patch version if requested, else 0
|
||||
``<PackageName>_FIND_VERSION_TWEAK``
|
||||
tweak version if requested, else 0
|
||||
Tweak version if requested, else 0
|
||||
``<PackageName>_FIND_VERSION_COUNT``
|
||||
number of version components, 0 to 4
|
||||
Number of version components, 0 to 4
|
||||
``<PackageName>_FIND_VERSION_EXACT``
|
||||
true if ``EXACT`` option was given
|
||||
True if ``EXACT`` option was given
|
||||
``<PackageName>_FIND_COMPONENTS``
|
||||
list of requested components
|
||||
List of requested components
|
||||
``<PackageName>_FIND_REQUIRED_<c>``
|
||||
true if component ``<c>`` is required,
|
||||
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
|
||||
|
@ -17,7 +17,8 @@ find_path
|
||||
.. |CMAKE_XXX_PATH| replace:: :variable:`CMAKE_INCLUDE_PATH`
|
||||
.. |CMAKE_XXX_MAC_PATH| replace:: :variable:`CMAKE_FRAMEWORK_PATH`
|
||||
|
||||
.. |SYSTEM_ENVIRONMENT_PATH_XXX| replace:: The directories in ``PATH`` and ``INCLUDE``.
|
||||
.. |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|.
|
||||
|
@ -14,9 +14,12 @@ 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
|
||||
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.
|
||||
|
||||
@ -88,6 +91,8 @@ yields
|
||||
|
||||
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
|
||||
|
@ -50,8 +50,9 @@ and so on. However, it is strongly recommended to stay with the
|
||||
case chosen in the function definition. Typically functions use
|
||||
all-lowercase names.
|
||||
|
||||
The :command:`cmake_language(CALL ...)` command can also be used to
|
||||
invoke the function.
|
||||
.. versionadded:: 3.18
|
||||
The :command:`cmake_language(CALL ...)` command can also be used to
|
||||
invoke the function.
|
||||
|
||||
Arguments
|
||||
^^^^^^^^^
|
||||
|
@ -8,9 +8,16 @@ Get a property of ``DIRECTORY`` scope.
|
||||
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.
|
||||
The specified directory must have already been traversed by CMake.
|
||||
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,
|
||||
|
@ -3,6 +3,11 @@ get_filename_component
|
||||
|
||||
Get a specific component of a full filename.
|
||||
|
||||
.. versionchanged:: 3.20
|
||||
This command been superseded by :command:`cmake_path` command, except
|
||||
``REALPATH`` now offered by :ref:`file(REAL_PATH) <REAL_PATH>` command and
|
||||
``PROGRAM`` now available in :command:`separate_arguments(PROGRAM)` command.
|
||||
|
||||
.. code-block:: cmake
|
||||
|
||||
get_filename_component(<var> <FileName> <mode> [CACHE])
|
||||
@ -14,11 +19,14 @@ 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 without directory or longest extension
|
||||
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 without directory or last extension
|
||||
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.
|
||||
@ -27,6 +35,8 @@ added to the cache.
|
||||
|
||||
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:
|
||||
|
||||
|
@ -31,31 +31,42 @@ It must be one of the following:
|
||||
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, but this can be
|
||||
overridden with one of the following sub-options:
|
||||
will be read from the current source directory's scope.
|
||||
|
||||
``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.
|
||||
.. versionadded:: 3.18
|
||||
Directory scope can be overridden with one of the following sub-options:
|
||||
|
||||
``TARGET_DIRECTORY <target>``
|
||||
The source file property will be read from the directory scope in which
|
||||
``<target>`` was created (``<target>`` must therefore already exist).
|
||||
``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``
|
||||
@ -83,3 +94,8 @@ 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.
|
||||
|
@ -19,22 +19,29 @@ 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, but this can be overridden with one of the following
|
||||
sub-options:
|
||||
directory's scope.
|
||||
|
||||
``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.
|
||||
.. versionadded:: 3.18
|
||||
Directory scope can be overridden with one of the following sub-options:
|
||||
|
||||
``TARGET_DIRECTORY <target>``
|
||||
The source file property will be read from the directory scope in which
|
||||
``<target>`` was created (``<target>`` must therefore already exist).
|
||||
``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`.
|
||||
|
||||
See also the more general :command:`get_property` command.
|
||||
|
||||
.. note::
|
||||
|
||||
The :prop_sf:`GENERATED` source file property may be globally visible.
|
||||
See its documentation for details.
|
||||
|
@ -39,15 +39,16 @@ the ``if``, ``elseif`` and :command:`while` clauses.
|
||||
|
||||
Compound conditions are evaluated in the following order of precedence:
|
||||
Innermost parentheses are evaluated first. Next come unary tests such
|
||||
as ``EXISTS``, ``COMMAND``, and ``DEFINED``. Then 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``,
|
||||
and ``MATCHES``. Then the boolean operators in the order ``NOT``, ``AND``,
|
||||
and finally ``OR``.
|
||||
as `EXISTS`_, `COMMAND`_, and `DEFINED`_. Then 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`_,
|
||||
and `MATCHES`_. Then the boolean operators in the order `NOT`_, `AND`_,
|
||||
and finally `OR`_.
|
||||
|
||||
Possible conditions are:
|
||||
Basic Expressions
|
||||
"""""""""""""""""
|
||||
|
||||
``if(<constant>)``
|
||||
True if the constant is ``1``, ``ON``, ``YES``, ``TRUE``, ``Y``,
|
||||
@ -62,15 +63,35 @@ Possible conditions are:
|
||||
True if given a variable that is defined to a value that is not a false
|
||||
constant. False otherwise. (Note macro arguments are not variables.)
|
||||
|
||||
Logic Operators
|
||||
"""""""""""""""
|
||||
|
||||
.. _NOT:
|
||||
|
||||
``if(NOT <condition>)``
|
||||
True if the condition is not true.
|
||||
|
||||
.. _AND:
|
||||
|
||||
``if(<cond1> AND <cond2>)``
|
||||
True if both conditions would be considered true individually.
|
||||
|
||||
.. _OR:
|
||||
|
||||
``if(<cond1> OR <cond2>)``
|
||||
True if either condition would be considered true individually.
|
||||
|
||||
``if((condition) AND (condition OR (condition)))``
|
||||
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
|
||||
""""""""""""""""
|
||||
|
||||
.. _COMMAND:
|
||||
|
||||
``if(COMMAND command-name)``
|
||||
True if the given name is a command, macro or function that can be
|
||||
invoked.
|
||||
@ -85,14 +106,35 @@ Possible conditions are:
|
||||
(in any directory).
|
||||
|
||||
``if(TEST test-name)``
|
||||
True if the given name is an existing test name created by the
|
||||
:command:`add_test` command.
|
||||
.. versionadded:: 3.3
|
||||
True if the given name is an existing test name created by the
|
||||
:command:`add_test` command.
|
||||
|
||||
.. _DEFINED:
|
||||
|
||||
``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 that macro arguments are not variables.
|
||||
|
||||
.. versionadded:: 3.14
|
||||
Added support for ``CACHE{<name>}`` variables.
|
||||
|
||||
``if(<variable|string> IN_LIST <variable>)``
|
||||
.. versionadded:: 3.3
|
||||
True if the given element is contained in the named list variable.
|
||||
|
||||
File Operations
|
||||
"""""""""""""""
|
||||
|
||||
.. _EXISTS:
|
||||
|
||||
``if(EXISTS path-to-file-or-directory)``
|
||||
True if the named file or directory exists. Behavior is well-defined
|
||||
only for full paths. 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.
|
||||
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.
|
||||
|
||||
``if(file1 IS_NEWER_THAN file2)``
|
||||
True if ``file1`` is newer than ``file2`` or if one of the two files doesn't
|
||||
@ -111,52 +153,97 @@ Possible conditions are:
|
||||
only for full paths.
|
||||
|
||||
``if(IS_ABSOLUTE path)``
|
||||
True if the given path is an 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
|
||||
"""""""""""
|
||||
|
||||
.. _MATCHES:
|
||||
|
||||
``if(<variable|string> MATCHES regex)``
|
||||
True if the given string or variable's value matches the given regular
|
||||
condition. See :ref:`Regex Specification` for regex format.
|
||||
``()`` groups are captured in :variable:`CMAKE_MATCH_<n>` variables.
|
||||
|
||||
.. versionadded:: 3.9
|
||||
``()`` groups are captured in :variable:`CMAKE_MATCH_<n>` variables.
|
||||
|
||||
.. _LESS:
|
||||
|
||||
``if(<variable|string> LESS <variable|string>)``
|
||||
True if the given string or variable's value is a valid number and less
|
||||
than that on the right.
|
||||
|
||||
.. _GREATER:
|
||||
|
||||
``if(<variable|string> GREATER <variable|string>)``
|
||||
True if the given string or variable's value is a valid number and greater
|
||||
than that on the right.
|
||||
|
||||
.. _EQUAL:
|
||||
|
||||
``if(<variable|string> EQUAL <variable|string>)``
|
||||
True if the given string or variable's value is a valid number and equal
|
||||
to that on the right.
|
||||
|
||||
.. _LESS_EQUAL:
|
||||
|
||||
``if(<variable|string> LESS_EQUAL <variable|string>)``
|
||||
True if the given string or variable's value is a valid number and less
|
||||
than or equal to that on the right.
|
||||
.. 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.
|
||||
|
||||
.. _GREATER_EQUAL:
|
||||
|
||||
``if(<variable|string> GREATER_EQUAL <variable|string>)``
|
||||
True if the given string or variable's value is a valid number and greater
|
||||
than or equal to that on the right.
|
||||
.. 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.
|
||||
|
||||
.. _STRLESS:
|
||||
|
||||
``if(<variable|string> STRLESS <variable|string>)``
|
||||
True if the given string or variable's value is lexicographically less
|
||||
than the string or variable on the right.
|
||||
|
||||
.. _STRGREATER:
|
||||
|
||||
``if(<variable|string> STRGREATER <variable|string>)``
|
||||
True if the given string or variable's value is lexicographically greater
|
||||
than the string or variable on the right.
|
||||
|
||||
.. _STREQUAL:
|
||||
|
||||
``if(<variable|string> STREQUAL <variable|string>)``
|
||||
True if the given string or variable's value is lexicographically equal
|
||||
to the string or variable on the right.
|
||||
|
||||
.. _STRLESS_EQUAL:
|
||||
|
||||
``if(<variable|string> STRLESS_EQUAL <variable|string>)``
|
||||
True if the given string or variable's value is lexicographically less
|
||||
than or equal to the string or variable on the right.
|
||||
.. 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.
|
||||
|
||||
.. _STRGREATER_EQUAL:
|
||||
|
||||
``if(<variable|string> STRGREATER_EQUAL <variable|string>)``
|
||||
True if the given string or variable's value is lexicographically greater
|
||||
than or equal to the string or variable on the right.
|
||||
.. 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
|
||||
"""""""""""""""""""
|
||||
|
||||
.. _VERSION_LESS:
|
||||
|
||||
``if(<variable|string> VERSION_LESS <variable|string>)``
|
||||
Component-wise integer version number comparison (version format is
|
||||
@ -164,43 +251,39 @@ Possible conditions are:
|
||||
Any non-integer version component or non-integer trailing part of a version
|
||||
component effectively truncates the string at that point.
|
||||
|
||||
.. _VERSION_GREATER:
|
||||
|
||||
``if(<variable|string> VERSION_GREATER <variable|string>)``
|
||||
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.
|
||||
|
||||
.. _VERSION_EQUAL:
|
||||
|
||||
``if(<variable|string> VERSION_EQUAL <variable|string>)``
|
||||
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.
|
||||
|
||||
.. _VERSION_LESS_EQUAL:
|
||||
|
||||
``if(<variable|string> VERSION_LESS_EQUAL <variable|string>)``
|
||||
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.
|
||||
.. 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.
|
||||
|
||||
.. _VERSION_GREATER_EQUAL:
|
||||
|
||||
``if(<variable|string> VERSION_GREATER_EQUAL <variable|string>)``
|
||||
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.
|
||||
|
||||
``if(<variable|string> IN_LIST <variable>)``
|
||||
True if the given element is contained in the named list variable.
|
||||
|
||||
``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 that macro arguments are not variables.
|
||||
|
||||
``if((condition) AND (condition OR (condition)))``
|
||||
The conditions inside the parenthesis are evaluated first and then
|
||||
the remaining condition is evaluated as in the previous examples.
|
||||
Where there are nested parenthesis the innermost are evaluated as part
|
||||
of evaluating the condition that contains them.
|
||||
.. 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.
|
||||
|
||||
Variable Expansion
|
||||
^^^^^^^^^^^^^^^^^^
|
||||
@ -268,11 +351,12 @@ above-documented condition syntax accepts ``<variable|string>``:
|
||||
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.
|
||||
|
||||
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`.
|
||||
.. 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
|
||||
|
@ -21,6 +21,7 @@ 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).
|
||||
|
||||
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.
|
||||
.. 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.
|
||||
|
@ -1,6 +1,8 @@
|
||||
include_guard
|
||||
-------------
|
||||
|
||||
.. versionadded:: 3.10
|
||||
|
||||
Provides an include guard for the file currently being processed by CMake.
|
||||
|
||||
.. code-block:: cmake
|
||||
|
@ -9,21 +9,26 @@ Synopsis
|
||||
.. parsed-literal::
|
||||
|
||||
install(`TARGETS`_ <target>... [...])
|
||||
install(`IMPORTED_RUNTIME_ARTIFACTS`_ <target>... [...])
|
||||
install({`FILES`_ | `PROGRAMS`_} <file>... [...])
|
||||
install(`DIRECTORY`_ <dir>... [...])
|
||||
install(`SCRIPT`_ <file> [...])
|
||||
install(`CODE`_ <code> [...])
|
||||
install(`EXPORT`_ <export-name> [...])
|
||||
install(`RUNTIME_DEPENDENCY_SET`_ <set-name> [...])
|
||||
|
||||
Introduction
|
||||
^^^^^^^^^^^^
|
||||
|
||||
This command generates installation rules for a project. Install rules
|
||||
specified by calls to the ``install()`` command within a source directory
|
||||
are executed in order during installation. Install rules in subdirectories
|
||||
added by calls to the :command:`add_subdirectory` command are interleaved
|
||||
with those in the parent directory to run in the order declared (see
|
||||
policy :policy:`CMP0082`).
|
||||
are executed in order during installation.
|
||||
|
||||
.. versionchanged:: 3.14
|
||||
Install rules in subdirectories
|
||||
added by calls to the :command:`add_subdirectory` command are interleaved
|
||||
with those in the parent directory to run in the order declared (see
|
||||
policy :policy:`CMP0082`).
|
||||
|
||||
There are multiple signatures for this command. Some of them define
|
||||
installation options for files and targets. Options common to
|
||||
@ -45,6 +50,9 @@ signatures that specify them. The common options are:
|
||||
|
||||
As absolute paths are not supported by :manual:`cpack <cpack(1)>` installer
|
||||
generators, it is preferable to use relative paths throughout.
|
||||
In particular, there is no need to make paths absolute by prepending
|
||||
:variable:`CMAKE_INSTALL_PREFIX`; this prefix is used by default if
|
||||
the DESTINATION is a relative path.
|
||||
|
||||
``PERMISSIONS``
|
||||
Specify permissions for installed files. Valid permissions are
|
||||
@ -82,6 +90,8 @@ signatures that specify them. The common options are:
|
||||
:variable:`CMAKE_INSTALL_DEFAULT_COMPONENT_NAME` variable.
|
||||
|
||||
``EXCLUDE_FROM_ALL``
|
||||
.. versionadded:: 3.6
|
||||
|
||||
Specify that the file is excluded from a full installation and only
|
||||
installed as part of a component-specific installation
|
||||
|
||||
@ -94,16 +104,18 @@ signatures that specify them. The common options are:
|
||||
Specify that it is not an error if the file to be installed does
|
||||
not exist.
|
||||
|
||||
Command signatures that install files may print messages during
|
||||
installation. Use the :variable:`CMAKE_INSTALL_MESSAGE` variable
|
||||
to control which messages are printed.
|
||||
.. versionadded:: 3.1
|
||||
Command signatures that install files may print messages during
|
||||
installation. Use the :variable:`CMAKE_INSTALL_MESSAGE` variable
|
||||
to control which messages are printed.
|
||||
|
||||
Many of the ``install()`` variants implicitly create the directories
|
||||
containing the installed files. If
|
||||
:variable:`CMAKE_INSTALL_DEFAULT_DIRECTORY_PERMISSIONS` is set, these
|
||||
directories will be created with the permissions specified. Otherwise,
|
||||
they will be created according to the uname rules on Unix-like platforms.
|
||||
Windows platforms are unaffected.
|
||||
.. versionadded:: 3.11
|
||||
Many of the ``install()`` variants implicitly create the directories
|
||||
containing the installed files. If
|
||||
:variable:`CMAKE_INSTALL_DEFAULT_DIRECTORY_PERMISSIONS` is set, these
|
||||
directories will be created with the permissions specified. Otherwise,
|
||||
they will be created according to the uname rules on Unix-like platforms.
|
||||
Windows platforms are unaffected.
|
||||
|
||||
Installing Targets
|
||||
^^^^^^^^^^^^^^^^^^
|
||||
@ -114,6 +126,7 @@ Installing Targets
|
||||
.. code-block:: cmake
|
||||
|
||||
install(TARGETS targets... [EXPORT <export-name>]
|
||||
[RUNTIME_DEPENDENCIES args...|RUNTIME_DEPENDENCY_SET <set-name>]
|
||||
[[ARCHIVE|LIBRARY|RUNTIME|OBJECTS|FRAMEWORK|BUNDLE|
|
||||
PRIVATE_HEADER|PUBLIC_HEADER|RESOURCE]
|
||||
[DESTINATION <dir>]
|
||||
@ -159,6 +172,8 @@ that may be installed:
|
||||
accompanying import libraries are of kind ``ARCHIVE``).
|
||||
|
||||
``OBJECTS``
|
||||
.. versionadded:: 3.9
|
||||
|
||||
Object files associated with *object libraries*.
|
||||
|
||||
``FRAMEWORK``
|
||||
@ -243,6 +258,8 @@ In addition to the common options listed above, each target can accept
|
||||
the following additional arguments:
|
||||
|
||||
``NAMELINK_COMPONENT``
|
||||
.. versionadded:: 3.12
|
||||
|
||||
On some platforms a versioned shared library has a symbolic link such
|
||||
as::
|
||||
|
||||
@ -324,6 +341,49 @@ top level:
|
||||
relative path is specified, it is treated as relative to the
|
||||
``$<INSTALL_PREFIX>``.
|
||||
|
||||
``RUNTIME_DEPENDENCY_SET``
|
||||
.. versionadded:: 3.21
|
||||
|
||||
This option causes all runtime dependencies of installed executable, shared
|
||||
library, and module targets to be added to the specified runtime dependency
|
||||
set. This set can then be installed with an
|
||||
`install(RUNTIME_DEPENDENCY_SET)`_ command.
|
||||
|
||||
This keyword and the ``RUNTIME_DEPENDENCIES`` keyword are mutually
|
||||
exclusive.
|
||||
|
||||
``RUNTIME_DEPENDENCIES``
|
||||
.. versionadded:: 3.21
|
||||
|
||||
This option causes all runtime dependencies of installed executable, shared
|
||||
library, and module targets to be installed along with the targets
|
||||
themselves. The ``RUNTIME``, ``LIBRARY``, ``FRAMEWORK``, and generic
|
||||
arguments are used to determine the properties (``DESTINATION``,
|
||||
``COMPONENT``, etc.) of the installation of these dependencies.
|
||||
|
||||
``RUNTIME_DEPENDENCIES`` is semantically equivalent to the following pair
|
||||
of calls:
|
||||
|
||||
.. code-block:: cmake
|
||||
|
||||
install(TARGETS ... RUNTIME_DEPENDENCY_SET <set-name>)
|
||||
install(RUNTIME_DEPENDENCY_SET <set-name> args...)
|
||||
|
||||
where ``<set-name>`` will be a randomly generated set name.
|
||||
The ``args...`` may include any of the following keywords supported by
|
||||
the `install(RUNTIME_DEPENDENCY_SET)`_ command:
|
||||
|
||||
* ``DIRECTORIES``
|
||||
* ``PRE_INCLUDE_REGEXES``
|
||||
* ``PRE_EXCLUDE_REGEXES``
|
||||
* ``POST_INCLUDE_REGEXES``
|
||||
* ``POST_EXCLUDE_REGEXES``
|
||||
* ``POST_INCLUDE_FILES``
|
||||
* ``POST_EXCLUDE_FILES``
|
||||
|
||||
The ``RUNTIME_DEPENDENCIES`` and ``RUNTIME_DEPENDENCY_SET`` keywords are
|
||||
mutually exclusive.
|
||||
|
||||
One or more groups of properties may be specified in a single call to
|
||||
the ``TARGETS`` form of this command. A target may be installed more than
|
||||
once to different locations. Consider hypothetical targets ``myExe``,
|
||||
@ -354,17 +414,57 @@ targets that link to the object libraries in their implementation.
|
||||
Installing a target with the :prop_tgt:`EXCLUDE_FROM_ALL` target property
|
||||
set to ``TRUE`` has undefined behavior.
|
||||
|
||||
`install(TARGETS)`_ can install targets that were created in
|
||||
other directories. When using such cross-directory install rules, running
|
||||
``make install`` (or similar) from a subdirectory will not guarantee that
|
||||
targets from other directories are up-to-date. You can use
|
||||
:command:`target_link_libraries` or :command:`add_dependencies`
|
||||
to ensure that such out-of-directory targets are built before the
|
||||
subdirectory-specific install rules are run.
|
||||
.. versionadded:: 3.3
|
||||
An install destination given as a ``DESTINATION`` argument may
|
||||
use "generator expressions" with the syntax ``$<...>``. See the
|
||||
:manual:`cmake-generator-expressions(7)` manual for available expressions.
|
||||
|
||||
An install destination given as a ``DESTINATION`` argument may
|
||||
use "generator expressions" with the syntax ``$<...>``. See the
|
||||
:manual:`cmake-generator-expressions(7)` manual for available expressions.
|
||||
.. versionadded:: 3.13
|
||||
`install(TARGETS)`_ can install targets that were created in
|
||||
other directories. When using such cross-directory install rules, running
|
||||
``make install`` (or similar) from a subdirectory will not guarantee that
|
||||
targets from other directories are up-to-date. You can use
|
||||
:command:`target_link_libraries` or :command:`add_dependencies`
|
||||
to ensure that such out-of-directory targets are built before the
|
||||
subdirectory-specific install rules are run.
|
||||
|
||||
Installing Imported Runtime Artifacts
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
.. _`install(IMPORTED_RUNTIME_ARTIFACTS)`:
|
||||
.. _IMPORTED_RUNTIME_ARTIFACTS:
|
||||
|
||||
.. versionadded:: 3.21
|
||||
|
||||
.. code-block:: cmake
|
||||
|
||||
install(IMPORTED_RUNTIME_ARTIFACTS targets...
|
||||
[RUNTIME_DEPENDENCY_SET <set-name>]
|
||||
[[LIBRARY|RUNTIME|FRAMEWORK|BUNDLE]
|
||||
[DESTINATION <dir>]
|
||||
[PERMISSIONS permissions...]
|
||||
[CONFIGURATIONS [Debug|Release|...]]
|
||||
[COMPONENT <component>]
|
||||
[OPTIONAL] [EXCLUDE_FROM_ALL]
|
||||
] [...]
|
||||
)
|
||||
|
||||
The ``IMPORTED_RUNTIME_ARTIFACTS`` form specifies rules for installing the
|
||||
runtime artifacts of imported targets. Projects may do this if they want to
|
||||
bundle outside executables or modules inside their installation. The
|
||||
``LIBRARY``, ``RUNTIME``, ``FRAMEWORK``, and ``BUNDLE`` arguments have the
|
||||
same semantics that they do in the `TARGETS`_ mode. Only the runtime artifacts
|
||||
of imported targets are installed (except in the case of :prop_tgt:`FRAMEWORK`
|
||||
libraries, :prop_tgt:`MACOSX_BUNDLE` executables, and :prop_tgt:`BUNDLE`
|
||||
CFBundles.) For example, headers and import libraries associated with DLLs are
|
||||
not installed. In the case of :prop_tgt:`FRAMEWORK` libraries,
|
||||
:prop_tgt:`MACOSX_BUNDLE` executables, and :prop_tgt:`BUNDLE` CFBundles, the
|
||||
entire directory is installed.
|
||||
|
||||
The ``RUNTIME_DEPENDENCY_SET`` option causes the runtime artifacts of the
|
||||
imported executable, shared library, and module library ``targets`` to be
|
||||
added to the ``<set-name>`` runtime dependency set. This set can then be
|
||||
installed with an `install(RUNTIME_DEPENDENCY_SET)`_ command.
|
||||
|
||||
Installing Files
|
||||
^^^^^^^^^^^^^^^^
|
||||
@ -452,9 +552,15 @@ this advice while installing headers to a project-specific subdirectory:
|
||||
DESTINATION ${CMAKE_INSTALL_INCLUDEDIR}/myproj
|
||||
)
|
||||
|
||||
An install destination given as a ``DESTINATION`` argument may
|
||||
use "generator expressions" with the syntax ``$<...>``. See the
|
||||
:manual:`cmake-generator-expressions(7)` manual for available expressions.
|
||||
.. versionadded:: 3.4
|
||||
An install destination given as a ``DESTINATION`` argument may
|
||||
use "generator expressions" with the syntax ``$<...>``. See the
|
||||
:manual:`cmake-generator-expressions(7)` manual for available expressions.
|
||||
|
||||
.. versionadded:: 3.20
|
||||
An install rename given as a ``RENAME`` argument may
|
||||
use "generator expressions" with the syntax ``$<...>``. See the
|
||||
:manual:`cmake-generator-expressions(7)` manual for available expressions.
|
||||
|
||||
Installing Directories
|
||||
^^^^^^^^^^^^^^^^^^^^^^
|
||||
@ -492,7 +598,8 @@ permissions specified in the ``FILES`` form of the command, and the
|
||||
directories will be given the default permissions specified in the
|
||||
``PROGRAMS`` form of the command.
|
||||
|
||||
The ``MESSAGE_NEVER`` option disables file installation status output.
|
||||
.. versionadded:: 3.1
|
||||
The ``MESSAGE_NEVER`` option disables file installation status output.
|
||||
|
||||
Installation of directories may be controlled with fine granularity
|
||||
using the ``PATTERN`` or ``REGEX`` options. These "match" options specify a
|
||||
@ -517,7 +624,8 @@ any expression. For example, the code
|
||||
|
||||
will extract and install header files from a source tree.
|
||||
|
||||
Some options may follow a ``PATTERN`` or ``REGEX`` expression and are applied
|
||||
Some options may follow a ``PATTERN`` or ``REGEX`` expression as described
|
||||
under :ref:`string(REGEX) <Regex Specification>` and are applied
|
||||
only to files or directories matching them. The ``EXCLUDE`` option will
|
||||
skip the matched file or directory. The ``PERMISSIONS`` option overrides
|
||||
the permissions setting for the matched file or directory. For
|
||||
@ -576,10 +684,14 @@ path that begins with the appropriate :module:`GNUInstallDirs` variable.
|
||||
This allows package maintainers to control the install destination by setting
|
||||
the appropriate cache variables.
|
||||
|
||||
The list of ``dirs...`` given to ``DIRECTORY`` and an install destination
|
||||
given as a ``DESTINATION`` argument may use "generator expressions"
|
||||
with the syntax ``$<...>``. See the :manual:`cmake-generator-expressions(7)`
|
||||
manual for available expressions.
|
||||
.. versionadded:: 3.4
|
||||
An install destination given as a ``DESTINATION`` argument may
|
||||
use "generator expressions" with the syntax ``$<...>``. See the
|
||||
:manual:`cmake-generator-expressions(7)` manual for available expressions.
|
||||
|
||||
.. versionadded:: 3.5
|
||||
The list of ``dirs...`` given to ``DIRECTORY`` may use
|
||||
"generator expressions" too.
|
||||
|
||||
Custom Installation Logic
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
@ -592,7 +704,8 @@ Custom Installation Logic
|
||||
.. code-block:: cmake
|
||||
|
||||
install([[SCRIPT <file>] [CODE <code>]]
|
||||
[COMPONENT <component>] [EXCLUDE_FROM_ALL] [...])
|
||||
[ALL_COMPONENTS | COMPONENT <component>]
|
||||
[EXCLUDE_FROM_ALL] [...])
|
||||
|
||||
The ``SCRIPT`` form will invoke the given CMake script files during
|
||||
installation. If the script file name is a relative path it will be
|
||||
@ -607,10 +720,17 @@ example, the code
|
||||
|
||||
will print a message during installation.
|
||||
|
||||
``<file>`` or ``<code>`` may use "generator expressions" with the syntax
|
||||
``$<...>`` (in the case of ``<file>``, this refers to their use in the file
|
||||
name, not the file's contents). See the
|
||||
:manual:`cmake-generator-expressions(7)` manual for available expressions.
|
||||
.. versionadded:: 3.21
|
||||
When the ``ALL_COMPONENTS`` option is given, the custom installation
|
||||
script code will be executed for every component of a component-specific
|
||||
installation. This option is mutually exclusive with the ``COMPONENT``
|
||||
option.
|
||||
|
||||
.. versionadded:: 3.14
|
||||
``<file>`` or ``<code>`` may use "generator expressions" with the syntax
|
||||
``$<...>`` (in the case of ``<file>``, this refers to their use in the file
|
||||
name, not the file's contents). See the
|
||||
:manual:`cmake-generator-expressions(7)` manual for available expressions.
|
||||
|
||||
Installing Exports
|
||||
^^^^^^^^^^^^^^^^^^
|
||||
@ -670,13 +790,14 @@ RPM, typically handle this by listing the ``Runtime`` component as a dependency
|
||||
of the ``Development`` component in the package metadata, ensuring that the
|
||||
library is always installed if the headers and CMake export file are present.
|
||||
|
||||
In addition to cmake language files, the ``EXPORT_ANDROID_MK`` mode maybe
|
||||
used to specify an export to the android ndk build system. This mode
|
||||
accepts the same options as the normal export mode. 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.
|
||||
.. versionadded:: 3.7
|
||||
In addition to cmake language files, the ``EXPORT_ANDROID_MK`` mode maybe
|
||||
used to specify an export to the android ndk build system. This mode
|
||||
accepts the same options as the normal export mode. 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 ``EXPORT`` form is useful to help outside projects use targets built
|
||||
and installed by the current project. For example, the code
|
||||
@ -695,7 +816,7 @@ executable from the installation tree using the imported target name
|
||||
``mp_myexe`` as if the target were built in its own tree.
|
||||
|
||||
.. note::
|
||||
This command supercedes the :command:`install_targets` command and
|
||||
This command supersedes the :command:`install_targets` command and
|
||||
the :prop_tgt:`PRE_INSTALL_SCRIPT` and :prop_tgt:`POST_INSTALL_SCRIPT`
|
||||
target properties. It also replaces the ``FILES`` forms of the
|
||||
:command:`install_files` and :command:`install_programs` commands.
|
||||
@ -704,6 +825,70 @@ executable from the installation tree using the imported target name
|
||||
:command:`install_files`, and :command:`install_programs` commands
|
||||
is not defined.
|
||||
|
||||
Installing Runtime Dependencies
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
.. _`install(RUNTIME_DEPENDENCY_SET)`:
|
||||
.. _RUNTIME_DEPENDENCY_SET:
|
||||
|
||||
.. versionadded:: 3.21
|
||||
|
||||
.. code-block:: cmake
|
||||
|
||||
install(RUNTIME_DEPENDENCY_SET <set-name>
|
||||
[[LIBRARY|RUNTIME|FRAMEWORK]
|
||||
[DESTINATION <dir>]
|
||||
[PERMISSIONS permissions...]
|
||||
[CONFIGURATIONS [Debug|Release|...]]
|
||||
[COMPONENT <component>]
|
||||
[NAMELINK_COMPONENT <component>]
|
||||
[OPTIONAL] [EXCLUDE_FROM_ALL]
|
||||
] [...]
|
||||
[PRE_INCLUDE_REGEXES regexes...]
|
||||
[PRE_EXCLUDE_REGEXES regexes...]
|
||||
[POST_INCLUDE_REGEXES regexes...]
|
||||
[POST_EXCLUDE_REGEXES regexes...]
|
||||
[POST_INCLUDE_FILES files...]
|
||||
[POST_EXCLUDE_FILES files...]
|
||||
[DIRECTORIES directories...]
|
||||
)
|
||||
|
||||
Installs a runtime dependency set previously created by one or more
|
||||
`install(TARGETS)`_ or `install(IMPORTED_RUNTIME_ARTIFACTS)`_ commands. The
|
||||
dependencies of targets belonging to a runtime dependency set are installed in
|
||||
the ``RUNTIME`` destination and component on DLL platforms, and in the
|
||||
``LIBRARY`` destination and component on non-DLL platforms. macOS frameworks
|
||||
are installed in the ``FRAMEWORK`` destination and component.
|
||||
Targets built within the build tree will never be installed as runtime
|
||||
dependencies, nor will their own dependencies, unless the targets themselves
|
||||
are installed with `install(TARGETS)`_.
|
||||
|
||||
The generated install script calls :command:`file(GET_RUNTIME_DEPENDENCIES)`
|
||||
on the build-tree files to calculate the runtime dependencies. The build-tree
|
||||
executable files are passed as the ``EXECUTABLES`` argument, the build-tree
|
||||
shared libraries as the ``LIBRARIES`` argument, and the build-tree modules as
|
||||
the ``MODULES`` argument. On macOS, if one of the executables is a
|
||||
:prop_tgt:`MACOSX_BUNDLE`, that executable is passed as the
|
||||
``BUNDLE_EXECUTABLE`` argument. At most one such bundle executable may be in
|
||||
the runtime dependency set on macOS. The :prop_tgt:`MACOSX_BUNDLE` property
|
||||
has no effect on other platforms. Note that
|
||||
:command:`file(GET_RUNTIME_DEPENDENCIES)` only supports collecting the runtime
|
||||
dependencies for Windows, Linux and macOS platforms, so
|
||||
``install(RUNTIME_DEPENDENCY_SET)`` has the same limitation.
|
||||
|
||||
The following sub-arguments are forwarded through as the corresponding
|
||||
arguments to :command:`file(GET_RUNTIME_DEPENDENCIES)` (for those that provide
|
||||
a non-empty list of directories, regular expressions or files). They all
|
||||
support :manual:`generator expressions <cmake-generator-expressions(7)>`.
|
||||
|
||||
* ``DIRECTORIES <directories>``
|
||||
* ``PRE_INCLUDE_REGEXES <regexes>``
|
||||
* ``PRE_EXCLUDE_REGEXES <regexes>``
|
||||
* ``POST_INCLUDE_REGEXES <regexes>``
|
||||
* ``POST_EXCLUDE_REGEXES <regexes>``
|
||||
* ``POST_INCLUDE_FILES <files>``
|
||||
* ``POST_EXCLUDE_FILES <files>``
|
||||
|
||||
Generated Installation Script
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
|
@ -5,7 +5,7 @@ install_files
|
||||
|
||||
Use the :command:`install(FILES)` command instead.
|
||||
|
||||
This command has been superceded by the :command:`install` command. It is
|
||||
This command has been superseded by the :command:`install` command. It is
|
||||
provided for compatibility with older CMake code. The ``FILES`` form is
|
||||
directly replaced by the ``FILES`` form of the :command:`install`
|
||||
command. The regexp form can be expressed more clearly using the ``GLOB``
|
||||
|
@ -5,7 +5,7 @@ install_programs
|
||||
|
||||
Use the :command:`install(PROGRAMS)` command instead.
|
||||
|
||||
This command has been superceded by the :command:`install` command. It is
|
||||
This command has been superseded by the :command:`install` command. It is
|
||||
provided for compatibility with older CMake code. The ``FILES`` form is
|
||||
directly replaced by the ``PROGRAMS`` form of the :command:`install`
|
||||
command. The regexp form can be expressed more clearly using the ``GLOB``
|
||||
|
@ -5,7 +5,7 @@ install_targets
|
||||
|
||||
Use the :command:`install(TARGETS)` command instead.
|
||||
|
||||
This command has been superceded by the :command:`install` command. It is
|
||||
This command has been superseded by the :command:`install` command. It is
|
||||
provided for compatibility with older CMake code.
|
||||
|
||||
::
|
||||
|
@ -11,21 +11,25 @@ Adds the paths in which the linker should search for libraries.
|
||||
Relative paths given to this command are interpreted as relative to
|
||||
the current source directory, see :policy:`CMP0015`.
|
||||
|
||||
The directories are added to the :prop_dir:`LINK_DIRECTORIES` directory
|
||||
property for the current ``CMakeLists.txt`` file, converting relative
|
||||
paths to absolute as needed.
|
||||
The command will apply only to targets created after it is called.
|
||||
|
||||
By default the directories specified are appended onto the current list of
|
||||
directories. This default behavior can be changed by setting
|
||||
:variable:`CMAKE_LINK_DIRECTORIES_BEFORE` to ``ON``. By using
|
||||
``AFTER`` or ``BEFORE`` explicitly, you can select between appending and
|
||||
prepending, independent of the default.
|
||||
.. versionadded:: 3.13
|
||||
The directories are added to the :prop_dir:`LINK_DIRECTORIES` directory
|
||||
property for the current ``CMakeLists.txt`` file, converting relative
|
||||
paths to absolute as needed. See the :manual:`cmake-buildsystem(7)`
|
||||
manual for more on defining buildsystem properties.
|
||||
|
||||
Arguments to ``link_directories`` may use "generator expressions" with
|
||||
the syntax "$<...>". See the :manual:`cmake-generator-expressions(7)`
|
||||
manual for available expressions. See the :manual:`cmake-buildsystem(7)`
|
||||
manual for more on defining buildsystem properties.
|
||||
.. versionadded:: 3.13
|
||||
By default the directories specified are appended onto the current list of
|
||||
directories. This default behavior can be changed by setting
|
||||
:variable:`CMAKE_LINK_DIRECTORIES_BEFORE` to ``ON``. By using
|
||||
``AFTER`` or ``BEFORE`` explicitly, you can select between appending and
|
||||
prepending, independent of the default.
|
||||
|
||||
.. versionadded:: 3.13
|
||||
Arguments to ``link_directories`` may use "generator expressions" with
|
||||
the syntax "$<...>". See the :manual:`cmake-generator-expressions(7)`
|
||||
manual for available expressions.
|
||||
|
||||
.. note::
|
||||
|
||||
|
@ -88,6 +88,8 @@ Returns the list of elements specified by indices from the list.
|
||||
|
||||
list(JOIN <list> <glue> <output variable>)
|
||||
|
||||
.. versionadded:: 3.12
|
||||
|
||||
Returns a string joining all list's elements using the glue string.
|
||||
To join multiple strings, which are not part of a list, use ``JOIN`` operator
|
||||
from :command:`string` command.
|
||||
@ -98,6 +100,8 @@ from :command:`string` command.
|
||||
|
||||
list(SUBLIST <list> <begin> <length> <output variable>)
|
||||
|
||||
.. versionadded:: 3.12
|
||||
|
||||
Returns a sublist of the given list.
|
||||
If ``<length>`` is 0, an empty list will be returned.
|
||||
If ``<length>`` is -1 or the list is smaller than ``<begin>+<length>`` then
|
||||
@ -132,11 +136,13 @@ Appends elements to the list.
|
||||
|
||||
list(FILTER <list> <INCLUDE|EXCLUDE> REGEX <regular_expression>)
|
||||
|
||||
.. versionadded:: 3.6
|
||||
|
||||
Includes or removes items from the list that match the mode's pattern.
|
||||
In ``REGEX`` mode, items will be matched against the given regular expression.
|
||||
|
||||
For more information on regular expressions see also the
|
||||
:command:`string` command.
|
||||
For more information on regular expressions look under
|
||||
:ref:`string(REGEX) <Regex Specification>`.
|
||||
|
||||
.. _INSERT:
|
||||
|
||||
@ -152,6 +158,8 @@ Inserts elements to the list to the specified location.
|
||||
|
||||
list(POP_BACK <list> [<out-var>...])
|
||||
|
||||
.. versionadded:: 3.15
|
||||
|
||||
If no variable name is given, removes exactly one element. Otherwise,
|
||||
assign the last element's value to the given variable and removes it,
|
||||
up to the last variable name given.
|
||||
@ -162,6 +170,8 @@ up to the last variable name given.
|
||||
|
||||
list(POP_FRONT <list> [<out-var>...])
|
||||
|
||||
.. versionadded:: 3.15
|
||||
|
||||
If no variable name is given, removes exactly one element. Otherwise,
|
||||
assign the first element's value to the given variable and removes it,
|
||||
up to the last variable name given.
|
||||
@ -172,6 +182,8 @@ up to the last variable name given.
|
||||
|
||||
list(PREPEND <list> [<element> ...])
|
||||
|
||||
.. versionadded:: 3.15
|
||||
|
||||
Insert elements to the 0th position in the list.
|
||||
|
||||
.. _REMOVE_ITEM:
|
||||
@ -206,6 +218,8 @@ but if duplicates are encountered, only the first instance is preserved.
|
||||
list(TRANSFORM <list> <ACTION> [<SELECTOR>]
|
||||
[OUTPUT_VARIABLE <output variable>])
|
||||
|
||||
.. versionadded:: 3.12
|
||||
|
||||
Transforms the list by applying an action to all or, by specifying a
|
||||
``<SELECTOR>``, to the selected elements of the list, storing the result
|
||||
in-place or in the specified output variable.
|
||||
@ -302,6 +316,13 @@ Reverses the contents of the list in-place.
|
||||
list(SORT <list> [COMPARE <compare>] [CASE <case>] [ORDER <order>])
|
||||
|
||||
Sorts the list in-place alphabetically.
|
||||
|
||||
.. versionadded:: 3.13
|
||||
Added the ``COMPARE``, ``CASE``, and ``ORDER`` options.
|
||||
|
||||
.. versionadded:: 3.18
|
||||
Added the ``COMPARE NATURAL`` option.
|
||||
|
||||
Use the ``COMPARE`` keyword to select the comparison method for sorting.
|
||||
The ``<compare>`` option should be one of:
|
||||
|
||||
|
@ -48,8 +48,9 @@ and so on. However, it is strongly recommended to stay with the
|
||||
case chosen in the macro definition. Typically macros use
|
||||
all-lowercase names.
|
||||
|
||||
The :command:`cmake_language(CALL ...)` command can also be used to
|
||||
invoke the macro.
|
||||
.. versionadded:: 3.18
|
||||
The :command:`cmake_language(CALL ...)` command can also be used to
|
||||
invoke the macro.
|
||||
|
||||
Arguments
|
||||
^^^^^^^^^
|
||||
|
@ -23,8 +23,6 @@ new values will be marked as advanced, but if a
|
||||
variable already has an advanced/non-advanced state,
|
||||
it will not be changed.
|
||||
|
||||
.. note::
|
||||
|
||||
Policy :policy:`CMP0102` affects the behavior of the ``mark_as_advanced``
|
||||
call. When set to ``NEW``, variables passed to this command which are not
|
||||
already in the cache are ignored. See policy :policy:`CMP0102`.
|
||||
.. versionchanged:: 3.17
|
||||
Variables passed to this command which are not already in the cache
|
||||
are ignored. See policy :policy:`CMP0102`.
|
||||
|
@ -17,17 +17,18 @@ Supported operators are ``+``, ``-``, ``*``, ``/``, ``%``, ``|``, ``&``,
|
||||
``^``, ``~``, ``<<``, ``>>``, and ``(...)``; they have the same meaning
|
||||
as in C code.
|
||||
|
||||
Hexadecimal numbers are recognized when prefixed with ``0x``, as in C code.
|
||||
.. versionadded:: 3.13
|
||||
Hexadecimal numbers are recognized when prefixed with ``0x``, as in C code.
|
||||
|
||||
The result is formatted according to the option ``OUTPUT_FORMAT``,
|
||||
where ``<format>`` is one of
|
||||
|
||||
``HEXADECIMAL``
|
||||
Hexadecimal notation as in C code, i. e. starting with "0x".
|
||||
``DECIMAL``
|
||||
Decimal notation. Which is also used if no ``OUTPUT_FORMAT`` option
|
||||
is specified.
|
||||
.. versionadded:: 3.13
|
||||
The result is formatted according to the option ``OUTPUT_FORMAT``,
|
||||
where ``<format>`` is one of
|
||||
|
||||
``HEXADECIMAL``
|
||||
Hexadecimal notation as in C code, i. e. starting with "0x".
|
||||
``DECIMAL``
|
||||
Decimal notation. Which is also used if no ``OUTPUT_FORMAT`` option
|
||||
is specified.
|
||||
|
||||
For example
|
||||
|
||||
|
@ -71,6 +71,9 @@ influences the way the message is handled:
|
||||
using this log level would normally only be temporary and would expect to be
|
||||
removed before releasing the project, packaging up the files, etc.
|
||||
|
||||
.. versionadded:: 3.15
|
||||
Added the ``NOTICE``, ``VERBOSE``, ``DEBUG``, and ``TRACE`` levels.
|
||||
|
||||
The CMake command-line tool displays ``STATUS`` to ``TRACE`` messages on stdout
|
||||
with the message preceded by two hyphens and a space. All other message types
|
||||
are sent to stderr and are not prefixed with hyphens. The
|
||||
@ -79,25 +82,29 @@ The :manual:`curses interface <ccmake(1)>` shows ``STATUS`` to ``TRACE``
|
||||
messages one at a time on a status line and other messages in an
|
||||
interactive pop-up box. The ``--log-level`` command-line option to each of
|
||||
these tools can be used to control which messages will be shown.
|
||||
To make a log level persist between CMake runs, the
|
||||
:variable:`CMAKE_MESSAGE_LOG_LEVEL` variable can be set instead.
|
||||
Note that the command line option takes precedence over the cache variable.
|
||||
|
||||
Messages of log levels ``NOTICE`` and below will have each line preceded
|
||||
by the content of the :variable:`CMAKE_MESSAGE_INDENT` variable (converted to
|
||||
a single string by concatenating its list items). For ``STATUS`` to ``TRACE``
|
||||
messages, this indenting content will be inserted after the hyphens.
|
||||
.. versionadded:: 3.17
|
||||
To make a log level persist between CMake runs, the
|
||||
:variable:`CMAKE_MESSAGE_LOG_LEVEL` variable can be set instead.
|
||||
Note that the command line option takes precedence over the cache variable.
|
||||
|
||||
Messages of log levels ``NOTICE`` and below can also have each line preceded
|
||||
with context of the form ``[some.context.example]``. The content between the
|
||||
square brackets is obtained by converting the :variable:`CMAKE_MESSAGE_CONTEXT`
|
||||
list variable to a dot-separated string. The message context will always
|
||||
appear before any indenting content but after any automatically added leading
|
||||
hyphens. By default, message context is not shown, it has to be explicitly
|
||||
enabled by giving the :manual:`cmake <cmake(1)>` ``--log-context``
|
||||
command-line option or by setting the :variable:`CMAKE_MESSAGE_CONTEXT_SHOW`
|
||||
variable to true. See the :variable:`CMAKE_MESSAGE_CONTEXT` documentation for
|
||||
usage examples.
|
||||
.. versionadded:: 3.16
|
||||
Messages of log levels ``NOTICE`` and below will have each line preceded
|
||||
by the content of the :variable:`CMAKE_MESSAGE_INDENT` variable (converted to
|
||||
a single string by concatenating its list items). For ``STATUS`` to ``TRACE``
|
||||
messages, this indenting content will be inserted after the hyphens.
|
||||
|
||||
.. versionadded:: 3.17
|
||||
Messages of log levels ``NOTICE`` and below can also have each line preceded
|
||||
with context of the form ``[some.context.example]``. The content between the
|
||||
square brackets is obtained by converting the :variable:`CMAKE_MESSAGE_CONTEXT`
|
||||
list variable to a dot-separated string. The message context will always
|
||||
appear before any indenting content but after any automatically added leading
|
||||
hyphens. By default, message context is not shown, it has to be explicitly
|
||||
enabled by giving the :manual:`cmake <cmake(1)>` ``--log-context``
|
||||
command-line option or by setting the :variable:`CMAKE_MESSAGE_CONTEXT_SHOW`
|
||||
variable to true. See the :variable:`CMAKE_MESSAGE_CONTEXT` documentation for
|
||||
usage examples.
|
||||
|
||||
CMake Warning and Error message text displays using a simple markup
|
||||
language. Non-indented text is formatted in line-wrapped paragraphs
|
||||
@ -107,6 +114,8 @@ delimited by newlines. Indented text is considered pre-formatted.
|
||||
Reporting checks
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
.. versionadded:: 3.17
|
||||
|
||||
A common pattern in CMake output is a message indicating the start of some
|
||||
sort of check, followed by another message reporting the result of that check.
|
||||
For example:
|
||||
|
@ -20,12 +20,18 @@ Sets the name of the project, and stores it in the variable
|
||||
``CMakeLists.txt`` also stores the project name in the
|
||||
variable :variable:`CMAKE_PROJECT_NAME`.
|
||||
|
||||
Also sets the variables
|
||||
Also sets the variables:
|
||||
|
||||
* :variable:`PROJECT_SOURCE_DIR`,
|
||||
:variable:`<PROJECT-NAME>_SOURCE_DIR`
|
||||
* :variable:`PROJECT_BINARY_DIR`,
|
||||
:variable:`<PROJECT-NAME>_BINARY_DIR`
|
||||
:variable:`PROJECT_SOURCE_DIR`, :variable:`<PROJECT-NAME>_SOURCE_DIR`
|
||||
Absolute path to the source directory for the project.
|
||||
|
||||
:variable:`PROJECT_BINARY_DIR`, :variable:`<PROJECT-NAME>_BINARY_DIR`
|
||||
Absolute path to the binary directory for the project.
|
||||
|
||||
:variable:`PROJECT_IS_TOP_LEVEL`, :variable:`<PROJECT-NAME>_IS_TOP_LEVEL`
|
||||
.. versionadded:: 3.21
|
||||
|
||||
Boolean value indicating whether the project is top-level.
|
||||
|
||||
Further variables are set by the optional arguments described in the following.
|
||||
If any of these arguments is not used, then the corresponding variables are
|
||||
@ -55,10 +61,14 @@ The options are:
|
||||
* :variable:`PROJECT_VERSION_TWEAK`,
|
||||
:variable:`<PROJECT-NAME>_VERSION_TWEAK`.
|
||||
|
||||
When the ``project()`` command is called from the top-level ``CMakeLists.txt``,
|
||||
then the version is also stored in the variable :variable:`CMAKE_PROJECT_VERSION`.
|
||||
.. versionadded:: 3.12
|
||||
When the ``project()`` command is called from the top-level
|
||||
``CMakeLists.txt``, then the version is also stored in the variable
|
||||
:variable:`CMAKE_PROJECT_VERSION`.
|
||||
|
||||
``DESCRIPTION <project-description-string>``
|
||||
.. versionadded:: 3.9
|
||||
|
||||
Optional.
|
||||
Sets the variables
|
||||
|
||||
@ -71,7 +81,12 @@ The options are:
|
||||
When the ``project()`` command is called from the top-level ``CMakeLists.txt``,
|
||||
then the description is also stored in the variable :variable:`CMAKE_PROJECT_DESCRIPTION`.
|
||||
|
||||
.. versionadded:: 3.12
|
||||
Added the ``<PROJECT-NAME>_DESCRIPTION`` variable.
|
||||
|
||||
``HOMEPAGE_URL <url-string>``
|
||||
.. versionadded:: 3.12
|
||||
|
||||
Optional.
|
||||
Sets the variables
|
||||
|
||||
@ -88,11 +103,20 @@ The options are:
|
||||
|
||||
Selects which programming languages are needed to build the project.
|
||||
Supported languages include ``C``, ``CXX`` (i.e. C++), ``CUDA``,
|
||||
``OBJC`` (i.e. Objective-C), ``OBJCXX``, ``Fortran``, and ``ASM``.
|
||||
``OBJC`` (i.e. Objective-C), ``OBJCXX``, ``Fortran``, ``HIP``, ``ISPC``, and ``ASM``.
|
||||
By default ``C`` and ``CXX`` are enabled if no language options are given.
|
||||
Specify language ``NONE``, or use the ``LANGUAGES`` keyword and list no languages,
|
||||
to skip enabling any languages.
|
||||
|
||||
.. versionadded:: 3.8
|
||||
Added ``CUDA`` support.
|
||||
|
||||
.. versionadded:: 3.16
|
||||
Added ``OBJC`` and ``OBJCXX`` support.
|
||||
|
||||
.. versionadded:: 3.18
|
||||
Added ``ISPC`` support.
|
||||
|
||||
If enabling ``ASM``, list it last so that CMake can check whether
|
||||
compilers for other languages like ``C`` work for assembly too.
|
||||
|
||||
@ -115,6 +139,13 @@ they point to will be included as the last step of the ``project()`` command.
|
||||
If both are set, then :variable:`CMAKE_PROJECT_INCLUDE` will be included before
|
||||
:variable:`CMAKE_PROJECT_<PROJECT-NAME>_INCLUDE`.
|
||||
|
||||
.. versionadded:: 3.15
|
||||
Added the ``CMAKE_PROJECT_INCLUDE`` and ``CMAKE_PROJECT_INCLUDE_BEFORE``
|
||||
variables.
|
||||
|
||||
.. versionadded:: 3.17
|
||||
Added the ``CMAKE_PROJECT_<PROJECT-NAME>_INCLUDE_BEFORE`` variable.
|
||||
|
||||
Usage
|
||||
^^^^^
|
||||
|
||||
|
@ -12,6 +12,7 @@ encountered in an included file (via :command:`include` or
|
||||
:command:`find_package`), it causes processing of the current file to stop
|
||||
and control is returned to the including file. If it is encountered in a
|
||||
file which is not included by another file, e.g. a ``CMakeLists.txt``,
|
||||
deferred calls scheduled by :command:`cmake_language(DEFER)` are invoked and
|
||||
control is returned to the parent directory if there is one. If return is
|
||||
called in a function, control is returned to the caller of the function.
|
||||
|
||||
|
@ -5,7 +5,7 @@ Parse command-line arguments into a semicolon-separated list.
|
||||
|
||||
.. code-block:: cmake
|
||||
|
||||
separate_arguments(<variable> <mode> <args>)
|
||||
separate_arguments(<variable> <mode> [PROGRAM [SEPARATE_ARGS]] <args>)
|
||||
|
||||
Parses a space-separated string ``<args>`` into a list of items,
|
||||
and stores this list in semicolon-separated standard form in ``<variable>``.
|
||||
@ -32,9 +32,43 @@ be one of the following keywords:
|
||||
MSDN article `Parsing C Command-Line Arguments`_ for details.
|
||||
|
||||
``NATIVE_COMMAND``
|
||||
.. versionadded:: 3.9
|
||||
|
||||
Proceeds as in ``WINDOWS_COMMAND`` mode if the host system is Windows.
|
||||
Otherwise proceeds as in ``UNIX_COMMAND`` mode.
|
||||
|
||||
``PROGRAM``
|
||||
.. versionadded:: 3.19
|
||||
|
||||
The first item in ``<args>`` is assumed to be an executable and will be
|
||||
searched in the system search path or left as a full path. If not found,
|
||||
``<variable>`` will be empty. Otherwise, ``<variable>`` is a list of 2
|
||||
elements:
|
||||
|
||||
0. Absolute path of the program
|
||||
1. Any command-line arguments present in ``<args>`` as a string
|
||||
|
||||
For example:
|
||||
|
||||
.. code-block:: cmake
|
||||
|
||||
separate_arguments (out UNIX_COMMAND PROGRAM "cc -c main.c")
|
||||
|
||||
* First element of the list: ``/path/to/cc``
|
||||
* Second element of the list: ``" -c main.c"``
|
||||
|
||||
``SEPARATE_ARGS``
|
||||
When this sub-option of ``PROGRAM`` option is specified, command-line
|
||||
arguments will be split as well and stored in ``<variable>``.
|
||||
|
||||
For example:
|
||||
|
||||
.. code-block:: cmake
|
||||
|
||||
separate_arguments (out UNIX_COMMAND PROGRAM SEPARATE_ARGS "cc -c main.c")
|
||||
|
||||
The contents of ``out`` will be: ``/path/to/cc;-c;main.c``
|
||||
|
||||
.. _`Parsing C Command-Line Arguments`: https://msdn.microsoft.com/library/a1y7w461.aspx
|
||||
|
||||
.. code-block:: cmake
|
||||
|
@ -68,9 +68,13 @@ users.
|
||||
|
||||
If the cache entry does not exist prior to the call or the ``FORCE``
|
||||
option is given then the cache entry will be set to the given value.
|
||||
Furthermore, any normal variable binding in the current scope will
|
||||
be removed to expose the newly cached value to any immediately
|
||||
following evaluation.
|
||||
|
||||
.. note::
|
||||
|
||||
The content of the cache variable will not be directly accessible if a normal
|
||||
variable of the same name already exists (see :ref:`rules of variable
|
||||
evaluation <CMake Language Variables>`). If policy :policy:`CMP0126` is set
|
||||
to ``OLD``, any normal variable binding in the current scope will be removed.
|
||||
|
||||
It is possible for the cache entry to exist prior to the call but
|
||||
have no type set if it was created on the :manual:`cmake(1)` command
|
||||
|
@ -26,10 +26,14 @@ It must be one of the following:
|
||||
Scope is unique and does not accept a name.
|
||||
|
||||
``DIRECTORY``
|
||||
Scope defaults to the current directory but another directory
|
||||
Scope defaults to the current directory but other directories
|
||||
(already processed by CMake) may be named by full or relative path.
|
||||
Relative paths are treated as relative to the current source directory.
|
||||
See also the :command:`set_directory_properties` command.
|
||||
|
||||
.. versionadded:: 3.19
|
||||
``<dir>`` may reference a binary directory.
|
||||
|
||||
``TARGET``
|
||||
Scope may name zero or more existing targets.
|
||||
See also the :command:`set_target_properties` command.
|
||||
@ -37,24 +41,31 @@ It must be one of the following:
|
||||
``SOURCE``
|
||||
Scope may name zero or more source files. By default, source file properties
|
||||
are only visible to targets added in the same directory (``CMakeLists.txt``).
|
||||
Visibility can be set in other directory scopes using one or both of the
|
||||
following sub-options:
|
||||
|
||||
``DIRECTORY <dirs>...``
|
||||
The source file property will be set in each of the ``<dirs>``
|
||||
directories' scopes. CMake must already know about each of these
|
||||
source directories, either by having added them through a call to
|
||||
:command:`add_subdirectory` or it being the top level source directory.
|
||||
Relative paths are treated as relative to the current source directory.
|
||||
.. versionadded:: 3.18
|
||||
Visibility can be set in other directory scopes using one or both of the
|
||||
following sub-options:
|
||||
|
||||
``TARGET_DIRECTORY <targets>...``
|
||||
The source file property will be set in each of the directory scopes
|
||||
where any of the specified ``<targets>`` were created (the ``<targets>``
|
||||
must therefore already exist).
|
||||
``DIRECTORY <dirs>...``
|
||||
The source file property will be set in each of the ``<dirs>``
|
||||
directories' scopes. CMake must already know about
|
||||
each of these directories, either by having added them through a call to
|
||||
:command:`add_subdirectory` or it being the top level source directory.
|
||||
Relative paths are treated as relative to the current source directory.
|
||||
|
||||
.. versionadded:: 3.19
|
||||
``<dirs>`` may reference a binary directory.
|
||||
|
||||
``TARGET_DIRECTORY <targets>...``
|
||||
The source file property will be set in each of the directory scopes
|
||||
where any of the specified ``<targets>`` were created (the ``<targets>``
|
||||
must therefore already exist).
|
||||
|
||||
See also the :command:`set_source_files_properties` command.
|
||||
|
||||
``INSTALL``
|
||||
.. versionadded:: 3.1
|
||||
|
||||
Scope may name zero or more installed file paths.
|
||||
These are made available to CPack to influence deployment.
|
||||
|
||||
@ -94,3 +105,8 @@ directly set in the nominated scope, the command will behave as though
|
||||
|
||||
See the :manual:`cmake-properties(7)` manual for a list of properties
|
||||
in each scope.
|
||||
|
||||
.. note::
|
||||
|
||||
The :prop_sf:`GENERATED` source file property may be globally visible.
|
||||
See its documentation for details.
|
||||
|
@ -14,9 +14,10 @@ Source files can have properties that affect how they are built.
|
||||
Sets properties associated with source files using a key/value paired
|
||||
list.
|
||||
|
||||
By default, source file properties are only visible to targets added in the
|
||||
same directory (``CMakeLists.txt``). Visibility can be set in other directory
|
||||
scopes using one or both of the following options:
|
||||
.. versionadded:: 3.18
|
||||
By default, source file properties are only visible to targets added in the
|
||||
same directory (``CMakeLists.txt``). Visibility can be set in other directory
|
||||
scopes using one or both of the following options:
|
||||
|
||||
``DIRECTORY <dirs>...``
|
||||
The source file properties will be set in each of the ``<dirs>``
|
||||
@ -35,3 +36,8 @@ See also the :command:`set_property(SOURCE)` command.
|
||||
|
||||
See :ref:`Source File Properties` for the list of properties known
|
||||
to CMake.
|
||||
|
||||
.. note::
|
||||
|
||||
The :prop_sf:`GENERATED` source file property may be globally visible.
|
||||
See its documentation for details.
|
||||
|
@ -6,3 +6,7 @@ Set the given variable to the name of the computer.
|
||||
.. code-block:: cmake
|
||||
|
||||
site_name(variable)
|
||||
|
||||
On UNIX-like platforms, if the variable ``HOSTNAME`` is set, its value
|
||||
will be executed as a command expected to print out the host name,
|
||||
much like the ``hostname`` command-line tool.
|
||||
|
@ -11,15 +11,22 @@ There are two different signatures to create source groups.
|
||||
|
||||
Defines a group into which sources will be placed in project files.
|
||||
This is intended to set up file tabs in Visual Studio.
|
||||
The group is scoped in the directory where the command is called,
|
||||
and applies to sources in targets created in that directory.
|
||||
|
||||
The options are:
|
||||
|
||||
``TREE``
|
||||
.. versionadded:: 3.8
|
||||
|
||||
CMake will automatically detect, from ``<src>`` files paths, source groups
|
||||
it needs to create, to keep structure of source groups analogically to the
|
||||
actual files and directories structure in the project. Paths of ``<src>``
|
||||
files will be cut to be relative to ``<root>``.
|
||||
|
||||
``PREFIX``
|
||||
.. versionadded:: 3.8
|
||||
|
||||
Source group and files located directly in ``<root>`` path, will be placed
|
||||
in ``<prefix>`` source groups.
|
||||
|
||||
@ -47,6 +54,9 @@ appropriately:
|
||||
source_group(outer\\inner ...)
|
||||
source_group(TREE <root> PREFIX sources\\inc ...)
|
||||
|
||||
.. versionadded:: 3.18
|
||||
Allow using forward slashes (``/``) to specify subgroups.
|
||||
|
||||
For backwards compatibility, the short-hand signature
|
||||
|
||||
.. code-block:: cmake
|
||||
|
@ -43,6 +43,19 @@ Synopsis
|
||||
string(`TIMESTAMP`_ <out-var> [<format string>] [UTC])
|
||||
string(`UUID`_ <out-var> ...)
|
||||
|
||||
`JSON`_
|
||||
string(JSON <out-var> [ERROR_VARIABLE <error-var>]
|
||||
{`GET`_ | `TYPE`_ | :ref:`LENGTH <JSONLENGTH>` | `REMOVE`_}
|
||||
<json-string> <member|index> [<member|index> ...])
|
||||
string(JSON <out-var> [ERROR_VARIABLE <error-var>]
|
||||
`MEMBER`_ <json-string>
|
||||
[<member|index> ...] <index>)
|
||||
string(JSON <out-var> [ERROR_VARIABLE <error-var>]
|
||||
`SET`_ <json-string>
|
||||
<member|index> [<member|index> ...] <value>)
|
||||
string(JSON <out-var> [ERROR_VARIABLE <error-var>]
|
||||
`EQUAL`_ <json-string1> <json-string2>)
|
||||
|
||||
Search and Replace
|
||||
^^^^^^^^^^^^^^^^^^
|
||||
|
||||
@ -157,10 +170,12 @@ The following characters have special meaning in regular expressions:
|
||||
Matches a pattern on either side of the ``|``
|
||||
``()``
|
||||
Saves a matched subexpression, which can be referenced
|
||||
in the ``REGEX REPLACE`` operation. Additionally it is saved
|
||||
by all regular expression-related commands, including
|
||||
e.g. :command:`if(MATCHES)`, in the variables
|
||||
:variable:`CMAKE_MATCH_<n>` for ``<n>`` 0..9.
|
||||
in the ``REGEX REPLACE`` operation.
|
||||
|
||||
.. versionadded:: 3.9
|
||||
All regular expression-related commands, including e.g.
|
||||
:command:`if(MATCHES)`, save subgroup matches in the variables
|
||||
:variable:`CMAKE_MATCH_<n>` for ``<n>`` 0..9.
|
||||
|
||||
``*``, ``+`` and ``?`` have higher precedence than concatenation. ``|``
|
||||
has lower precedence than concatenation. This means that the regular
|
||||
@ -192,6 +207,8 @@ Manipulation
|
||||
|
||||
string(APPEND <string_variable> [<input>...])
|
||||
|
||||
.. versionadded:: 3.4
|
||||
|
||||
Append all the ``<input>`` arguments to the string.
|
||||
|
||||
.. _PREPEND:
|
||||
@ -200,6 +217,8 @@ Append all the ``<input>`` arguments to the string.
|
||||
|
||||
string(PREPEND <string_variable> [<input>...])
|
||||
|
||||
.. versionadded:: 3.10
|
||||
|
||||
Prepend all the ``<input>`` arguments to the string.
|
||||
|
||||
.. _CONCAT:
|
||||
@ -217,6 +236,8 @@ the result in the named ``<output_variable>``.
|
||||
|
||||
string(JOIN <glue> <output_variable> [<input>...])
|
||||
|
||||
.. versionadded:: 3.12
|
||||
|
||||
Join all the ``<input>`` arguments together using the ``<glue>``
|
||||
string and store the result in the named ``<output_variable>``.
|
||||
|
||||
@ -258,16 +279,15 @@ result stored in ``<output_variable>`` will *not* be the number of characters.
|
||||
|
||||
Store in an ``<output_variable>`` a substring of a given ``<string>``. If
|
||||
``<length>`` is ``-1`` the remainder of the string starting at ``<begin>``
|
||||
will be returned. If ``<string>`` is shorter than ``<length>`` then the
|
||||
end of the string is used instead.
|
||||
will be returned.
|
||||
|
||||
.. versionchanged:: 3.2
|
||||
If ``<string>`` is shorter than ``<length>`` then the end of the string
|
||||
is used instead. Previous versions of CMake reported an error in this case.
|
||||
|
||||
Both ``<begin>`` and ``<length>`` are counted in bytes, so care must
|
||||
be exercised if ``<string>`` could contain multi-byte characters.
|
||||
|
||||
.. note::
|
||||
CMake 3.1 and below reported an error if ``<length>`` pointed past
|
||||
the end of ``<string>``.
|
||||
|
||||
.. _STRIP:
|
||||
|
||||
.. code-block:: cmake
|
||||
@ -283,6 +303,8 @@ leading and trailing spaces removed.
|
||||
|
||||
string(GENEX_STRIP <string> <output_variable>)
|
||||
|
||||
.. versionadded:: 3.1
|
||||
|
||||
Strip any :manual:`generator expressions <cmake-generator-expressions(7)>`
|
||||
from the input ``<string>`` and store the result in the ``<output_variable>``.
|
||||
|
||||
@ -292,6 +314,8 @@ from the input ``<string>`` and store the result in the ``<output_variable>``.
|
||||
|
||||
string(REPEAT <string> <count> <output_variable>)
|
||||
|
||||
.. versionadded:: 3.15
|
||||
|
||||
Produce the output string as the input ``<string>`` repeated ``<count>`` times.
|
||||
|
||||
Comparison
|
||||
@ -310,6 +334,9 @@ Comparison
|
||||
|
||||
Compare the strings and store true or false in the ``<output_variable>``.
|
||||
|
||||
.. versionadded:: 3.7
|
||||
Added the ``LESS_EQUAL`` and ``GREATER_EQUAL`` options.
|
||||
|
||||
.. _`Supported Hash Algorithms`:
|
||||
|
||||
Hashing
|
||||
@ -345,6 +372,9 @@ The supported ``<HASH>`` algorithm names are:
|
||||
``SHA3_512``
|
||||
Keccak SHA-3.
|
||||
|
||||
.. versionadded:: 3.8
|
||||
Added the ``SHA3_*`` hash algorithms.
|
||||
|
||||
Generation
|
||||
^^^^^^^^^^
|
||||
|
||||
@ -362,6 +392,8 @@ Convert all numbers into corresponding ASCII characters.
|
||||
|
||||
string(HEX <string> <output_variable>)
|
||||
|
||||
.. versionadded:: 3.18
|
||||
|
||||
Convert each byte in the input ``<string>`` to its hexadecimal representation
|
||||
and store the concatenated hex digits in the ``<output_variable>``. Letters in
|
||||
the output (``a`` through ``f``) are in lowercase.
|
||||
@ -438,6 +470,18 @@ specifiers:
|
||||
%y The last two digits of the current year (00-99)
|
||||
%Y The current year.
|
||||
|
||||
.. versionadded:: 3.6
|
||||
``%s`` format specifier (UNIX time).
|
||||
|
||||
.. versionadded:: 3.7
|
||||
``%a`` and ``%b`` format specifiers (abbreviated month and weekday names).
|
||||
|
||||
.. versionadded:: 3.8
|
||||
``%%`` specifier (literal ``%``).
|
||||
|
||||
.. versionadded:: 3.7
|
||||
``%A`` and ``%B`` format specifiers (full month and weekday names).
|
||||
|
||||
Unknown format specifiers will be ignored and copied to the output
|
||||
as-is.
|
||||
|
||||
@ -448,8 +492,7 @@ If no explicit ``<format_string>`` is given, it will default to:
|
||||
%Y-%m-%dT%H:%M:%S for local time.
|
||||
%Y-%m-%dT%H:%M:%SZ for UTC.
|
||||
|
||||
.. note::
|
||||
|
||||
.. versionadded:: 3.8
|
||||
If the ``SOURCE_DATE_EPOCH`` environment variable is set,
|
||||
its value will be used instead of the current time.
|
||||
See https://reproducible-builds.org/specs/source-date-epoch/ for details.
|
||||
@ -461,6 +504,8 @@ If no explicit ``<format_string>`` is given, it will default to:
|
||||
string(UUID <output_variable> NAMESPACE <namespace> NAME <name>
|
||||
TYPE <MD5|SHA1> [UPPER])
|
||||
|
||||
.. versionadded:: 3.1
|
||||
|
||||
Create a universally unique identifier (aka GUID) as per RFC4122
|
||||
based on the hash of the combined values of ``<namespace>``
|
||||
(which itself has to be a valid UUID) and ``<name>``.
|
||||
@ -470,3 +515,98 @@ A UUID has the format ``xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx``
|
||||
where each ``x`` represents a lower case hexadecimal character.
|
||||
Where required, an uppercase representation can be requested
|
||||
with the optional ``UPPER`` flag.
|
||||
|
||||
.. _JSON:
|
||||
|
||||
JSON
|
||||
^^^^
|
||||
|
||||
.. versionadded:: 3.19
|
||||
|
||||
Functionality for querying a JSON string.
|
||||
|
||||
.. note::
|
||||
In each of the following JSON-related subcommands, if the optional
|
||||
``ERROR_VARIABLE`` argument is given, errors will be reported in
|
||||
``<error-variable>`` and the ``<out-var>`` will be set to
|
||||
``<member|index>-[<member|index>...]-NOTFOUND`` with the path elements
|
||||
up to the point where the error occurred, or just ``NOTFOUND`` if there
|
||||
is no relevant path. If an error occurs but the ``ERROR_VARIABLE``
|
||||
option is not present, a fatal error message is generated. If no error
|
||||
occurs, the ``<error-variable>`` will be set to ``NOTFOUND``.
|
||||
|
||||
.. _GET:
|
||||
.. code-block:: cmake
|
||||
|
||||
string(JSON <out-var> [ERROR_VARIABLE <error-variable>]
|
||||
GET <json-string> <member|index> [<member|index> ...])
|
||||
|
||||
Get an element from ``<json-string>`` at the location given
|
||||
by the list of ``<member|index>`` arguments.
|
||||
Array and object elements will be returned as a JSON string.
|
||||
Boolean elements will be returned as ``ON`` or ``OFF``.
|
||||
Null elements will be returned as an empty string.
|
||||
Number and string types will be returned as strings.
|
||||
|
||||
.. _TYPE:
|
||||
.. code-block:: cmake
|
||||
|
||||
string(JSON <out-var> [ERROR_VARIABLE <error-variable>]
|
||||
TYPE <json-string> <member|index> [<member|index> ...])
|
||||
|
||||
Get the type of an element in ``<json-string>`` at the location
|
||||
given by the list of ``<member|index>`` arguments. The ``<out-var>``
|
||||
will be set to one of ``NULL``, ``NUMBER``, ``STRING``, ``BOOLEAN``,
|
||||
``ARRAY``, or ``OBJECT``.
|
||||
|
||||
.. _MEMBER:
|
||||
.. code-block:: cmake
|
||||
|
||||
string(JSON <out-var> [ERROR_VARIABLE <error-var>]
|
||||
MEMBER <json-string>
|
||||
[<member|index> ...] <index>)
|
||||
|
||||
Get the name of the ``<index>``-th member in ``<json-string>`` at the location
|
||||
given by the list of ``<member|index>`` arguments.
|
||||
Requires an element of object type.
|
||||
|
||||
.. _JSONLENGTH:
|
||||
.. code-block:: cmake
|
||||
|
||||
string(JSON <out-var> [ERROR_VARIABLE <error-variable>]
|
||||
LENGTH <json-string> <member|index> [<member|index> ...])
|
||||
|
||||
Get the length of an element in ``<json-string>`` at the location
|
||||
given by the list of ``<member|index>`` arguments.
|
||||
Requires an element of array or object type.
|
||||
|
||||
.. _REMOVE:
|
||||
.. code-block:: cmake
|
||||
|
||||
string(JSON <out-var> [ERROR_VARIABLE <error-variable>]
|
||||
REMOVE <json-string> <member|index> [<member|index> ...])
|
||||
|
||||
Remove an element from ``<json-string>`` at the location
|
||||
given by the list of ``<member|index>`` arguments. The JSON string
|
||||
without the removed element will be stored in ``<out-var>``.
|
||||
|
||||
.. _SET:
|
||||
.. code-block:: cmake
|
||||
|
||||
string(JSON <out-var> [ERROR_VARIABLE <error-variable>]
|
||||
SET <json-string> <member|index> [<member|index> ...] <value>)
|
||||
|
||||
Set an element in ``<json-string>`` at the location
|
||||
given by the list of ``<member|index>`` arguments to ``<value>``.
|
||||
The contents of ``<value>`` should be valid JSON.
|
||||
|
||||
.. _EQUAL:
|
||||
.. code-block:: cmake
|
||||
|
||||
string(JSON <out-var> [ERROR_VARIABLE <error-var>]
|
||||
EQUAL <json-string1> <json-string2>)
|
||||
|
||||
Compare the two JSON objects given by ``<json-string1>`` and ``<json-string2>``
|
||||
for equality. The contents of ``<json-string1>`` and ``<json-string2>``
|
||||
should be valid JSON. The ``<out-var>`` will be set to a true value if the
|
||||
JSON objects are considered equal, or a false value otherwise.
|
||||
|
@ -19,10 +19,12 @@ specify the scope of the following arguments. ``PRIVATE`` and ``PUBLIC``
|
||||
items will populate the :prop_tgt:`COMPILE_DEFINITIONS` property of
|
||||
``<target>``. ``PUBLIC`` and ``INTERFACE`` items will populate the
|
||||
:prop_tgt:`INTERFACE_COMPILE_DEFINITIONS` property of ``<target>``.
|
||||
(:ref:`IMPORTED targets <Imported Targets>` only support ``INTERFACE`` items.)
|
||||
The following arguments specify compile definitions. Repeated calls for the
|
||||
same ``<target>`` append items in the order called.
|
||||
|
||||
.. versionadded:: 3.11
|
||||
Allow setting ``INTERFACE`` items on :ref:`IMPORTED targets <Imported Targets>`.
|
||||
|
||||
Arguments to ``target_compile_definitions`` may use "generator expressions"
|
||||
with the syntax ``$<...>``. See the :manual:`cmake-generator-expressions(7)`
|
||||
manual for available expressions. See the :manual:`cmake-buildsystem(7)`
|
||||
@ -37,3 +39,12 @@ For example, the following are all equivalent:
|
||||
target_compile_definitions(foo PUBLIC -DFOO) # -D removed
|
||||
target_compile_definitions(foo PUBLIC "" FOO) # "" ignored
|
||||
target_compile_definitions(foo PUBLIC -D FOO) # -D becomes "", then ignored
|
||||
|
||||
Definitions may optionally have values:
|
||||
|
||||
.. code-block:: cmake
|
||||
|
||||
target_compile_definitions(foo PUBLIC FOO=1)
|
||||
|
||||
Note that many compilers treat ``-DFOO`` as equivalent to ``-DFOO=1``, but
|
||||
other tools may not recognize this in all circumstances (e.g. IntelliSense).
|
||||
|
@ -1,6 +1,8 @@
|
||||
target_compile_features
|
||||
-----------------------
|
||||
|
||||
.. versionadded:: 3.1
|
||||
|
||||
Add expected compiler features to a target.
|
||||
|
||||
.. code-block:: cmake
|
||||
@ -19,9 +21,11 @@ specify the scope of the features. ``PRIVATE`` and ``PUBLIC`` items will
|
||||
populate the :prop_tgt:`COMPILE_FEATURES` property of ``<target>``.
|
||||
``PUBLIC`` and ``INTERFACE`` items will populate the
|
||||
:prop_tgt:`INTERFACE_COMPILE_FEATURES` property of ``<target>``.
|
||||
(:ref:`IMPORTED targets <Imported Targets>` only support ``INTERFACE`` items.)
|
||||
Repeated calls for the same ``<target>`` append items.
|
||||
|
||||
.. versionadded:: 3.11
|
||||
Allow setting ``INTERFACE`` items on :ref:`IMPORTED targets <Imported Targets>`.
|
||||
|
||||
The named ``<target>`` must have been created by a command such as
|
||||
:command:`add_executable` or :command:`add_library` and must not be an
|
||||
:ref:`ALIAS target <Alias Targets>`.
|
||||
|
@ -26,10 +26,12 @@ specify the scope of the following arguments. ``PRIVATE`` and ``PUBLIC``
|
||||
items will populate the :prop_tgt:`COMPILE_OPTIONS` property of
|
||||
``<target>``. ``PUBLIC`` and ``INTERFACE`` items will populate the
|
||||
:prop_tgt:`INTERFACE_COMPILE_OPTIONS` property of ``<target>``.
|
||||
(:ref:`IMPORTED targets <Imported Targets>` only support ``INTERFACE`` items.)
|
||||
The following arguments specify compile options. Repeated calls for the same
|
||||
``<target>`` append items in the order called.
|
||||
|
||||
.. versionadded:: 3.11
|
||||
Allow setting ``INTERFACE`` items on :ref:`IMPORTED targets <Imported Targets>`.
|
||||
|
||||
Arguments to ``target_compile_options`` may use "generator expressions"
|
||||
with the syntax ``$<...>``. See the :manual:`cmake-generator-expressions(7)`
|
||||
manual for available expressions. See the :manual:`cmake-buildsystem(7)`
|
||||
|
@ -5,7 +5,7 @@ Add include directories to a target.
|
||||
|
||||
.. code-block:: cmake
|
||||
|
||||
target_include_directories(<target> [SYSTEM] [BEFORE]
|
||||
target_include_directories(<target> [SYSTEM] [AFTER|BEFORE]
|
||||
<INTERFACE|PUBLIC|PRIVATE> [items1...]
|
||||
[<INTERFACE|PUBLIC|PRIVATE> [items2...] ...])
|
||||
|
||||
@ -14,17 +14,19 @@ The named ``<target>`` must have been created by a command such
|
||||
as :command:`add_executable` or :command:`add_library` and must not be an
|
||||
:ref:`ALIAS target <Alias Targets>`.
|
||||
|
||||
If ``BEFORE`` is specified, the content will be prepended to the property
|
||||
instead of being appended.
|
||||
By using ``AFTER`` or ``BEFORE`` explicitly, you can select between appending
|
||||
and prepending, independent of the default.
|
||||
|
||||
The ``INTERFACE``, ``PUBLIC`` and ``PRIVATE`` keywords are required to specify
|
||||
the scope of the following arguments. ``PRIVATE`` and ``PUBLIC`` items will
|
||||
populate the :prop_tgt:`INCLUDE_DIRECTORIES` property of ``<target>``.
|
||||
``PUBLIC`` and ``INTERFACE`` items will populate the
|
||||
:prop_tgt:`INTERFACE_INCLUDE_DIRECTORIES` property of ``<target>``.
|
||||
(:ref:`IMPORTED targets <Imported Targets>` only support ``INTERFACE`` items.)
|
||||
The following arguments specify include directories.
|
||||
|
||||
.. versionadded:: 3.11
|
||||
Allow setting ``INTERFACE`` items on :ref:`IMPORTED targets <Imported Targets>`.
|
||||
|
||||
Specified include directories may be absolute paths or relative paths.
|
||||
Repeated calls for the same <target> append items in the order called. If
|
||||
``SYSTEM`` is specified, the compiler will be told the
|
||||
|
@ -1,6 +1,8 @@
|
||||
target_link_directories
|
||||
-----------------------
|
||||
|
||||
.. versionadded:: 3.13
|
||||
|
||||
Add link directories to a target.
|
||||
|
||||
.. code-block:: cmake
|
||||
|
@ -27,6 +27,10 @@ set to ``NEW`` then the target must have been created in the current
|
||||
directory. Repeated calls for the same ``<target>`` append items in
|
||||
the order called.
|
||||
|
||||
.. versionadded:: 3.13
|
||||
The ``<target>`` doesn't have to be defined in the same directory as the
|
||||
``target_link_libraries`` call.
|
||||
|
||||
Each ``<item>`` may be:
|
||||
|
||||
* **A library target name**: The generated link line will have the
|
||||
@ -62,10 +66,11 @@ Each ``<item>`` may be:
|
||||
:ref:`usage requirement <Target Usage Requirements>`. This has the same
|
||||
effect as passing the framework directory as an include directory.
|
||||
|
||||
On :ref:`Visual Studio Generators` for VS 2010 and above, library files
|
||||
ending in ``.targets`` will be treated as MSBuild targets files and
|
||||
imported into generated project files. This is not supported by other
|
||||
generators.
|
||||
.. versionadded:: 3.8
|
||||
On :ref:`Visual Studio Generators` for VS 2010 and above, library files
|
||||
ending in ``.targets`` will be treated as MSBuild targets files and
|
||||
imported into generated project files. This is not supported by other
|
||||
generators.
|
||||
|
||||
The full path to the library file will be quoted/escaped for
|
||||
the shell automatically.
|
||||
@ -89,6 +94,11 @@ Each ``<item>`` may be:
|
||||
flags explicitly. The flags will then be placed at the toolchain-defined
|
||||
flag position in the link command.
|
||||
|
||||
.. versionadded:: 3.13
|
||||
:prop_tgt:`LINK_OPTIONS` target property and :command:`target_link_options`
|
||||
command. For earlier versions of CMake, use :prop_tgt:`LINK_FLAGS`
|
||||
property instead.
|
||||
|
||||
The link flag is treated as a command-line string fragment and
|
||||
will be used with no extra quoting or escaping.
|
||||
|
||||
@ -216,6 +226,8 @@ is not ``NEW``, they are also appended to the
|
||||
Linking Object Libraries
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
.. versionadded:: 3.12
|
||||
|
||||
:ref:`Object Libraries` may be used as the ``<target>`` (first) argument
|
||||
of ``target_link_libraries`` to specify dependencies of their sources
|
||||
on other libraries. For example, the code
|
||||
@ -277,6 +289,91 @@ treated as :ref:`Interface Libraries`, but when they appear in
|
||||
a target's :prop_tgt:`LINK_LIBRARIES` property their object files
|
||||
will be included in the link too.
|
||||
|
||||
.. _`Linking Object Libraries via $<TARGET_OBJECTS>`:
|
||||
|
||||
Linking Object Libraries via $<TARGET_OBJECTS>
|
||||
""""""""""""""""""""""""""""""""""""""""""""""
|
||||
|
||||
.. versionadded:: 3.21
|
||||
|
||||
The object files associated with an object library may be referenced
|
||||
by the :genex:`$<TARGET_OBJECTS>` generator expression. Such object
|
||||
files are placed on the link line *before* all libraries, regardless
|
||||
of their relative order. Additionally, an ordering dependency will be
|
||||
added to the build system to make sure the object library is up-to-date
|
||||
before the dependent target links. For example, the code
|
||||
|
||||
.. code-block:: cmake
|
||||
|
||||
add_library(obj3 OBJECT obj3.c)
|
||||
target_compile_definitions(obj3 PUBLIC OBJ3)
|
||||
|
||||
add_executable(main3 main3.c)
|
||||
target_link_libraries(main3 PRIVATE a3 $<TARGET_OBJECTS:obj3> b3)
|
||||
|
||||
links executable ``main3`` with object files from ``main3.c``
|
||||
and ``obj3.c`` followed by the ``a3`` and ``b3`` libraries.
|
||||
``main3.c`` is *not* compiled with usage requirements from ``obj3``,
|
||||
such as ``-DOBJ3``.
|
||||
|
||||
This approach can be used to achieve transitive inclusion of object
|
||||
files in link lines as usage requirements. Continuing the above
|
||||
example, the code
|
||||
|
||||
.. code-block:: cmake
|
||||
|
||||
add_library(iface_obj3 INTERFACE)
|
||||
target_link_libraries(iface_obj3 INTERFACE obj3 $<TARGET_OBJECTS:obj3>)
|
||||
|
||||
creates an interface library ``iface_obj3`` that forwards the ``obj3``
|
||||
usage requirements and adds the ``obj3`` object files to dependents'
|
||||
link lines. The code
|
||||
|
||||
.. code-block:: cmake
|
||||
|
||||
add_executable(use_obj3 use_obj3.c)
|
||||
target_link_libraries(use_obj3 PRIVATE iface_obj3)
|
||||
|
||||
compiles ``use_obj3.c`` with ``-DOBJ3`` and links executable ``use_obj3``
|
||||
with object files from ``use_obj3.c`` and ``obj3.c``.
|
||||
|
||||
This also works transitively through a static library. Since a static
|
||||
library does not link, it does not consume the object files from
|
||||
object libraries referenced this way. Instead, the object files
|
||||
become transitive link dependencies of the static library.
|
||||
Continuing the above example, the code
|
||||
|
||||
.. code-block:: cmake
|
||||
|
||||
add_library(static3 STATIC static3.c)
|
||||
target_link_libraries(static3 PRIVATE iface_obj3)
|
||||
|
||||
add_executable(use_static3 use_static3.c)
|
||||
target_link_libraries(use_static3 PRIVATE static3)
|
||||
|
||||
compiles ``static3.c`` with ``-DOBJ3`` and creates ``libstatic3.a``
|
||||
using only its own object file. ``use_static3.c`` is compiled *without*
|
||||
``-DOBJ3`` because the usage requirement is not transitive through
|
||||
the private dependency of ``static3``. However, the link dependencies
|
||||
of ``static3`` are propagated, including the ``iface_obj3`` reference
|
||||
to ``$<TARGET_OBJECTS:obj3>``. The ``use_static3`` executable is
|
||||
created with object files from ``use_static3.c`` and ``obj3.c``, and
|
||||
linked to library ``libstatic3.a``.
|
||||
|
||||
When using this approach, it is the project's responsibility to avoid
|
||||
linking multiple dependent binaries to ``iface_obj3``, because they will
|
||||
all get the ``obj3`` object files on their link lines.
|
||||
|
||||
.. note::
|
||||
|
||||
Referencing :genex:`$<TARGET_OBJECTS>` in ``target_link_libraries``
|
||||
calls worked in versions of CMake prior to 3.21 for some cases,
|
||||
but was not fully supported:
|
||||
|
||||
* It did not place the object files before libraries on link lines.
|
||||
* It did not add an ordering dependency on the object library.
|
||||
* It did not work in Xcode with multiple architectures.
|
||||
|
||||
Cyclic Dependencies of Static Libraries
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
|
@ -1,6 +1,8 @@
|
||||
target_link_options
|
||||
-------------------
|
||||
|
||||
.. versionadded:: 3.13
|
||||
|
||||
Add options to the link step for an executable, shared library or module
|
||||
library target.
|
||||
|
||||
@ -34,10 +36,12 @@ specify the scope of the following arguments. ``PRIVATE`` and ``PUBLIC``
|
||||
items will populate the :prop_tgt:`LINK_OPTIONS` property of
|
||||
``<target>``. ``PUBLIC`` and ``INTERFACE`` items will populate the
|
||||
:prop_tgt:`INTERFACE_LINK_OPTIONS` property of ``<target>``.
|
||||
(:ref:`IMPORTED targets <Imported Targets>` only support ``INTERFACE`` items.)
|
||||
The following arguments specify link options. Repeated calls for the same
|
||||
``<target>`` append items in the order called.
|
||||
|
||||
.. note::
|
||||
:ref:`IMPORTED targets <Imported Targets>` only support ``INTERFACE`` items.
|
||||
|
||||
Arguments to ``target_link_options`` may use "generator expressions"
|
||||
with the syntax ``$<...>``. See the :manual:`cmake-generator-expressions(7)`
|
||||
manual for available expressions. See the :manual:`cmake-buildsystem(7)`
|
||||
|
@ -1,6 +1,8 @@
|
||||
target_precompile_headers
|
||||
-------------------------
|
||||
|
||||
.. versionadded:: 3.16
|
||||
|
||||
Add a list of header files to precompile.
|
||||
|
||||
Precompiling header files can speed up compilation by creating a partially
|
||||
@ -32,7 +34,7 @@ Repeated calls for the same ``<target>`` will append items in the order called.
|
||||
|
||||
Projects should generally avoid using ``PUBLIC`` or ``INTERFACE`` for targets
|
||||
that will be :ref:`exported <install(EXPORT)>`, or they should at least use
|
||||
the ``$<BUILD_INTERFACE:...>`` generator expression to prevent precompile
|
||||
the :genex:`$<BUILD_INTERFACE:...>` generator expression to prevent precompile
|
||||
headers from appearing in an installed exported target. Consumers of a target
|
||||
should typically be in control of what precompile headers they use, not have
|
||||
precompile headers forced on them by the targets being consumed (since
|
||||
@ -72,7 +74,7 @@ Arguments to ``target_precompile_headers()`` may use "generator expressions"
|
||||
with the syntax ``$<...>``.
|
||||
See the :manual:`cmake-generator-expressions(7)` manual for available
|
||||
expressions.
|
||||
The ``$<COMPILE_LANGUAGE:...>`` generator expression is particularly
|
||||
The :genex:`$<COMPILE_LANGUAGE:...>` generator expression is particularly
|
||||
useful for specifying a language-specific header to precompile for
|
||||
only one language (e.g. ``CXX`` and not ``C``). In this case, header
|
||||
file names that are not explicitly in double quotes or angle brackets
|
||||
|
@ -1,6 +1,8 @@
|
||||
target_sources
|
||||
--------------
|
||||
|
||||
.. versionadded:: 3.1
|
||||
|
||||
Add sources to a target.
|
||||
|
||||
.. code-block:: cmake
|
||||
@ -9,26 +11,38 @@ Add sources to a target.
|
||||
<INTERFACE|PUBLIC|PRIVATE> [items1...]
|
||||
[<INTERFACE|PUBLIC|PRIVATE> [items2...] ...])
|
||||
|
||||
Specifies sources to use when compiling a given target. Relative
|
||||
source file paths are interpreted as being relative to the current
|
||||
source directory (i.e. :variable:`CMAKE_CURRENT_SOURCE_DIR`). The
|
||||
named ``<target>`` must have been created by a command such as
|
||||
:command:`add_executable` or :command:`add_library` and must not be an
|
||||
Specifies sources to use when building a target and/or its dependents.
|
||||
The named ``<target>`` must have been created by a command such as
|
||||
:command:`add_executable` or :command:`add_library` or
|
||||
:command:`add_custom_target` and must not be an
|
||||
:ref:`ALIAS target <Alias Targets>`.
|
||||
|
||||
.. versionchanged:: 3.13
|
||||
Relative source file paths are interpreted as being relative to the current
|
||||
source directory (i.e. :variable:`CMAKE_CURRENT_SOURCE_DIR`).
|
||||
See policy :policy:`CMP0076`.
|
||||
|
||||
.. versionadded:: 3.20
|
||||
``<target>`` can be a custom target.
|
||||
|
||||
The ``INTERFACE``, ``PUBLIC`` and ``PRIVATE`` keywords are required to
|
||||
specify the scope of the following arguments. ``PRIVATE`` and ``PUBLIC``
|
||||
specify the scope of the items following them. ``PRIVATE`` and ``PUBLIC``
|
||||
items will populate the :prop_tgt:`SOURCES` property of
|
||||
``<target>``. ``PUBLIC`` and ``INTERFACE`` items will populate the
|
||||
:prop_tgt:`INTERFACE_SOURCES` property of ``<target>``.
|
||||
(:ref:`IMPORTED targets <Imported Targets>` only support ``INTERFACE`` items.)
|
||||
``<target>``, which are used when building the target itself.
|
||||
``PUBLIC`` and ``INTERFACE`` items will populate the
|
||||
:prop_tgt:`INTERFACE_SOURCES` property of ``<target>``, which are used
|
||||
when building dependents.
|
||||
The following arguments specify sources. Repeated calls for the same
|
||||
``<target>`` append items in the order called.
|
||||
``<target>`` append items in the order called. The targets created by
|
||||
:command:`add_custom_target` can only have ``PRIVATE`` scope.
|
||||
|
||||
.. versionadded:: 3.3
|
||||
Allow exporting targets with :prop_tgt:`INTERFACE_SOURCES`.
|
||||
|
||||
.. versionadded:: 3.11
|
||||
Allow setting ``INTERFACE`` items on :ref:`IMPORTED targets <Imported Targets>`.
|
||||
|
||||
Arguments to ``target_sources`` may use "generator expressions"
|
||||
with the syntax ``$<...>``. See the :manual:`cmake-generator-expressions(7)`
|
||||
manual for available expressions. See the :manual:`cmake-buildsystem(7)`
|
||||
manual for more on defining buildsystem properties.
|
||||
|
||||
See also the :policy:`CMP0076` policy for older behavior related to the
|
||||
handling of relative source file paths.
|
||||
|
@ -19,6 +19,10 @@ Try Compiling Whole Projects
|
||||
Try building a project. The success or failure of the ``try_compile``,
|
||||
i.e. ``TRUE`` or ``FALSE`` respectively, is returned in ``<resultVar>``.
|
||||
|
||||
.. versionadded:: 3.14
|
||||
The name of the ``<resultVar>`` is defined by the user. Previously, it had
|
||||
a fixed name ``RESULT_VAR``.
|
||||
|
||||
In this form, ``<srcdir>`` should contain a complete CMake project with a
|
||||
``CMakeLists.txt`` file and all sources. The ``<bindir>`` and ``<srcdir>``
|
||||
will not be deleted after this command is run. Specify ``<targetName>`` to
|
||||
@ -47,6 +51,10 @@ Try building an executable or static library from one or more source files
|
||||
variable). The success or failure of the ``try_compile``, i.e. ``TRUE`` or
|
||||
``FALSE`` respectively, is returned in ``<resultVar>``.
|
||||
|
||||
.. versionadded:: 3.14
|
||||
The name of the ``<resultVar>`` is defined by the user. Previously, it had
|
||||
a fixed name ``RESULT_VAR``.
|
||||
|
||||
In this form, one or more source files must be provided. If
|
||||
:variable:`CMAKE_TRY_COMPILE_TARGET_TYPE` is unset or is set to ``EXECUTABLE``,
|
||||
the sources must include a definition for ``main`` and CMake will create a
|
||||
@ -94,6 +102,8 @@ The options are:
|
||||
given to the ``CMAKE_FLAGS`` option will be ignored.
|
||||
|
||||
``LINK_OPTIONS <options>...``
|
||||
.. versionadded:: 3.14
|
||||
|
||||
Specify link step options to pass to :command:`target_link_options` or to
|
||||
set the :prop_tgt:`STATIC_LIBRARY_OPTIONS` target property in the generated
|
||||
project, depending on the :variable:`CMAKE_TRY_COMPILE_TARGET_TYPE` variable.
|
||||
@ -102,17 +112,23 @@ The options are:
|
||||
Store the output from the build process in the given variable.
|
||||
|
||||
``<LANG>_STANDARD <std>``
|
||||
.. versionadded:: 3.8
|
||||
|
||||
Specify the :prop_tgt:`C_STANDARD`, :prop_tgt:`CXX_STANDARD`,
|
||||
:prop_tgt:`OBJC_STANDARD`, :prop_tgt:`OBJCXX_STANDARD`,
|
||||
or :prop_tgt:`CUDA_STANDARD` target property of the generated project.
|
||||
|
||||
``<LANG>_STANDARD_REQUIRED <bool>``
|
||||
.. versionadded:: 3.8
|
||||
|
||||
Specify the :prop_tgt:`C_STANDARD_REQUIRED`,
|
||||
:prop_tgt:`CXX_STANDARD_REQUIRED`, :prop_tgt:`OBJC_STANDARD_REQUIRED`,
|
||||
:prop_tgt:`OBJCXX_STANDARD_REQUIRED`,or :prop_tgt:`CUDA_STANDARD_REQUIRED`
|
||||
target property of the generated project.
|
||||
|
||||
``<LANG>_EXTENSIONS <bool>``
|
||||
.. versionadded:: 3.8
|
||||
|
||||
Specify the :prop_tgt:`C_EXTENSIONS`, :prop_tgt:`CXX_EXTENSIONS`,
|
||||
:prop_tgt:`OBJC_EXTENSIONS`, :prop_tgt:`OBJCXX_EXTENSIONS`,
|
||||
or :prop_tgt:`CUDA_EXTENSIONS` target property of the generated project.
|
||||
@ -131,24 +147,26 @@ the try_compile call of interest, and then re-run cmake again with
|
||||
Other Behavior Settings
|
||||
^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
If set, the following variables are passed in to the generated
|
||||
try_compile CMakeLists.txt to initialize compile target properties with
|
||||
default values:
|
||||
.. versionadded:: 3.4
|
||||
If set, the following variables are passed in to the generated
|
||||
try_compile CMakeLists.txt to initialize compile target properties with
|
||||
default values:
|
||||
|
||||
* :variable:`CMAKE_CUDA_RUNTIME_LIBRARY`
|
||||
* :variable:`CMAKE_ENABLE_EXPORTS`
|
||||
* :variable:`CMAKE_LINK_SEARCH_START_STATIC`
|
||||
* :variable:`CMAKE_LINK_SEARCH_END_STATIC`
|
||||
* :variable:`CMAKE_MSVC_RUNTIME_LIBRARY`
|
||||
* :variable:`CMAKE_POSITION_INDEPENDENT_CODE`
|
||||
* :variable:`CMAKE_CUDA_RUNTIME_LIBRARY`
|
||||
* :variable:`CMAKE_ENABLE_EXPORTS`
|
||||
* :variable:`CMAKE_LINK_SEARCH_START_STATIC`
|
||||
* :variable:`CMAKE_LINK_SEARCH_END_STATIC`
|
||||
* :variable:`CMAKE_MSVC_RUNTIME_LIBRARY`
|
||||
* :variable:`CMAKE_POSITION_INDEPENDENT_CODE`
|
||||
|
||||
If :policy:`CMP0056` is set to ``NEW``, then
|
||||
:variable:`CMAKE_EXE_LINKER_FLAGS` is passed in as well.
|
||||
If :policy:`CMP0056` is set to ``NEW``, then
|
||||
:variable:`CMAKE_EXE_LINKER_FLAGS` is passed in as well.
|
||||
|
||||
If :policy:`CMP0083` is set to ``NEW``, then in order to obtain correct
|
||||
behavior at link time, the ``check_pie_supported()`` command from the
|
||||
:module:`CheckPIESupported` module must be called before using the
|
||||
:command:`try_compile` command.
|
||||
.. versionchanged:: 3.14
|
||||
If :policy:`CMP0083` is set to ``NEW``, then in order to obtain correct
|
||||
behavior at link time, the ``check_pie_supported()`` command from the
|
||||
:module:`CheckPIESupported` module must be called before using the
|
||||
:command:`try_compile` command.
|
||||
|
||||
The current settings of :policy:`CMP0065` and :policy:`CMP0083` are propagated
|
||||
through to the generated test project.
|
||||
@ -156,37 +174,41 @@ through to the generated test project.
|
||||
Set the :variable:`CMAKE_TRY_COMPILE_CONFIGURATION` variable to choose
|
||||
a build configuration.
|
||||
|
||||
Set the :variable:`CMAKE_TRY_COMPILE_TARGET_TYPE` variable to specify
|
||||
the type of target used for the source file signature.
|
||||
.. versionadded:: 3.6
|
||||
Set the :variable:`CMAKE_TRY_COMPILE_TARGET_TYPE` variable to specify
|
||||
the type of target used for the source file signature.
|
||||
|
||||
Set the :variable:`CMAKE_TRY_COMPILE_PLATFORM_VARIABLES` variable to specify
|
||||
variables that must be propagated into the test project. This variable is
|
||||
meant for use only in toolchain files and is only honored by the
|
||||
``try_compile()`` command for the source files form, not when given a whole
|
||||
project.
|
||||
.. versionadded:: 3.6
|
||||
Set the :variable:`CMAKE_TRY_COMPILE_PLATFORM_VARIABLES` variable to specify
|
||||
variables that must be propagated into the test project. This variable is
|
||||
meant for use only in toolchain files and is only honored by the
|
||||
``try_compile()`` command for the source files form, not when given a whole
|
||||
project.
|
||||
|
||||
If :policy:`CMP0067` is set to ``NEW``, or any of the ``<LANG>_STANDARD``,
|
||||
``<LANG>_STANDARD_REQUIRED``, or ``<LANG>_EXTENSIONS`` options are used,
|
||||
then the language standard variables are honored:
|
||||
.. versionchanged:: 3.8
|
||||
If :policy:`CMP0067` is set to ``NEW``, or any of the ``<LANG>_STANDARD``,
|
||||
``<LANG>_STANDARD_REQUIRED``, or ``<LANG>_EXTENSIONS`` options are used,
|
||||
then the language standard variables are honored:
|
||||
|
||||
* :variable:`CMAKE_C_STANDARD`
|
||||
* :variable:`CMAKE_C_STANDARD_REQUIRED`
|
||||
* :variable:`CMAKE_C_EXTENSIONS`
|
||||
* :variable:`CMAKE_CXX_STANDARD`
|
||||
* :variable:`CMAKE_CXX_STANDARD_REQUIRED`
|
||||
* :variable:`CMAKE_CXX_EXTENSIONS`
|
||||
* :variable:`CMAKE_OBJC_STANDARD`
|
||||
* :variable:`CMAKE_OBJC_STANDARD_REQUIRED`
|
||||
* :variable:`CMAKE_OBJC_EXTENSIONS`
|
||||
* :variable:`CMAKE_OBJCXX_STANDARD`
|
||||
* :variable:`CMAKE_OBJCXX_STANDARD_REQUIRED`
|
||||
* :variable:`CMAKE_OBJCXX_EXTENSIONS`
|
||||
* :variable:`CMAKE_CUDA_STANDARD`
|
||||
* :variable:`CMAKE_CUDA_STANDARD_REQUIRED`
|
||||
* :variable:`CMAKE_CUDA_EXTENSIONS`
|
||||
* :variable:`CMAKE_C_STANDARD`
|
||||
* :variable:`CMAKE_C_STANDARD_REQUIRED`
|
||||
* :variable:`CMAKE_C_EXTENSIONS`
|
||||
* :variable:`CMAKE_CXX_STANDARD`
|
||||
* :variable:`CMAKE_CXX_STANDARD_REQUIRED`
|
||||
* :variable:`CMAKE_CXX_EXTENSIONS`
|
||||
* :variable:`CMAKE_OBJC_STANDARD`
|
||||
* :variable:`CMAKE_OBJC_STANDARD_REQUIRED`
|
||||
* :variable:`CMAKE_OBJC_EXTENSIONS`
|
||||
* :variable:`CMAKE_OBJCXX_STANDARD`
|
||||
* :variable:`CMAKE_OBJCXX_STANDARD_REQUIRED`
|
||||
* :variable:`CMAKE_OBJCXX_EXTENSIONS`
|
||||
* :variable:`CMAKE_CUDA_STANDARD`
|
||||
* :variable:`CMAKE_CUDA_STANDARD_REQUIRED`
|
||||
* :variable:`CMAKE_CUDA_EXTENSIONS`
|
||||
|
||||
Their values are used to set the corresponding target properties in
|
||||
the generated project (unless overridden by an explicit option).
|
||||
Their values are used to set the corresponding target properties in
|
||||
the generated project (unless overridden by an explicit option).
|
||||
|
||||
For the :generator:`Green Hills MULTI` generator the GHS toolset and target
|
||||
system customization cache variables are also propagated into the test project.
|
||||
.. versionchanged:: 3.14
|
||||
For the :generator:`Green Hills MULTI` generator the GHS toolset and target
|
||||
system customization cache variables are also propagated into the test project.
|
||||
|
@ -20,6 +20,7 @@ Try Compiling and Running Source Files
|
||||
[COMPILE_OUTPUT_VARIABLE <var>]
|
||||
[RUN_OUTPUT_VARIABLE <var>]
|
||||
[OUTPUT_VARIABLE <var>]
|
||||
[WORKING_DIRECTORY <var>]
|
||||
[ARGS <args>...])
|
||||
|
||||
Try compiling a ``<srcfile>``. Returns ``TRUE`` or ``FALSE`` for success
|
||||
@ -29,6 +30,11 @@ executable was built, but failed to run, then ``<runResultVar>`` will be
|
||||
set to ``FAILED_TO_RUN``. See the :command:`try_compile` command for
|
||||
information on how the test project is constructed to build the source file.
|
||||
|
||||
.. versionadded:: 3.14
|
||||
The names of the result variables ``<runResultVar>`` and
|
||||
``<compileResultVar>`` are defined by the user. Previously, they had
|
||||
fixed names ``RUN_RESULT_VAR`` and ``COMPILE_RESULT_VAR``.
|
||||
|
||||
The options are:
|
||||
|
||||
``CMAKE_FLAGS <flags>...``
|
||||
@ -46,6 +52,8 @@ The options are:
|
||||
Report the compile step build output in a given variable.
|
||||
|
||||
``LINK_LIBRARIES <libs>...``
|
||||
.. versionadded:: 3.2
|
||||
|
||||
Specify libraries to be linked in the generated project.
|
||||
The list of libraries may refer to system libraries and to
|
||||
:ref:`Imported Targets <Imported Targets>` from the calling project.
|
||||
@ -54,6 +62,8 @@ The options are:
|
||||
given to the ``CMAKE_FLAGS`` option will be ignored.
|
||||
|
||||
``LINK_OPTIONS <options>...``
|
||||
.. versionadded:: 3.14
|
||||
|
||||
Specify link step options to pass to :command:`target_link_options` in the
|
||||
generated project.
|
||||
|
||||
@ -65,6 +75,12 @@ The options are:
|
||||
``RUN_OUTPUT_VARIABLE <var>``
|
||||
Report the output from running the executable in a given variable.
|
||||
|
||||
``WORKING_DIRECTORY <var>``
|
||||
.. versionadded:: 3.20
|
||||
|
||||
Run the executable in the given directory. If no ``WORKING_DIRECTORY`` is
|
||||
specified, the executable will run in ``<bindir>``.
|
||||
|
||||
Other Behavior Settings
|
||||
^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
@ -74,6 +90,10 @@ a build configuration.
|
||||
Behavior when Cross Compiling
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
.. versionadded:: 3.3
|
||||
Use ``CMAKE_CROSSCOMPILING_EMULATOR`` when running cross-compiled
|
||||
binaries.
|
||||
|
||||
When cross compiling, the executable compiled in the first step
|
||||
usually cannot be run on the build host. The ``try_run`` command checks
|
||||
the :variable:`CMAKE_CROSSCOMPILING` variable to detect whether CMake is in
|
||||
|
@ -7,9 +7,42 @@ Watch the CMake variable for change.
|
||||
|
||||
variable_watch(<variable> [<command>])
|
||||
|
||||
If the specified ``<variable>`` changes, a message will be printed
|
||||
to inform about the change.
|
||||
If the specified ``<variable>`` changes and no ``<command>`` is given,
|
||||
a message will be printed to inform about the change.
|
||||
|
||||
Additionally, if ``<command>`` is given, this command will be executed.
|
||||
If ``<command>`` is given, this command will be executed instead.
|
||||
The command will receive the following arguments:
|
||||
``COMMAND(<variable> <access> <value> <current_list_file> <stack>)``
|
||||
|
||||
``<variable>``
|
||||
Name of the variable being accessed.
|
||||
|
||||
``<access>``
|
||||
One of ``READ_ACCESS``, ``UNKNOWN_READ_ACCESS``, ``MODIFIED_ACCESS``,
|
||||
``UNKNOWN_MODIFIED_ACCESS``, or ``REMOVED_ACCESS``. The ``UNKNOWN_``
|
||||
values are only used when the variable has never been set. Once set,
|
||||
they are never used again during the same CMake run, even if the
|
||||
variable is later unset.
|
||||
|
||||
``<value>``
|
||||
The value of the variable. On a modification, this is the new
|
||||
(modified) value of the variable. On removal, the value is empty.
|
||||
|
||||
``<current_list_file>``
|
||||
Full path to the file doing the access.
|
||||
|
||||
``<stack>``
|
||||
List of absolute paths of all files currently on the stack of file
|
||||
inclusion, with the bottom-most file first and the currently
|
||||
processed file (that is, ``current_list_file``) last.
|
||||
|
||||
Note that for some accesses such as :command:`list(APPEND)`, the watcher
|
||||
is executed twice, first with a read access and then with a write one.
|
||||
Also note that an :command:`if(DEFINED)` query on the variable does not
|
||||
register as an access and the watcher is not executed.
|
||||
|
||||
Only non-cache variables can be watched using this command. Access to
|
||||
cache variables is never watched. However, the existence of a cache
|
||||
variable ``var`` causes accesses to the non-cache variable ``var`` to
|
||||
not use the ``UNKNOWN_`` prefix, even if a non-cache variable ``var``
|
||||
has never existed.
|
||||
|
@ -12,6 +12,12 @@ any of the following formats:
|
||||
- TZST (.tar.zst)
|
||||
- ZIP (.zip)
|
||||
|
||||
.. versionadded:: 3.1
|
||||
``7Z`` and ``TXZ`` formats support.
|
||||
|
||||
.. versionadded:: 3.16
|
||||
``TZST`` format support.
|
||||
|
||||
When this generator is called from ``CPackSourceConfig.cmake`` (or through
|
||||
the ``package_source`` target), then the generated archive will contain all
|
||||
files in the project directory, except those specified in
|
||||
@ -46,6 +52,9 @@ Variables specific to CPack Archive generator
|
||||
The default is ``<CPACK_PACKAGE_FILE_NAME>[-<component>]``, with spaces
|
||||
replaced by '-'.
|
||||
|
||||
.. versionadded:: 3.9
|
||||
Per-component ``CPACK_ARCHIVE_<component>_FILE_NAME`` variables.
|
||||
|
||||
.. variable:: CPACK_ARCHIVE_COMPONENT_INSTALL
|
||||
|
||||
Enable component packaging. If enabled (ON), then the archive generator
|
||||
@ -63,13 +72,18 @@ CPack generators which are essentially archives at their core. These include:
|
||||
|
||||
.. variable:: CPACK_ARCHIVE_THREADS
|
||||
|
||||
.. versionadded:: 3.18
|
||||
|
||||
The number of threads to use when performing the compression. If set to
|
||||
``0``, the number of available cores on the machine will be used instead.
|
||||
The default is ``1`` which limits compression to a single thread. Note that
|
||||
not all compression modes support threading in all environments. Currently,
|
||||
only the XZ compression may support it.
|
||||
|
||||
.. note::
|
||||
See also the :variable:`CPACK_THREADS` variable.
|
||||
|
||||
Official CMake binaries available on ``cmake.org`` ship with a ``liblzma``
|
||||
that does not support parallel compression.
|
||||
.. versionadded:: 3.21
|
||||
|
||||
Official CMake binaries available on ``cmake.org`` now ship
|
||||
with a ``liblzma`` that supports parallel compression.
|
||||
Older versions did not.
|
||||
|
@ -36,6 +36,8 @@ Bundle-specific parameters (``CPACK_BUNDLE_xxx``).
|
||||
|
||||
.. variable:: CPACK_BUNDLE_APPLE_CERT_APP
|
||||
|
||||
.. versionadded:: 3.2
|
||||
|
||||
The name of your Apple supplied code signing certificate for the application.
|
||||
The name usually takes the form ``Developer ID Application: [Name]`` or
|
||||
``3rd Party Mac Developer Application: [Name]``. If this variable is not set
|
||||
@ -43,23 +45,31 @@ Bundle-specific parameters (``CPACK_BUNDLE_xxx``).
|
||||
|
||||
.. variable:: CPACK_BUNDLE_APPLE_ENTITLEMENTS
|
||||
|
||||
.. versionadded:: 3.2
|
||||
|
||||
The name of the Property List (``.plist``) file that contains your Apple
|
||||
entitlements for sandboxing your application. This file is required
|
||||
for submission to the macOS App Store.
|
||||
|
||||
.. variable:: CPACK_BUNDLE_APPLE_CODESIGN_FILES
|
||||
|
||||
.. versionadded:: 3.2
|
||||
|
||||
A list of additional files that you wish to be signed. You do not need to
|
||||
list the main application folder, or the main executable. You should
|
||||
list any frameworks and plugins that are included in your app bundle.
|
||||
|
||||
.. variable:: CPACK_BUNDLE_APPLE_CODESIGN_PARAMETER
|
||||
|
||||
.. versionadded:: 3.3
|
||||
|
||||
Additional parameter that will passed to ``codesign``.
|
||||
Default value: ``--deep -f``
|
||||
|
||||
.. variable:: CPACK_COMMAND_CODESIGN
|
||||
|
||||
.. versionadded:: 3.2
|
||||
|
||||
Path to the ``codesign(1)`` command used to sign applications with an
|
||||
Apple cert. This variable can be used to override the automatically
|
||||
detected command (or specify its location if the auto-detection fails
|
||||
|
@ -6,7 +6,9 @@ Cygwin CPack generator (Cygwin).
|
||||
Variables affecting the CPack Cygwin generator
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
- :variable:`CPACK_ARCHIVE_THREADS`
|
||||
- .. versionadded:: 3.18
|
||||
:variable:`CPACK_ARCHIVE_THREADS`
|
||||
|
||||
|
||||
Variables specific to CPack Cygwin generator
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
@ -54,11 +54,16 @@ List of CPack DEB generator specific variables:
|
||||
- :variable:`CPACK_DEBIAN_PACKAGE_NAME` suffixed with -<COMPONENT>
|
||||
for component-based installations.
|
||||
|
||||
.. versionadded:: 3.5
|
||||
Per-component ``CPACK_DEBIAN_<COMPONENT>_PACKAGE_NAME`` variables.
|
||||
|
||||
See https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Source
|
||||
|
||||
.. variable:: CPACK_DEBIAN_FILE_NAME
|
||||
CPACK_DEBIAN_<COMPONENT>_FILE_NAME
|
||||
|
||||
.. versionadded:: 3.6
|
||||
|
||||
Package file name.
|
||||
|
||||
* Mandatory : YES
|
||||
@ -72,6 +77,9 @@ List of CPack DEB generator specific variables:
|
||||
Alternatively provided package file name must end
|
||||
with either ``.deb`` or ``.ipk`` suffix.
|
||||
|
||||
.. versionadded:: 3.10
|
||||
``.ipk`` suffix used by OPKG packaging system.
|
||||
|
||||
.. note::
|
||||
|
||||
Preferred setting of this variable is ``DEB-DEFAULT`` but for backward
|
||||
@ -86,6 +94,8 @@ List of CPack DEB generator specific variables:
|
||||
|
||||
.. variable:: CPACK_DEBIAN_PACKAGE_EPOCH
|
||||
|
||||
.. versionadded:: 3.10
|
||||
|
||||
The Debian package epoch
|
||||
|
||||
* Mandatory : No
|
||||
@ -116,6 +126,8 @@ List of CPack DEB generator specific variables:
|
||||
|
||||
.. variable:: CPACK_DEBIAN_PACKAGE_RELEASE
|
||||
|
||||
.. versionadded:: 3.6
|
||||
|
||||
The Debian package release - Debian revision number.
|
||||
|
||||
* Mandatory : No
|
||||
@ -136,6 +148,9 @@ List of CPack DEB generator specific variables:
|
||||
* Default : Output of ``dpkg --print-architecture`` (or ``i386``
|
||||
if ``dpkg`` is not found)
|
||||
|
||||
.. versionadded:: 3.6
|
||||
Per-component ``CPACK_DEBIAN_<COMPONENT>_PACKAGE_ARCHITECTURE`` variables.
|
||||
|
||||
.. variable:: CPACK_DEBIAN_PACKAGE_DEPENDS
|
||||
CPACK_DEBIAN_<COMPONENT>_PACKAGE_DEPENDS
|
||||
|
||||
@ -148,6 +163,10 @@ List of CPack DEB generator specific variables:
|
||||
- :variable:`CPACK_DEBIAN_PACKAGE_DEPENDS` for component-based
|
||||
installations.
|
||||
|
||||
|
||||
.. versionadded:: 3.3
|
||||
Per-component ``CPACK_DEBIAN_<COMPONENT>_PACKAGE_DEPENDS`` variables.
|
||||
|
||||
.. note::
|
||||
|
||||
If :variable:`CPACK_DEBIAN_PACKAGE_SHLIBDEPS` or
|
||||
@ -165,7 +184,9 @@ List of CPack DEB generator specific variables:
|
||||
|
||||
.. variable:: CPACK_DEBIAN_ENABLE_COMPONENT_DEPENDS
|
||||
|
||||
Sets inter component dependencies if listed with
|
||||
.. versionadded:: 3.6
|
||||
|
||||
Sets inter-component dependencies if listed with
|
||||
:variable:`CPACK_COMPONENT_<compName>_DEPENDS` variables.
|
||||
|
||||
* Mandatory : NO
|
||||
@ -196,6 +217,15 @@ List of CPack DEB generator specific variables:
|
||||
used if set. Otherwise, :variable:`CPACK_PACKAGE_DESCRIPTION_SUMMARY` will be added as the first
|
||||
line of description as defined in `Debian Policy Manual`_.
|
||||
|
||||
.. versionadded:: 3.3
|
||||
Per-component ``CPACK_COMPONENT_<compName>_DESCRIPTION`` variables.
|
||||
|
||||
.. versionadded:: 3.16
|
||||
Per-component ``CPACK_DEBIAN_<COMPONENT>_DESCRIPTION`` variables.
|
||||
|
||||
.. versionadded:: 3.16
|
||||
The ``CPACK_PACKAGE_DESCRIPTION_FILE`` variable.
|
||||
|
||||
.. _Debian Policy Manual: https://www.debian.org/doc/debian-policy/ch-controlfields.html#description
|
||||
|
||||
.. variable:: CPACK_DEBIAN_PACKAGE_SECTION
|
||||
@ -206,10 +236,17 @@ List of CPack DEB generator specific variables:
|
||||
* Mandatory : YES
|
||||
* Default : "devel"
|
||||
|
||||
.. versionadded:: 3.5
|
||||
Per-component ``CPACK_DEBIAN_<COMPONENT>_PACKAGE_SECTION`` variables.
|
||||
|
||||
See https://www.debian.org/doc/debian-policy/ch-archive.html#s-subsections
|
||||
|
||||
.. variable:: CPACK_DEBIAN_ARCHIVE_TYPE
|
||||
|
||||
.. versionadded:: 3.7
|
||||
|
||||
.. deprecated:: 3.14
|
||||
|
||||
The archive format used for creating the Debian package.
|
||||
|
||||
* Mandatory : YES
|
||||
@ -228,6 +265,8 @@ List of CPack DEB generator specific variables:
|
||||
|
||||
.. variable:: CPACK_DEBIAN_COMPRESSION_TYPE
|
||||
|
||||
.. versionadded:: 3.1
|
||||
|
||||
The compression used for creating the Debian package.
|
||||
|
||||
* Mandatory : YES
|
||||
@ -249,6 +288,9 @@ List of CPack DEB generator specific variables:
|
||||
* Mandatory : YES
|
||||
* Default : "optional"
|
||||
|
||||
.. versionadded:: 3.5
|
||||
Per-component ``CPACK_DEBIAN_<COMPONENT>_PACKAGE_PRIORITY`` variables.
|
||||
|
||||
See https://www.debian.org/doc/debian-policy/ch-archive.html#s-priorities
|
||||
|
||||
.. variable:: CPACK_DEBIAN_PACKAGE_HOMEPAGE
|
||||
@ -260,6 +302,9 @@ List of CPack DEB generator specific variables:
|
||||
* Mandatory : NO
|
||||
* Default : :variable:`CMAKE_PROJECT_HOMEPAGE_URL`
|
||||
|
||||
.. versionadded:: 3.12
|
||||
The ``CMAKE_PROJECT_HOMEPAGE_URL`` variable.
|
||||
|
||||
.. note::
|
||||
|
||||
The content of this field is a simple URL without any surrounding
|
||||
@ -284,6 +329,36 @@ List of CPack DEB generator specific variables:
|
||||
may fail to find your own shared libs.
|
||||
See https://gitlab.kitware.com/cmake/community/-/wikis/doc/cmake/RPATH-handling
|
||||
|
||||
.. note::
|
||||
|
||||
You can also set :variable:`CPACK_DEBIAN_PACKAGE_SHLIBDEPS_PRIVATE_DIRS`
|
||||
to an appropriate value if you use this feature, in order to please
|
||||
``dpkg-shlibdeps``. However, you should only do this for private
|
||||
shared libraries that could not get resolved otherwise.
|
||||
|
||||
.. versionadded:: 3.3
|
||||
Per-component ``CPACK_DEBIAN_<COMPONENT>_PACKAGE_SHLIBDEPS`` variables.
|
||||
|
||||
.. versionadded:: 3.6
|
||||
Correct handling of ``$ORIGIN`` in :variable:`CMAKE_INSTALL_RPATH`.
|
||||
|
||||
.. variable:: CPACK_DEBIAN_PACKAGE_SHLIBDEPS_PRIVATE_DIRS
|
||||
|
||||
.. versionadded:: 3.20
|
||||
|
||||
May be set to a list of directories that will be given to ``dpkg-shlibdeps``
|
||||
via its ``-l`` option. These will be searched by ``dpkg-shlibdeps`` in order
|
||||
to find private shared library dependencies.
|
||||
|
||||
* Mandatory : NO
|
||||
* Default :
|
||||
|
||||
.. note::
|
||||
|
||||
You should prefer to set :variable:`CMAKE_INSTALL_RPATH` to an appropriate
|
||||
value if you use ``dpkg-shlibdeps``. The current option is really only
|
||||
needed for private shared library dependencies.
|
||||
|
||||
.. variable:: CPACK_DEBIAN_PACKAGE_DEBUG
|
||||
|
||||
May be set when invoking cpack in order to trace debug information
|
||||
@ -308,6 +383,9 @@ List of CPack DEB generator specific variables:
|
||||
- :variable:`CPACK_DEBIAN_PACKAGE_PREDEPENDS` for component-based
|
||||
installations.
|
||||
|
||||
.. versionadded:: 3.4
|
||||
Per-component ``CPACK_DEBIAN_<COMPONENT>_PACKAGE_PREDEPENDS`` variables.
|
||||
|
||||
See http://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps
|
||||
|
||||
.. variable:: CPACK_DEBIAN_PACKAGE_ENHANCES
|
||||
@ -325,6 +403,9 @@ List of CPack DEB generator specific variables:
|
||||
- :variable:`CPACK_DEBIAN_PACKAGE_ENHANCES` for component-based
|
||||
installations.
|
||||
|
||||
.. versionadded:: 3.4
|
||||
Per-component ``CPACK_DEBIAN_<COMPONENT>_PACKAGE_ENHANCES`` variables.
|
||||
|
||||
See http://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps
|
||||
|
||||
.. variable:: CPACK_DEBIAN_PACKAGE_BREAKS
|
||||
@ -345,6 +426,9 @@ List of CPack DEB generator specific variables:
|
||||
- :variable:`CPACK_DEBIAN_PACKAGE_BREAKS` for component-based
|
||||
installations.
|
||||
|
||||
.. versionadded:: 3.4
|
||||
Per-component ``CPACK_DEBIAN_<COMPONENT>_PACKAGE_BREAKS`` variables.
|
||||
|
||||
See https://www.debian.org/doc/debian-policy/ch-relationships.html#s-breaks
|
||||
|
||||
.. variable:: CPACK_DEBIAN_PACKAGE_CONFLICTS
|
||||
@ -362,6 +446,9 @@ List of CPack DEB generator specific variables:
|
||||
- :variable:`CPACK_DEBIAN_PACKAGE_CONFLICTS` for component-based
|
||||
installations.
|
||||
|
||||
.. versionadded:: 3.4
|
||||
Per-component ``CPACK_DEBIAN_<COMPONENT>_PACKAGE_CONFLICTS`` variables.
|
||||
|
||||
See https://www.debian.org/doc/debian-policy/ch-relationships.html#s-conflicts
|
||||
|
||||
.. note::
|
||||
@ -386,6 +473,9 @@ List of CPack DEB generator specific variables:
|
||||
- :variable:`CPACK_DEBIAN_PACKAGE_PROVIDES` for component-based
|
||||
installations.
|
||||
|
||||
.. versionadded:: 3.4
|
||||
Per-component ``CPACK_DEBIAN_<COMPONENT>_PACKAGE_PROVIDES`` variables.
|
||||
|
||||
See https://www.debian.org/doc/debian-policy/ch-relationships.html#s-virtual
|
||||
|
||||
.. variable:: CPACK_DEBIAN_PACKAGE_REPLACES
|
||||
@ -402,6 +492,9 @@ List of CPack DEB generator specific variables:
|
||||
- :variable:`CPACK_DEBIAN_PACKAGE_REPLACES` for component-based
|
||||
installations.
|
||||
|
||||
.. versionadded:: 3.4
|
||||
Per-component ``CPACK_DEBIAN_<COMPONENT>_PACKAGE_REPLACES`` variables.
|
||||
|
||||
See http://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps
|
||||
|
||||
.. variable:: CPACK_DEBIAN_PACKAGE_RECOMMENDS
|
||||
@ -418,6 +511,9 @@ List of CPack DEB generator specific variables:
|
||||
- :variable:`CPACK_DEBIAN_PACKAGE_RECOMMENDS` for component-based
|
||||
installations.
|
||||
|
||||
.. versionadded:: 3.4
|
||||
Per-component ``CPACK_DEBIAN_<COMPONENT>_PACKAGE_RECOMMENDS`` variables.
|
||||
|
||||
See http://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps
|
||||
|
||||
.. variable:: CPACK_DEBIAN_PACKAGE_SUGGESTS
|
||||
@ -433,10 +529,15 @@ List of CPack DEB generator specific variables:
|
||||
- :variable:`CPACK_DEBIAN_PACKAGE_SUGGESTS` for component-based
|
||||
installations.
|
||||
|
||||
.. versionadded:: 3.4
|
||||
Per-component ``CPACK_DEBIAN_<COMPONENT>_PACKAGE_SUGGESTS`` variables.
|
||||
|
||||
See http://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps
|
||||
|
||||
.. variable:: CPACK_DEBIAN_PACKAGE_GENERATE_SHLIBS
|
||||
|
||||
.. versionadded:: 3.6
|
||||
|
||||
* Mandatory : NO
|
||||
* Default : OFF
|
||||
|
||||
@ -451,6 +552,8 @@ List of CPack DEB generator specific variables:
|
||||
|
||||
.. variable:: CPACK_DEBIAN_PACKAGE_GENERATE_SHLIBS_POLICY
|
||||
|
||||
.. versionadded:: 3.6
|
||||
|
||||
Compatibility policy for auto-generated shlibs control file.
|
||||
|
||||
* Mandatory : NO
|
||||
@ -476,17 +579,14 @@ List of CPack DEB generator specific variables:
|
||||
set(CPACK_DEBIAN_PACKAGE_CONTROL_EXTRA
|
||||
"${CMAKE_CURRENT_SOURCE_DIR}/prerm;${CMAKE_CURRENT_SOURCE_DIR}/postrm")
|
||||
|
||||
.. note::
|
||||
|
||||
The original permissions of the files will be used in the final
|
||||
package unless the variable
|
||||
:variable:`CPACK_DEBIAN_PACKAGE_CONTROL_STRICT_PERMISSION` is set.
|
||||
In particular, the scripts should have the proper executable
|
||||
flag prior to the generation of the package.
|
||||
.. versionadded:: 3.4
|
||||
Per-component ``CPACK_DEBIAN_<COMPONENT>_PACKAGE_CONTROL_EXTRA`` variables.
|
||||
|
||||
.. variable:: CPACK_DEBIAN_PACKAGE_CONTROL_STRICT_PERMISSION
|
||||
CPACK_DEBIAN_<COMPONENT>_PACKAGE_CONTROL_STRICT_PERMISSION
|
||||
|
||||
.. versionadded:: 3.4
|
||||
|
||||
This variable indicates if the Debian policy on control files should be
|
||||
strictly followed.
|
||||
|
||||
@ -497,15 +597,22 @@ List of CPack DEB generator specific variables:
|
||||
|
||||
set(CPACK_DEBIAN_PACKAGE_CONTROL_STRICT_PERMISSION TRUE)
|
||||
|
||||
This overrides the permissions on the original files, following the rules
|
||||
set by Debian policy
|
||||
https://www.debian.org/doc/debian-policy/ch-files.html#s-permissions-owners
|
||||
|
||||
.. note::
|
||||
|
||||
This overrides the permissions on the original files, following the rules
|
||||
set by Debian policy
|
||||
https://www.debian.org/doc/debian-policy/ch-files.html#s-permissions-owners
|
||||
The original permissions of the files will be used in the final
|
||||
package unless this variable is set to ``TRUE``.
|
||||
In particular, the scripts should have the proper executable
|
||||
flag prior to the generation of the package.
|
||||
|
||||
.. variable:: CPACK_DEBIAN_PACKAGE_SOURCE
|
||||
CPACK_DEBIAN_<COMPONENT>_PACKAGE_SOURCE
|
||||
|
||||
.. versionadded:: 3.5
|
||||
|
||||
Sets the ``Source`` field of the binary Debian package.
|
||||
When the binary package name is not the same as the source package name
|
||||
(in particular when several components/binaries are generated from one
|
||||
@ -529,6 +636,8 @@ List of CPack DEB generator specific variables:
|
||||
Packaging of debug information
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
.. versionadded:: 3.13
|
||||
|
||||
Dbgsym packages contain debug symbols for debugging packaged binaries.
|
||||
|
||||
Dbgsym packaging has its own set of variables:
|
||||
@ -549,6 +658,8 @@ Dbgsym packaging has its own set of variables:
|
||||
Building Debian packages on Windows
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
.. versionadded:: 3.10
|
||||
|
||||
To communicate UNIX file permissions from the install stage
|
||||
to the CPack DEB generator the "cmake_mode_t" NTFS
|
||||
alternate data stream (ADT) is used.
|
||||
@ -559,6 +670,8 @@ permissions can be preserved.
|
||||
Reproducible packages
|
||||
^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
.. versionadded:: 3.13
|
||||
|
||||
The environment variable ``SOURCE_DATE_EPOCH`` may be set to a UNIX
|
||||
timestamp, defined as the number of seconds, excluding leap seconds,
|
||||
since 01 Jan 1970 00:00:00 UTC. If set, the CPack DEB generator will
|
||||
|
@ -30,6 +30,8 @@ on macOS:
|
||||
|
||||
.. variable:: CPACK_DMG_DS_STORE_SETUP_SCRIPT
|
||||
|
||||
.. versionadded:: 3.5
|
||||
|
||||
Path to a custom AppleScript file. This AppleScript is used to generate
|
||||
a ``.DS_Store`` file which specifies the Finder window position/geometry and
|
||||
layout (such as hidden toolbars, placement of the icons etc.).
|
||||
@ -47,11 +49,15 @@ on macOS:
|
||||
|
||||
.. variable:: CPACK_DMG_DISABLE_APPLICATIONS_SYMLINK
|
||||
|
||||
Default behaviour is to include a symlink to ``/Applications`` in the DMG.
|
||||
.. versionadded:: 3.6
|
||||
|
||||
Default behavior is to include a symlink to ``/Applications`` in the DMG.
|
||||
Set this option to ``ON`` to avoid adding the symlink.
|
||||
|
||||
.. variable:: CPACK_DMG_SLA_DIR
|
||||
|
||||
.. versionadded:: 3.5
|
||||
|
||||
Directory where license and menu files for different languages are stored.
|
||||
Setting this causes CPack to look for a ``<language>.menu.txt`` and
|
||||
``<language>.license.txt`` or ``<language>.license.rtf`` file for every
|
||||
@ -61,8 +67,13 @@ on macOS:
|
||||
``<language>.license.txt`` and ``<language>.license.rtf`` exist, the ``.txt``
|
||||
file will be used.
|
||||
|
||||
.. versionadded:: 3.17
|
||||
RTF support.
|
||||
|
||||
.. variable:: CPACK_DMG_SLA_LANGUAGES
|
||||
|
||||
.. versionadded:: 3.5
|
||||
|
||||
Languages for which a license agreement is provided when mounting the
|
||||
generated DMG. A menu file consists of 9 lines of text. The first line is
|
||||
is the name of the language itself, uppercase, in English (e.g. German).
|
||||
@ -85,11 +96,21 @@ on macOS:
|
||||
|
||||
.. variable:: CPACK_DMG_<component>_FILE_NAME
|
||||
|
||||
.. versionadded:: 3.17
|
||||
|
||||
File name when packaging ``<component>`` as its own DMG
|
||||
(``CPACK_COMPONENTS_GROUPING`` set to IGNORE).
|
||||
|
||||
- Default: ``CPACK_PACKAGE_FILE_NAME-<component>``
|
||||
|
||||
.. variable:: CPACK_DMG_FILESYSTEM
|
||||
|
||||
.. versionadded:: 3.21
|
||||
|
||||
The filesystem format. Common values are ``APFS`` and ``HFS+``.
|
||||
See ``man hdiutil`` for a full list of supported formats.
|
||||
Defaults to ``HFS+``.
|
||||
|
||||
.. variable:: CPACK_COMMAND_HDIUTIL
|
||||
|
||||
Path to the ``hdiutil(1)`` command used to operate on disk image files on
|
||||
|
@ -1,6 +1,8 @@
|
||||
CPack External Generator
|
||||
------------------------
|
||||
|
||||
.. versionadded:: 3.13
|
||||
|
||||
CPack provides many generators to create packages for a variety of platforms
|
||||
and packaging systems. The intention is for CMake/CPack to be a complete
|
||||
end-to-end solution for building and packaging a software project. However, it
|
||||
@ -281,3 +283,12 @@ Variables specific to CPack External generator
|
||||
It is invoked after (optional) staging took place and may
|
||||
run an external packaging tool. The script has access to
|
||||
the variables defined by the CPack config file.
|
||||
|
||||
.. variable:: CPACK_EXTERNAL_BUILT_PACKAGES
|
||||
|
||||
.. versionadded:: 3.19
|
||||
|
||||
The ``CPACK_EXTERNAL_PACKAGE_SCRIPT`` script may set this list variable to the
|
||||
full paths of generated package files. CPack will copy these files from the
|
||||
staging directory back to the top build directory and possibly produce
|
||||
checksum files if the :variable:`CPACK_PACKAGE_CHECKSUM` is set.
|
||||
|
@ -1,12 +1,15 @@
|
||||
CPack FreeBSD Generator
|
||||
-----------------------
|
||||
|
||||
.. versionadded:: 3.10
|
||||
|
||||
The built in (binary) CPack FreeBSD (pkg) generator (Unix only)
|
||||
|
||||
Variables affecting the CPack FreeBSD (pkg) generator
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
- :variable:`CPACK_ARCHIVE_THREADS`
|
||||
- .. versionadded:: 3.18
|
||||
:variable:`CPACK_ARCHIVE_THREADS`
|
||||
|
||||
Variables specific to CPack FreeBSD (pkg) generator
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
@ -71,7 +74,7 @@ the RPM information (e.g. package license).
|
||||
* Default:
|
||||
|
||||
- :variable:`CPACK_DEBIAN_PACKAGE_DESCRIPTION` (this may be set already
|
||||
for Debian packaging, so we may as well re-use it).
|
||||
for Debian packaging, so it is used as a fallback).
|
||||
|
||||
.. variable:: CPACK_FREEBSD_PACKAGE_WWW
|
||||
|
||||
@ -84,7 +87,10 @@ the RPM information (e.g. package license).
|
||||
|
||||
- :variable:`CMAKE_PROJECT_HOMEPAGE_URL`, or if that is not set,
|
||||
:variable:`CPACK_DEBIAN_PACKAGE_HOMEPAGE` (this may be set already
|
||||
for Debian packaging, so we may as well re-use it).
|
||||
for Debian packaging, so it is used as a fallback).
|
||||
|
||||
.. versionadded:: 3.12
|
||||
The ``CMAKE_PROJECT_HOMEPAGE_URL`` variable.
|
||||
|
||||
.. variable:: CPACK_FREEBSD_PACKAGE_LICENSE
|
||||
|
||||
|
@ -1,6 +1,8 @@
|
||||
CPack IFW Generator
|
||||
-------------------
|
||||
|
||||
.. versionadded:: 3.1
|
||||
|
||||
Configure and run the Qt Installer Framework to generate a Qt installer.
|
||||
|
||||
.. only:: html
|
||||
@ -35,6 +37,8 @@ Debug
|
||||
|
||||
.. variable:: CPACK_IFW_VERBOSE
|
||||
|
||||
.. versionadded:: 3.3
|
||||
|
||||
Set to ``ON`` to enable addition debug output.
|
||||
By default is ``OFF``.
|
||||
|
||||
@ -71,41 +75,59 @@ Package
|
||||
|
||||
.. variable:: CPACK_IFW_PACKAGE_WATERMARK
|
||||
|
||||
.. versionadded:: 3.8
|
||||
|
||||
Filename for a watermark is used as QWizard::WatermarkPixmap.
|
||||
|
||||
.. variable:: CPACK_IFW_PACKAGE_BANNER
|
||||
|
||||
.. versionadded:: 3.8
|
||||
|
||||
Filename for a banner is used as QWizard::BannerPixmap.
|
||||
|
||||
.. variable:: CPACK_IFW_PACKAGE_BACKGROUND
|
||||
|
||||
.. versionadded:: 3.8
|
||||
|
||||
Filename for an image used as QWizard::BackgroundPixmap (only used by MacStyle).
|
||||
|
||||
.. variable:: CPACK_IFW_PACKAGE_WIZARD_STYLE
|
||||
|
||||
.. versionadded:: 3.8
|
||||
|
||||
Wizard style to be used ("Modern", "Mac", "Aero" or "Classic").
|
||||
|
||||
.. variable:: CPACK_IFW_PACKAGE_STYLE_SHEET
|
||||
|
||||
Filename for a stylesheet.
|
||||
|
||||
.. variable:: CPACK_IFW_PACKAGE_WIZARD_DEFAULT_WIDTH
|
||||
|
||||
.. versionadded:: 3.8
|
||||
|
||||
Default width of the wizard in pixels. Setting a banner image will override this.
|
||||
|
||||
.. variable:: CPACK_IFW_PACKAGE_WIZARD_DEFAULT_HEIGHT
|
||||
|
||||
.. versionadded:: 3.8
|
||||
|
||||
Default height of the wizard in pixels. Setting a watermark image will override this.
|
||||
|
||||
.. variable:: CPACK_IFW_PACKAGE_WIZARD_SHOW_PAGE_LIST
|
||||
|
||||
.. versionadded:: 3.20
|
||||
|
||||
Set to ``OFF`` if the widget listing installer pages on the left side of the wizard should not be shown.
|
||||
|
||||
It is ``ON`` by default, but will only have an effect if using QtIFW 4.0 or later.
|
||||
|
||||
.. variable:: CPACK_IFW_PACKAGE_TITLE_COLOR
|
||||
|
||||
.. versionadded:: 3.8
|
||||
|
||||
Color of the titles and subtitles (takes an HTML color code, such as "#88FF33").
|
||||
|
||||
.. variable:: CPACK_IFW_PACKAGE_START_MENU_DIRECTORY
|
||||
.. variable:: CPACK_IFW_PACKAGE_STYLE_SHEET
|
||||
|
||||
Name of the default program group for the product in the Windows Start menu.
|
||||
.. versionadded:: 3.15
|
||||
|
||||
By default used :variable:`CPACK_IFW_PACKAGE_NAME`.
|
||||
Filename for a stylesheet.
|
||||
|
||||
.. variable:: CPACK_IFW_TARGET_DIRECTORY
|
||||
|
||||
@ -123,6 +145,14 @@ Package
|
||||
|
||||
You can use predefined variables.
|
||||
|
||||
.. variable:: CPACK_IFW_PACKAGE_REMOVE_TARGET_DIR
|
||||
|
||||
.. versionadded:: 3.11
|
||||
|
||||
Set to ``OFF`` if the target directory should not be deleted when uninstalling.
|
||||
|
||||
Is ``ON`` by default
|
||||
|
||||
.. variable:: CPACK_IFW_PACKAGE_GROUP
|
||||
|
||||
The group, which will be used to configure the root package
|
||||
@ -132,43 +162,57 @@ Package
|
||||
The root package name, which will be used if configuration group is not
|
||||
specified
|
||||
|
||||
.. variable:: CPACK_IFW_PACKAGE_START_MENU_DIRECTORY
|
||||
|
||||
.. versionadded:: 3.3
|
||||
|
||||
Name of the default program group for the product in the Windows Start menu.
|
||||
|
||||
By default used :variable:`CPACK_IFW_PACKAGE_NAME`.
|
||||
|
||||
.. variable:: CPACK_IFW_PACKAGE_MAINTENANCE_TOOL_NAME
|
||||
|
||||
.. versionadded:: 3.3
|
||||
|
||||
Filename of the generated maintenance tool.
|
||||
The platform-specific executable file extension is appended.
|
||||
|
||||
By default used QtIFW defaults (``maintenancetool``).
|
||||
|
||||
.. variable:: CPACK_IFW_PACKAGE_REMOVE_TARGET_DIR
|
||||
|
||||
Set to ``OFF`` if the target directory should not be deleted when uninstalling.
|
||||
|
||||
Is ``ON`` by default
|
||||
|
||||
.. variable:: CPACK_IFW_PACKAGE_MAINTENANCE_TOOL_INI_FILE
|
||||
|
||||
.. versionadded:: 3.3
|
||||
|
||||
Filename for the configuration of the generated maintenance tool.
|
||||
|
||||
By default used QtIFW defaults (``maintenancetool.ini``).
|
||||
|
||||
.. variable:: CPACK_IFW_PACKAGE_ALLOW_NON_ASCII_CHARACTERS
|
||||
|
||||
.. versionadded:: 3.3
|
||||
|
||||
Set to ``ON`` if the installation path can contain non-ASCII characters.
|
||||
|
||||
Is ``ON`` for QtIFW less 2.0 tools.
|
||||
|
||||
.. variable:: CPACK_IFW_PACKAGE_ALLOW_SPACE_IN_PATH
|
||||
|
||||
.. versionadded:: 3.3
|
||||
|
||||
Set to ``OFF`` if the installation path cannot contain space characters.
|
||||
|
||||
Is ``ON`` for QtIFW less 2.0 tools.
|
||||
|
||||
.. variable:: CPACK_IFW_PACKAGE_CONTROL_SCRIPT
|
||||
|
||||
.. versionadded:: 3.3
|
||||
|
||||
Filename for a custom installer control script.
|
||||
|
||||
.. variable:: CPACK_IFW_PACKAGE_RESOURCES
|
||||
|
||||
.. versionadded:: 3.7
|
||||
|
||||
List of additional resources ('.qrc' files) to include in the installer
|
||||
binary.
|
||||
|
||||
@ -177,6 +221,8 @@ Package
|
||||
|
||||
.. variable:: CPACK_IFW_PACKAGE_FILE_EXTENSION
|
||||
|
||||
.. versionadded:: 3.10
|
||||
|
||||
The target binary extension.
|
||||
|
||||
On Linux, the name of the target binary is automatically extended with
|
||||
@ -216,6 +262,8 @@ Components
|
||||
|
||||
.. variable:: CPACK_IFW_REPOSITORIES_DIRECTORIES
|
||||
|
||||
.. versionadded:: 3.10
|
||||
|
||||
Additional prepared repository dirs that will be used to resolve and
|
||||
repack dependent components. This feature available only
|
||||
since QtIFW 3.1.
|
||||
@ -225,12 +273,20 @@ QtIFW Tools
|
||||
|
||||
.. variable:: CPACK_IFW_FRAMEWORK_VERSION
|
||||
|
||||
.. versionadded:: 3.3
|
||||
|
||||
The version of used QtIFW tools.
|
||||
|
||||
The following variables provide the locations of the QtIFW
|
||||
command-line tools as discovered by the module :module:`CPackIFW`.
|
||||
These variables are cached, and may be configured if needed.
|
||||
|
||||
.. variable:: CPACK_IFW_ARCHIVEGEN_EXECUTABLE
|
||||
|
||||
.. versionadded:: 3.19
|
||||
|
||||
The path to ``archivegen``.
|
||||
|
||||
.. variable:: CPACK_IFW_BINARYCREATOR_EXECUTABLE
|
||||
|
||||
The path to ``binarycreator``.
|
||||
@ -256,6 +312,8 @@ the path may be specified in either a CMake or an environment variable:
|
||||
|
||||
.. variable:: CPACK_IFW_ROOT
|
||||
|
||||
.. versionadded:: 3.9
|
||||
|
||||
An CMake variable which specifies the location of the QtIFW tool suite.
|
||||
|
||||
The variable will be cached in the ``CPackConfig.cmake`` file and used at
|
||||
@ -302,6 +360,8 @@ these files accessible from a download URL.
|
||||
Internationalization
|
||||
""""""""""""""""""""
|
||||
|
||||
.. versionadded:: 3.9
|
||||
|
||||
Some variables and command arguments support internationalization via
|
||||
CMake script. This is an optional feature.
|
||||
|
||||
|
Some files were not shown because too many files have changed in this diff Show More
Loading…
x
Reference in New Issue
Block a user