Fix commit e40d2cb3af (Xcode: Add embed resources support, 2023-07-31,
v3.28.0-rc1~281^2). The implementation should not name the `_PATH`
suffix explicitly. That variant is automatically handled by
`cmGlobalXCodeGenerator::AddEmbeddedObjects`.
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
Now that scanning support is no longer experimental, the logic for
whether or not to scan C++ 20 sources is now important because all
projects are now exposted to the logic. Make the scanning rules explicit
in the documentation and rework the queries to localize all of the
associated logic.
A policy to handle the ultimate fallback logic will be implemented in a
following commit.
With Xcode 14 support for the Legacy Build System has been removed
and the BuildSystemType in the WorkspaceSettings is ignored.
If CMake still generates projects targeted to the Lecacy Build
System the build preparation phase will likely fail because Xcode
for example misses any declared outputs from script invocations.
This is a hard to debug problem and CMake should reject the invalid
configuration instead.
571b5e1f2c cxxmodules: improve error messages for C++ module setup
8b4d32c18b cmStandardLevelResolver: add query for the effective standard level
17ddc4ac76 cmStandardLevelResolver: compare with static string literals
6f1dae2b01 cmStandardLevelResolver: use `cmStrCat` where possible
0d45d40e13 cmStandardLevelResolver: use character literals where possible
Acked-by: Kitware Robot <kwrobot@kitware.com>
Tested-by: buildbot <buildbot@kitware.com>
Merge-request: !8755
After b665966933 (cmComputeLinkInformation: track `OBJECT` library
dependencies, 2023-07-22), introduced in !8645 as a fix for #25112,
`OBJECT` libraries were tracked in a separate member to reduce the risk
of further regressions. This commit prepares consumers to handle
`OBJECT` libraries once they start appearing as link items.
When the build system re-runs `cmake` to regenerate itself, preserve the
`--compile-no-warning-as-error` option if it was used when `cmake` was
last explicitly invoked. Normally such settings are preserved in the
cache, but the purpose of this option is to be beyond the reach of
project code.
This was accidentally left out of commit de962cc00d (CMake: Internally
uses -S instead of -H to specify source directory, 2018-09-06,
v3.13.0-rc1~76^2~1).
In commit 8527f42b96 (Xcode: Explicitly disable deprecated user include
path feature, 2023-01-31, v3.26.0-rc1~7^2) we dropped the Xcode build
setting `USE_HEADERMAP = NO` because Xcode 14's "Build Documentation"
feature (`xcodebuild RUN_DOCUMENTATION_COMPILER=YES`) fails in some
cases without header maps. However, enabling header maps causes Xcode
to add `-iquote .../foo.hmap` and `-I .../bar.hmap` flags that can
change the intended header file search order based on the contents of
the header maps. This can break existing projects. Restore the
`USE_HEADERMAP = NO` setting to fix the header file search order.
Further investigation will be needed to resolve the problematic cases
with the Xcode 14 "Build Documentation" feature. Meanwhile projects
encountering such cases can set the `XCODE_ATTRIBUTE_USE_HEADERMAP`
target property to `YES` themselves.
Fixes: #24418
Issue: #24379
Many custom commands are created by CMake itself rather than by
the user. These custom commands should always have their policies
set to NEW, and user-created custom commands should have their
policy values set only from the state snapshot. In addition, we
want to genericize the mechanism of recording a policy at the time
of custom command creation.
Add a CM_FOR_EACH_CUSTOM_COMMAND_POLICY macro to genericize
custom command policies. Use this to define all custom command
policies. Make all such policies NEW instead of WARN by default.
Remove individual policy modifier methods and add a single method
that records relevant values from a cmStateSnapshot. Remove the
no longer needed explicit policy settings from synthesized custom
commands.
The `ALWAYS_SEARCH_USER_PATHS` feature is documented [1] to search the
paths in `USER_HEADER_SEARCH_PATHS` before `HEADER_SEARCH_PATHS`. The
behavior has been long discouraged and was deprecated by Xcode 8.3.
Furthermore, Xcode explicitly disables this setting when creating new
projects. We can do that too since we do not generate any user header
search paths anyway.
Previously we always set `USE_HEADERMAP` to `NO` to prevent Xcode's
warning about an ancient "header map" feature deprecation. However,
this somehow breaks Xcode 14's "Build Documentation" feature. Setting
`ALWAYS_SEARCH_USER_PATHS` to `NO` seems to prevent the header map
warning too, so drop `USE_HEADERMAP` to fix the documentation feature.
[1] https://developer.apple.com/documentation/xcode/build-settings-referenceFixes: #24379
Extend the change from commit dfaf55fbfd (Xcode: add extra
'$(inherited)' entries using InheritBuildSettingAttribute, 2021-05-03,
v3.21.0-rc1~182^2) to cover Swift flags and compilation conditions,
allowing CocoaPods and CMake to interoperate when used in the same
project.
7480fa0a5f COMPILE_DEFINITIONS property: ensure leading -D is removed in all cases
Acked-by: Kitware Robot <kwrobot@kitware.com>
Tested-by: buildbot <buildbot@kitware.com>
Merge-request: !8004
Before, a documentation entry was in/out parameter.
Now it's a normal return value.
This also makes possible to eliminate defaulted default ctor
for `cmDocumentationEntry` for C++ 11.
Also, simplify `cmake::AppendGlobalGeneratorsDocumentation()`.
