16 files changed, 275 insertions, 218 deletions
diff --git a/Help/command/ctest_test.rst b/Help/command/ctest_test.rst
index 0a33da3..7a3393b 100644
--- a/Help/command/ctest_test.rst
+++ b/Help/command/ctest_test.rst
@@ -17,7 +17,7 @@ Perform the :ref:`CTest Test Step` as a :ref:`Dashboard Client`.
              [EXCLUDE_FIXTURE_SETUP <regex>]
              [EXCLUDE_FIXTURE_CLEANUP <regex>]
              [PARALLEL_LEVEL <level>]
-             [HARDWARE_SPEC_FILE <file>]
+             [RESOURCE_SPEC_FILE <file>]
              [TEST_LOAD <threshold>]
              [SCHEDULE_RANDOM <ON|OFF>]
              [STOP_TIME <time-of-day>]
@@ -83,10 +83,10 @@ The options are:
   Specify a positive number representing the number of tests to
   be run in parallel.
 
-``HARDWARE_SPEC_FILE <file>``
+``RESOURCE_SPEC_FILE <file>``
   Specify a
-  :ref:`hardware specification file <ctest-hardware-specification-file>`. See
-  :ref:`ctest-hardware-allocation` for more information.
+  :ref:`resource specification file <ctest-resource-specification-file>`. See
+  :ref:`ctest-resource-allocation` for more information.
 
 ``TEST_LOAD <threshold>``
   While running tests in parallel, try not to start tests when they
diff --git a/Help/command/target_precompile_headers.rst b/Help/command/target_precompile_headers.rst
index d283948..5ab3766 100644
--- a/Help/command/target_precompile_headers.rst
+++ b/Help/command/target_precompile_headers.rst
@@ -79,6 +79,17 @@ must be available for the compiler to find them.  Other header file names
 source directory (e.g. :variable:`CMAKE_CURRENT_SOURCE_DIR`) and will be
 included by absolute path.
 
+When specifying angle brackets inside a :manual:`generator expression
+<cmake-generator-expressions(7)>`, be sure to encode the closing ``>``
+as ``$<ANGLE-R>``.  For example:
+
+.. code-block:: cmake
+
+  target_precompile_headers(mylib PRIVATE
+    "$<$<COMPILE_LANGUAGE:C>:<stddef.h$<ANGLE-R>>"
+    "$<$<COMPILE_LANGUAGE:CXX>:<cstddef$<ANGLE-R>>"
+    )
+
 See Also
 ^^^^^^^^
 
diff --git a/Help/manual/cmake-properties.7.rst b/Help/manual/cmake-properties.7.rst
index 1369aa3..a59dd6b 100644
--- a/Help/manual/cmake-properties.7.rst
+++ b/Help/manual/cmake-properties.7.rst
@@ -414,10 +414,10 @@ Properties on Tests
    /prop_test/LABELS
    /prop_test/MEASUREMENT
    /prop_test/PASS_REGULAR_EXPRESSION
-   /prop_test/PROCESSES
    /prop_test/PROCESSOR_AFFINITY
    /prop_test/PROCESSORS
    /prop_test/REQUIRED_FILES
+   /prop_test/RESOURCE_GROUPS
    /prop_test/RESOURCE_LOCK
    /prop_test/RUN_SERIAL
    /prop_test/SKIP_REGULAR_EXPRESSION
diff --git a/Help/manual/cpack.1.rst b/Help/manual/cpack.1.rst
index f82c466..395cd41 100644
--- a/Help/manual/cpack.1.rst
+++ b/Help/manual/cpack.1.rst
@@ -55,6 +55,8 @@ Options
   When the CMake project uses a multi-configuration
   generator such as Xcode or Visual Studio, this option is needed to tell
   ``cpack`` which built executables to include in the package.
+  The user is responsible for ensuring that the configuration(s) listed
+  have already been built before invoking ``cpack``.
 
 ``-D <var>=<value>``
   Set a CPack variable.  This will override any value set for ``<var>`` in the
diff --git a/Help/manual/ctest.1.rst b/Help/manual/ctest.1.rst
index a18d43f..dbefb91 100644
--- a/Help/manual/ctest.1.rst
+++ b/Help/manual/ctest.1.rst
@@ -90,14 +90,14 @@ Options
 
  See `Label and Subproject Summary`_.
 
-``--hardware-spec-file <file>``
- Run CTest with :ref:`hardware allocation <ctest-hardware-allocation>` enabled,
+``--resource-spec-file <file>``
+ Run CTest with :ref:`resource allocation <ctest-resource-allocation>` enabled,
  using the
- :ref:`hardware specification file <ctest-hardware-specification-file>`
+ :ref:`resource specification file <ctest-resource-specification-file>`
  specified in ``<file>``.
 
  When ``ctest`` is run as a `Dashboard Client`_ this sets the
