summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* Help: Add MSVC_TOOLSET_VERSION value for v143 toolsetHeiko Thiel2022-02-091-0/+1
| | | | | | 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).
* CMake 3.21.5v3.21.5Brad King2022-02-012-1/+8
|
* Merge branch 'release-3.20' into release-3.21Brad King2022-01-310-0/+0
|\
| * Merge branch 'help-try-compile-result-var' into release-3.20Brad King2022-01-312-13/+0
| |\ | | | | | | | | | Merge-request: !6923
* | \ Merge branch 'help-try-compile-result-var' into release-3.21Brad King2022-01-312-13/+0
|\ \ \ | | |/ | |/| | | | Merge-request: !6923
| * | Help: Drop incorrect versionadded for try_compile result variablefriendlyanon2022-01-312-13/+0
| |/ | | | | | | | | | | | | | | | | | | | | | | 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.
* | Merge branch 'message-flush' into release-3.21Brad King2022-01-271-2/+2
|\ \ | | | | | | | | | Merge-request: !6913
| * | message: Restore explicit flushing of messages on stderrBrad King2022-01-271-2/+2
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | Merge branch 'FindThreads-libc-pthread-flag' into release-3.21Brad King2022-01-261-8/+11
|\ \ | | | | | | | | | Merge-request: !6906
| * | FindThreads: Honor THREADS_PREFER_PTHREAD_FLAG when pthread is found in libcMattias Ellert2022-01-261-8/+11
| | | | | | | | | | | | | | | | | | | | | | | | 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.
* | | Merge branch 'nmake-rsp-encoding' into release-3.21Brad King2022-01-261-2/+15
|\ \ \ | |/ / |/| | | | | Merge-request: !6905
| * | NMake: Use UTF-8 BOM in response files only with MSVC toolingBrad King2022-01-261-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
| * | NMake: Document response file encoding heuristic in a commentBrad King2022-01-261-2/+10
|/ / | | | | | | | | | | | | | | 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.
* | Merge branch 'ci-xcode-13.2' into release-3.21Brad King2022-01-251-6/+6
|\ \ | | | | | | | | | Merge-request: !6897
| * | gitlab-ci: update macOS jobs to use Xcode 13.2Brad King2022-01-251-6/+6
|/ /
* | Merge branch 'vs2022-v143-link-guard-cf' into release-3.21Brad King2022-01-124-7/+48
|\ \ | | | | | | | | | Merge-request: !6858
| * | VS: Remove the '/guard:cf' flag from v143 link flag tableBenjamin Sluis2022-01-124-7/+48
|/ / | | | | | | | | | | | | | | | | | | | | | | 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.
* | Merge branch 'vs-intel-oneapi-toolset' into release-3.21Brad King2021-12-151-5/+3
|\ \ | | | | | | | | | Merge-request: !6806
| * | VS: Fix detecting icx.exe with Intel Compiler toolsets newer than 2021William R. Dieter2021-12-151-5/+3
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Merge branch 'ci-xcode-13.1' into release-3.21Brad King2021-11-231-6/+6
|\ \ | | | | | | | | | Merge-request: !6757
| * | gitlab-ci: update macOS jobs to use Xcode 13.1Brad King2021-11-221-6/+6
|/ /
* | Merge branch 'UseSWIG-create-workingdir' into release-3.21Brad King2021-11-192-1/+2
|\ \ | | | | | | | | | Merge-request: !6750
| * | UseSWIG: ensure directory for depfile existsMarc Chevrier2021-11-192-1/+2
|/ / | | | | | | | | | | | | 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
* | Merge branch 'release-3.20' into release-3.21Brad King2021-11-180-0/+0
|\ \ | |/
| * Merge branch 'IntelLLVM-Fortran-copy-mod' into release-3.20Brad King2021-11-171-1/+1
| |\ | | | | | | | | | Merge-request: !6740
* | \ Merge branch 'IntelLLVM-Fortran-copy-mod' into release-3.21Brad King2021-11-171-1/+1
|\ \ \ | | |/ | |/| | | | Merge-request: !6740
| * | IntelLLVM: Enable Fortran module rebuild avoidance in Makefile generatorsBrad King2021-11-171-1/+1
| |/ | | | | | | | | | | | | | | | | | | 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
* | Merge branch 'release-3.20' into release-3.21Brad King2021-11-120-0/+0
|\ \ | |/
| * Merge branch 'IntelLLVM-Fortran-frontend-variant' into release-3.20Brad King2021-11-111-0/+1
| |\ | | | | | | | | | Merge-request: !6718
* | \ Merge branch 'IntelLLVM-Fortran-frontend-variant' into release-3.21Brad King2021-11-111-0/+1
|\ \ \ | | |/ | |/| | | | Merge-request: !6718
| * | Fortran: Save frontend variant persistently for IntelLLVMWilliam R. Dieter2021-11-111-0/+1
| |/ | | | | | | | | | | | | | | | | 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>
* | Merge branch 'IntelLLVM-no-xilink' into release-3.21Brad King2021-11-101-1/+1
|\ \ | | | | | | | | | Merge-request: !6719
| * | IntelLLVM: Use MSVC linker with MSVC frontend variantWilliam R. Dieter2021-11-101-1/+1
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Merge branch 'doc-TARGET_RUNTIME_DLLS' into release-3.21Brad King2021-11-032-2/+14
|\ \ | | | | | | | | | Merge-request: !6700
| * | Help: Clarify TARGET_RUNTIME_DLLS behavior on imported targetsBrad King2021-11-032-2/+14
| | | | | | | | | | | | | | | | | | | | | | | | 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
* | | Merge branch 'msvc-cxx-modules-scanDependencies' into release-3.21Brad King2021-11-031-1/+1
|\ \ \ | | | | | | | | | | | | Merge-request: !6696
| * | | cmScanDepFormat: Accept P1689r4 files with version 1Brad King2021-11-031-1/+1
| |/ / | | | | | | | | | | | | VS 2022's `cl` 19.30 has a `-scanDependencies` option that produces the P1689r4 format. It reports the "version" field with value "1".
* | | Merge branch 'GNUtoMS-vs2022' into release-3.21Brad King2021-11-031-1/+1
|\ \ \ | |/ / |/| | | | | Merge-request: !6695
| * | GNUtoMS: Add search path for VS 2022 environment scriptsBrad King2021-11-031-1/+1
|/ / | | | | | | | | | | | | | | 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
* | CMake 3.21.4v3.21.4Brad King2021-10-271-1/+1
| |
* | Merge branch 'backport-3.21-vs2022' into release-3.21Brad King2021-10-272-10/+10
|\ \ | | | | | | | | | Merge-request: !6664
| * | VS: Update Visual Studio 17 2022 generator for the Release CandidatesBrad King2021-10-272-10/+10
| | | | | | | | | | | | | | | Assume this is close enough to the final release to treat as non-experimental support.
* | | Merge branch 'binutils-llvm-strip' into release-3.21Brad King2021-10-221-1/+4
|\ \ \ | | | | | | | | | | | | Merge-request: !6655
| * | | BinUtils: Avoid llvm-strip versions older than Clang 11Brad King2021-10-221-1/+4
|/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | | Merge branch 'backport-3.21-vs2022' into release-3.21Brad King2021-10-192-4/+4
|\ \ \ | |/ / | | | | | | Merge-request: !6640
| * | VS: Update Visual Studio 17 2022 generator for the Release CandidateBrad King2021-10-192-4/+4
|/ /
* | Merge branch 'release-3.20' into release-3.21Brad King2021-10-150-0/+0
|\ \ | |/
| * Merge branch 'release-3.19' into release-3.20Brad King2021-10-150-0/+0
| |\
| | * Merge branch 'fix-ifdef-windows' into release-3.19Brad King2021-10-154-4/+4
| | |\ | | | | | | | | | | | | Merge-request: !6631
| * | \ Merge branch 'fix-ifdef-windows' into release-3.20Brad King2021-10-154-4/+4
| |\ \ \ | | | |/ | | |/| | | | | Merge-request: !6631
generated by cgit v0.12 at 2025-09-12 20:06:45 (GMT)