| 97073b1 | Brad King | 01 June 2022, 13:53:26 UTC | CMake 3.21.7 | 01 June 2022, 13:53:26 UTC |
| 245edf3 | Brad King | 31 May 2022, 15:56:27 UTC | Merge branch 'release-3.20' into release-3.21 | 31 May 2022, 15:56:27 UTC |
| 7b3d228 | Brad King | 27 May 2022, 16:01:58 UTC | Merge branch 'cmake-gui-locale' into release-3.21 Merge-request: !7303 | 27 May 2022, 16:02:01 UTC |
| a539aed | Brad King | 27 May 2022, 16:01:41 UTC | Merge branch 'cmake-gui-locale' into release-3.20 Merge-request: !7303 | 27 May 2022, 16:01:41 UTC |
| ae13524 | Brad King | 27 May 2022, 14:51:24 UTC | cmake-gui: Restore support for internationalization with Qt5 on Windows Restore the logic removed by commit 035078d847 (cmake-gui: Remove explicit locale setup, 2020-12-17, v3.20.0-rc1~205^2~6), but only with Qt5 on Windows. Leave a FIXME comment to support Qt6 later. Fixes: #23562 Issue: #23565 | 27 May 2022, 15:52:51 UTC |
| f334235 | Brad King | 19 May 2022, 21:55:04 UTC | Merge branch 'vs2022-only' into release-3.21 Merge-request: !7282 | 19 May 2022, 21:55:04 UTC |
| 235b5fb | Brad King | 19 May 2022, 21:23:37 UTC | file(GET_RUNTIME_DEPENDENCIES): Support VS 2022 without VS 2019 Find MSVC tools in VS 2022 installation. | 19 May 2022, 21:50:06 UTC |
| adcb98c | Brad King | 26 April 2022, 15:12:02 UTC | Merge branch 'ci-xcode-13.3' into release-3.21 Merge-request: !7204 | 26 April 2022, 15:12:02 UTC |
| 65b6daf | Brad King | 25 April 2022, 17:16:57 UTC | gitlab-ci: update macOS jobs to use Xcode 13.3 | 25 April 2022, 19:52:15 UTC |
| 94361a1 | Gregor Jasny | 03 April 2022, 19:58:22 UTC | Tests: Ignore all classes in Xcode internal objc warnings Xcode on Apple Silicon warns not only about AMSupportURL classes but also many more. | 25 April 2022, 19:52:15 UTC |
| da9f864 | Brad King | 16 February 2022, 16:21:54 UTC | Tests: Teach RunCMake to ignore Xcode extension point warnings On some Xcode versions, `xcodebuild` may warn: ... xcodebuild[...] Requested but did not find extension point with identifier ... Teach RunCMake to drop such incidental lines before matching against expected output. | 25 April 2022, 18:35:11 UTC |
| 024204f | Brad King | 26 March 2022, 12:36:17 UTC | Merge branch 'aix-exe-exports' into release-3.21 Merge-request: !7120 | 26 March 2022, 12:36:17 UTC |
| a8dae21 | Brad King | 26 March 2022, 12:23:36 UTC | AIX: Fix executable ENABLE_EXPORTS in Makefile generators In commit afcd9fe669 (AIX: Add an option to disable automatic exports from shared libraries, 2020-01-30, v3.17.0-rc1~47^2) the population of the `<AIX_EXPORTS>` rule variable placeholder was accidentally added to the device linking rule rather than the main linking rule. This caused our `ExportImportList` script on AIX, when called for executables with `ENABLE_EXPORTS` set, to be given an `AIX_EXPORTS` file name that does not exist, leading to a warning from the `dump` tool. Move the population of the `<AIX_EXPORTS>` placeholder in the Makefile generators to the main link rule. Issue: #20290 | 26 March 2022, 12:28:59 UTC |
| f71e89a | Brad King | 21 March 2022, 18:13:31 UTC | Merge branch 'rel-win-docker' into release-3.21 Merge-request: !7087 | 21 March 2022, 18:13:31 UTC |
| a6aa88e | Brad King | 18 March 2022, 13:47:20 UTC | Utilities/Release: Add "source" stage to Windows docker spec Revise the spec added by commit ff929badb3 (Utilities/Release: Add docker specs to build and test Windows binaries, 2020-05-05, v3.18.0-rc1~203^2~1) to add a `source` stage that stops just after copying the source tree into the image. This provides more granular control to driving scripts. | 18 March 2022, 13:50:55 UTC |
| 12e03d7 | Brad King | 16 March 2022, 14:50:43 UTC | Merge branch 'binutils-llvm-ar-apple' into release-3.21 Merge-request: !7077 | 16 March 2022, 14:50:43 UTC |
| fee36b7 | Brad King | 15 March 2022, 20:58:45 UTC | BinUtils: Restore llvm-ar fallback on Apple platforms Since commit 29ea94e17c (BinUtils: Avoid llvm-ar on Apple platforms, 2022-03-03, v3.21.6~1^2) we do not consider `llvm-ar` at all on Apple platforms. However, there are existing cross-compiling use cases in which the toolchain has `llvm-ar` but not `ar`. Prior to the re-ordering in commit cf82300a63 (BinUtils: Clarify search logic and make it more consistent, 2021-05-27, v3.21.0-rc1~119^2~2), we preferred `ar` and then `llvm-ar`. Restore the original order for Apple. Fixes: #23320 | 16 March 2022, 14:46:11 UTC |
| bb99538 | Brad King | 11 March 2022, 15:33:02 UTC | Merge branch 'AppleClang-cxx20-cxx23-flags' into release-3.21 Merge-request: !7063 | 11 March 2022, 15:33:02 UTC |
| 683e4e9 | Ken Matsui | 11 March 2022, 12:51:25 UTC | AppleClang: Add C++20 and C++23 flags Follow up commit 886e27062b (Clang/MSVC: C++20 final flag, C++23 support, 2021-05-29, v3.20.4~7^2) with support for AppleClang. | 11 March 2022, 15:00:21 UTC |
| 33ed5b9 | Brad King | 08 March 2022, 16:54:58 UTC | Merge branch 'binutils-llvm-mt' into release-3.21 Merge-request: !7054 | 08 March 2022, 16:54:58 UTC |
| 73d0d4e | Brad King | 08 March 2022, 16:44:45 UTC | BinUtils: Avoid llvm-mt because it is missing 'mt' features we use 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-mt` over `mt` when using Clang. However, the `llvm-mt` tool does not yet support all the flags we need in the implementation of `vs_link_{exe,dll}`. Prefer plain `mt` for now. Fixes: #23305 | 08 March 2022, 16:48:30 UTC |
| 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 |
