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
`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
