Replace our hard-coded default for `/Zi` with a first-class abstraction
to select the debug information format an enumeration of logical
names. We've long hesitated to do this because the idea of "debug
information format" touches on related concepts on several platforms.
Avoid that scope creep by simply defining an abstraction that applies
only when targeting the MSVC ABI on Windows.
Removing the old default flag requires a policy because existing
projects may rely on string processing to edit them and choose a
runtime library under the old behavior. Add policy CMP0141 to
provide compatibility.
Fixes: #10189
Revert commit 5fcadc481e (MSVC: Default to -ZI instead of /Zi for x86
and x64, 2022-05-24). The `-ZI` flag is incompatible with the `-GL`
flag used for IPO, and so is not an unconditionally better default.
Revert the change pending future design of a first-class setting for
MSVC debug info format that can be automatically reconciled with IPO
settings.
That commit introduced policy CMP0138, but we already have later policy
numbers used too. Leave placeholder text to avoid policy renumbering.
Issue: #23607, #10189
The `cmcldeps` executable is only built on Windows. If running MSVC on
a different OS (with various compatibility wrapping), don't try to use
`cmcldeps`, as the executable doesn't exist.
Fixes: #21760
Update the support added by commit 4ea3a88625 (MSVC: Add support for
targeting ARM64EC, 2020-12-30, v3.20.0-rc1~121^2).
Add `softintrin.lib` to `CMAKE_C_STANDARD_LIBRARIES_INIT`.
Remove `/D_ARM64EC_WORKAROUND` from the flags as it was only ever needed
in preview versions of VS.
Issue: #21724
This was forgotten in commit 0c7f918fb1 (VS: Update Visual Studio 17
2022 generator for Preview 2, 2021-07-14, v3.21.1~29^2) when the toolset
was first renumbered to `v143`.
Fixes: #22585
Allows using different compilers with different flags for different languages.
For example Clang with GNU-like commandline for CXX and MSVC as host compiler
for CUDA.
Should help with #21914.
Each source compilation generates a dependencies file. These dependencies
files are consolidated in one file per target. This consolidation is done
as part of command 'cmake -E cmake_depends` launched before evaluation of
makefile dependency graph.
The consolidation uses the same approach as `CMake` dependencies management.
Fixes: #21321
The `/GR` flag has been on by default since MSVC cl 14.0 from VS 2005.
Remove it from the default flags to make it easier for projects to pass
`/GR-` themselves to turn it off.
Projects may be using string processing to replace `/GR` with another
flag, so we cannot simply drop it. Add a policy to drop it in a
compatible way.
Fixes: #21428
On Linux and macOS, absolute paths start with `/` which may be
interpreted by clang-cl as an option. To avoid this, we separate the
source file path from preceding options with `--` to tell `clang-cl` it
is not an option.
During compiler identification, if CMAKE_{C,CXX}_COMPILER_TARGET is
defined, the corresponding clang target flag is used to guaranty proper
target architecture detection.
`link.exe /lib` is an undocumented flag and it just calls `lib.exe`.
Also `link.exe` doesn't parse the `/lib` option correctly when in a
response file.
We do not add default warning flags on other compilers, and having
a warning flag in the default flags makes it hard for projects to
customize the warning level. They need to use string processing
to remove `/W3` from `CMAKE_{C,CXX}_FLAGS`. Therefore we should
drop it.
However, projects may be using string processing to replace `/W3`
with another flag, so we cannot simply drop it. Add a policy to
drop it in a compatible way.
Fixes: #18317
Replace our hard-coded defaults for `/MD` and `/MDd` with a first-class
abstraction to select the runtime library from an enumeration of logical
names. We've long hesitated to do this because the idea of "runtime
library selection" touches on related concepts on several platforms.
Avoid that scope creep by simply defining an abstraction that applies
only when targeting the MSVC ABI on Windows.
Removing the old default flags requires a policy because existing
projects may rely on string processing to edit them and choose a runtime
library under the old behavior. Add policy CMP0091 to provide
compatibility.
Fixes: #19108
This was forgotten in commit 626c51f47b (VS: Update for Visual Studio
2019 Preview 2, 2019-01-24, v3.14.0-rc1~74^2) when the toolset was
first renumbered to `v142`.
Issue: #19125
CMake commands vs_link_dll and vs_link_exe, performing linking on MSVC,
are responsible for calling resource compiler and manifest tool.
Before this commit, both of these tools were called directly, with the
expectation that they are available in the `PATH`. This has been fixed
by respecting CMake variables `CMAKE_RC_COMPILER` and `CMAKE_MT`
defining paths to these tools.
Fixes: #17804
When using a real MSVC compiler for `C` or `CXX`, use the version of
that compiler for `MSVC_VERSION`. This is preferred over the MSVC
version that a non-MSVC compiler "simulates".
Fixes: #17468
Revert commit v3.7.0-rc1~25^2 (VS: Recognize VS/LLVM toolset names as
Clang, 2016-09-28). Since at least LLVM 5.0 the VS integration of the
LLVM toolchain now mimics cl and accepts MSVC-style command-line
arguments (unlike Microsoft Clang/C2).
Fixes: #17193, #17235
In commit v3.8.0-rc1~304^2 (MSVC: Do not define _DEBUG explicitly when
using /MDd, 2016-11-15) we removed the `_DEBUG` preprocessor definition
from MSVC C and C++ flags because the `cl` compiler automatically
defines it in Debug builds anyway. However, the VS generators propagate
C preprocessor definitions to the RC (Windows Resource Compiler) tool.
This means that we used to explicitly define `_DEBUG` for RC debug
builds. Therefore existing project code may expect the definition to be
there even though the `rc` compiler itself does not implicitly define
`_DEBUG` in debug builds.
Add the `_DEBUG` flag to the default `CMAKE_RC_FLAGS_DEBUG` instead
to restore this definition for RC debug builds. This also makes it
available consistently in VS, Ninja, and Makefile generators.
Fixes: #16745
Update the toolset name matching added by commit v3.6.0-rc1~279^2~10
(VS: in Clang/C2 toolset, setup correct compiler settings, 2016-02-18)
to match VS/LLVM toolset names too.
Per-source copyright/license notice headers that spell out copyright holder
names and years are hard to maintain and often out-of-date or plain wrong.
Precise contributor information is already maintained automatically by the
version control tool. Ultimately it is the receiver of a file who is
responsible for determining its licensing status, and per-source notices are
merely a convenience. Therefore it is simpler and more accurate for
each source to have a generic notice of the license name and references to
more detailed information on copyright holders and full license terms.
Our `Copyright.txt` file now contains a list of Contributors whose names
appeared source-level copyright notices. It also references version control
history for more precise information. Therefore we no longer need to spell
out the list of Contributors in each source file notice.
Replace CMake per-source copyright/license notice headers with a short
description of the license and links to `Copyright.txt` and online information
available from "https://cmake.org/licensing". The online URL also handles
cases of modules being copied out of our source into other projects, so we
can drop our notices about replacing links with full license text.
Run the `Utilities/Scripts/filter-notices.bash` script to perform the majority
of the replacements mechanically. Manually fix up shebang lines and trailing
newlines in a few files. Manually update the notices in a few files that the
script does not handle.
Document these variables.
Change our convention for setting these variables from:
set(CMAKE_EXE_LINKER_FLAGS_INIT "...")
to
string(APPEND CMAKE_EXE_LINKER_FLAGS_INIT " ...")
so that any value previously set by a toolchain file will be used.
