Misc touch-ups

README.md

@@ -91,7 +91,7 @@ There are some other places to find good information on the web. Here are some o
 
 ## Credits
 
-Modern CMake was originally written by [Henry Schreiner](https://iscinumpy.gitlab.io). Other contributors can be found [listed on GitLab](https://gitlab.com/CLIUtils/modern-cmake/graphs/master).
+Modern CMake was originally written by [Henry Schreiner](https://iscinumpy.gitlab.io). Other contributors can be found [listed on GitLab](https://gitlab.com/CLIUtils/modern-cmake/-/network/master).
 
 [^1]: CMake 3.0 also removed several long deprecated features from very old versions of CMake and make one very tiny backwards incompatible change to syntax related to square brackets, so this is not entirely fair; there might be some very, very old CMake files that would stop working with 3. I've never seen one, though.
 

SUMMARY.md

@@ -30,7 +30,7 @@
     * [Installing](chapters/install/installing.md)
     * [Exporting](chapters/install/exporting.md)
     * [Packaging](chapters/install/packaging.md)
-* [Looking for libraries](chapters/packages.md)
+* [Looking for Libraries (Packages)](chapters/packages.md)
     * [CUDA](chapters/packages/CUDA.md)
     * [OpenMP](chapters/packages/OpenMP.md)
     * [Boost](chapters/packages/Boost.md)

chapters/install/exporting.md

@@ -1,10 +1,10 @@
 # Exporting
 
 {% hint style='danger' %}
-The default behavior for exporting changed in CMake 3.15. Since changing files in a user's home directory is considered "surprising" (and it is, which is why this chapter exists), it is no longer the default behavior. If you set a minimum or maximum CMake version of 3.15 or better, this will no longer happen unless you set `CMAKE_EXPORT_PACKAGE_REGISTRY`, as mentioned below.
+The default behavior for exporting changed in CMake 3.15. Since changing files in a user's home directory is considered "surprising" (and it is, which is why this chapter exists), it is no longer the default behavior. If you set a minimum or maximum CMake version of 3.15 or later, this will no longer happen unless you set `CMAKE_EXPORT_PACKAGE_REGISTRY` as shown below.
 {% endhint %}
 
-There are three ways to access a project from another project: subdirectory, exported build directories, and installing. To use the build directory of one project in another project, you will need to export targets. Exporting targets is needed for a proper install, allowing the build directory to be used as well is just two added lines. It is not generally a way to work that I would recommend, but can be useful for development and as way to prepare the installation procedure discussed later.
+There are three ways to access a project from another project: subdirectory, exported build directories, and installing. To use the build directory of one project in another project, you will need to export targets. Exporting targets is needed for a proper install; allowing the build directory to be used is just two added lines. It is not generally a way to work that I would recommend, but can be useful for development and as way to prepare the installation procedure discussed later.
 
 You should make an export set, probably near the end of your main `CMakeLists.txt`:
 

chapters/install/packaging.md

@@ -15,7 +15,7 @@ set(CPACK_RESOURCE_FILE_README "${CMAKE_CURRENT_SOURCE_DIR}/README.md")
 
 These are the most common variables you'll need to make a binary package. A binary package uses the install mechanism of CMake, so anything that is installed will be present.
 
-You can also make a source package. You should set `CMAKE_SOUCE_IGNORE_FILES` to regular expressions that ensure you don't pick up any extra files (like the build directory or git details); otherwise `make package_source` will bundle up literally everything in the source directory. You can also set the source generator to make your favorite types of files for source packages:
+You can also make a source package. You should set `CMAKE_SOURCE_IGNORE_FILES` to regular expressions that ensure you don't pick up any extra files (like the build directory or git details); otherwise `make package_source` will bundle up literally everything in the source directory. You can also set the source generator to make your favorite types of files for source packages:
 
 ```cmake
 set(CPACK_SOURCE_GENERATOR "TGZ;ZIP")

chapters/intro/newcmake.md

@@ -97,7 +97,7 @@ This adds CUDA as a language, as well as `cxx_std_11` as a compiler meta-feature
 * `COMPILE_FLAGS` now supports generator expression
 * `*_CPPLINT` added
 * `$<IF:cond,true-value,false-value>` added (wow!)
-* `source_group(TREE` added (finally allowing IDE's to reflect the project folder structure!)
+* `source_group(TREE` added (finally allowing IDEs to reflect the project folder structure!)
 
 ## [CMake 3.9][] : IPO
 

chapters/packages.md

@@ -1,3 +1,3 @@
-# Finding Package
+# Finding Packages
 
-There are two ways to find packages in CMake.
+There are two ways to find packages in CMake: "Module" mode and "Config" mode.

chapters/projects/download.md

@@ -1,8 +1,8 @@
-# GoogleTest: Download method
+# Downloading Projects
 
 ## Downloading Method: build time
 
-Until CMake 3.11, the primary download method for packages was done at build time. This causes several issues; most important of which is that `add_subdirectory` doesn't work on a file that doesn't exist yet! The tool for this, ExternalProject, has to work around this by doing the build itself. (It can, however, build non-CMake packages as well).[^1]
+Until CMake 3.11, the primary download method for packages was done at build time. This causes several issues; most important of which is that `add_subdirectory` doesn't work on a file that doesn't exist yet! The built-in tool for this, ExternalProject, has to work around this by doing the build itself. (It can, however, build non-CMake packages as well).[^1]
 
 
 [^1]: Note that ExternalData is the tool for non-package data.
@@ -11,6 +11,3 @@ Until CMake 3.11, the primary download method for packages was done at build tim
 
 If you prefer configure time, see the [Crascit/DownloadProject](https://github.com/Crascit/DownloadProject) repository for a drop-in solution. Submodules work so well, though, that I've discontinued most of the downloads for things like GoogleTest and moved them to submodules. Auto downloads are harder to mimic if you
 don't have internet access, and they are often implemented in the build directory, wasting time and space if you have multiple build directories. 
-
-
-[DownloadProject]: https://github.com/Crascit/DownloadProject

chapters/testing.md

@@ -10,7 +10,7 @@ if(CMAKE_PROJECT_NAME STREQUAL PROJECT_NAME)
 endif()
 ```
 
-Which will enable testing and set a `BUILD_TESTING` option so users can turn testing on and off (Along with [a few other things](https://gitlab.kitware.com/cmake/cmake/blob/master/Modules/CTest.cmake)). Or you can do this yourself by directly calling `enable_testing()`.
+Which will enable testing and set a `BUILD_TESTING` option so users can turn testing on and off (along with [a few other things](https://gitlab.kitware.com/cmake/cmake/blob/master/Modules/CTest.cmake)). Or you can do this yourself by directly calling `enable_testing()`.
 
 When you add your test folder, you should do something like this:
 

chapters/testing/googletest.md

@@ -94,7 +94,7 @@ package_add_test_with_libraries(test1 test1.cpp lib_to_test "${PROJECT_DIR}/euro
 
 You can use the downloader in my [CMake helper repository][CLIUtils/cmake], using CMake's `include` command.
 
-This is a downloader for [GoogleTest], based on the excellent [DownloadProject] tool. Downloading a copy for each project is the recommended way to use GoogleTest (so much so, in fact, that they have disabled the automatic CMake install target), so this respects that design decision. This method downloads the project at configure time, so that IDE's correctly find the libraries. Using it is simple:
+This is a downloader for [GoogleTest], based on the excellent [DownloadProject] tool. Downloading a copy for each project is the recommended way to use GoogleTest (so much so, in fact, that they have disabled the automatic CMake install target), so this respects that design decision. This method downloads the project at configure time, so that IDEs correctly find the libraries. Using it is simple:
 
 ```cmake
 cmake_minimum_required(VERSION 3.10)

examples/extended-project/CMakeLists.txt

@@ -1,4 +1,4 @@
-# Works with 3.11 and tested through 3.15
+# Works with 3.11 and tested through 3.16
 cmake_minimum_required(VERSION 3.11...3.16)
 
 # Project name and a few useful settings. Other commands can pick up the results
@@ -15,7 +15,7 @@ if(CMAKE_PROJECT_NAME STREQUAL PROJECT_NAME)
     # Let's ensure -std=c++xx instead of -std=g++xx
     set(CMAKE_CXX_EXTENSIONS OFF)
 
-    # Let's nicely support folders in IDE's
+    # Let's nicely support folders in IDEs
     set_property(GLOBAL PROPERTY USE_FOLDERS ON)
 
     # Testing only available if this is the main app
@@ -36,7 +36,7 @@ endif()
 
 # FetchContent added in CMake 3.11, downloads during the configure step
 include(FetchContent)
-# FetchContent_MakeAvailable was not added until CMake 3.14
+# FetchContent_MakeAvailable was not added until CMake 3.14; use our shim
 if(${CMAKE_VERSION} VERSION_LESS 3.14)
     include(cmake/add_FetchContent_MakeAvailable.cmake)
 endif()