Merge-request: !6923

Merge-request: !6923

friendlyanon authored 3 years ago and Brad King committed 3 years ago

In commit c705279b (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 7975edea (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-request: !6913

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 0a0a0f8a (cmMessenger: Color messages to
terminal by type, 2021-05-18, v3.21.0-rc1~146^2) and an update by
commit c7a8c9c8 (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-request: !6906

Mattias Ellert authored 3 years ago and Brad King committed 3 years ago

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-request: !6905

Since commit f3f57cc4 (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

Since commit f3f57cc4 (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-request: !6897

Merge-request: !6858

Benjamin Sluis authored 3 years ago and Brad King committed 3 years ago

Apply the change from commit db35e3cf (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-request: !6806

William R. Dieter authored 3 years ago and Brad King committed 3 years ago

The logic added by commit 7808cbd6 (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-request: !6757

Merge-request: !6750

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-request: !6740

Merge-request: !6740

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-request: !6718

Merge-request: !6718

William R. Dieter authored 3 years ago and Brad King committed 3 years ago

Since commit a90d2a9e (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-request: !6719

William R. Dieter authored 3 years ago and Brad King committed 3 years ago

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-request: !6700

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-request: !6696

VS 2022's `cl` 19.30 has a `-scanDependencies` option that produces the
P1689r4 format.  It reports the "version" field with value "1".

Merge-request: !6695

Extend the logic from commit 08c5b3ef (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

Merge-request: !6664