- ``HardwareSpecFile`` option of the `CTest Test Step`_.
+ ``ResourceSpecFile`` option of the `CTest Test Step`_.
 
 ``--test-load <level>``
  While running tests in parallel (e.g. with ``-j``), try not to start
@@ -967,10 +967,10 @@ Arguments to the command may specify some of the step settings.
 
 Configuration settings include:
 
-``HardwareSpecFile``
+``ResourceSpecFile``
   Specify a
-  :ref:`hardware specification file <ctest-hardware-specification-file>`. See
-  :ref:`ctest-hardware-allocation` for more information.
+  :ref:`resource specification file <ctest-resource-specification-file>`. See
+  :ref:`ctest-resource-allocation` for more information.
 
 ``LabelsForSubprojects``
   Specify a semicolon-separated list of labels that will be treated as
@@ -1281,22 +1281,22 @@ model is defined as follows:
     Test properties.
     Can contain keys for each of the supported test properties.
 
-.. _`ctest-hardware-allocation`:
+.. _`ctest-resource-allocation`:
 
-Hardware Allocation
+Resource Allocation
 ===================
 
-CTest provides a mechanism for tests to specify the hardware that they need and
-how much of it they need, and for users to specify the hardware availiable on
+CTest provides a mechanism for tests to specify the resources that they need
+in a fine-grained way, and for users to specify the resources availiable on
 the running machine. This allows CTest to internally keep track of which
-hardware is in use and which is free, scheduling tests in a way that prevents
-them from trying to claim hardware that is not available.
+resources are in use and which are free, scheduling tests in a way that
+prevents them from trying to claim resources that are not available.
 
 A common use case for this feature is for tests that require the use of a GPU.
 Multiple tests can simultaneously allocate memory from a GPU, but if too many
 tests try to do this at once, some of them will fail to allocate, resulting in
 a failed test, even though the test would have succeeded if it had the memory
-it needed. By using the hardware allocation feature, each test can specify how
+it needed. By using the resource allocation feature, each test can specify how
 much memory it requires from a GPU, allowing CTest to schedule tests in a way
 that running several of these tests at once does not exhaust the GPU's memory
 pool.
@@ -1312,36 +1312,35 @@ When a test is executed, and slots from a resource are allocated to that test,
 tests may assume that they have exclusive use of those slots for the duration
 of the test's process.
 
-The CTest hardware allocation feature consists of two inputs:
+The CTest resource allocation feature consists of two inputs:
 
-* The :ref:`hardware specification file <ctest-hardware-specification-file>`,
-  described below, which describes the hardware resources available on the
-  system, and
-* The :prop_test:`PROCESSES` property of tests, which describes the resources
-  required by the test
+* The :ref:`resource specification file <ctest-resource-specification-file>`,
+  described below, which describes the resources available on the system.
+* The :prop_test:`RESOURCE_GROUPS` property of tests, which describes the
+  resources required by the test.
 
-When CTest runs a test, the hardware allocated to that test is passed in the
+When CTest runs a test, the resources allocated to that test are passed in the
 form of a set of
-:ref:`environment variables <ctest-hardware-environment-variables>` as
+:ref:`environment variables <ctest-resource-environment-variables>` as
 described below. Using this information to decide which resource to connect to
 is left to the test writer.
 
-Please note that these processes are not spawned by CTest. The ``PROCESSES``
-property merely tells CTest what processes the test expects to launch. It is up
-to the test itself to do this process spawning, and read the :ref:`environment
-variables <ctest-hardware-environment-variables>` to determine which resources
-each process has been allocated.
+The ``RESOURCE_GROUPS`` property tells CTest what resources a test expects
+to use grouped in a way meaningful to the test.  The test itself must read
+the :ref:`environment variables <ctest-resource-environment-variables>` to
+determine which resources have been allocated to each group.  For example,
+each group may correspond to a process the test will spawn when executed.
 
-.. _`ctest-hardware-specification-file`:
+.. _`ctest-resource-specification-file`:
 
-Hardware Specification File
+Resource Specification File
 ---------------------------
 
-The hardware specification file is a JSON file which is passed to CTest, either
-on the :manual:`ctest(1)` command line as ``--hardware-spec-file``, or as the
-``HARDWARE_SPEC_FILE`` argument of :command:`ctest_test`. The hardware
+The resource specification file is a JSON file which is passed to CTest, either
+on the :manual:`ctest(1)` command line as ``--resource-spec-file``, or as the
+``RESOURCE_SPEC_FILE`` argument of :command:`ctest_test`. The resource
 specification file must be a JSON object. All examples in this document assume
-the following hardware specification file:
+the following resource specification file:
 
 .. code-block:: json
 
@@ -1378,11 +1377,11 @@ the following hardware specification file:
 The members are:
 
 ``local``
-  A JSON array consisting of CPU sockets present on the system. Currently, only
-  one socket is supported.
+  A JSON array of resource sets present on the system.  Currently, this array
+  is restricted to being of size 1.
 
