16 files changed, 295 insertions, 70 deletions
diff --git a/Help/command/if.rst b/Help/command/if.rst
index 72d328d..c51d2bc 100644
--- a/Help/command/if.rst
+++ b/Help/command/if.rst
@@ -47,7 +47,8 @@ as ``EXISTS``, ``COMMAND``, and ``DEFINED``.  Then binary tests such as
 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,6 +63,9 @@ 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
+"""""""""""""""
+
 ``if(NOT <condition>)``
  True if the condition is not true.
 
@@ -71,6 +75,15 @@ Possible conditions are:
 ``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
+""""""""""""""""
+
 ``if(COMMAND command-name)``
  True if the given name is a command, macro or function that can be
  invoked.
@@ -89,6 +102,21 @@ Possible conditions are:
   True if the given name is an existing test name created by the
   :command:`add_test` command.
 
+``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
+"""""""""""""""
+
 ``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
@@ -114,6 +142,9 @@ Possible conditions are:
 ``if(IS_ABSOLUTE path)``
  True if the given path is an absolute path.
 
+Comparisons
+"""""""""""
+
 ``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.
@@ -165,6 +196,9 @@ Possible conditions are:
   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
+"""""""""""""""""""
+
 ``if(<variable|string> VERSION_LESS <variable|string>)``
  Component-wise integer version number comparison (version format is
  ``major[.minor[.patch[.tweak]]]``, omitted components are treated as zero).
@@ -197,24 +231,6 @@ Possible conditions are:
   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>)``
- .. versionadded:: 3.3
-  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.
-
- .. versionadded:: 3.14
-  Added support for ``CACHE{<name>}`` 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.
-
 Variable Expansion
 ^^^^^^^^^^^^^^^^^^
 
diff --git a/Help/command/install.rst b/Help/command/install.rst
index bd8da39..35207f4 100644
--- a/Help/command/install.rst
+++ b/Help/command/install.rst
@@ -473,6 +473,11 @@ this advice while installing headers to a project-specific subdirectory:
   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
 ^^^^^^^^^^^^^^^^^^^^^^
 
diff --git a/Help/dev/experimental.rst b/Help/dev/experimental.rst
index 4d2b076..d019161 100644
--- a/Help/dev/experimental.rst
+++ b/Help/dev/experimental.rst
@@ -7,4 +7,64 @@ See documentation on `CMake Development`_ for more information.
 
 .. _`CMake Development`: README.rst
 
-No experimental features are under development in this version of CMake.
+C++20 Module Dependencies
+=========================
+
+The Ninja generator has experimental infrastructure supporting C++20 module
+dependency scanning.  This is similar to the Fortran modules support, but
+relies on external tools to scan C++20 translation units for module
+dependencies.  The approach is described by Kitware's `D1483r1`_ paper.
+
+The ``CMAKE_EXPERIMENTAL_CXX_MODULE_DYNDEP`` variable can be set to ``1``
+in order to activate this undocumented experimental infrastructure.  This
+is **intended to make the functionality available to compiler writers** so
+they can use it to develop and test their dependency scanning tool.
+The ``CMAKE_EXPERIMENTAL_CXX_SCANDEP_SOURCE`` variable must also be set
+to tell CMake how to invoke the C++20 module dependency scanning tool.
+
+For example, add code like the following to a test project:
+
+.. code-block:: cmake
+
+  set(CMAKE_EXPERIMENTAL_CXX_MODULE_DYNDEP 1)
+  string(CONCAT CMAKE_EXPERIMENTAL_CXX_SCANDEP_SOURCE
+    "<CMAKE_CXX_COMPILER> <DEFINES> <INCLUDES> <FLAGS> <SOURCE>"
+    " -MT <DYNDEP_FILE> -MD -MF <DEP_FILE>"
+    " ${flags_to_scan_deps} -fdep-file=<DYNDEP_FILE> -fdep-output=<OBJECT>"
+    )
+
+The tool specified by ``CMAKE_EXPERIMENTAL_CXX_SCANDEP_SOURCE`` is
+expected to process the translation unit, write preprocessor dependencies
+to the file specified by the ``<DEP_FILE>`` placeholder, and write module
+dependencies to the file specified by the ``<DYNDEP_FILE>`` placeholder.
+
+The module dependencies should be written in the format described
+by the `P1689r3`_ paper.
+
+Compiler writers may try out their scanning functionality using
+the `cxx-modules-sandbox`_ test project, modified to set variables
+as above for their compiler.
+
+For compilers that generate module maps, tell CMake as follows:
+
+.. code-block:: cmake
+
+  set(CMAKE_EXPERIMENTAL_CXX_MODULE_MAP_FORMAT "gcc")
+  set(CMAKE_EXPERIMENTAL_CXX_MODULE_MAP_FLAG
+    "${compiler_flags_for_module_map} -fmodule-mapper=<MODULE_MAP_FILE>")
+
+Currently, the only supported format is ``gcc``.  The format is described in
+the GCC documentation, but the relevant section for the purposes of CMake is:
+
+    A mapping file consisting of space-separated module-name, filename
+    pairs, one per line.  Only the mappings for the direct imports and any
+    module export name need be provided.  If other mappings are provided,
+    they override those stored in any imported CMI files.  A repository
+    root may be specified in the mapping file by using ``$root`` as the
+    module name in the first active line.
+
+    -- GCC module mapper documentation
+
+.. _`D1483r1`: https://mathstuf.fedorapeople.org/fortran-modules/fortran-modules.html
+.. _`P1689r3`: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1689r3.html
+.. _`cxx-modules-sandbox`: https://github.com/mathstuf/cxx-modules-sandbox
diff --git a/Help/generator/Ninja Multi-Config.rst b/Help/generator/Ninja Multi-Config.rst
index d1df42b..8901192 100644
--- a/Help/generator/Ninja Multi-Config.rst
+++ b/Help/generator/Ninja Multi-Config.rst
@@ -130,3 +130,34 @@ output config using the ``Release`` command config. The ``Release`` build of
 the ``generator`` target is called with ``Debug.txt Debug Release`` as
 arguments. The command depends on the ``Release`` builds of ``tgt1`` and
 ``tgt4``, and the ``Debug`` builds of ``tgt2`` and ``tgt3``.
