The Xcode generator implements `target_precompile_headers()` through the
`GCC_PREFIX_HEADER` build setting, so Clang receives the prefix header as
an `-include` flag and finds the precompiled `.gch` next to it. Clang
honors that only when it is the first `-include` flag. Xcode extracts
every `-include <file>` pair out of settings such as `OTHER_CFLAGS` and
places it on the command line ahead of the prefix header, so a force
include added by the project always came first and the precompiled header
was dropped:
precompiled header '.../cmake_pch.hxx.gch' was ignored
because '-include .../cmake_pch.hxx' is not first '-include'
Pass such flags straight to the compiler front end as a single joined
`-Xclang -include<file>` argument instead. Xcode does not recognize it as
a force include and leaves it in the response file, and the driver no
longer sees an `-include` flag of its own, so the prefix header stays
first. The header is still force included: Xcode compiles the prefix
header in a step of its own, in which every force include, `-Xclang` or
not, is processed before the prefix header itself.
Rewrite every spelling Clang accepts, joined ones such as `-include<file>`
and `--include=<file>` included, since the driver recognizes them all.
Leave alone a flag already handed to a sub-tool with `-Xclang` or
`-Xpreprocessor`, as well as one whose value looks like another flag.
`GCC_PREFIX_HEADER` is a target-wide setting, so apply the rewrite to
every language compiled in the target, not just the one the precompiled
header was requested for. Do it where the `OTHER_*FLAGS` strings are
assembled so that the define flags are covered too. Only rewrite for
languages the prefix header applies to, and for compilers that understand
`-Xclang`.
Fixes: #23259
- Update discover_tests to work with test_prep targets and ctest --out-of-date
- Extend behavior to gtest_discover_tests
- Don't treat non-built targets as always out of date
- Support imported targets in BUILD_DEPENDS
Issue: #28052, #28070
Multiple targets embedding the same internal framework dependency with
different code-signing attributes should not overwrite each other in the
generated `PBXBuildFile`. Extend commit 0282429c5a (Xcode: Fix
XCODE_EMBED_FRAMEWORKS when settings differ across targets, 2024-12-02,
v4.0.0-rc1~358^2) to cover target names.
Remove `FileRefToEmbedBuildFileMap` entirely, forcing CMake to
instantiate a brand-new `PBXBuildFile` reference object with a unique
ref value for every separate target embedding action, matching Xcode's
native multi-target configuration behavior.
Fixes: #27850
The generator does a lot of tricks in order to make the "rebuild-bff"
target up-to-date immediately after the generation. We can skip all of
those during "TryCompile" runs, which should reduce configure time.
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.
External tools may create a `.xcworkspace` directory next to the
`.xcodeproj` directory that CMake generates. If a workspace exists,
drive the build through it instead.
Closes: #26958
Co-authored-by: Brad King <brad.king@kitware.com>
149ee3b4bc Xcode: Use DEBUGGER_WORKING_DIRECTORY as a fallback for scheme work dir
0f1b9ef32a Help: VS_DEBUGGER_WORKING_DIRECTORY precedence
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !10736
This also means when XCODE_SCHEME_WORKING_DIRECTORY is
set and a Xcode generator is used, that property will be used when
writing the debugger field in the file API replies.
Fixes: #26909
XCode 16+ no longer delays our POST_BUILD phase until after bundle files
like `Info.plist` are generated. Teach the Xcode generator to add
explicit dependencies to the POST_BUILD phase in bundle targets to
ensure the files are created before it runs.
Fixes: #26656
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
In commit 5651901c54 (Xcode: add support for embedding frameworks,
2020-10-24, v3.20.0-rc1~402^2) we incorrectly reused `PBXBuildFile`
instances when the same framework is embedded in multiple targets,
causing target-specific settings to conflict.
Fixes: #26438
The following variables now support the LINKER: prefix:
* CMAKE_SHARED_LIBRARY_CREATE_<LANG>_FLAGS
* CMAKE_SHARED_MODULE_CREATE_<LANG>_FLAGS
* CMAKE_<LANG>_LINK_FLAGS
When a CMake-generated Xcode project is included in another Xcode project,
the used targets' object ids are kept as `remoteGlobalIDString`.
Make the ids deterministic and somewhat independent of the build
tree location.
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()`.
Since commit dc5fc898f6 (Xcode: Set object file locations using
TARGET_TEMP_DIR, 2022-09-29, v3.25.0-rc1~64^2~1), `xcodebuild clean`
does not remove the object files in our explicit `TARGET_TEMP_DIR`
because it is not under the `SYMROOT`. Put it there.
Fixes: #24096
Allow `cmGlobalGenerator`s to decide `HasKnownObjectFileLocation()` per given
`cmTarget`
- `cmGlobalGenerator::HasKnownObjectFileLocation()` now takes an optional `cmGeneratorTarget`
- `cmTarget::HasKnownObjectFileLocation()` added as a shorthand
Revert the changes from commit d5b5c19278 (cmGlobalGenerator:
FindMakeProgram() before CMakeDetermineSystem, 2020-06-15,
v3.19.0-rc1~619^2~3) and commit ef91fb02f3 (cmGlobalGenerator:
FindMakeProgram() at a generator-specific time, 2020-11-23,
v3.19.1~2^2). We must delay selecting the location of MSBuild until
after an instance of Visual Studio has been selected.
It is now safe to revert the ordering because the motivating use
case (sysroot detection in Platform/Android-Determine) has been
implemented another way.
Fixes: #22782
The Xcode "new build system" only considers a script build phase up to
date if it has run before, even if outputs are newer than inputs. Use a
deterministic object id for script build phases associated with custom
commands so that they do not need to re-run after CMake re-generates the
project.
Fixes: #21669
Generalize the change from commit bffb17be3d (Xcode: Inherit target
library and framework search paths from project, 2020-11-04,
v3.19.0-rc3~4^2) to apply to framework and other kinds of search paths
added either for include directories or for linking.
Issue: #21617
Cristian Adam