-  Each socket is a JSON object with members whose names are equal to the
-  desired resource types, such as ``gpu``. These names must start with a
+  Each array element is a JSON object with members whose names are equal to the
+  desired resource types, such as ``gpus``. These names must start with a
   lowercase letter or an underscore, and subsequent characters can be a
   lowercase letter, a digit, or an underscore. Uppercase letters are not
   allowed, because certain platforms have case-insensitive environment
@@ -1423,12 +1422,12 @@ In the example file above, there are four GPUs with ID's 0 through 3. GPU 0 has
 2 slots, GPU 1 has 4, GPU 2 has 2, and GPU 3 has a default of 1 slot. There is
 also one cryptography chip with 4 slots.
 
-``PROCESSES`` Property
-----------------------
+``RESOURCE_GROUPS`` Property
+----------------------------
 
-See :prop_test:`PROCESSES` for a description of this property.
+See :prop_test:`RESOURCE_GROUPS` for a description of this property.
 
-.. _`ctest-hardware-environment-variables`:
+.. _`ctest-resource-environment-variables`:
 
 Environment Variables
 ---------------------
@@ -1436,65 +1435,67 @@ Environment Variables
 Once CTest has decided which resources to allocate to a test, it passes this
 information to the test executable as a series of environment variables. For
 each example below, we will assume that the test in question has a
-:prop_test:`PROCESSES` property of ``2,gpus:2;gpus:4,gpus:1,crypto_chips:2``.
+:prop_test:`RESOURCE_GROUPS` property of
+``2,gpus:2;gpus:4,gpus:1,crypto_chips:2``.
 
 The following variables are passed to the test process:
 
-.. envvar:: CTEST_PROCESS_COUNT
+.. envvar:: CTEST_RESOURCE_GROUP_COUNT
 
-  The total number of processes specified by the :prop_test:`PROCESSES`
+  The total number of groups specified by the :prop_test:`RESOURCE_GROUPS`
   property. For example:
 
-  * ``CTEST_PROCESS_COUNT=3``
+  * ``CTEST_RESOURCE_GROUP_COUNT=3``
 
   This variable will only be defined if :manual:`ctest(1)` has been given a
-  ``--hardware-spec-file``, or if :command:`ctest_test` has been given a
-  ``HARDWARE_SPEC_FILE``. If no hardware specification file has been given,
+  ``--resource-spec-file``, or if :command:`ctest_test` has been given a
+  ``RESOURCE_SPEC_FILE``. If no resource specification file has been given,
   this variable will not be defined.
 
-.. envvar:: CTEST_PROCESS_<num>
+.. envvar:: CTEST_RESOURCE_GROUP_<num>
 
-  The list of resource types allocated to each process, with each item
+  The list of resource types allocated to each group, with each item
   separated by a comma. ``<num>`` is a number from zero to
-  ``CTEST_PROCESS_COUNT`` minus one. ``CTEST_PROCESS_<num>`` is defined for
-  each ``<num>`` in this range. For example:
+  ``CTEST_RESOURCE_GROUP_COUNT`` minus one. ``CTEST_RESOURCE_GROUP_<num>``
+  is defined for each ``<num>`` in this range. For example:
 
-  * ``CTEST_PROCESS_0=gpus``
-  * ``CTEST_PROCESS_1=gpus``
-  * ``CTEST_PROCESS_2=crypto_chips,gpus``
+  * ``CTEST_RESOURCE_GROUP_0=gpus``
+  * ``CTEST_RESOURCE_GROUP_1=gpus``
+  * ``CTEST_RESOURCE_GROUP_2=crypto_chips,gpus``
 
-.. envvar:: CTEST_PROCESS_<num>_<resource-type>
+.. envvar:: CTEST_RESOURCE_GROUP_<num>_<resource-type>
 
   The list of resource IDs and number of slots from each ID allocated to each
-  process for a given resource type. This variable consists of a series of
+  group for a given resource type. This variable consists of a series of
   pairs, each pair separated by a semicolon, and with the two items in the pair
   separated by a comma. The first item in each pair is ``id:`` followed by the
   ID of a resource of type ``<resource-type>``, and the second item is
   ``slots:`` followed by the number of slots from that resource allocated to
-  the given process. For example:
+  the given group. For example:
 
-  * ``CTEST_PROCESS_0_GPUS=id:0,slots:2``
-  * ``CTEST_PROCESS_1_GPUS=id:2,slots:2``
-  * ``CTEST_PROCESS_2_GPUS=id:1,slots:4;id:3,slots:1``
-  * ``CTEST_PROCESS_2_CRYPTO_CHIPS=id:card0,slots:2``
+  * ``CTEST_RESOURCE_GROUP_0_GPUS=id:0,slots:2``
+  * ``CTEST_RESOURCE_GROUP_1_GPUS=id:2,slots:2``
+  * ``CTEST_RESOURCE_GROUP_2_GPUS=id:1,slots:4;id:3,slots:1``
+  * ``CTEST_RESOURCE_GROUP_2_CRYPTO_CHIPS=id:card0,slots:2``
 
