summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* CMake 3.21.6v3.21.6Brad King2022-03-042-4/+4
|
* Merge branch 'binutils-llvm-ar-clang-macos' into release-3.21Brad King2022-03-031-1/+4
|\ | | | | | | Merge-request: !7039
| * BinUtils: Avoid llvm-ar on Apple platformsBrad King2022-03-031-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-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
* Merge branch 'FindThreads-revert-libc-pthread-flag' into release-3.21Brad King2022-02-281-11/+8
|\ | | | | | | Merge-request: !7025
| * FindThreads: Revert "Honor THREADS_PREFER_PTHREAD_FLAG when ... in libc"Brad King2022-02-281-11/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | Merge branch 'backport-IntelLLVM-depfile-flags' into release-3.21Brad King2022-02-093-3/+3
|\ \ | | | | | | | | | Merge-request: !6964
| * | IntelLLVM: Add dependencies on system header files on WindowsWilliam R. Dieter2022-02-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | Intel: Add dependencies on system header files on WindowsBrad King2022-02-092-2/+2
| |/ | | | | | | | | | | | | 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).
* | Merge branch 'doc-MSVC_TOOLSET_VERSION-v143' into release-3.21Brad King2022-02-091-0/+1
|\ \ | |/ |/| | | Merge-request: !6966
| * 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-221-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
View Lorry Controller Status