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.
Add and use a couple helper functions for issuing policy warnings. This
improves consistency and allows some simplification of many call sites.
(One or two instances in particular are greatly simplified.)
Create new cmDiagnosticContext used to capture the diagnostic state for
instances when the issuing of a diagnostic might happen at a point far
separated from processing the CMake command ultimately responsible for
the diagnostic. (This is particularly the case for diagnostics that get
emitted during the generation phase.) In such cases, it is preferred
that we record the diagnostic state that pertained when the ultimately
instigating command was processed, so that users can control the
diagnostic in a natural manner. Copying the entire cmStateSnapshot is
unreasonably expensive; this will provide a lighter-weight mechanism for
capturing the relevant diagnostic state for later use.
Since it is almost universal that the points where we would capture this
state also capture a stack trace (which is likewise used to issue
diagnostics), the new class contains a stack trace, and replaces the
stack trace in some diagnostic calls. (In some instances, an overload
which implicitly converts a stack trace to the new context class is
retained for convenience. These will behave the same, since capturing
diagnostic state is an optional function of the new class.)
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
Create methods to issue diagnostics. Diagnostics are similar to
messages, except that they are associated with a diagnostic category,
and the diagnostic state determines their severity. Also, add overloads
of methods to issue messages and diagnostics that accept a backtrace, as
a number of places must currently bypass layers in order to pass a
custom backtrace. These are also sub-optimal because the lower level
APIs require the diagnostic state to be explicitly passed by the caller,
which we would prefer to avoid whenever possible.
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>
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
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
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.
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.
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
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.
Run the `clang-format.bash` script to update all our C and C++ code to a
new style defined by `.clang-format`, now with "east const" enforcement.
Use `clang-format` version 18.
* If you reached this commit for a line in `git blame`, re-run the blame
operation starting at the parent of this commit to see older history
for the content.
* See the parent commit for instructions to rebase a change across this
style transition commit.
Issue: #26123
Add a way to specify, in a portable way, to raise an error for any
warning during the link step. For that purpose, define:
* CMAKE_LINK_WARNING_AS_ERROR variable
* LINK_WARNING_AS_ERROR target property
Fixes: #25343
The following variables now support the LINKER: prefix:
* CMAKE_SHARED_LIBRARY_CREATE_<LANG>_FLAGS
* CMAKE_SHARED_MODULE_CREATE_<LANG>_FLAGS
* CMAKE_<LANG>_LINK_FLAGS
Add a target property that will be read on unity file generation to
attempt to use a relative path to the source file from the CMake Source
Directory or the generated unity file. Additionally add the CMake
Source Directory and the CMake Binary directory to the include path of
the generated unity files.
Closes: #26352
Splitting the Swift build into an object build and a separate link step,
instead of building and linking in one step. The immediate benefit is
LSP support because we are able to emit compile-commands for Swift files
now. Additionally, it is possible to specify flags to the compile step,
enabling folks to emit C and C++ headers from their Swift builds for
C/C++ interop, without needing custom commands. Eventually, this gives
us a path toward working object libraries.
Object Libraries:
- Object libraries don't work today because CMake doesn't emit targets
for object libraries into the Ninja build file.
- tl;dr: Object libraries work if they aren't WMO. Still need work to
make WMO'd object libraries work.
Object libraries still don't completely work with this patch because,
while we emit the targets, the `TARGET_OBJECTS` generator expression
expansion has a separate mechanism for determining what the names of
the objects are based on the input source files, so targets that
depend on an object library built with a whole-module optimization
will depend on objects based on the name of the source file instead
of the actual emitted object file.
These features require being able to accurately model wholemodule builds
though, because we actually need to track object files and WMO affects
what objects are emitted. For that, we require CMP0157 use the NEW
policy. When it's OLD, we have to fall back on the old behavior and
cannot provide object libraries or the compile-commands for LSP.
Issue: #25308
Add a `CMAKE_Swift_COMPILATION_MODE` variable and corresponding
`Swift_COMPILATION_MODE` target property to control the compilation
mode. Select among `wholemodule`, `singlefile`, and `incremental`.
Add policy CMP0157 to remove the default `-wmo` flags in favor of the
abstract setting.
Issue: #25366
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
`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 12.