-  In this example, process 0 gets 2 slots from GPU ``0``, process 1 gets 2 slots
-  from GPU ``2``, and process 2 gets 4 slots from GPU ``1`` and 2 slots from
-  cryptography chip ``card0``.
+  In this example, group 0 gets 2 slots from GPU ``0``, group 1 gets 2 slots
+  from GPU ``2``, and group 2 gets 4 slots from GPU ``1``, 1 slot from GPU
+  ``3``, and 2 slots from cryptography chip ``card0``.
 
-  ``<num>`` is a number from zero to ``CTEST_PROCESS_COUNT`` minus one.
+  ``<num>`` is a number from zero to ``CTEST_RESOURCE_GROUP_COUNT`` minus one.
   ``<resource-type>`` is the name of a resource type, converted to uppercase.
-  ``CTEST_PROCESS_<num>_<resource-type>`` is defined for the product of each
-  ``<num>`` in the range listed above and each resource type listed in
-  ``CTEST_PROCESS_<num>``.
+  ``CTEST_RESOURCE_GROUP_<num>_<resource-type>`` is defined for the product
+  of each ``<num>`` in the range listed above and each resource type listed in
+  ``CTEST_RESOURCE_GROUP_<num>``.
 
   Because some platforms have case-insensitive names for environment variables,
   the names of resource types may not clash in a case-insensitive environment.
   Because of this, for the sake of simplicity, all resource types must be
   listed in all lowercase in the
-  :ref:`hardware specification file <ctest-hardware-specification-file>` and in
-  the :prop_test:`PROCESSES` property, and they are converted to all uppercase
-  in the ``CTEST_PROCESS_<num>_<resource-type>`` environment variable.
+  :ref:`resource specification file <ctest-resource-specification-file>` and
+  in the :prop_test:`RESOURCE_GROUPS` property, and they are converted to all
+  uppercase in the ``CTEST_RESOURCE_GROUP_<num>_<resource-type>`` environment
+  variable.
 
 See Also
 ========
diff --git a/Help/prop_sf/SKIP_UNITY_BUILD_INCLUSION.rst b/Help/prop_sf/SKIP_UNITY_BUILD_INCLUSION.rst
index 53f3970..6d1e60d 100644
--- a/Help/prop_sf/SKIP_UNITY_BUILD_INCLUSION.rst
+++ b/Help/prop_sf/SKIP_UNITY_BUILD_INCLUSION.rst
@@ -1,7 +1,11 @@
 SKIP_UNITY_BUILD_INCLUSION
 --------------------------
 
-Is this source file skipped by :prop_tgt:`UNITY_BUILD` feature.
+Setting this property to true ensures the source file will be skipped by
+unity builds when its associated target has its :prop_tgt:`UNITY_BUILD`
+property set to true.  The source file will instead be compiled on its own
+in the same way as it would with unity builds disabled.
 
