This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
       via  543ceb9d9e06647356328313b8d0ec0c4a171de3 (commit)
       via  6416753f32075c9d6b6aaf84f55ab21eccc0ba93 (commit)
       via  cae17f7208de2d460d7d70d3fc6624ad6a84bb11 (commit)
       via  1463cfb437768c5f330f2c5aa73deaecfc0d50e0 (commit)
       via  9682adb6ad10b22297125f74d4919031f7ce227b (commit)
       via  657fb0aa6fadf0c3aa4f8a914feb621cdfb6af4f (commit)
       via  067ee518f792b2babc9ae53c69bddeb5e15f3d76 (commit)
       via  59673bb2dc4a1336dd9028573ed33d934087f8ee (commit)
       via  210d04bb79b961252c3685b1d7a3653beec39fe6 (commit)
      from  e3afdef8c567880d7c83ca5980e4c5f5d289880c (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=543ceb9d9e06647356328313b8d0ec0c4a171de3
commit 543ceb9d9e06647356328313b8d0ec0c4a171de3
Merge: 6416753f32 657fb0aa6f
Author:     Brad King <brad.k...@kitware.com>
AuthorDate: Mon Nov 4 15:20:48 2019 +0000
Commit:     Kitware Robot <kwro...@kitware.com>
CommitDate: Mon Nov 4 10:21:27 2019 -0500

    Merge topic 'fix_load_cache_docs'
    
    657fb0aa6f Help: Clarify load_cache documentation of first parameter
    
    Acked-by: Kitware Robot <kwro...@kitware.com>
    Merge-request: !3971


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6416753f32075c9d6b6aaf84f55ab21eccc0ba93
commit 6416753f32075c9d6b6aaf84f55ab21eccc0ba93
Merge: cae17f7208 9682adb6ad
Author:     Brad King <brad.k...@kitware.com>
AuthorDate: Mon Nov 4 15:20:26 2019 +0000
Commit:     Kitware Robot <kwro...@kitware.com>
CommitDate: Mon Nov 4 10:20:34 2019 -0500

    Merge topic 'tutorial-cleanup'
    
    9682adb6ad Tutorial: clean up typos, grammar and formatting
    
    Acked-by: Kitware Robot <kwro...@kitware.com>
    Merge-request: !3984


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=cae17f7208de2d460d7d70d3fc6624ad6a84bb11
commit cae17f7208de2d460d7d70d3fc6624ad6a84bb11
Merge: 1463cfb437 067ee518f7
Author:     Brad King <brad.k...@kitware.com>
AuthorDate: Mon Nov 4 15:13:02 2019 +0000
Commit:     Kitware Robot <kwro...@kitware.com>
CommitDate: Mon Nov 4 10:13:27 2019 -0500

    Merge topic 'FindCUDA-find-nvcc'
    
    067ee518f7 FindCUDA: Use find_program instead of find_path to find nvcc
    
    Acked-by: Kitware Robot <kwro...@kitware.com>
    Merge-request: !3973


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1463cfb437768c5f330f2c5aa73deaecfc0d50e0
commit 1463cfb437768c5f330f2c5aa73deaecfc0d50e0
Merge: e3afdef8c5 59673bb2dc
Author:     Brad King <brad.k...@kitware.com>
AuthorDate: Mon Nov 4 15:12:19 2019 +0000
Commit:     Kitware Robot <kwro...@kitware.com>
CommitDate: Mon Nov 4 10:12:26 2019 -0500

    Merge topic 'pgi-license-warnings'
    
    59673bb2dc Tests: Teach RunCMake to ignore PGI license expiry warnings
    210d04bb79 CTestCustom: Suppress PGI Community Edition compiler license 
warnings
    
    Acked-by: Kitware Robot <kwro...@kitware.com>
    Merge-request: !3975


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9682adb6ad10b22297125f74d4919031f7ce227b
commit 9682adb6ad10b22297125f74d4919031f7ce227b
Author:     Craig Scott <craig.sc...@crascit.com>
AuthorDate: Mon Nov 4 12:33:50 2019 +1100
Commit:     Craig Scott <craig.sc...@crascit.com>
CommitDate: Mon Nov 4 12:44:34 2019 +1100

    Tutorial: clean up typos, grammar and formatting

diff --git a/Help/guide/tutorial/index.rst b/Help/guide/tutorial/index.rst
index d858c25f97..3f20aa26e5 100644
--- a/Help/guide/tutorial/index.rst
+++ b/Help/guide/tutorial/index.rst
@@ -18,9 +18,9 @@ A Basic Starting Point (Step 1)
 ===============================
 
 The most basic project is an executable built from source code files.
-For simple projects, a three line CMakeLists file is all that is required.
-This will be the starting point for our tutorial. Create a ``CMakeLists.txt``
-file in the ``Step1`` directory that looks like:
+For simple projects, a three line ``CMakeLists.txt`` file is all that is
+required. This will be the starting point for our tutorial. Create a
+``CMakeLists.txt`` file in the ``Step1`` directory that looks like:
 
 .. code-block:: cmake
 
@@ -33,7 +33,7 @@ file in the ``Step1`` directory that looks like:
   add_executable(Tutorial tutorial.cxx)
 
 
-Note that this example uses lower case commands in the CMakeLists file.
+Note that this example uses lower case commands in the ``CMakeLists.txt`` file.
 Upper, lower, and mixed case commands are supported by CMake. The source
 code for ``tutorial.cxx`` is provided in the ``Step1`` directory and can be
 used to compute the square root of a number.
@@ -43,9 +43,9 @@ Adding a Version Number and Configured Header File
 
 The first feature we will add is to provide our executable and project with a
 version number. While we could do this exclusively in the source code, using
-CMakeLists provides more flexibility.
+``CMakeLists.txt`` provides more flexibility.
 
-First, modify the CMakeLists file to set the version number.
+First, modify the ``CMakeLists.txt`` file to set the version number.
 
 .. literalinclude:: Step2/CMakeLists.txt
   :language: cmake
@@ -61,7 +61,7 @@ code:
 
 Since the configured file will be written into the binary tree, we
 must add that directory to the list of paths to search for include
-files. Add the following lines to the end of the CMakeLists file:
+files. Add the following lines to the end of the ``CMakeLists.txt`` file:
 
 .. literalinclude:: Step2/CMakeLists.txt
   :language: cmake
@@ -103,8 +103,8 @@ Next let's add some C++11 features to our project by 
replacing ``atof`` with
 We will need to explicitly state in the CMake code that it should use the
 correct flags. The easiest way to enable support for a specific C++ standard
 in CMake is by using the ``CMAKE_CXX_STANDARD`` variable. For this tutorial,
-set the ``CMAKE_CXX_STANDARD`` variable in the CMakeLists file to 11 and
-``CMAKE_CXX_STANDARD_REQUIRED`` to True:
+set the ``CMAKE_CXX_STANDARD`` variable in the ``CMakeLists.txt`` file to 11
+and ``CMAKE_CXX_STANDARD_REQUIRED`` to True:
 
 .. literalinclude:: Step2/CMakeLists.txt
   :language: cmake
@@ -145,22 +145,22 @@ then use this library instead of the standard square root 
function provided by
 the compiler.
 
 For this tutorial we will put the library into a subdirectory
-called MathFunctions. This directory already contains a header file,
+called ``MathFunctions``. This directory already contains a header file,
 ``MathFunctions.h``, and a source file ``mysqrt.cxx``. The source file has one
 function called ``mysqrt`` that provides similar functionality to the
 compiler's ``sqrt`` function.
 
-Add the following one line ``CMakeLists.txt`` file to the MathFunctions
+Add the following one line ``CMakeLists.txt`` file to the ``MathFunctions``
 directory:
 
 .. literalinclude:: Step3/MathFunctions/CMakeLists.txt
   :language: cmake
 
 To make use of the new library we will add an ``add_subdirectory`` call in the
-top-level CMakeLists file so that the library will get built. We add the new
-library to the executable, and add MathFunctions as an include directory so
-that the ``mqsqrt.h`` header file can be found. The last few lines of the
-top-level CMakeLists file should now look like:
+top-level ``CMakeLists.txt`` file so that the library will get built. We add
+the new library to the executable, and add ``MathFunctions`` as an include
+directory so that the ``mqsqrt.h`` header file can be found. The last few lines
+of the top-level ``CMakeLists.txt`` file should now look like:
 
 .. code-block:: cmake
 
@@ -181,8 +181,8 @@ top-level CMakeLists file should now look like:
 
 Now let us make the MathFunctions library optional. While for the tutorial
 there really isn’t any need to do so, for larger projects this is a common
-occurrence. The first step is to add an option to the top-level CMakeLists
-file.
+occurrence. The first step is to add an option to the top-level
+``CMakeLists.txt`` file.
 
 .. literalinclude:: Step3/CMakeLists.txt
   :language: cmake
@@ -195,8 +195,8 @@ the cache so that the user does not need to set the value 
each time they run
 CMake on a build directory.
 
 The next change is to make building and linking the MathFunctions library
-conditional. To do this we change the end of the top-level CMakeLists file to
-look like the following:
+conditional. To do this we change the end of the top-level ``CMakeLists.txt``
+file to look like the following:
 
 .. literalinclude:: Step3/CMakeLists.txt
   :language: cmake
@@ -209,15 +209,15 @@ classic approach when dealing with many optional 
components, we will cover
 the modern approach in the next step.
 
 The corresponding changes to the source code are fairly straightforward. First,
-in ``tutorial.cxx``, include the MathFunctions header if we need it:
+in ``tutorial.cxx``, include the ``MathFunctions.h`` header if we need it:
 
 .. literalinclude:: Step3/tutorial.cxx
   :language: c++
   :start-after: // should we include the MathFunctions header
   :end-before: int main
 
-Then, in the same file, make which square root function is used dependent on
-``USE_MYMATH``:
+Then, in the same file, make ``USE_MYMATH`` control which square root
+function is used:
 
 .. literalinclude:: Step3/tutorial.cxx
   :language: c++
@@ -268,7 +268,7 @@ doesn't. Add the following lines to the end of 
``MathFunctions/CMakeLists.txt``:
 
 Now that we've specified usage requirements for MathFunctions we can safely
 remove our uses of the ``EXTRA_INCLUDES`` variable from the top-level
-CMakeLists, here:
+``CMakeLists.txt``, here:
 
 .. literalinclude:: Step4/CMakeLists.txt
   :language: cmake
@@ -330,9 +330,9 @@ Verify that the installed Tutorial runs.
 Testing Support
 ---------------
 
-Next let's test our application. At the end of the top-level CMakeLists file we
-can enable testing and then add a number of basic tests to verify that the
-application is working correctly.
+Next let's test our application. At the end of the top-level ``CMakeLists.txt``
+file we can enable testing and then add a number of basic tests to verify that
+the application is working correctly.
 
 .. literalinclude:: Step5/CMakeLists.txt
   :language: cmake
@@ -344,7 +344,7 @@ test.
 
 The next test makes use of the ``PASS_REGULAR_EXPRESSION`` test property to
 verify that the output of the test contains certain strings. In this case,
-verifying that the the usage message is printed when an incorrect number of
+verifying that the usage message is printed when an incorrect number of
 arguments are provided.
 
 Lastly, we have a function called ``do_test`` that runs the application and
@@ -370,9 +370,9 @@ tutorial assume that they are not common.
 
 If the platform has ``log`` and ``exp`` then we will use them to compute the
 square root in the ``mysqrt`` function. We first test for the availability of
-these functions using the ``CheckSymbolExists.cmake`` macro in the top-level
-CMakeLists. We're going to use the new defines in ``TutorialConfig.h.in``,
-so be sure to set them before that file is configured.
+these functions using the ``CheckSymbolExists`` module in the top-level
+``CMakeLists.txt``. We're going to use the new defines in
+``TutorialConfig.h.in``, so be sure to set them before that file is configured.
 
 .. literalinclude:: Step6/MathFunctions/CMakeLists.txt
   :language: cmake
@@ -405,9 +405,8 @@ You will notice that we're not using ``log`` and ``exp``, 
even if we think they
 should be available. We should realize quickly that we have forgotten to 
include
 ``TutorialConfig.h`` in ``mysqrt.cxx``.
 
-We will also need to update MathFunctions/CMakeLists so ``mysqrt.cxx`` knows
-where this file is located:
-
+We will also need to update ``MathFunctions/CMakeLists.txt`` so ``mysqrt.cxx``
+knows where this file is located:
 
 .. code-block:: cmake
 
@@ -432,10 +431,10 @@ other than in ``TutorialConfig.h``? Let's try to use
 
 First, remove the defines from ``TutorialConfig.h.in``. We no longer need to
 include ``TutorialConfig.h`` from ``mysqrt.cxx`` or the extra include in
-MathFunctions/CMakeLists.
+``MathFunctions/CMakeLists.txt``.
 
 Next, we can move the check for ``HAVE_LOG`` and ``HAVE_EXP`` to
-MathFunctions/CMakeLists and then add specify those values as ``PRIVATE``
+``MathFunctions/CMakeLists.txt`` and then specify those values as ``PRIVATE``
 compile definitions.
 
 .. literalinclude:: Step6/MathFunctions/CMakeLists.txt
@@ -444,7 +443,7 @@ compile definitions.
   :end-before: # install rules
 
 After making these updates, go ahead and build the project again. Run the
-built  Tutorial executable and verify that the results are same as earlier in
+built Tutorial executable and verify that the results are same as earlier in
 this step.
 
 Adding a Custom Command and Generated File (Step 6)
@@ -457,22 +456,23 @@ In this section, we will create the table as part of the 
build process,
 and then compile that table into our application.
 
 First, let's remove the check for the ``log`` and ``exp`` functions in
-MathFunctions/CMakeLists. Then remove the check for ``HAVE_LOG`` and
+``MathFunctions/CMakeLists.txt``. Then remove the check for ``HAVE_LOG`` and
 ``HAVE_EXP`` from ``mysqrt.cxx``. At the same time, we can remove
 :code:`#include <cmath>`.
 
-In the MathFunctions subdirectory, a new source file named ``MakeTable.cxx``
+In the ``MathFunctions`` subdirectory, a new source file named 
``MakeTable.cxx``
 has been provided to generate the table.
 
 After reviewing the file, we can see that the table is produced as valid C++
 code and that the output filename is passed in as an argument.
 
-The next step is to add the appropriate commands to MathFunctions CMakeLists
-file to build the MakeTable executable and then run it as part of the build
-process. A few commands are needed to accomplish this.
+The next step is to add the appropriate commands to the
+``MathFunctions/CMakeLists.txt`` file to build the MakeTable executable and
+then run it as part of the build process. A few commands are needed to
+accomplish this.
 
-First, at the top of MathFunctions/CMakeLists, the executable for ``MakeTable``
-is added as any other executable would be added.
+First, at the top of ``MathFunctions/CMakeLists.txt``, the executable for
+``MakeTable`` is added as any other executable would be added.
 
 .. literalinclude:: Step7/MathFunctions/CMakeLists.txt
   :language: cmake
@@ -619,7 +619,7 @@ type must be specified::
 
 Or, from an IDE, build the ``Experimental`` target.
 
-Ctest will build and test the project and submit the results to the Kitware
+``ctest`` will build and test the project and submit the results to the Kitware
 public dashboard. The results of your dashboard will be uploaded to Kitware's
 public dashboard here: https://my.cdash.org/index.php?project=CMakeTutorial.
 
@@ -628,8 +628,8 @@ Mixing Static and Shared (Step 9)
 
 In this section we will show how by using the ``BUILD_SHARED_LIBS`` variable
 we can control the default behavior of ``add_library``, and allow control
-over how libraries without an explicit type (STATIC/SHARED/MODULE/OBJECT) are
-built.
+over how libraries without an explicit type (``STATIC``, ``SHARED``, ``MODULE``
+or ``OBJECT``) are built.
 
 To accomplish this we need to add ``BUILD_SHARED_LIBS`` to the top-level
 ``CMakeLists.txt``. We use the ``option`` command as it allows users to
@@ -678,10 +678,10 @@ Finally, update ``MathFunctions/MathFunctions.h`` to use 
dll export defines:
   :language: c++
 
 At this point, if you build everything, you will notice that linking fails
-as we are combining a static library without position enabled code with a
-library that has position enabled code. The solution to this is to explicitly
-set the ``POSITION_INDEPENDENT_CODE`` target property of SqrtLibrary to be
-True no matter the build type.
+as we are combining a static library without position independent code with a
+library that has position independent code. The solution to this is to
+explicitly set the ``POSITION_INDEPENDENT_CODE`` target property of SqrtLibrary
+to be True no matter the build type.
 
 .. literalinclude:: Step10/MathFunctions/CMakeLists.txt
   :language: cmake
@@ -718,7 +718,7 @@ string, and ``<1:...>`` results in the content of "...".  
They can also be
 nested.
 
 A common usage of generator expressions is to conditionally add compiler
-flags, such as those as language levels or warnings. A nice pattern is
+flags, such as those for language levels or warnings. A nice pattern is
 to associate this information to an ``INTERFACE`` target allowing this
 information to propagate. Lets start by constructing an ``INTERFACE``
 target and specifying the required C++ standard level of ``11`` instead
@@ -816,19 +816,19 @@ directory and from an install / package. This means 
converting the
   :start-after: # to find MathFunctions.h, while we don't.
   :end-before: # should we use our own math functions
 
-Once this has been updated, we can re-run CMake and see verify that it doesn't
+Once this has been updated, we can re-run CMake and verify that it doesn't
 warn anymore.
 
 At this point, we have CMake properly packaging the target information that is
 required but we will still need to generate a ``MathFunctionsConfig.cmake`` so
-that the CMake ``find_package command`` can find our project. So let's go
+that the CMake ``find_package`` command can find our project. So let's go
 ahead and add a new file to the top-level of the project called
 ``Config.cmake.in`` with the following contents:
 
 .. literalinclude:: Complete/Config.cmake.in
 
 Then, to properly configure and install that file, add the following to the
-bottom of the top-level CMakeLists:
+bottom of the top-level ``CMakeLists.txt``:
 
 .. literalinclude:: Complete/CMakeLists.txt
   :language: cmake
@@ -838,7 +838,7 @@ bottom of the top-level CMakeLists:
 At this point, we have generated a relocatable CMake Configuration for our
 project that can be used after the project has been installed or packaged. If
 we want our project to also be used from a build directory we only have to add
-the following to the bottom of the top level CMakeLists:
+the following to the bottom of the top level ``CMakeLists.txt``:
 
 .. literalinclude:: Complete/CMakeLists.txt
   :language: cmake
@@ -851,7 +851,7 @@ other projects, without needing it to be installed.
 Import a CMake Project (Consumer)
 =================================
 
-This examples shows how a project can find other CMake packages that
+This example shows how a project can find other CMake packages that
 generate ``Config.cmake`` files.
 
 It also shows how to state a project's external dependencies when generating
@@ -860,22 +860,24 @@ a ``Config.cmake``.
 Packaging Debug and Release (MultiPackage)
 ==========================================
 
-By default CMake is model is that a build directory only contains a single
+By default CMake's model is that a build directory only contains a single
 configuration, be it Debug, Release, MinSizeRel, or RelWithDebInfo.
 
 But it is possible to setup CPack to bundle multiple build directories at the
 same time to build a package that contains multiple configurations of the
 same project.
 
-First we need to ahead and construct a directory called ``multi_config`` this
+First we need to construct a directory called ``multi_config``, which
 will contain all the builds that we want to package together.
 
 Second create a ``debug`` and ``release`` directory underneath
 ``multi_config``. At the end you should have a layout that looks like:
 
-─ multi_config
-    ├── debug
-    └── release
+.. code-block:: none
+
+  ─ multi_config
+      ├── debug
+      └── release
 
 Now we need to setup debug and release builds, which would roughly entail
 the following:
@@ -891,8 +893,9 @@ the following:
   cd ..
 
 
-Now that both the debug and release builds are complete we can now use
-the custom MultiCPackConfig to package both builds into a single release.
+Now that both the debug and release builds are complete, we can use
+a custom ``MultiCPackConfig.cmake`` file to package both builds into a single
+release.
 
 .. code-block:: console
 

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=657fb0aa6fadf0c3aa4f8a914feb621cdfb6af4f
commit 657fb0aa6fadf0c3aa4f8a914feb621cdfb6af4f
Author:     Charles Barto <chba...@microsoft.com>
AuthorDate: Thu Oct 31 11:30:29 2019 -0700
Commit:     Brad King <brad.k...@kitware.com>
CommitDate: Fri Nov 1 10:00:28 2019 -0400

    Help: Clarify load_cache documentation of first parameter
    
    The first parameter is the path to the *directory* containing the
    `CMakeCache.txt` file, not the file itself.

diff --git a/Help/command/load_cache.rst b/Help/command/load_cache.rst
index 33625c4635..b89eb61776 100644
--- a/Help/command/load_cache.rst
+++ b/Help/command/load_cache.rst
@@ -5,7 +5,7 @@ Load in the values from another project's CMake cache.
 
 .. code-block:: cmake
 
-  load_cache(pathToCacheFile READ_WITH_PREFIX prefix entry1...)
+  load_cache(pathToBuildDirectory READ_WITH_PREFIX prefix entry1...)
 
 Reads the cache and store the requested entries in variables with their
 name prefixed with the given prefix.  This only reads the values, and
@@ -13,7 +13,7 @@ does not create entries in the local project's cache.
 
 .. code-block:: cmake
 
-  load_cache(pathToCacheFile [EXCLUDE entry1...]
+  load_cache(pathToBuildDirectory [EXCLUDE entry1...]
              [INCLUDE_INTERNALS entry1...])
 
 Loads in the values from another cache and store them in the local

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=067ee518f792b2babc9ae53c69bddeb5e15f3d76
commit 067ee518f792b2babc9ae53c69bddeb5e15f3d76
Author:     Hong Xu <h...@topbug.net>
AuthorDate: Thu Oct 31 13:50:24 2019 -0700
Commit:     Brad King <brad.k...@kitware.com>
CommitDate: Fri Nov 1 09:57:11 2019 -0400

    FindCUDA: Use find_program instead of find_path to find nvcc
    
    Otherwise nvcc is not found if it is in env PATH but a non-standard
    location.

diff --git a/Modules/FindCUDA.cmake b/Modules/FindCUDA.cmake
index b6859aaf41..79d7fda653 100644
--- a/Modules/FindCUDA.cmake
+++ b/Modules/FindCUDA.cmake
@@ -676,7 +676,7 @@ endif()
 # Search for the cuda distribution.
 if(NOT CUDA_TOOLKIT_ROOT_DIR AND NOT CMAKE_CROSSCOMPILING)
   # Search in the CUDA_BIN_PATH first.
-  find_path(CUDA_TOOLKIT_ROOT_DIR
+  find_program(CUDA_TOOLKIT_ROOT_DIR
     NAMES nvcc nvcc.exe
     PATHS
       ENV CUDA_TOOLKIT_ROOT
@@ -688,7 +688,7 @@ if(NOT CUDA_TOOLKIT_ROOT_DIR AND NOT CMAKE_CROSSCOMPILING)
     )
 
   # Now search default paths
-  find_path(CUDA_TOOLKIT_ROOT_DIR
+  find_program(CUDA_TOOLKIT_ROOT_DIR
     NAMES nvcc nvcc.exe
     PATHS /opt/cuda/bin
     PATH_SUFFIXES cuda/bin

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=59673bb2dc4a1336dd9028573ed33d934087f8ee
commit 59673bb2dc4a1336dd9028573ed33d934087f8ee
Author:     Brad King <brad.k...@kitware.com>
AuthorDate: Fri Nov 1 09:20:41 2019 -0400
Commit:     Brad King <brad.k...@kitware.com>
CommitDate: Fri Nov 1 09:23:03 2019 -0400

    Tests: Teach RunCMake to ignore PGI license expiry warnings
    
    These are not useful in nightly testing.

diff --git a/Tests/RunCMake/RunCMake.cmake b/Tests/RunCMake/RunCMake.cmake
index f24cfab62a..cb20fb1f3d 100644
--- a/Tests/RunCMake/RunCMake.cmake
+++ b/Tests/RunCMake/RunCMake.cmake
@@ -146,6 +146,12 @@ function(run_cmake test)
     "|clang[^:]*: warning: the object size sanitizer has no effect at -O0, but 
is explicitly enabled:"
     "|Error kstat returned"
     "|Hit xcodebuild bug"
+
+    "|LICENSE WARNING:"
+    "|Your license to use PGI[^\n]*expired"
+    "|Please obtain a new version at"
+    "|contact PGI Sales at"
+
     "|[^\n]*xcodebuild[^\n]*warning: file type[^\n]*is based on missing file 
type"
     "|[^\n]*is a member of multiple groups"
     "|[^\n]*from Time Machine by path"

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=210d04bb79b961252c3685b1d7a3653beec39fe6
commit 210d04bb79b961252c3685b1d7a3653beec39fe6
Author:     Brad King <brad.k...@kitware.com>
AuthorDate: Fri Nov 1 09:15:54 2019 -0400
Commit:     Brad King <brad.k...@kitware.com>
CommitDate: Fri Nov 1 09:22:05 2019 -0400

    CTestCustom: Suppress PGI Community Edition compiler license warnings
    
    These are not useful in nightly testing.

diff --git a/CTestCustom.cmake.in b/CTestCustom.cmake.in
index 823ee3cb7c..af4bb2dc46 100644
--- a/CTestCustom.cmake.in
+++ b/CTestCustom.cmake.in
@@ -71,6 +71,7 @@ list(APPEND CTEST_CUSTOM_WARNING_EXCEPTION
   "cm(StringCommand|CTestTestHandler)\\.cxx.*warning.*rand.*isn.*t random" # 
we do not do crypto
   "cm(StringCommand|CTestTestHandler)\\.cxx.*warning.*srand.*seed choices 
are.*poor" # we do not do crypto
   "IPA warning: function.*multiply defined in"
+  "LICENSE WARNING" # PGI license expiry.  Not useful in nightly testing.
 
   # Ignore compiler summary warning, assuming prior text has matched some
   # other warning expression:

-----------------------------------------------------------------------

Summary of changes:
 CTestCustom.cmake.in          |   1 +
 Help/command/load_cache.rst   |   4 +-
 Help/guide/tutorial/index.rst | 129 +++++++++++++++++++++---------------------
 Modules/FindCUDA.cmake        |   4 +-
 Tests/RunCMake/RunCMake.cmake |   6 ++
 5 files changed, 77 insertions(+), 67 deletions(-)


hooks/post-receive
-- 
CMake
_______________________________________________
Cmake-commits mailing list
Cmake-commits@cmake.org
https://cmake.org/mailman/listinfo/cmake-commits

Reply via email to