| 78ae759 | Brad King | 04 March 2022, 15:52:43 UTC | CMake 3.21.6 | 04 March 2022, 15:52:43 UTC |
| e47e5c7 | Brad King | 03 March 2022, 17:55:33 UTC | Merge branch 'binutils-llvm-ar-clang-macos' into release-3.21 Merge-request: !7039 | 03 March 2022, 17:55:33 UTC |
| 29ea94e | Brad King | 03 March 2022, 17:52:37 UTC | BinUtils: Avoid llvm-ar on Apple platforms Since commit cf82300a63 (BinUtils: Clarify search logic and make it more consistent, 2021-05-27, v3.21.0-rc1~119^2~2) we correctly prefer the more-specific name `llvm-ar` over `ar` when using Clang. However, on Apple platforms, `llvm-ar` does not generate a symbol table that the Apple linker accepts. Fall back to `ar` on Apple platforms. Fixes: #23269 | 03 March 2022, 17:54:10 UTC |
| 02b04f1 | Brad King | 28 February 2022, 18:09:00 UTC | Merge branch 'FindThreads-revert-libc-pthread-flag' into release-3.21 Merge-request: !7025 | 28 February 2022, 18:09:00 UTC |
| c6da90b | Brad King | 28 February 2022, 17:53:15 UTC | FindThreads: Revert "Honor THREADS_PREFER_PTHREAD_FLAG when ... in libc" Revert commit 5efb6fb516 (FindThreads: Honor THREADS_PREFER_PTHREAD_FLAG when pthread is found in libc, 2021-11-03, v3.21.5~4^2). The check for the `-pthread` flag can pass on compilers like XL, that interprets it as `-p -t hread` and returns zero. Prior to that commit, we did not use the check in the `CMAKE_HAVE_LIBC_PTHREAD` code path. Now we do, it succeeds, and we incorrectly add the `-pthread` flag for XL. This change was backported to the 3.21 and 3.22 release series long after they initially came out. Since there may be more cases where we now add `-pthread` incorrectly, it is simplest to revert the change in all release series pending further investigation. Fixes: #23270 | 28 February 2022, 17:53:15 UTC |
| be20a94 | Brad King | 09 February 2022, 15:09:28 UTC | Merge branch 'backport-IntelLLVM-depfile-flags' into release-3.21 Merge-request: !6964 | 09 February 2022, 15:09:28 UTC |
| a8b6bf9 | William R. Dieter | 09 February 2022, 06:10:02 UTC | IntelLLVM: Add dependencies on system header files on Windows In commit a90d2a9eed (IntelLLVM: Add support for Intel LLVM-based compilers, 2020-11-02, v3.20.0-rc1~89^2~20) the IntelLLVM depfile generation flags were taken from `Platform/Windows-Intel-C`. Those flags were added by commit a624a3e1b3 (Ninja: Use deps=gcc for Intel Compiler on Windows, 2019-01-30, v3.14.0-rc1~30^2), which forgot to account for commit 6d74e7870b (Ninja: Add dependencies on system-provided header files, 2016-03-15, v3.6.0-rc1~265^2). The `-QMD` option generates Makefile dependencies. The `-QMMD` option generates Makefile dependencies, but excludes system header files. Part of the BuildDepends test includes a header, cmake_pch.hxx, that includes a second header, zot_pch.hxx. The test builds a pch file for cmake_pch.hxx, touches zot_pch.hxx, then verifes that cmake_pch.hxx.pch is regenerated based on the dependencies. The cmake_pch.hxx contains `#pragma system_header` before it includes zot_pch.hxx. `#pragma system_header` indicates that the portion of the file following the pragma is to be treated as a system header. When `-QMMD` is used to generate dependencies, the `#include` of zot_pch.hxx is ignored because it `-QMMD` says to ignore system headers. Using `-QMD` instead uses all headers when generating dependencies and causes this test to pass. The Clang configuration in Platform/Windows-Clang.cmake also uses the `-MD` option for generating pre-compiled headers, instead of `-MMD`. Signed-off-by: William R. Dieter <william.r.dieter@intel.com> | 09 February 2022, 15:07:51 UTC |
| 94f1bbd | Brad King | 09 February 2022, 15:01:04 UTC | Intel: Add dependencies on system header files on Windows In commit a624a3e1b3 (Ninja: Use deps=gcc for Intel Compiler on Windows, 2019-01-30, v3.14.0-rc1~30^2) we forgot to account for commit 6d74e7870b (Ninja: Add dependencies on system-provided header files, 2016-03-15, v3.6.0-rc1~265^2). | 09 February 2022, 15:07:51 UTC |
| 4423fa2 | Brad King | 09 February 2022, 14:54:18 UTC | Merge branch 'doc-MSVC_TOOLSET_VERSION-v143' into release-3.21 Merge-request: !6966 | 09 February 2022, 14:54:18 UTC |
| dca3a03 | Heiko Thiel | 09 February 2022, 14:07:02 UTC | Help: Add MSVC_TOOLSET_VERSION value for v143 toolset This was accidentally left out of commit f01ea7e391 (MSVC: Fix MSVC_TOOLSET_VERSION for VS 2022 v143 toolset, 2019-04-03, v3.21.3~10^2~1). | 09 February 2022, 14:53:11 UTC |
| 6fe5df1 | Brad King | 01 February 2022, 15:51:25 UTC | CMake 3.21.5 | 01 February 2022, 15:54:10 UTC |
| fc27354 | Brad King | 31 January 2022, 16:36:57 UTC | Merge branch 'release-3.20' into release-3.21 | 31 January 2022, 16:36:57 UTC |
| d647ca1 | Brad King | 31 January 2022, 16:36:42 UTC | Merge branch 'help-try-compile-result-var' into release-3.21 Merge-request: !6923 | 31 January 2022, 16:36:46 UTC |
| d6bfce2 | Brad King | 31 January 2022, 16:35:58 UTC | Merge branch 'help-try-compile-result-var' into release-3.20 Merge-request: !6923 | 31 January 2022, 16:35:58 UTC |
| 34d2632 | friendlyanon | 30 January 2022, 10:27:58 UTC | Help: Drop incorrect versionadded for try_compile result variable In commit c705279bae (Help: Add `.. versionadded` directives to commands documentation, 2020-11-08, v3.20.0-rc1~508^2) we accidentally added ``versionadded`` markup suggesting that the first argument to `try_compile` was fixed as `RESULT_VAR` prior to CMake 3.14. This was probably due to misinterpreting the change from commit 7975edeac5 (Help: User-provided variable names for try_* commands, 2019-02-24, v3.14.0-rc3~16^2~3). The result variable has never been fixed. Drop the incorrect markup. | 31 January 2022, 15:59:56 UTC |
| 9025bde | Brad King | 27 January 2022, 21:25:41 UTC | Merge branch 'message-flush' into release-3.21 Merge-request: !6913 | 27 January 2022, 21:25:41 UTC |
| 634587e | Brad King | 27 January 2022, 20:18:08 UTC | message: Restore explicit flushing of messages on stderr In the `cmake` command-line tool, the `message()` command with no message mode argument prints the message stderr using the C++ `cerr` stream. Since commit 0a0a0f8a74 (cmMessenger: Color messages to terminal by type, 2021-05-18, v3.21.0-rc1~146^2) and an update by commit c7a8c9c811 (cmMessenger: Revert to non-color messages on Windows, 2021-07-20, v3.21.1~15^2), we print the newline at the end of the message using just `\n`. We've now observed some cases of output on stdout and stderr getting jumbled when the two go to the same file descriptor. Previously the newline was printed with `endl`, which implicitly flushes. Flush explicitly to restore that behavior. Fixes: #23155 | 27 January 2022, 21:06:35 UTC |
| fc153c7 | Brad King | 26 January 2022, 13:54:00 UTC | Merge branch 'FindThreads-libc-pthread-flag' into release-3.21 Merge-request: !6906 | 26 January 2022, 13:54:00 UTC |
| 5efb6fb | Mattias Ellert | 03 November 2021, 08:43:37 UTC | FindThreads: Honor THREADS_PREFER_PTHREAD_FLAG when pthread is found in libc The `-pthread` flag tells the compiler/linker to link to additional libraries needed for thread support (e.g. libatomic on riscv64). The flag therefore should be used if requested using `THREADS_PREFER_PTHREAD_FLAG` also when the pthread functions are found in libc. | 26 January 2022, 13:50:16 UTC |
| ece5378 | Brad King | 26 January 2022, 13:45:11 UTC | Merge branch 'nmake-rsp-encoding' into release-3.21 Merge-request: !6905 | 26 January 2022, 13:45:11 UTC |
| d5ee6d5 | Brad King | 26 January 2022, 12:24:02 UTC | NMake: Use UTF-8 BOM in response files only with MSVC tooling Since commit f3f57cc4ed (NMake: Use UTF-8 with BOM if supported by nmake, 2021-04-22, v3.21.0-rc1~217^2), we add a BOM to response files to tell MSVC tooling that they are encoded as UTF-8. However, the "NMake Makefiles" generator may also be used with non-MSVC toolchains that do not understand the BOM. Update the response file encoding selection heuristic to add the BOM only with MSVC tooling. Fixes: #23143 | 26 January 2022, 12:57:43 UTC |
| cab631c | Brad King | 26 January 2022, 12:23:29 UTC | NMake: Document response file encoding heuristic in a comment Since commit f3f57cc4ed (NMake: Use UTF-8 with BOM if supported by nmake, 2021-04-22, v3.21.0-rc1~217^2) the encoding of response files is selected based on the makefile encoding. In principle these may be orthogonal, but in practice it is a useful heuristic. Call out this heuristic in a comment, and leave a FIXME to do something better. | 26 January 2022, 12:40:36 UTC |
| 74f1499 | Brad King | 25 January 2022, 10:43:40 UTC | Merge branch 'ci-xcode-13.2' into release-3.21 Merge-request: !6897 | 25 January 2022, 10:43:40 UTC |
| 8cb32fc | Brad King | 25 January 2022, 10:06:40 UTC | gitlab-ci: update macOS jobs to use Xcode 13.2 | 25 January 2022, 10:06:40 UTC |
| 88198e6 | Brad King | 12 January 2022, 21:53:51 UTC | Merge branch 'vs2022-v143-link-guard-cf' into release-3.21 Merge-request: !6858 | 12 January 2022, 21:53:51 UTC |
| 9e24437 | Benjamin Sluis | 11 January 2022, 15:43:23 UTC | VS: Remove the '/guard:cf' flag from v143 link flag table Apply the change from commit db35e3cfd6 (VS: Fix support for '/guard:cf' linker flag for v142, 2019-01-24, v3.14.0-rc1~74^2~2) to the v143 flag table. The entry for `LinkControlFlowGuard` in `v143_Link.json` does not work when used in a `.vcxproj` file. Drop our link flag table entries for this toolset so that the flag will be passed via `AdditionalOptions`. Also add a test case. | 12 January 2022, 21:45:07 UTC |
| b8e0b40 | Brad King | 15 December 2021, 20:58:43 UTC | Merge branch 'vs-intel-oneapi-toolset' into release-3.21 Merge-request: !6806 | 15 December 2021, 20:58:43 UTC |
| 612c0d4 | William R. Dieter | 09 December 2021, 05:33:25 UTC | VS: Fix detecting icx.exe with Intel Compiler toolsets newer than 2021 The logic added by commit 7808cbd644 (CMakeDetermineCompilerId: support Intel DPC++ compiler toolset for VS gen, 2020-12-06, v3.20.0-rc1~330^2) matches a specific toolset known to be the `icx.exe` compiler, and assumes all other Intel C++ compilers (that are not DPC++) must be `icl.exe`. Since `icx.exe` is officially replacing `icl.exe`, use a regex that matches the now-fixed set of toolsets known to use `icl.exe`. Any other Intel C++ compiler will be assumed to be `icx.exe`. Signed-off-by: William R. Dieter <william.r.dieter@intel.com> | 15 December 2021, 20:56:20 UTC |
| b54d61c | Brad King | 23 November 2021, 00:40:47 UTC | Merge branch 'ci-xcode-13.1' into release-3.21 Merge-request: !6757 | 23 November 2021, 00:40:47 UTC |
| 224d81e | Brad King | 22 November 2021, 23:04:43 UTC | gitlab-ci: update macOS jobs to use Xcode 13.1 | 22 November 2021, 23:04:43 UTC |
| bad7959 | Brad King | 19 November 2021, 17:12:07 UTC | Merge branch 'UseSWIG-create-workingdir' into release-3.21 Merge-request: !6750 | 19 November 2021, 17:12:07 UTC |
| 7224eb5 | Marc Chevrier | 19 November 2021, 16:42:39 UTC | UseSWIG: ensure directory for depfile exists When `Visual Studio` and `Xcode` generators are used, directory for depfile is not implicitely created by CMake when OUTFILE_DIR option is used. Fixes: #22932 | 19 November 2021, 16:50:52 UTC |
| c468f98 | Brad King | 18 November 2021, 14:00:15 UTC | Merge branch 'release-3.20' into release-3.21 | 18 November 2021, 14:00:15 UTC |
| 80b6b20 | Brad King | 17 November 2021, 15:42:51 UTC | Merge branch 'IntelLLVM-Fortran-copy-mod' into release-3.21 Merge-request: !6740 | 17 November 2021, 15:42:51 UTC |
| 7cc7f9a | Brad King | 17 November 2021, 15:42:37 UTC | Merge branch 'IntelLLVM-Fortran-copy-mod' into release-3.20 Merge-request: !6740 | 17 November 2021, 15:42:37 UTC |
| 209b896 | Brad King | 17 November 2021, 15:35:12 UTC | IntelLLVM: Enable Fortran module rebuild avoidance in Makefile generators The Makefile generators use an internal `cmake -E cmake_copy_f90_mod` tool to avoid rebuilding module consumers when the `.mod` content changes only in a trivial way (e.g. the time it was built). This is done with logic specific to each vendor's module file format. Enable the "Intel" format support when using the IntelLLVM compiler (ifx) too. Issue: #22922 | 17 November 2021, 15:41:30 UTC |
| bb48c75 | Brad King | 12 November 2021, 13:59:43 UTC | Merge branch 'release-3.20' into release-3.21 | 12 November 2021, 13:59:43 UTC |
| 521c49e | Brad King | 11 November 2021, 16:24:01 UTC | Merge branch 'IntelLLVM-Fortran-frontend-variant' into release-3.21 Merge-request: !6718 | 11 November 2021, 16:24:01 UTC |
| 09ef62f | Brad King | 11 November 2021, 16:23:35 UTC | Merge branch 'IntelLLVM-Fortran-frontend-variant' into release-3.20 Merge-request: !6718 | 11 November 2021, 16:23:35 UTC |
| b1edd6e | William R. Dieter | 06 November 2021, 05:11:35 UTC | Fortran: Save frontend variant persistently for IntelLLVM Since commit a90d2a9eed (IntelLLVM: Add support for Intel LLVM-based compilers, 2020-11-02, v3.20.0-rc1~89^2~20), our IntelLLVM compiler support populates `CMAKE_Fortran_COMPILER_FRONTEND_VARIANT`. However, the frontend variant was not stored in `CMakeCompilerFortran.cmake`. Signed-off-by: William R. Dieter <william.r.dieter@intel.com> | 11 November 2021, 16:22:07 UTC |
| b0ee343 | Brad King | 10 November 2021, 18:43:41 UTC | Merge branch 'IntelLLVM-no-xilink' into release-3.21 Merge-request: !6719 | 10 November 2021, 18:43:41 UTC |
| 48f29b5 | William R. Dieter | 25 September 2021, 00:31:05 UTC | IntelLLVM: Use MSVC linker with MSVC frontend variant The Intel compiler (pre-LLVM) expected xilink.exe and had special logic to set xilink.exe. The newer LLVM-based compiler does not want xilink.exe. link.exe works better for host code, and is the default, so change the matching condition such that the old compiler matches (and gets xilink.exe) and the new compiler gets the default link.exe it expects. A better solution will be to use the compiler as the linker. A future change will switch to compiler as linker by default, but that fix needs more validation. Signed-off-by: William R. Dieter <william.r.dieter@intel.com> | 10 November 2021, 18:41:06 UTC |
| d18ba5b | Brad King | 03 November 2021, 20:18:29 UTC | Merge branch 'doc-TARGET_RUNTIME_DLLS' into release-3.21 Merge-request: !6700 | 03 November 2021, 20:18:29 UTC |
| 001870d | Brad King | 03 November 2021, 19:51:35 UTC | Help: Clarify TARGET_RUNTIME_DLLS behavior on imported targets This generator expression does not report the locations of `.dll` files on imported targets with the `UNKNWON` type, since their `IMPORTED_LOCATION` refers to the import library and not the DLL. Fixes: #22845 | 03 November 2021, 20:17:17 UTC |
| 6202af6 | Brad King | 03 November 2021, 14:51:37 UTC | Merge branch 'msvc-cxx-modules-scanDependencies' into release-3.21 Merge-request: !6696 | 03 November 2021, 14:51:37 UTC |
| 9ed1d7b | Brad King | 03 November 2021, 14:50:54 UTC | cmScanDepFormat: Accept P1689r4 files with version 1 VS 2022's `cl` 19.30 has a `-scanDependencies` option that produces the P1689r4 format. It reports the "version" field with value "1". | 03 November 2021, 14:50:54 UTC |
| ac5932c | Brad King | 03 November 2021, 14:34:05 UTC | Merge branch 'GNUtoMS-vs2022' into release-3.21 Merge-request: !6695 | 03 November 2021, 14:34:05 UTC |
| 571a795 | Brad King | 03 November 2021, 14:31:19 UTC | GNUtoMS: Add search path for VS 2022 environment scripts Extend the logic from commit 08c5b3eff0 (GNUtoMS: Add search path for VS 2019 environment scripts, 2020-01-09, v3.16.3~15^2) to consider VS 2022 paths too. Fixes: #22847 | 03 November 2021, 14:32:14 UTC |
| f65cebf | Brad King | 27 October 2021, 13:51:39 UTC | CMake 3.21.4 | 27 October 2021, 13:51:39 UTC |
| 9d44ea4 | Brad King | 27 October 2021, 13:00:58 UTC | Merge branch 'backport-3.21-vs2022' into release-3.21 Merge-request: !6664 | 27 October 2021, 13:00:58 UTC |
| f3ddc52 | Brad King | 26 October 2021, 17:06:57 UTC | VS: Update Visual Studio 17 2022 generator for the Release Candidates Assume this is close enough to the final release to treat as non-experimental support. | 27 October 2021, 12:49:47 UTC |
| 69355ff | Brad King | 22 October 2021, 13:25:24 UTC | Merge branch 'binutils-llvm-strip' into release-3.21 Merge-request: !6655 | 22 October 2021, 13:25:24 UTC |
| 5dd9815 | Brad King | 22 October 2021, 13:14:51 UTC | BinUtils: Avoid llvm-strip versions older than Clang 11 Since commit cf82300a63 (BinUtils: Clarify search logic and make it more consistent, 2021-05-27, v3.21.0-rc1~119^2~2) we correctly prefer the more-specific name `llvm-strip` over `strip` when using Clang. However, `llvm-strip` from Clang versions prior to 11 require extra flags to strip everything. Until our `install(TARGETS)` logic learns to add those flags, avoid using older versions of `llvm-strip` by default. Fixes: #22785 | 22 October 2021, 13:24:46 UTC |
| 69c6994 | Brad King | 19 October 2021, 13:34:06 UTC | Merge branch 'backport-3.21-vs2022' into release-3.21 Merge-request: !6640 | 19 October 2021, 13:35:50 UTC |
| 3d9d75b | Brad King | 19 October 2021, 13:27:37 UTC | VS: Update Visual Studio 17 2022 generator for the Release Candidate | 19 October 2021, 13:27:37 UTC |
| 71dc6fe | Brad King | 15 October 2021, 16:15:15 UTC | Merge branch 'release-3.20' into release-3.21 | 15 October 2021, 16:15:15 UTC |
| e8e64e1 | Brad King | 15 October 2021, 16:15:05 UTC | Merge branch 'release-3.19' into release-3.20 | 15 October 2021, 16:15:05 UTC |
| 8497701 | Brad King | 15 October 2021, 16:14:50 UTC | Merge branch 'fix-ifdef-windows' into release-3.21 Merge-request: !6631 | 15 October 2021, 16:14:50 UTC |
| ad76bed | Brad King | 15 October 2021, 16:14:38 UTC | Merge branch 'fix-ifdef-windows' into release-3.20 Merge-request: !6631 | 15 October 2021, 16:14:38 UTC |
| f00763c | Brad King | 15 October 2021, 16:13:59 UTC | Merge branch 'fix-ifdef-windows' into release-3.19 Merge-request: !6631 | 15 October 2021, 16:13:59 UTC |
| 40e73c5 | Brad King | 15 October 2021, 15:33:00 UTC | Source: Fix typo in _WIN32 preprocessor checks Since CMake's default compiler flags with MSVC include `-DWIN32` for historical reasons, a few preprocessor conditions were accidentally checking for `WIN32` instead of `_WIN32`. The corresponding blocks were left out when compiling official binaries for `cmake.org` because we hard-code compiler flags without `-DWIN32`. Fixes: #22764 | 15 October 2021, 15:39:04 UTC |
| 4d4336e | Brad King | 14 October 2021, 17:49:46 UTC | Merge branch 'backport-3.21-vs2022' into release-3.21 Merge-request: !6628 | 14 October 2021, 17:50:11 UTC |
| a841419 | Brad King | 14 October 2021, 17:38:44 UTC | VS: Update Visual Studio 17 2022 generator for Preview 5 | 14 October 2021, 17:39:45 UTC |
| 787ab7f | Brad King | 14 October 2021, 16:36:51 UTC | IRSL: Fix discovery of VS 2022 v143 toolset redistributables for preview 5 VS 2022 Preview 5 renamed the redist directories from `Microsoft.VC142.*` to `Microsoft.VC143.*` in order to match the `v143` toolset name. Fixes: #22586 | 14 October 2021, 17:37:05 UTC |
| 69f3fa9 | Brad King | 14 October 2021, 14:51:56 UTC | Merge branch 'release-3.20' into release-3.21 | 14 October 2021, 14:51:56 UTC |
| cd44a5b | Brad King | 14 October 2021, 14:51:43 UTC | Merge branch 'zstd-armv6' into release-3.21 Merge-request: !6625 | 14 October 2021, 14:51:43 UTC |
| 6a8531a | Brad King | 14 October 2021, 14:51:05 UTC | Merge branch 'zstd-armv6' into release-3.20 Merge-request: !6625 | 14 October 2021, 14:51:05 UTC |
| e4e4c59 | Brad King | 14 October 2021, 14:35:52 UTC | zstd: Backport fix for SIGBUS on armv6 from zstd 1.5.0 Backport zstd commit `28d0120b` (Avoid SIGBUS on armv6, 2021-05-11, `v1.5.0^2~11^2`) to our bundled copy of zstd 1.4.5. Fixes: #22754 | 14 October 2021, 14:35:52 UTC |
| f07bedb | Brad King | 12 October 2021, 13:36:09 UTC | Merge branch 'release-3.20' into release-3.21 | 12 October 2021, 13:36:09 UTC |
| 568a93d | Brad King | 12 October 2021, 13:35:56 UTC | Merge branch 'msvc-c++23' into release-3.21 Merge-request: !6614 | 12 October 2021, 13:35:56 UTC |
| e19016c | Brad King | 12 October 2021, 13:35:32 UTC | Merge branch 'msvc-c++23' into release-3.20 Merge-request: !6614 | 12 October 2021, 13:35:32 UTC |
| f6ec46a | Brad King | 08 October 2021, 13:47:33 UTC | Merge branch 'release-3.20' into release-3.21 | 08 October 2021, 13:47:33 UTC |
| de99806 | Brad King | 08 October 2021, 13:46:51 UTC | Merge branch 'release-3.19' into release-3.20 | 08 October 2021, 13:46:51 UTC |
| ac910db | Brad King | 08 October 2021, 13:46:39 UTC | Merge branch 'revert-debian-libexec' into release-3.20 Merge-request: !6607 | 08 October 2021, 13:46:39 UTC |
| c352d16 | Brad King | 08 October 2021, 13:46:09 UTC | Merge branch 'revert-debian-libexec' into release-3.19 Merge-request: !6607 | 08 October 2021, 13:46:09 UTC |
| 1a47305 | Brad King | 08 October 2021, 13:44:56 UTC | Merge topic 'revert-debian-libexec' into release-3.21 6658e260d4 GNUInstallDirs: Fix misinterpretation of Debian Policy on LIBEXECDIR Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !6607 | 08 October 2021, 13:45:10 UTC |
| 6658e26 | Timo Röhling | 07 October 2021, 17:45:39 UTC | GNUInstallDirs: Fix misinterpretation of Debian Policy on LIBEXECDIR Revert commit 798c1c3192 (GNUInstallDirs: Comply with Debian Policy on LIBEXECDIR, 2020-10-08, v3.19.0-rc1~11^2). The Debian Policy builds upon FHS 3.0 and permits installing to `/usr/libexec`. While Policy does grant an additional exception for applications to use a single subdirectory of `/usr/lib/<triplet>`, this is not meant to replace `/usr/libexec` as valid target. Fixes: #22731 | 07 October 2021, 18:29:18 UTC |
| ef47e18 | Brad King | 07 October 2021, 15:37:59 UTC | MSVC: Tolerate cxx_std_23 feature on older compiler versions In commit 3aaf1d91bf (MSVC: C++20 final flag, C++23 support, 2021-05-29, v3.20.4~7^2~1) we forgot to add `cxx_std_23` to the fallback table for MSVC versions from VS 2010 through VS 2015. This allows project to at least attempt compilation with these compilers since they do not have any modes. Issue: #22729 | 07 October 2021, 15:46:09 UTC |
| 2104c19 | Brad King | 07 October 2021, 13:11:04 UTC | Merge topic 'corret_nvhpc_fortran_compile_deps' into release-3.21 1a828043b7 NVHPC: only use '-MD' for the C and CXX languages Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !6602 | 07 October 2021, 13:11:20 UTC |
| 1a82804 | Robert Maynard | 06 October 2021, 20:21:29 UTC | NVHPC: only use '-MD' for the C and CXX languages CMake shouldn't use '-MD' for nvfortran to generate dependency information. Fixes #22723 | 06 October 2021, 20:21:29 UTC |
| b82e7ed | Brad King | 06 October 2021, 14:28:43 UTC | Merge topic 'bootstrap-qt6' into release-3.21 6458a32242 bootstrap: Enable cmake_language command to support cmake-gui with Qt 6.2 Acked-by: Kitware Robot <kwrobot@kitware.com> Reviewed-by: Andrew Maclean <andrew.amaclean@gmail.com> Merge-request: !6593 | 06 October 2021, 14:28:59 UTC |
| cd51eba | Brad King | 06 October 2021, 14:26:22 UTC | Merge topic 'cpack-qtifw-4.1' into release-3.21 5895f236ae CPack/IFW: Add support for QtIFW 4.1 Acked-by: Kitware Robot <kwrobot@kitware.com> Acked-by: Konstantin Podsvirov <konstantin@podsvirov.pro> Merge-request: !6592 | 06 October 2021, 14:26:35 UTC |
| 1e3cc4b | Brad King | 06 October 2021, 14:25:18 UTC | Merge topic 'ci-xcode-13.0' into release-3.21 429522e89c gitlab-ci: update macOS jobs to use Xcode 13.0 75901f0472 Tests: Fix RunCMake.XcodeProject XcodeIOSInstallCombined cases for Xcode 13.0 Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !6578 | 06 October 2021, 14:25:30 UTC |
| 5eef6ca | Brad King | 06 October 2021, 14:24:01 UTC | Merge topic 'xcode13-schema' into release-3.21 0e86fea0be Tests: Specify destination for Xcode scheme Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !6582 | 06 October 2021, 14:24:15 UTC |
| 15f405c | Brad King | 06 October 2021, 14:22:12 UTC | Merge topic 'ci-ctest-update' into release-3.21 3b581ab3aa ci: Enable CTest.Update{CVS,SVN,HG} tests Acked-by: Kitware Robot <kwrobot@kitware.com> Acked-by: Ben Boeckel <ben.boeckel@kitware.com> Merge-request: !6596 | 06 October 2021, 14:22:21 UTC |
| 3b581ab | Brad King | 05 October 2021, 14:21:57 UTC | ci: Enable CTest.Update{CVS,SVN,HG} tests Enable all three in Debian builds. Leave out CVS in Fedora builds because the cvs package was not built with `--enable-rootcommit`. | 05 October 2021, 15:06:42 UTC |
| 6458a32 | Brad King | 05 October 2021, 13:47:19 UTC | bootstrap: Enable cmake_language command to support cmake-gui with Qt 6.2 Fixes: #22721 | 05 October 2021, 13:48:46 UTC |
| 5895f23 | Erlend E. Aasland | 05 October 2021, 07:12:15 UTC | CPack/IFW: Add support for QtIFW 4.1 Fixes: #22722 | 05 October 2021, 13:18:52 UTC |
| 429522e | Brad King | 30 September 2021, 14:37:05 UTC | gitlab-ci: update macOS jobs to use Xcode 13.0 | 05 October 2021, 13:13:23 UTC |
| 75901f0 | Brad King | 30 September 2021, 15:46:56 UTC | Tests: Fix RunCMake.XcodeProject XcodeIOSInstallCombined cases for Xcode 13.0 The output of `otool -vf` now contains additional content that happens to be matched by our architectures regex. Make the regex more strict. | 05 October 2021, 13:13:23 UTC |
| 7518fc0 | Brad King | 05 October 2021, 13:01:49 UTC | Merge topic 'testdriver-old-cast-warning' into release-3.21 ba54092842 TestDriver: Fix old-style-cast warning in C++ mode Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !6590 | 05 October 2021, 13:01:59 UTC |
| 0e86fea | Gregor Jasny | 01 October 2021, 08:04:48 UTC | Tests: Specify destination for Xcode scheme The `Using the first of multiple matching destinations` warning vanishes if we explicitly specify a destination. Fixes: #22704 | 05 October 2021, 11:38:48 UTC |
| ba54092 | Sylvain Joubert | 04 October 2021, 13:28:18 UTC | TestDriver: Fix old-style-cast warning in C++ mode A C-style cast was added by commit 3f6ff4b5db (create_test_sourcelist: add test driver option to run all tests, 2021-04-27, v3.21.0-rc1~257^2). Use our `CM_CAST` macro to adapt based on the language. | 04 October 2021, 15:00:12 UTC |
| d1a7e78 | Brad King | 04 October 2021, 14:35:29 UTC | Merge topic 'FortranCInterface-timestamp-check' into release-3.21 2a00e5072d FortranCInterface: Fix regression in timestamp check Acked-by: Kitware Robot <kwrobot@kitware.com> Acked-by: Craig Scott <craig.scott@crascit.com> Merge-request: !6581 | 04 October 2021, 14:36:51 UTC |
| 2a00e50 | Seth R Johnson | 01 October 2021, 01:48:26 UTC | FortranCInterface: Fix regression in timestamp check Since commit d7c8030541 (FortranCInterface: Fix misuse of IS_NEWER_THAN in timestamp check, 2021-02-21, v3.21.0-rc1~631^2~3), FortranCInterface checks for `Output.cmake.in` in the build tree instead of the source tree as before. This caused it to always re-run the detection. Fixes: #22709 | 01 October 2021, 17:00:18 UTC |
| 12b999e | Brad King | 27 September 2021, 17:48:33 UTC | Merge topic 'autogen-dep-on-imported-implib-only-target' into release-3.21 895fa3433f cmQtAutoGenInitializer: support IMPLIB-only imported targets 354c1f5628 Tests/RunCMake/Autogen: test CMP0111 behavior Acked-by: Kitware Robot <kwrobot@kitware.com> Tested-by: buildbot <buildbot@kitware.com> Merge-request: !6558 | 27 September 2021, 17:48:56 UTC |
| 895fa34 | Ben Boeckel | 23 September 2021, 21:05:22 UTC | cmQtAutoGenInitializer: support IMPLIB-only imported targets Instead of using the target name directly (which ends up in the `Ninja` generators querying for the `LOCATION` parameter), wrap up the target name in a `$<TARGET_LINKER_FILE:>` to avoid the query for the unset property. | 24 September 2021, 15:29:54 UTC |
| 354c1f5 | Ben Boeckel | 23 September 2021, 21:05:03 UTC | Tests/RunCMake/Autogen: test CMP0111 behavior On Windows, imported shared libraries which only have an `IMPORTED_IMPLIB` set fail if they are depended upon by a target using automoc. Add a test for the behavior of depending upon all imported target types from an automoc-using target. | 24 September 2021, 15:29:54 UTC |
| afd4d25 | Brad King | 24 September 2021, 13:14:03 UTC | Merge topic 'FindMatlab-r2021b' into release-3.21 a013404f43 FindMatlab: Add R2021b => 9.11 version Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !6556 | 24 September 2021, 13:14:19 UTC |
| a013404 | Michael Hirsch | 23 September 2021, 02:56:09 UTC | FindMatlab: Add R2021b => 9.11 version R2021b released 09/22/2021. | 23 September 2021, 14:41:20 UTC |
