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.
The call site in `AddLanguageFlags` is now the "one true place" for
adding language standard flags. Inline the helper to reduce risk of
adding other call sites later.
Previously items linked via the link interface of a dependency were
reported in CMP0028 messages as if directly linked by a target.
Clarify the messages to indicate that an offending item is actually
in the link interface of a given target, regardless of its consumer.
Move the check to the end of generation and look through the final set
of link implementations and link interfaces that were used for
generation. This avoids repeating messages on link interfaces that
have multiple consumers.
Store the main dependency as the first entry in the dependency list plus
a boolean member indicating its existence. Note that this slightly
changes existing behavior: the main dependency was previously the last
entry of the dependency list.
It is unused since commit c564a3e3ff (Ninja: Always compile sources
using absolute paths, 2021-05-19, v3.21.0-rc1~129^2), which left
behind a FIXME comment to eventually remove it.
