| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
| |
Since commit 0b552eb877 (MSVC: Embed manifests directly for
non-incremental vs_link_exe links, 2023-02-20, v3.27.0-rc1~438^2) we use
`/MANIFEST:EMBED`, but that is not supported by older MSVC linkers.
Restore use of the standalone manifest tool.
Update `Tests/MSManifest` to recognize `dpiAwareness` in the manifest
content as written by MSVC v100 tooling.
Fixes: #26179
|
|
|
|
| |
Fixes: #26019
|
|
|
|
|
|
|
|
| |
A new set of files are dedicated to linker configuration.
This set of files enable a fine-tuned configuration based of the linker
type as identified during compiler detection.
Fixes: #25360
|
|
|
|
|
|
| |
Remove `/DAMD64` and `/DARM64EC` flags added by commit 4ea3a88625 (MSVC:
Add support for targeting ARM64EC, 2020-12-30, v3.20.0-rc1~121^2) that
are not longer expected.
|
|
|
|
|
| |
* enhance OVERRIDE handling
* Update wording
|
| |
|
|
|
|
| |
Fixes: #24504, #25954
|
|
|
|
|
|
|
|
|
|
|
|
| |
The link flag wrapping added by commit 5d5a712303 (IntelLLVM: Pass
linker flags to the compiler when used as linker, 2022-05-27,
v3.25.0-rc1~344^2~4) is not needed with Visual Studio generators because
MSBuild invokes the linker directly. Furthermore, that commit omitted
wrapping of the per-config linker flags.
Revise the logic to add the link flag wrapping more precisely.
Fixes: #25533
|
|
|
|
|
|
|
|
|
| |
Some platforms, Apple or Windows for instance, do not require to duplicate
static libraries to resolve mutual dependencies. Moreover, Xcode version 15
emits a warning if a library is duplicated.
On Windows, enable a better control of libraries order.
Fixes: #20722, #25297
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Offer the capability, through variable `CMAKE_LINKER_TYPE`, as well as
the target property `LINKER_TYPE` to specify which linker must be used.
The implementation of this capability is specified by variables specific
to the language and linker type: `CMAKE_<LANG>_USING_LINKER_<TYPE>`.
Some definitions are provided as part of `CMake`.
For example, to select the `LLVM` linker rather than the standard one,
the type `LLD` should be specified through the variable `CMAKE_LINKER_TYPE`.
And, on `Apple`, `Linux` and some environments on `Windows`, the variable
`CMAKE_<LANG>_USING_LINKER_LLD` has value `-fuse-ld=lld`. And for `Windows`
environments based on `MSVC`, where the linker is used directly, the tool
`lld-link.exe` will be used rather than `link.exe`.
Fixes: #19174, #24254, #24990
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
Add a policy for compatibility.
For more information, see [1].
[1] https://docs.microsoft.com/en-us/cpp/build/reference/z7-zi-zi-debug-information-format?view=msvc-170
Fixes: #10189
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| | |
d49e168e1b Ninja: Do not use cmcldeps for RC on non-Windows hosts
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Dmitry Mikushin <dmitry@kernelgen.org>
Merge-request: !6843
|
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |
|
|
|
|
|
| |
* Use same configuration variables to configure dependencies
* Abstract Ninja deps format from compiler one
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
Fixes: #21097
|
|
|
|
|
|
| |
In commit d993ebd4ca (clang-cl: Add '--' before source file, 2020-07-28)
we accidentally replaced these rules with those to compile an object
file.
|
|
|
|
|
|
|
| |
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.
|
|\
| |
| |
| |
| |
| |
| | |
6c2514dabe MSVC: Use 'pragma system_header' in PCH only on cl 19.13 and above
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4736
|
| |
| |
| |
| |
| |
| |
| | |
VS 2017 15.6 introduced support for this pragma. Older MSVC versions
warn that it is unknown.
Fixes: #20692
|
| |
| |
| |
| |
| |
| | |
`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.
|
|/
|
|
|
|
| |
Add the same import library as x86/x64 by default for Windows 10 ARM64 (Desktop, not UWP).
Fixes: #20077
|
|
|
|
|
|
|
| |
Add the ability to share precompiled headers artifacts between
targets.
Fixes: #19659
|
|
|
|
| |
Co-Author: Daniel Pfeifer <daniel@pfeifer-mail.de>
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|\
| |
| |
| |
| |
| |
| |
| | |
33ee779330 IRSL: Fix discovery of VS 2019 v142 toolset redistributables
d8cf8380fb MSVC: Fix MSVC_TOOLSET_VERSION for VS 2019 v142 toolset
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !3186
|
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
|/
|
|
| |
llvm-rc can't handle definitions given with /D and without a space.
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
This will be useful to call from elsewhere later.
|
|
|
|
|
|
| |
Provide the MSVC toolset version number based on the compiler version.
Fixes: #16923
|
|
|
|
| |
Fixes: #17692
|
|
|
|
|
|
|
|
| |
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
|
|\
| |
| |
| |
| |
| |
| | |
bc7c94fe MSVC: Add support for ARM64 architecture
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !1215
|
| |
| |
| |
| |
| |
| | |
Visual Studio 15.4 adds support for this architecture.
Fixes: #17213
|
|/
|
|
|
|
|
|
|
| |
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
|