As of commit ed48feeae8 (clang-cl: Add support for C++ modules,
2026-03-27, v4.4.0-rc1~428^2) CMake tries to support modules for
clang-cl, which can mostly be accomplished, except for the ClangCl VS
toolset, where the /scanDependencies flag is not yet supported.
Amend commit 3022f0363f (VS: set ScanSourceForModuleDependencies at
vcxproj level, 2024-04-27, v3.28.5~3^2) to only emit this setting when
scanning is supported by the toolchain.
Fixes: #27957
Issue: #27977
Move some target related enumeration types from `cmStateTypes.h` to a
new header, as these really aren't "state" types. Also, make
`TargetType` a strongly-typed enumeration.
Find places that are currently relying on diagnostic-specific message
types to issue diagnostics and replace these with calls to the new
diagnostic methods.
Two targets whose names differ only in a `.exe` suffix create a
conflict when adding target- and file-level dependencies for a custom
command. Add CMP0212 to provide compatibility with the old behavior.
Issue: #27612
Each Rust source file given to a target is considered a separate crate
root. There's a concept of a "main crate root", which is the `.rs` file
that is given to the final linker phase in CMake. Other Rust source file
in a target are built as rlib separately.
The project can still build `.rs` files into object files by setting the
Rust_EMIT property on the desired source file.
To manage the generation step, introduce cmGeneratorFileSet and
cmGeneratorFileSets classes.
These reorganizations of the code are done in preparation of the
implementation of SOURCES file set type as well as user's file set types.
Issues: #27550, #27383
e4f6701ad4 cmVisualStudio10TargetGenerator: use language extension for objects
3b9cd510d7 cmVisualStudio10TargetGenerator: only write a single object filename
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !11654
Previously, `CMAKE_<LANG>_LINK_FLAGS` was an undocumented variable used
for linking executables only. Re-spell that variable mirroring the
existing spellings for shared and module libraries, and add policy
CMP0210 to preserve compatibility.
Then, repurpose `CMAKE_<LANG>_LINK_FLAGS` to provide a variable to be
used for per-language link flags for all target types, along with a
per-configuration variant. These are added to the `<LINK_FLAGS>` rule
placeholder in the generators.
Fixes: #21934
Relates: #25620
Co-authored-by: Brad King <brad.king@kitware.com>
Restore conditions broken by commit 19a61e56cf (VS: Refactor MSVC
character set selection, 2025-10-10, v4.2.0-rc1~12^2~1). We had misread
the purpose/scope of the `<= cmStateEnums::OBJECT_LIBRARY` condition.
In the original code it was only about safely indexing `ClOptions`,
not about the kinds of targets that can use a unicode character set.
Fixes: #27490
In commit 99d09ec45a (VS: Suppress MSBuild default link flags not
specified by project or user, 2025-06-17, v4.1.0-rc1~6^2) we removed our
default `-subsystem:...` link flag from `SHARED` and `MODULE` libraries
in Visual Studio generators for consistency with command-line generators.
However, unlike other flag suppressions for #27004, this change did not
just suppress MSBuild defaults, but actually changed flags the generator
was previously adding itself.
For the linker subsystem flag, consistency across generators should
perhaps achieved by adding the flag in other generators instead of
removing it from Visual Studio generators. Restore the previous
behavior pending further investigation.
Issue: #27466Fixes: #27464
Since commit 7db3dbddb2 (VS: Suppress MSBuild default flags not
specified by project or user, 2025-06-02, v4.1.0-rc1~69^2) we suppress
the `-Zc:inline` default flag when the project/user does not specify it.
That triggers an apparent bug in VS 2019 with v142 toolset versions
before 14.29 in which MSBuild fails when both `-Zc:inline` and `-nologo`
are suppressed. This happens when `CMAKE_VERBOSE_MAKEFILE` is enabled,
such as in `try_compile` projects like our builtin compiler inspection.
Since `-nologo` is incidental, avoid suppressing it if `-Zc:inline` is
also suppressed. Limit this workaround to relevant toolset versions.
Fixes: #27439
Introduce an index from source file to source group in
`cmLocalGenerator` to make lookups significantly more efficient
during the source group generation, which could be particularly
slow when dealing with thousands of source files.
Falls back to the recursive lookup when the source file is not present
on the index, which is more likely to happen when dealing with
regex-based sources.
Fixes: #27359
Extend commit 7f15c99851 (CUDA: forward unknown flags to host compiler
when possible, 2019-11-29, v3.17.0-rc1~326^2~1) to work in VS too.
Fixes: #27210
The logic in commit f78f592b78 (pchreuse: defer target existence
enforcement to generation time, 2025-06-16, v4.2.0-rc1~481^2~4) caused
generator targets to always respond with something for compilation PDB
files. This may be a directory as the flag supports it (the then
compiler chooses the filename). However, one caller was expecting it to
always be a path to a file in order to specify the
`ProgramDataBaseFileName` element. However, this usage cannot be a
directory.
In addition to not having a PDB path at all, also verify that it is not
a path to a directory before creating the `ProgramDataBaseFileName`
element.
This was observed in builds using `import std` in Debug mode.
Fixes: #27320
Visual Studio defines this automatically for `.dll` targets.
For consistency, define it when compiling for the MSVC ABI
with other generators. Add policy CMP0203 for compatibility.
Fixes: #27253
Projects which ship object files as artifacts may want to control the
object names as much as possible. Support setting explicit object names
as source file properties to support such use cases.
Although there is no `cl -std:c23` flag, the underlying Clang compiler
does have a C23 mode we can activate by passing `-std=c23` through a
`clang-cl` wrapper flag.
Also port the fix from commit 30139913e9 (VS: Restore support for mixing
C++23 and C in one target with clang-cl, 2024-12-09, v3.31.3~10^2).
Fixes: #27038
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Co-authored-by: Brad King <brad.king@kitware.com>
MSBuild adds some `link` flags by default, but for CMake they may not
match what's produced by command-line generators. If these flags are
not specified by the project or user, suppress them.
Fixes: #27004
`Microsoft.Cl.Common.props` adds some `cl` flags by default, but for
CMake they may not match what's produced by command-line generators.
If the `-Zc:wchar_t`, `-Zc:forScope`, and/or `-Zc:inline` flags are
not specified by the project or user, suppress them.
Fixes: #26964