Commit 503ac624 authored by Daniel Schmidt's avatar Daniel Schmidt

Merge branch 'master' of

parents e93413b9 8c704cfa
Pipeline #138544 passed with stage
......@@ -31,11 +31,11 @@ syn region cmakeGeneratorExpression start="$<" end=">" contained oneline contain
syn region cmakeString start='"' end='"' contained contains=cmakeTodo,cmakeVariableValue,cmakeEscaped
syn region cmakeVariableValue start="${" end="}" contained oneline contains=cmakeVariable,cmakeTodo
syn region cmakeVariableValue start="${" end="}" contained oneline contains=cmakeVariable,cmakeTodo,cmakeVariableValue
syn region cmakeEnvironment start="$ENV{" end="}" contained oneline contains=cmakeTodo
syn region cmakeArguments start="(" end=")" contains=ALLBUT,cmakeCommand,cmakeCommandConditional,cmakeCommandRepeat,cmakeCommandDeprecated,cmakeCommandManuallyAdded,cmakeArguments,cmakeTodo
syn region cmakeArguments start="(" end=")" contains=ALLBUT,cmakeGeneratorExpressions,cmakeCommand,cmakeCommandConditional,cmakeCommandRepeat,cmakeCommandDeprecated,cmakeCommandManuallyAdded,cmakeArguments,cmakeTodo
syn case match
......@@ -13,6 +13,9 @@ my @properties;
my @modules;
my %keywords; # command => keyword-list
# find cmake/Modules/ | sed -rn 's/.*CMakeDetermine(.+)Compiler.cmake/\1/p' | sort
my @languages = qw(ASM ASM_MASM ASM_NASM C CSharp CUDA CXX Fortran Java RC Swift);
# unwanted upper-cases
my %unwanted = map { $_ => 1 } qw(VS CXX IDE NOTFOUND NO_ DFOO DBAR NEW);
# cannot remove ALL - exists for add_custom_command
......@@ -30,8 +33,21 @@ push @modules, "ExternalProject";
# variables
open(CMAKE, "$cmake --help-variable-list|") or die "could not run cmake";
while (<CMAKE>) {
next if /\</; # skip if containing < or >
if (/<(.*?)>/) {
if ($1 eq 'LANG') {
foreach my $lang (@languages) {
(my $V = $_) =~ s/<.*>/$lang/;
push @variables, $V;
} else {
next; # skip if containing < or >
push @variables, $_;
This diff is collapsed.
# Distributed under the OSI-approved BSD 3-Clause License. See accompanying
# file Copyright.txt or for details.
cmake_minimum_required(VERSION 3.1...3.12 FATAL_ERROR)
cmake_minimum_required(VERSION 3.1...3.14 FATAL_ERROR)
......@@ -822,4 +822,10 @@ if(NOT CMake_TEST_EXTERNAL_CMAKE)
# Install auxiliary files integrating with other tools.
# Optionally sign installed binaries.
configure_file(Source/ Source/CMakeInstallSignTool.cmake @ONLY)
install(SCRIPT ${CMAKE_CURRENT_BINARY_DIR}/Source/CMakeInstallSignTool.cmake)
......@@ -8,11 +8,16 @@ if(WIN32 AND CMAKE_C_COMPILER_ID STREQUAL "Intel")
# Disable deprecation warnings for standard C functions.
# really only needed for newer versions of VS, but should
# not hurt other versions, and this will work into the
# future
......@@ -21,6 +26,10 @@ if(MSVC)
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -Xlinker -stack:20000000")
#silence duplicate symbol warnings on AIX
......@@ -23,6 +23,7 @@ The first signature is for adding a custom command to produce an output:
[COMMENT comment]
[DEPFILE depfile]
[JOB_POOL job_pool]
......@@ -144,6 +145,13 @@ The options are:
Note that the ``IMPLICIT_DEPENDS`` option is currently supported
only for Makefile generators and will be ignored by other generators.
Specify a :prop_gbl:`pool <JOB_POOLS>` for the :generator:`Ninja`
generator. Incompatible with ``USES_TERMINAL``, which implies
the ``console`` pool.
Using a pool that is not defined by :prop_gbl:`JOB_POOLS` causes
an error by ninja at build time.
Specify the primary input source file to the command. This is
treated just like any value given to the ``DEPENDS`` option
......@@ -11,6 +11,7 @@ Add a target with no output so it will always be built.
[BYPRODUCTS [files...]]
[COMMENT comment]
[JOB_POOL job_pool]
[SOURCES src1 [src2...]])
......@@ -97,6 +98,13 @@ The options are:
to be properly expanded.
Specify a :prop_gbl:`pool <JOB_POOLS>` for the :generator:`Ninja`
generator. Incompatible with ``USES_TERMINAL``, which implies
the ``console`` pool.
Using a pool that is not defined by :prop_gbl:`JOB_POOLS` causes
an error by ninja at build time.
Specify additional source files to be included in the custom target.
Specified source files will be added to IDE project files for
......@@ -94,6 +94,12 @@ The most important properties are:
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
......@@ -292,7 +292,8 @@ 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.
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.
......@@ -311,6 +312,7 @@ Create the given directories and their parents as needed.
[FILE_PERMISSIONS <permissions>...]
[DIRECTORY_PERMISSIONS <permissions>...]
[[PATTERN <pattern> | REGEX <regex>]
[EXCLUDE] [PERMISSIONS <permissions>...]] [...])
......@@ -324,6 +326,32 @@ 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:
* ``/opt/foo/lib/``
* ``/opt/foo/lib/ ->``
* ``/opt/foo/lib/ ->``
* ``/opt/foo/lib/ ->``
and you do:
.. code-block:: cmake
This will install all of the symlinks and ```` itself into
See the :command:`install(DIRECTORY)` command for documentation of
permissions, ``FILES_MATCHING``, ``PATTERN``, ``REGEX``, and
``EXCLUDE`` options. Copying directories preserves the structure
......@@ -59,6 +59,13 @@ for finding the package, checking the version, and producing any needed
messages. Some find-modules provide limited or no support for versioning;
check the module documentation.
If the ``MODULE`` option is not specfied in the above signature,
CMake first searches for the package using Module mode. Then, if the
package is not found, it searches again using Config mode. A user
may set the variable :variable:`CMAKE_FIND_PACKAGE_PREFER_CONFIG` to
``TRUE`` to direct CMake first search using Config mode before falling
back to Module mode.
Full Signature and Config Mode
......@@ -660,9 +660,9 @@ and installed by the current project. For example, the code
install(TARGETS myexe EXPORT myproj DESTINATION bin)
install(EXPORT myproj NAMESPACE mp_ DESTINATION lib/myproj)
install(EXPORT_ANDROID_MK myexp DESTINATION share/ndk-modules)
install(EXPORT_ANDROID_MK myproj DESTINATION share/ndk-modules)
will install the executable myexe to ``<prefix>/bin`` and code to import
will install the executable ``myexe`` to ``<prefix>/bin`` and code to import
it in the file ``<prefix>/lib/myproj/myproj.cmake`` and
``<prefix>/share/ndk-modules/``. An outside project
may load this file with the include command and reference the ``myexe``
......@@ -188,12 +188,6 @@ Update ``Source/CMakeVersion.cmake`` to set the version to
set(CMake_VERSION_RC 1)
Update ``Utilities/Release/upload_release.cmake``:
.. code-block:: cmake
set(VERSION $ver)
Update uses of ``DEVEL_CMAKE_VERSION`` in the source tree to mention the
actual version number:
......@@ -377,7 +377,15 @@ command is needed to stage it again.
A MR may be resolved in one of the following ways.
The workflow used by the CMake project supports a number of different
ways in which a MR can be moved to a resolved state. In addition to
the conventional practices of merging or closing a MR without merging it,
a MR can also be moved to a quasi-resolved state pending some action.
This may involve moving discussion to an issue or it may be the result of
an extended period of inactivity. These quasi-resolved states are used
to help manage the relatively large number of MRs the project receives
and are not an indication of the changes being rejected. The following
sections explain the different resolutions a MR may be given.
......@@ -433,15 +441,68 @@ Close
If review has concluded that the MR should not be integrated then it
may be closed through GitLab.
may be closed through GitLab. This would normally be a final state
with no expectation that the MR would be re-opened in the future.
It is also used when a MR is being superseded by another separate one,
in which case a reference to the new MR should be added to the MR being
If progress on a MR has stalled for a while, it may be closed with a
``workflow:expired`` label and a comment indicating that the MR has
been closed due to inactivity.
Contributors are welcome to re-open an expired MR when they are ready
to continue work. Please re-open *before* pushing an update to the
MR topic branch to ensure GitLab will still act on the association.
been closed due to inactivity (it may also be done where the MR is blocked
for an extended period by work in a different MR). This is not an
indication that there is a problem with the MR's content, it is only a
practical measure to allow the reviewers to focus attention on MRs that
are actively being worked on. As a guide, the average period of inactivity
before transitioning a MR to the expired state would be around 2 weeks,
but this may decrease to 1 week or less when there is a high number of
open merge requests.
Reviewers would usually provide a message similar to the following when
resolving a MR as expired::
Closing for now. @<MR-author> please re-open when ready to continue work.
This is to make it clear to contributors that they are welcome to re-open
the expired MR when they are ready to return to working on it and moving
it forward. In the meantime, the MR will appear as ``Closed`` in GitLab,
but it can be differentiated from permanently closed MRs by the presence
of the ``workflow:expired`` label.
**NOTE:** Please re-open *before* pushing an update to the MR topic branch
to ensure GitLab will still act on the association. If changes are pushed
before re-opening the MR, the reviewer should initiate a ``Do: check`` to
force GitLab to act on the updates.
External Discussion
In some situations, a series of comments on a MR may develop into a more
involved discussion, or it may become apparent that there are broader
discussions that need to take place before the MR can move forward in an
agreed direction. Such discussions are better suited to GitLab issues
rather than in a MR because MRs may be superseded by a different MR, or
the set of changes may evolve to look quite different to the context in
which the discussions began. When this occurs, reviewers may ask the
MR author to open an issue to discuss things there and they will transition
the MR to a resolved state with the label ``workflow:external-discussion``.
The MR will appear in GitLab as closed, but it can be differentiated from
permanently closed MRs by the presence of the ``workflow:external-discussion``
label. Reviewers should leave a message clearly explaining the action
so that the MR author understands that the MR closure is temporary and
it is clear what actions need to happen next. The following is an example
of such a message, but it will usually be necessary to tailor the message
to the individual situation::
The desired behavior here looks to be more involved than first thought.
Please open an issue so we can discuss the relevant details there.
Once the path forward is clear, we can re-open this MR and continue work.
When the discussion in the associated issue runs its course and the way
forward is clear, the MR can be re-opened again and the
``workflow:external-discussion`` label removed. Reviewers should ensure
that the issue created contains a reference to the MR so that GitLab
provides a cross-reference to link the two.
.. include:: ENV_VAR.txt
Specifies the CMake default generator to use when no generator is supplied
with ``-G``. If the provided value doesn't name a generator known by CMake,
the internal default is used. Either way the resulting generator selection
is stored in the :variable:`CMAKE_GENERATOR` variable.
Some generators may be additionally configured using the environment
.. include:: ENV_VAR.txt
Default value for :variable:`CMAKE_GENERATOR_INSTANCE` if no Cache entry is
present. This value is only applied if :envvar:`CMAKE_GENERATOR` is set.
.. include:: ENV_VAR.txt
Default value for :variable:`CMAKE_GENERATOR_PLATFORM` if no Cache entry
is present and no value is specified by :manual:`cmake(1)` ``-A`` option.
This value is only applied if :envvar:`CMAKE_GENERATOR` is set.
.. include:: ENV_VAR.txt
Default value for :variable:`CMAKE_GENERATOR_TOOLSET` if no Cache entry
is present and no value is specified by :manual:`cmake(1)` ``-T`` option.
This value is only applied if :envvar:`CMAKE_GENERATOR` is set.
.. include:: ENV_VAR.txt
Preferred executable for compiling ``Swift`` language files. Will only be used by
CMake on the first configuration to determine ``Swift`` compiler, after which the
value for ``SWIFTC`` is stored in the cache as
:variable:`CMAKE_Swift_COMPILER <CMAKE_<LANG>_COMPILER>`. For any configuration run
(including the first), the environment variable will be ignored if the