-This property helps with "ODR (One definition rule)" problems
-that one would run into when using an :prop_tgt:`UNITY_BUILD`.
+This property helps with "ODR (One definition rule)" problems where combining
+a particular source file with others might lead to build errors or other
+unintended side effects.
diff --git a/Help/prop_test/PROCESSES.rst b/Help/prop_test/PROCESSES.rst
deleted file mode 100644
index d09c6d1..0000000
--- a/Help/prop_test/PROCESSES.rst
+++ /dev/null
@@ -1,54 +0,0 @@
-PROCESSES
-----------
-
-Set to specify the number of processes spawned by a test, and the resources
-that they require. See :ref:`hardware allocation <ctest-hardware-allocation>`
-for more information on how this property integrates into the CTest hardware
-allocation feature.
-
-The ``PROCESSES`` property is a :ref:`semicolon-separated list <CMake Language
-Lists>` of process descriptions. Each process description consists of an
-optional number of processes for the description followed by a series of
-resource requirements for those processes. These requirements (and the number
-of processes) are separated by commas. The resource requirements consist of the
-name of a resource type, followed by a colon, followed by an unsigned integer
-specifying the number of slots required on one resource of the given type.
-
-Please note that these processes are not spawned by CTest. The ``PROCESSES``
-property merely tells CTest what processes the test expects to launch. It is up
-to the test itself to do this process spawning, and read the :ref:`environment
-variables <ctest-hardware-environment-variables>` to determine which resources
-each process has been allocated.
-
-Consider the following example:
-
-.. code-block:: cmake
-
-  add_test(NAME MyTest COMMAND MyExe)
-  set_property(TEST MyTest PROPERTY PROCESSES
-    "2,gpus:2"
-    "gpus:4,crypto_chips:2")
-
-In this example, there are two process descriptions (implicitly separated by a
-semicolon.) The content of the first description is ``2,gpus:2``. This
-description spawns 2 processes, each of which requires 2 slots from a single
-GPU. The content of the second description is ``gpus:4,crypto_chips:2``. This
-description does not specify a process count, so a default of 1 is assumed.
-This single process requires 4 slots from a single GPU and 2 slots from a
-single cryptography chip. In total, 3 processes are spawned from this test,
-each with their own unique requirements.
-
-When CTest sets the :ref:`environment variables
-<ctest-hardware-environment-variables>` for a test, it assigns a process number
-based on the process description, starting at 0 on the left and the number of
-processes minus 1 on the right. For example, in the example above, the two
-processes in the first description would have IDs of 0 and 1, and the single
-process in the second description would have an ID of 2.
-
-Both the ``PROCESSES`` and :prop_test:`RESOURCE_LOCK` properties serve similar
-purposes, but they are distinct and orthogonal. Resources specified by
-``PROCESSES`` do not affect :prop_test:`RESOURCE_LOCK`, and vice versa. Whereas
-:prop_test:`RESOURCE_LOCK` is a simpler property that is used for locking one
-global resource, ``PROCESSES`` is a more advanced property that allows multiple
-tests to simultaneously use multiple resources of the same type, specifying
-their requirements in a fine-grained manner.
diff --git a/Help/prop_test/RESOURCE_GROUPS.rst b/Help/prop_test/RESOURCE_GROUPS.rst
new file mode 100644
index 0000000..436451c
--- /dev/null
+++ b/Help/prop_test/RESOURCE_GROUPS.rst
@@ -0,0 +1,54 @@
+RESOURCE_GROUPS
+---------------
+
+Specify resources required by a test, grouped in a way that is meaningful to
+the test.  See :ref:`resource allocation <ctest-resource-allocation>`
+for more information on how this property integrates into the CTest resource
+allocation feature.
+
+The ``RESOURCE_GROUPS`` property is a :ref:`semicolon-separated list <CMake
+Language Lists>` of group descriptions. Each entry consists of an optional
+number of groups using the description followed by a series of resource
+requirements for those groups. These requirements (and the number of groups)
+are separated by commas. The resource requirements consist of the name of a
+resource type, followed by a colon, followed by an unsigned integer
+specifying the number of slots required on one resource of the given type.
+
+The ``RESOURCE_GROUPS`` property tells CTest what resources a test expects
+to use grouped in a way meaningful to the test.  The test itself must read
+the :ref:`environment variables <ctest-resource-environment-variables>` to
+determine which resources have been allocated to each group.  For example,
+each group may correspond to a process the test will spawn when executed.
+
+Consider the following example:
+
+.. code-block:: cmake
+
+  add_test(NAME MyTest COMMAND MyExe)
+  set_property(TEST MyTest PROPERTY RESOURCE_GROUPS
+    "2,gpus:2"
+    "gpus:4,crypto_chips:2")
+
+In this example, there are two group descriptions (implicitly separated by a
+semicolon.) The content of the first description is ``2,gpus:2``. This
+description specifies 2 groups, each of which requires 2 slots from a single
+GPU. The content of the second description is ``gpus:4,crypto_chips:2``. This
+description does not specify a group count, so a default of 1 is assumed.
+This single group requires 4 slots from a single GPU and 2 slots from a
+single cryptography chip. In total, 3 resource groups are specified for this
+test, each with its own unique requirements.
+
+When CTest sets the :ref:`environment variables
+<ctest-resource-environment-variables>` for a test, it assigns a group number
+based on the group description, starting at 0 on the left and the number of
+groups minus 1 on the right. For example, in the example above, the two
+groups in the first description would have IDs of 0 and 1, and the single
+group in the second description would have an ID of 2.
+
+Both the ``RESOURCE_GROUPS`` and :prop_test:`RESOURCE_LOCK` properties serve
+similar purposes, but they are distinct and orthogonal. Resources specified by
+``RESOURCE_GROUPS`` do not affect :prop_test:`RESOURCE_LOCK`, and vice versa.
+Whereas :prop_test:`RESOURCE_LOCK` is a simpler property that is used for
+locking one global resource, ``RESOURCE_GROUPS`` is a more advanced property
+that allows multiple tests to simultaneously use multiple resources of the
+same type, specifying their requirements in a fine-grained manner.
diff --git a/Help/prop_test/RESOURCE_LOCK.rst b/Help/prop_test/RESOURCE_LOCK.rst
index 7d61f77..8b13a01 100644
--- a/Help/prop_test/RESOURCE_LOCK.rst
+++ b/Help/prop_test/RESOURCE_LOCK.rst
@@ -9,10 +9,10 @@ not to run concurrently.
 See also :prop_test:`FIXTURES_REQUIRED` if the resource requires any setup or
 cleanup steps.
 
