`include-what-you-use` diagnostics, in practice, are specific to
the environment's compiler and standard library. Update includes
to satisfy IWYU for our CI job under Debian 13. Some patterns:
* Types named in virtual `override` signatures no longer require
includes since the overridden signature already names them.
* A function argument's type needs to be included even if its constructor
is called only by implicit conversion. For example, constructing a
`std::function` from a lambda now requires `<functional>`.
* Some prior mysterious `<type_traits>` inclusions are no longer required.
When targeting the MSVC ABI, define `_MBCS` by default if the project
does not define `_SBCS` or `_UNICODE`. Visual Studio has long defined
one of the three character set macros automatically. For consistency,
define it when compiling for the MSVC ABI with other generators.
Add policy CMP0204 for compatibility.
Fixes: #27275
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
The arguments need to be able to force a long name computation so that
install paths can use the intended long paths. Use this computed state
rather than asking the generator for its base state.
Also force long paths for Visual Studio generators when computing it.
Fixes: #27233
There's no control over the object base name implemented in the
FASTBuild generator. Rather than expecting some half-supported behavior,
just ignore it completely there.
Similarly, Xcode ends up making its own object paths internally
regardless of what CMake would like.
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.
`cmLocalGenerator::GetObjectFileNameWithoutTarget` used a heuristic to
detect PCH sources. Use the new special source types to detect them
reliably instead.
These source file types don't necessarily show up in the CMake code, but
are side effects of other behaviors in CMake. Support tracking them
specially so that heuristics are not required to figure out if a given
`cmSourceFile` is one of them.
Not just short directory roots. The test suites did an improper
generator check and masked them as the generator masks were put in place
after the core development but before the autogen-specific logic tests
were created.
Testing locally, `.idb` files are *not* made unconditionally with v71 at
least. Perhaps v90 is an outlier?
In any case, the typo introduced in 1f791eb160 (Multi-Ninja: Fix
reusable PCHs for MSVC, 2020-05-24) via !4787 (see
`cmLocalGenerator.cxx:2751` for extra space inside the quotes) was
preserved when fixing `IS_NEWER_THAN` logic in 28501fca94 (PCH PDB: Fix
misuse of IS_NEWER_THAN in timestamp check, 2021-02-21) from !5825. The
typo itself was fixed in cb46c4a918 (cmLocalGenerator: fix quoting in
generated script, 2025-06-16) via !10887 but the condition was fumbled
later in that MR's commit f78f592b78 (pchreuse: defer target existence
enforcement to generation time, 2025-06-16) in constructing `to_file`
for the script.
In the end, these typos ended up making the builds pass. In fixing it
properly in the parent commit, it exposed MSVC v71 as an outlier in
passing the tests again. Since I do not see `.idb` files with the
toolchain as tested in CI, further investigation into the build that
caused the condition to be added in the first place is required. In the
meantime, removing this check makes things happy as far as CMake's own
test suite is concerned.
Now that generation can work with any way the state gets to the way it
is, just do the target enforcement at generation time. This allows PCH
reuse targets to be declared before or after targets which use them.
Also update `cmLocalGenerator` to use the methods now that they reliably
provide values rather than parallel construction.
Revert infrastructure from commit 8bcf9c7a3e (Add support of "LINKER:"
prefix for artifact creation flags, 2024-10-12, v4.0.0-rc1~522^2~1).
It is not needed to populate legacy placeholders with empty strings.
Previously we used separate placeholders for builtin linker flags:
* CMAKE_<LANG>_LINK_FLAGS for EXECUTABLEs
* CMAKE_SHARED_LIBRARY_CREATE_<LANG>_FLAGS for SHARED libraries
* CMAKE_SHARED_MODULE_CREATE_<LANG>_FLAGS for MODULE libraries
These correspond to variables set by our compiler information modules.
Teach the generators to look up these variables and add them to the
existing `<LINK_FLAGS>` placeholder instead. Substitute the empty
string for the old placeholders.
Issue: #21934
Clarify comments from commit 8bcf9c7a3e (Add support of "LINKER:" prefix
for artifact creation flags, 2024-10-12, v4.0.0-rc1~522^2~1) about
MODULE library creation flags. Also avoid falling back to EXECUTABLE
flag placeholders for SHARED or MODULE libraries. I don't think we
ever populate `CMAKE_<LANG>_CREATE_SHARED_{LIBRARY,MODULE}` from the
value of `CMAKE_<LANG>_LINK_EXECUTALBE`.
With IntelLLVM on Windows, we link using the compiler driver.
With MSVC on Windows, we invoke the linker directly. If we
use both in a single build tree, for separate languages,
the value of `CMAKE_LINK_DEF_FILE_FLAG` conflicts. Add a
per-language `CMAKE_<LANG>_LINK_DEF_FILE_FLAG` variable to
avoid the conflict. Preserve the language-agnostic variable
for compatibility with projects that reference it.
Fixes: #26005
Visual Studio doesn't use a `CMakeFiles` subdirectory for its support
directories. However, some codepaths expect to use paths which are
always under `CMakeFiles`. Add a mechanism to keep the path for such
files.
When target directories are shortened, the `CMakeFiles` path component
will be part of the root, not the target directory. Since other files
end up constructing paths manually, move the differing component into
the correct logical path construction part.
In commit 7b19531291 (macOS: Do not pass any SDK/-isysroot to compilers
by default, 2024-11-06, v4.0.0-rc1~511^2) we broke support for using
upstream LLVM/Clang to build for macOS because the compiler has no
default sysroot. Handle empty `CMAKE_OSX_SYSROOT` with LLVM/Clang by
falling back to the macOS SDK reported by `xcrun --show-sdk-path` .
Fixes: #26863
Refactoring in commit 2b2344b412 (MSVC: Add abstraction for runtime
checks, 2025-01-22) switched to using local compiler id variables to
recognize compilers that target the MSVC ABI. However, those variables
may be modified modified in a special case for `lang == "RC"` that does
not apply to the ABI check. Check the target ABI before applying the
special case.
Fixes: #26663
Replace our hard-coded default for `/RTC1` with a first-class
abstraction to select runtime checks from an enumeration of logical
names. Add a `MSVC_RUNTIME_CHECKS` target property and corresponding
`CMAKE_MSVC_RUNTIME_CHECKS` variable.
Removing the old default flag requires a policy because existing
projects may rely on string processing to edit them and choose
runtime checks under the old behavior. Add policy CMP0184 to
provide compatibility.
Fixes: #26614