+
+``PRE_BUILD``, ``PRE_LINK``, and ``POST_BUILD`` custom commands for targets
+only get run in their "native" configuration (the ``Release`` configuration in
+the ``build-Release.ninja`` file) unless they have no ``BYPRODUCTS`` or their
+``BYPRODUCTS`` are unique per config. Consider the following example:
+
+.. code-block:: cmake
+
+  add_executable(exe main.c)
+  add_custom_command(
+    TARGET exe
+    POST_BUILD
+    COMMAND ${CMAKE_COMMAND} -E echo "Running no-byproduct command"
+    )
+  add_custom_command(
+    TARGET exe
+    POST_BUILD
+    COMMAND ${CMAKE_COMMAND} -E echo "Running separate-byproduct command for $<CONFIG>"
+    BYPRODUCTS $<CONFIG>.txt
+    )
+  add_custom_command(
+    TARGET exe
+    POST_BUILD
+    COMMAND ${CMAKE_COMMAND} -E echo "Running common-byproduct command for $<CONFIG>"
+    BYPRODUCTS exe.txt
+    )
+
+In this example, if you build ``exe:Debug`` in ``build-Release.ninja``, the
+first and second custom commands get run, since their byproducts are unique
+per-config, but the last custom command does not. However, if you build
+``exe:Release`` in ``build-Release.ninja``, all three custom commands get run.
diff --git a/Help/guide/importing-exporting/MathFunctions/CMakeLists.txt b/Help/guide/importing-exporting/MathFunctions/CMakeLists.txt
index 13c82dd..9a9e40e 100644
--- a/Help/guide/importing-exporting/MathFunctions/CMakeLists.txt
+++ b/Help/guide/importing-exporting/MathFunctions/CMakeLists.txt
@@ -31,7 +31,7 @@ install(FILES MathFunctions.h DESTINATION include)
 install(EXPORT MathFunctionsTargets
         FILE MathFunctionsTargets.cmake
         NAMESPACE MathFunctions::
-        DESTINATION lib/cmake
+        DESTINATION lib/cmake/MathFunctions
 )
 
 # include CMakePackageConfigHelpers macro