-Both the :prop_test:`PROCESSES` and ``RESOURCE_LOCK`` properties serve similar
-purposes, but they are distinct and orthogonal. Resources specified by
-:prop_test:`PROCESSES` do not affect ``RESOURCE_LOCK``, and vice versa. Whereas
-``RESOURCE_LOCK`` is a simpler property that is used for locking one global
-resource, :prop_test:`PROCESSES` is a more advanced property that allows
-multiple tests to simultaneously use multiple resources of the same type,
-specifying their requirements in a fine-grained manner.
+Both the :prop_test:`RESOURCE_GROUPS` and ``RESOURCE_LOCK`` properties serve
+similar purposes, but they are distinct and orthogonal. Resources specified by
+:prop_test:`RESOURCE_GROUPS` do not affect ``RESOURCE_LOCK``, and vice versa.
+Whereas ``RESOURCE_LOCK`` is a simpler property that is used for locking one
+global resource, :prop_test:`RESOURCE_GROUPS` is a more advanced property
+that allows multiple tests to simultaneously use multiple resources of the
+same type, specifying their requirements in a fine-grained manner.
diff --git a/Help/prop_tgt/UNITY_BUILD.rst b/Help/prop_tgt/UNITY_BUILD.rst
index 2faad92..479802e 100644
--- a/Help/prop_tgt/UNITY_BUILD.rst
+++ b/Help/prop_tgt/UNITY_BUILD.rst
@@ -1,61 +1,60 @@
 UNITY_BUILD
 -----------
 
-Should the target source files be processed into batches for
-faster compilation. This feature is known as "Unity build",
-or "Jumbo build".
-
-The ``C`` and ``CXX`` source files are grouped separately.
-
-This property is initialized by the value of the
-:variable:`CMAKE_UNITY_BUILD` variable if it is set when
-a target is created.
-
-.. note::
-
-  It's not recommended to directly set :prop_tgt:`UNITY_BUILD`
-  to ``ON``, but to instead set :variable:`CMAKE_UNITY_BUILD` from
-  the command line.  However, it IS recommended to set
-  :prop_tgt:`UNITY_BUILD` to ``OFF`` if you need to ensure that a
-  target doesn't get a unity build.
-
-The batch size can be specified by setting
-:prop_tgt:`UNITY_BUILD_BATCH_SIZE`.
-
-The batching of source files is done by adding new sources files
-which will ``#include`` the source files, and exclude them from
-building by setting :prop_sf:`HEADER_FILE_ONLY` to ``ON``.
+When this property is set to true, the target source files will be combined
+into batches for faster compilation.  This is done by creating a (set of)
+unity sources which ``#include`` the original sources, then compiling these
+unity sources instead of the originals.  This is known as a *Unity* or *Jumbo*
+build.  The :prop_tgt:`UNITY_BUILD_BATCH_SIZE` property controls the upper
+limit on how many sources can be combined per unity source file.
+
+Unity builds are not currently supported for all languages.  CMake version
+|release| supports combining ``C`` and ``CXX`` source files.  For targets that
+mix source files from more than one language, CMake will separate the languages
+such that each generated unity source file only contains sources for a single
+language.
+
+This property is initialized by the value of the :variable:`CMAKE_UNITY_BUILD`
+variable when a target is created.
 
 .. note::
 
-  Marking the original sources with :prop_sf:`HEADER_FILE_ONLY`
-  is considered an implementation detail that may change in the
-  future because it does not work well in combination with
-  the :variable:`CMAKE_EXPORT_COMPILE_COMMANDS` variable.
+  Projects should not directly set the ``UNITY_BUILD`` property or its
+  associated :variable:`CMAKE_UNITY_BUILD` variable to true.  Depending
+  on the capabilities of the build machine and compiler used, it might or
+  might not be appropriate to enable unity builds.  Therefore, this feature
+  should be under developer control, which would normally be through the
+  developer choosing whether or not to set the :variable:`CMAKE_UNITY_BUILD`
+  variable on the :manual:`cmake(1)` command line or some other equivalent
+  method.  However, it IS recommended to set the ``UNITY_BUILD`` target
+  property to false if it is known that enabling unity builds for the
+  target can lead to problems.
 
 ODR (One definition rule) errors
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-Since multiple source files are included into one source file,
-it can lead to ODR errors. This section contains properties
-which help fixing these errors.
-
-The source files marked by :prop_sf:`GENERATED` will be skipped
-from unity build. This applies also for the source files marked
-with :prop_sf:`SKIP_UNITY_BUILD_INCLUSION`.
-
-The source files that have :prop_sf:`COMPILE_OPTIONS`,
-:prop_sf:`COMPILE_DEFINITIONS`, :prop_sf:`COMPILE_FLAGS`, or
-:prop_sf:`INCLUDE_DIRECTORIES` will also be skipped.
-
-With the :prop_tgt:`UNITY_BUILD_CODE_BEFORE_INCLUDE` and
-:prop_tgt:`UNITY_BUILD_CODE_AFTER_INCLUDE` one can specify code
-to be injected in the unity source file before and after every
-``#include`` statement.
-
-.. note::
-
-  The order of source files defined in the ``CMakeLists.txt`` will
-  be preserved into the generated unity source files. This can
-  be used to manually enforce a specific grouping based on the
-  :prop_tgt:`UNITY_BUILD_BATCH_SIZE` target property.
+When multiple source files are included into one source file, as is done
+for unity builds, it can potentially lead to ODR errors.  CMake provides
+a number of measures to help address such problems:
+
+* Any source file that has a non-empty :prop_sf:`COMPILE_OPTIONS`,
+  :prop_sf:`COMPILE_DEFINITIONS`, :prop_sf:`COMPILE_FLAGS`, or
+  :prop_sf:`INCLUDE_DIRECTORIES` source property will not be combined
+  into a unity source.
+
+* Projects can prevent an individual source file from being combined into
+  a unity source by setting its :prop_sf:`SKIP_UNITY_BUILD_INCLUSION`
+  source property to true.  This can be a more effective way to prevent
+  problems with specific files than disabling unity builds for an entire
+  target.
+
+* The :prop_tgt:`UNITY_BUILD_CODE_BEFORE_INCLUDE` and
+  :prop_tgt:`UNITY_BUILD_CODE_AFTER_INCLUDE` target properties can be used
+  to inject code into the unity source files before and after every
+  ``#include`` statement.
+
+* The order of source files added to the target via commands like
+  :command:`add_library`, :command:`add_executable` or
+  :command:`target_sources` will be preserved in the generated unity source
+  files.  This can be used to manually enforce a specific grouping based on
+  the :prop_tgt:`UNITY_BUILD_BATCH_SIZE` target property.
diff --git a/Help/prop_tgt/UNITY_BUILD_BATCH_SIZE.rst b/Help/prop_tgt/UNITY_BUILD_BATCH_SIZE.rst
index 84047f2..44ffe27 100644
--- a/Help/prop_tgt/UNITY_BUILD_BATCH_SIZE.rst
+++ b/Help/prop_tgt/UNITY_BUILD_BATCH_SIZE.rst
@@ -1,13 +1,23 @@
 UNITY_BUILD_BATCH_SIZE
 ----------------------
 
-Specifies how many source code files will be included into a
-:prop_tgt:`UNITY_BUILD` source file.
+Specifies the maximum number of source files that can be combined into any one
+unity source file when unity builds are enabled by the :prop_tgt:`UNITY_BUILD`
+target property.  The original source files will be distributed across as many
+unity source files as necessary to honor this limit.
 
-If the property is not set, CMake will use the value provided
-by :variable:`CMAKE_UNITY_BUILD_BATCH_SIZE`.
+The initial value for this property is taken from the
+:variable:`CMAKE_UNITY_BUILD_BATCH_SIZE` variable when the target is created.
+If that variable has not been set, the initial value will be 8.
 
-By setting it to value `0` the generated unity source file will
-contain all the source files that would otherwise be split
-into multiple batches. It is not recommended to do so, since it
-would affect performance.
+The batch size needs to be selected carefully.  If set too high, the size of
+the combined source files could result in the compiler using excessive memory
+or hitting other similar limits.  In extreme cases, this can even result in
+build failure.  On the other hand, if the batch size is too low, there will be
+little gain in build performance.
+
+Although strongly discouraged, the batch size may be set to a value of 0 to
+combine all the sources for the target into a single unity file, regardless of
+how many sources are involved.  This runs the risk of creating an excessively
+large unity source file and negatively impacting the build performance, so
+a value of 0 is not generally recommended.
diff --git a/Help/prop_tgt/UNITY_BUILD_CODE_AFTER_INCLUDE.rst b/Help/prop_tgt/UNITY_BUILD_CODE_AFTER_INCLUDE.rst
index 7795289..7231b61 100644
--- a/Help/prop_tgt/UNITY_BUILD_CODE_AFTER_INCLUDE.rst
+++ b/Help/prop_tgt/UNITY_BUILD_CODE_AFTER_INCLUDE.rst
@@ -2,7 +2,18 @@ UNITY_BUILD_CODE_AFTER_INCLUDE
 ------------------------------
 
 Code snippet which is included verbatim by the :prop_tgt:`UNITY_BUILD`
-feature just after the `#include` statement of the targeted source
-files.
+feature just after every ``#include`` statement in the generated unity
+source files.  For example:
 