@@ -58,14 +58,14 @@ write_basic_package_version_file(
 # create config file
 configure_package_config_file(${CMAKE_CURRENT_SOURCE_DIR}/Config.cmake.in
   "${CMAKE_CURRENT_BINARY_DIR}/MathFunctionsConfig.cmake"
-  INSTALL_DESTINATION lib/cmake
+  INSTALL_DESTINATION lib/cmake/MathFunctions
 )
 
 # install config files
 install(FILES
           "${CMAKE_CURRENT_BINARY_DIR}/MathFunctionsConfig.cmake"
           "${CMAKE_CURRENT_BINARY_DIR}/MathFunctionsConfigVersion.cmake"
-        DESTINATION lib/cmake
+        DESTINATION lib/cmake/MathFunctions
 )
 
 # generate the export targets for the build tree
diff --git a/Help/manual/cmake-developer.7.rst b/Help/manual/cmake-developer.7.rst
index 85ed935..af9a8ab 100644
--- a/Help/manual/cmake-developer.7.rst
+++ b/Help/manual/cmake-developer.7.rst
@@ -23,15 +23,14 @@ in turn link to developer guides for CMake itself.
 Find Modules
 ============
 
-A "find module" is a ``Find<PackageName>.cmake`` file to be loaded
-by the :command:`find_package` command when invoked for ``<PackageName>``.
+A "find module" is a ``Find<PackageName>.cmake`` file to be loaded by the
+:command:`find_package` command when invoked for ``<PackageName>``.
 
-The primary task of a find module is to determine whether a package
-exists on the system, set the ``<PackageName>_FOUND`` variable to reflect
-this and provide any variables, macros and imported targets required to
-use the package.  A find module is useful in cases where an upstream
-library does not provide a
-:ref:`config file package <Config File Packages>`.
+The primary task of a find module is to determine whether a package is
+available, set the ``<PackageName>_FOUND`` variable to reflect this and
+provide any variables, macros and imported targets required to use the
+package.  A find module is useful in cases where an upstream library does
+not provide a :ref:`config file package <Config File Packages>`.
 
 The traditional approach is to use variables for everything, including
 libraries and executables: see the `Standard Variable Names`_ section
@@ -91,55 +90,92 @@ Standard Variable Names
 For a ``FindXxx.cmake`` module that takes the approach of setting
 variables (either instead of or in addition to creating imported
 targets), the following variable names should be used to keep things
-consistent between find modules.  Note that all variables start with
-``Xxx_`` to make sure they do not interfere with other find modules; the
-same consideration applies to macros, functions and imported targets.
+consistent between Find modules.  Note that all variables start with
+``Xxx_``, which (unless otherwise noted) must match exactly the name
+of the ``FindXxx.cmake`` file, including upper/lowercase.
+This prefix on the variable names ensures that they do not conflict with
+variables of other Find modules.  The same pattern should also be followed
+for any macros, functions and imported targets defined by the Find module.
 
 ``Xxx_INCLUDE_DIRS``
   The final set of include directories listed in one variable for use by
-  client code.  This should not be a cache entry.
+  client code. This should not be a cache entry (note that this also means
+  this variable should not be used as the result variable of a
+  :command:`find_path` command - see ``Xxx_INCLUDE_DIR`` below for that).
 
 ``Xxx_LIBRARIES``
-  The libraries to link against to use Xxx. These should include full
-  paths.  This should not be a cache entry.
+  The libraries to use with the module.  These may be CMake targets, full
+  absolute paths to a library binary or the name of a library that the
+  linker must find in its search path.  This should not be a cache entry
+  (note that this also means this variable should not be used as the
+  result variable of a :command:`find_library` command - see
+  ``Xxx_LIBRARY`` below for that).
 
 ``Xxx_DEFINITIONS``
-  Definitions to use when compiling code that uses Xxx. This really
-  shouldn't include options such as ``-DHAS_JPEG`` that a client
+  The compile definitions to use when compiling code that uses the module.
+  This really shouldn't include options such as ``-DHAS_JPEG`` that a client
   source-code file uses to decide whether to ``#include <jpeg.h>``
 
 ``Xxx_EXECUTABLE``
-  Where to find the Xxx tool.
-
-``Xxx_Yyy_EXECUTABLE``
-  Where to find the Yyy tool that comes with Xxx.
+  The full absolute path to an executable.  In this case, ``Xxx`` might not
+  be the name of the module, it might be the name of the tool (usually
+  converted to all uppercase), assuming that tool has such a well-known name
+  that it is unlikely that another tool with the same name exists.  It would
+  be appropriate to use this as the result variable of a
+  :command:`find_program` command.
+
+``Xxx_YYY_EXECUTABLE``
+  Similar to ``Xxx_EXECUTABLE`` except here the ``Xxx`` is always the module
+  name and ``YYY`` is the tool name (again, usually fully uppercase).
+  Prefer this form if the tool name is not very widely known or has the
+  potential  to clash with another tool.  For greater consistency, also
+  prefer this form if the module provides more than one executable.
 
 ``Xxx_LIBRARY_DIRS``
   Optionally, the final set of library directories listed in one
-  variable for use by client code.  This should not be a cache entry.
+  variable for use by client code. This should not be a cache entry.
 
 ``Xxx_ROOT_DIR``
-  Where to find the base directory of Xxx.
-
-``Xxx_VERSION_Yy``
-  Expect Version Yy if true. Make sure at most one of these is ever true.
-
-``Xxx_WRAP_Yy``
-  If False, do not try to use the relevant CMake wrapping command.
+  Where to find the base directory of the module.
+
+``Xxx_VERSION_VV``
+  Variables of this form specify whether the ``Xxx`` module being provided
+  is version ``VV`` of the module.  There should not be more than one
+  variable of this form set to true for a given module.  For example, a
+  module ``Barry`` might have evolved over many years and gone through a
+  number of different major versions.  Version 3 of the ``Barry`` module
+  might set the variable ``Barry_VERSION_3`` to true, whereas an older
+  version of the module might set ``Barry_VERSION_2`` to true instead.
+  It would be an error for both ``Barry_VERSION_3`` and ``Barry_VERSION_2``
+  to both be set to true.
+
+``Xxx_WRAP_YY``
+  When a variable of this form is set to false, it indicates that the
+  relevant wrapping command should not be used.  The wrapping command
+  depends on the module, it may be implied by the module name or it might
+  be specified by the ``YY`` part of the variable.
 
 ``Xxx_Yy_FOUND``
-  If False, optional Yy part of Xxx system is not available.
+  For variables of this form, ``Yy`` is the name of a component for the
+  module.  It should match exactly one of the valid component names that
+  may be passed to the :command:`find_package` command for the module.
+  If a variable of this form is set to false, it means that the ``Yy``
+  component of module ``Xxx`` was not found or is not available.
+  Variables of this form would typically be used for optional components
+  so that the caller can check whether an optional component is available.
 
 ``Xxx_FOUND``
-  Set to false, or undefined, if we haven't found, or don't want to use
-  Xxx.
+  When the :command:`find_package` command returns to the caller, this
+  variable will be set to true if the module was deemed to have been found
+  successfully.
 
 ``Xxx_NOT_FOUND_MESSAGE``
   Should be set by config-files in the case that it has set
   ``Xxx_FOUND`` to FALSE.  The contained message will be printed by the
   :command:`find_package` command and by
-  ``find_package_handle_standard_args()`` to inform the user about the
-  problem.
+  :command:`find_package_handle_standard_args` to inform the user about the
+  problem.  Use this instead of calling :command:`message` directly to
+  report a reason for failing to find the module or package.
 
 ``Xxx_RUNTIME_LIBRARY_DIRS``
   Optionally, the runtime library search path for use when running an
@@ -160,23 +196,36 @@ same consideration applies to macros, functions and imported targets.
 ``Xxx_VERSION_PATCH``
   The patch version of the package found, if any.
 
-The following names should not usually be used in CMakeLists.txt files, but
-are typically cache variables for users to edit and control the
-behaviour of find modules (like entering the path to a library manually)
+The following names should not usually be used in ``CMakeLists.txt`` files.
+They are intended for use by Find modules to specify and cache the locations
+of specific files or directories.  Users are typically able to set and edit
+these variables to control the behavior of Find modules (like entering the
+path to a library manually):
 
 ``Xxx_LIBRARY``
-  The path of the Xxx library (as used with :command:`find_library`, for
-  example).
+  The path of the library.  Use this form only when the module provides a
+  single library.  It is appropriate to use this as the result variable
+  in a :command:`find_library` command.
 
 ``Xxx_Yy_LIBRARY``
-  The path of the Yy library that is part of the Xxx system. It may or
-  may not be required to use Xxx.
+  The path of library ``Yy`` provided by the module ``Xxx``.  Use this form
+  when the module provides more than one library or where other modules may
+  also provide a library of the same name. It is also appropriate to use
+  this form as the result variable in a :command:`find_library` command.
 
 ``Xxx_INCLUDE_DIR``
-  Where to find headers for using the Xxx library.
+  When the module provides only a single library, this variable can be used
+  to specify where to find headers for using the library (or more accurately,
+  the path that consumers of the library should add to their header search
+  path).  It would be appropriate to use this as the result variable in a
+  :command:`find_path` command.
 
 ``Xxx_Yy_INCLUDE_DIR``
-  Where to find headers for using the Yy library of the Xxx system.
+  If the module provides more than one library or where other modules may
+  also provide a library of the same name, this form is recommended for
+  specifying where to find headers for using library ``Yy`` provided by
+  the module.  Again, it would be appropriate to use this as the result
+  variable in a :command:`find_path` command.
 
 To prevent users being overwhelmed with settings to configure, try to
 keep as many options as possible out of the cache, leaving at least one
@@ -185,7 +234,8 @@ not-found library (e.g. ``Xxx_ROOT_DIR``).  For the same reason, mark
 most cache options as advanced.  For packages which provide both debug
 and release binaries, it is common to create cache variables with a
 ``_LIBRARY_<CONFIG>`` suffix, such as ``Foo_LIBRARY_RELEASE`` and
-``Foo_LIBRARY_DEBUG``.
+``Foo_LIBRARY_DEBUG``.  The :module:`SelectLibraryConfigurations` module
+can be helpful for such cases.
 
 While these are the standard variable names, you should provide
 backwards compatibility for any old names that were actually in use.
diff --git a/Help/manual/cmake-properties.7.rst b/Help/manual/cmake-properties.7.rst
index 5dbc1a4..af170da 100644
--- a/Help/manual/cmake-properties.7.rst
+++ b/Help/manual/cmake-properties.7.rst
@@ -196,6 +196,7 @@ Properties on Targets
    /prop_tgt/EXCLUDE_FROM_ALL
    /prop_tgt/EXCLUDE_FROM_DEFAULT_BUILD
    /prop_tgt/EXCLUDE_FROM_DEFAULT_BUILD_CONFIG
+   /prop_tgt/EXPORT_COMPILE_COMMANDS
    /prop_tgt/EXPORT_NAME
    /prop_tgt/EXPORT_PROPERTIES
    /prop_tgt/FOLDER
diff --git a/Help/prop_tgt/EXPORT_COMPILE_COMMANDS.rst b/Help/prop_tgt/EXPORT_COMPILE_COMMANDS.rst
new file mode 100644
index 0000000..0b1145c
--- /dev/null
+++ b/Help/prop_tgt/EXPORT_COMPILE_COMMANDS.rst
@@ -0,0 +1,9 @@
+EXPORT_COMPILE_COMMANDS
+-----------------------
+
+.. versionadded:: 3.20
+
+Enable/Disable output of compile commands during generation for a target.
+
+This property is initialized by the value of the variable
+:variable:`CMAKE_EXPORT_COMPILE_COMMANDS` if it is set when a target is created.
diff --git a/Help/release/3.19.rst b/Help/release/3.19.rst
index eb49c6f..7ad27c8 100644
--- a/Help/release/3.19.rst
+++ b/Help/release/3.19.rst
@@ -390,3 +390,13 @@ Changes made since CMake 3.19.0 include the following.
 ------
 
 * A precompiled Linux ``aarch64`` binary is now provided on ``cmake.org``.
+
+* Two precompiled macOS binaries are now provided on ``cmake.org``:
+
+  * The naming pattern ``cmake-$ver-macos-universal`` is a universal
+    binary with ``x86_64`` and ``arm64`` architectures.  It requires
+    macOS 10.13 or newer.
+
+  * The naming pattern ``cmake-$ver-macos10.10-universal`` is a universal
+    binary with ``x86_64`` and ``arm64`` architectures.  It requires
+    macOS 10.10 or newer.
diff --git a/Help/release/dev/cuda-nvcc-ccache-symlink.rst b/Help/release/dev/cuda-nvcc-ccache-symlink.rst
new file mode 100644
index 0000000..4d38047
--- /dev/null
+++ b/Help/release/dev/cuda-nvcc-ccache-symlink.rst
@@ -0,0 +1,9 @@
+cuda-nvcc-ccache-symlink
+------------------------
+
+* ``CUDA`` language support now works when ``nvcc`` is a symbolic link,
+  for example due to a ``ccache`` or ``colornvcc`` wrapper script.
+
+* The :module:`FindCUDAToolkit` module gained support for finding CUDA
+  toolkits when ``nvcc`` is a symbolic link,
+  for example due to a ``ccache`` or ``colornvcc`` wrapper script.
diff --git a/Help/release/dev/export-compile-commands-per-target.rst b/Help/release/dev/export-compile-commands-per-target.rst
new file mode 100644
index 0000000..7063547
--- /dev/null
+++ b/Help/release/dev/export-compile-commands-per-target.rst
@@ -0,0 +1,6 @@
+export-compile-commands-per-target
+----------------------------------
+
+* The :prop_tgt:`EXPORT_COMPILE_COMMANDS` target property was added
+  for the associated :variable:`CMAKE_EXPORT_COMPILE_COMMANDS` variable
+  to allow for configuration of exporting compile commands per target.
diff --git a/Help/release/dev/external-project-configure-handled-by-build.rst b/Help/release/dev/external-project-configure-handled-by-build.rst
new file mode 100644
index 0000000..4a1fac8
--- /dev/null
+++ b/Help/release/dev/external-project-configure-handled-by-build.rst
@@ -0,0 +1,8 @@
+external-project-configure-handled-by-build
+-------------------------------------------
+
+* The :module:`ExternalProject` function ``ExternalProject_Add`` learned a new
+  ``CONFIGURE_HANDLED_BY_BUILD`` option to have subsequent runs of the configure
+  step be triggered by the build step when an external project dependency
+  rebuilds instead of always rerunning the configure step when an external
+  project dependency rebuilds.
diff --git a/Help/release/dev/install-files-rename-genex.rst b/Help/release/dev/install-files-rename-genex.rst
new file mode 100644
index 0000000..f735e24
--- /dev/null
+++ b/Help/release/dev/install-files-rename-genex.rst
@@ -0,0 +1,5 @@
+install-files-rename-genex
+--------------------------
+
+* The :command:`install(FILES)` command ``RENAME`` option learned to
+  support :manual:`generator expressions <cmake-generator-expressions(7)>`.
diff --git a/Help/variable/CMAKE_CUDA_ARCHITECTURES.rst b/Help/variable/CMAKE_CUDA_ARCHITECTURES.rst
index 7f7e679..d885516 100644
--- a/Help/variable/CMAKE_CUDA_ARCHITECTURES.rst
+++ b/Help/variable/CMAKE_CUDA_ARCHITECTURES.rst
@@ -18,3 +18,18 @@ and compiler versions.
 
 This variable is used to initialize the :prop_tgt:`CUDA_ARCHITECTURES` property
 on all targets. See the target property for additional information.
+
+Examples
+^^^^^^^^
+
+.. code-block:: cmake
+
+  cmake_minimum_required(VERSION)
+
+  if(NOT DEFINED CMAKE_CUDA_ARCHITECTURES)
+    set(CMAKE_CUDA_ARCHITECTURES 75)
+  endif()
+
+  project(example LANGUAGES CUDA)
+
+``CMAKE_CUDA_ARCHITECTURES`` will default to ``75`` unless overridden by the user.
diff --git a/Help/variable/CMAKE_EXPORT_COMPILE_COMMANDS.rst b/Help/variable/CMAKE_EXPORT_COMPILE_COMMANDS.rst
index 724f309..53a19dc 100644
--- a/Help/variable/CMAKE_EXPORT_COMPILE_COMMANDS.rst
+++ b/Help/variable/CMAKE_EXPORT_COMPILE_COMMANDS.rst
@@ -28,7 +28,8 @@ form.  The format of the JSON file looks like:
   ]
 
 This is initialized by the :envvar:`CMAKE_EXPORT_COMPILE_COMMANDS` environment
-variable.
+variable, and initializes the :prop_tgt:`EXPORT_COMPILE_COMMANDS` target
+property for all targets.
 
 .. note::
   This option is implemented only by :ref:`Makefile Generators`
diff --git a/Help/variable/MSVC.rst b/Help/variable/MSVC.rst
index ca8775c..a2dbc2e 100644
--- a/Help/variable/MSVC.rst
+++ b/Help/variable/MSVC.rst
@@ -1,8 +1,7 @@
 MSVC
 ----
 
-Set to ``true`` when the compiler is some version of Microsoft Visual
-C++ or another compiler simulating Visual C++.  Any compiler defining
-``_MSC_VER`` is considered simulating Visual C++.
+Set to ``true`` when the compiler is some version of Microsoft Visual C++
+or another compiler simulating the Visual C++ ``cl`` command-line syntax.
 
 See also the :variable:`MSVC_VERSION` variable.