-This could be something like `#undef NOMINMAX`.
+.. code-block:: cmake
+
+  set(after [[
+  #if defined(NOMINMAX)
+  #undef NOMINMAX
+  #endif
+  ]])
+  set_target_properties(myTarget PROPERTIES
+    UNITY_BUILD_CODE_AFTER_INCLUDE "${after}"
+  )
+
+See also :prop_tgt:`UNITY_BUILD_CODE_BEFORE_INCLUDE`.
diff --git a/Help/prop_tgt/UNITY_BUILD_CODE_BEFORE_INCLUDE.rst b/Help/prop_tgt/UNITY_BUILD_CODE_BEFORE_INCLUDE.rst
index f335463..7ed6fa1 100644
--- a/Help/prop_tgt/UNITY_BUILD_CODE_BEFORE_INCLUDE.rst
+++ b/Help/prop_tgt/UNITY_BUILD_CODE_BEFORE_INCLUDE.rst
@@ -2,7 +2,18 @@ UNITY_BUILD_CODE_BEFORE_INCLUDE
 -------------------------------
 
 Code snippet which is included verbatim by the :prop_tgt:`UNITY_BUILD`
-feature just before the `#include` statement of the targeted source
-files.
+feature just before every ``#include`` statement in the generated unity
+source files.  For example:
 
-This could be something like `#define NOMINMAX`.
+.. code-block:: cmake
+
+  set(before [[
+  #if !defined(NOMINMAX)
+  #define NOMINMAX
+  #endif
+  ]])
+  set_target_properties(myTarget PROPERTIES
+    UNITY_BUILD_CODE_BEFORE_INCLUDE "${before}"
+  )
+
+See also :prop_tgt:`UNITY_BUILD_CODE_AFTER_INCLUDE`.
diff --git a/Help/release/3.16.rst b/Help/release/3.16.rst
index 3f198ca..0d1cc1e 100644
--- a/Help/release/3.16.rst
+++ b/Help/release/3.16.rst
@@ -192,8 +192,8 @@ Autogen
 CTest
 -----
 
-* :manual:`ctest(1)` now has the ability to serialize tests based on hardware
-  requirements for each test. See :ref:`ctest-hardware-allocation` for
+* :manual:`ctest(1)` now has the ability to schedule tests based on resource
+  requirements for each test. See :ref:`ctest-resource-allocation` for
   details.
 
 * A new test property, :prop_test:`SKIP_REGULAR_EXPRESSION`, has been added.
@@ -207,9 +207,8 @@ CTest
 CPack
 -----
 
-* CPack variable :variable:`CPACK_INSTALL_CMAKE_CONFIGURATIONS` was added to
-  control what configurations are to be packaged for multi-configuration
-  CMake generators.
+* :manual:`cpack(1)` learned support for multiple configurations for ``-C``
+  option.
 
 * The :cpack_gen:`CPack DEB Generator` is now able to format generic text
   (usually used as the description for multiple CPack generators) according
diff --git a/Help/variable/CMAKE_UNITY_BUILD.rst b/Help/variable/CMAKE_UNITY_BUILD.rst
index bbcfd68..a86cd67 100644
--- a/Help/variable/CMAKE_UNITY_BUILD.rst
+++ b/Help/variable/CMAKE_UNITY_BUILD.rst
@@ -1,11 +1,19 @@
 CMAKE_UNITY_BUILD
 -----------------
 
-Initializes the :prop_tgt:`UNITY_BUILD` target property on targets
-as they are created.  Set to ``ON`` to batch compilation of multiple
-sources within each target.  This feature is known as "Unity build",
-or "Jumbo build".  By default this variable is not set and so does
-not enable unity builds on targets.
+This variable is used to initialize the :prop_tgt:`UNITY_BUILD`
+property of targets when they are created.  Setting it to true
+enables batch compilation of multiple sources within each target.
+This feature is known as a *Unity* or *Jumbo* build.
+
+Projects should not set this variable, it is intended as a developer
+control to be set on the :manual:`cmake(1)` command line or other
+equivalent methods.  The developer must have the ability to enable or
+disable unity builds according to the capabilities of their own machine
+and compiler.
+
+By default, this variable is not set, which will result in unity builds
+being disabled.
 
 .. note::
   This option currently does not work well in combination with
diff --git a/Help/variable/CMAKE_UNITY_BUILD_BATCH_SIZE.rst b/Help/variable/CMAKE_UNITY_BUILD_BATCH_SIZE.rst
index 3ab2344..7988d4b 100644
--- a/Help/variable/CMAKE_UNITY_BUILD_BATCH_SIZE.rst
+++ b/Help/variable/CMAKE_UNITY_BUILD_BATCH_SIZE.rst
@@ -1,6 +1,7 @@
 CMAKE_UNITY_BUILD_BATCH_SIZE
 ----------------------------
 
-Default value for :prop_tgt:`UNITY_BUILD_BATCH_SIZE` of targets.
-
-By default ``CMAKE_UNITY_BUILD_BATCH_SIZE`` is set to ``8``.
+This variable is used to initialize the :prop_tgt:`UNITY_BUILD_BATCH_SIZE`
+property of targets when they are created.  It specifies the default upper
+limit on the number of source files that may be combined in any one unity
+source file when unity builds are enabled for a target.