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
We can't represent frameworks as PBXFileReferences unless we have
an existing absolute path, or are able to resolve relative paths
(including framework name only) to an SDK-root relative or absolute
path, which we don't do at the moment.
Which means we can't represent these frameworks in the Frameworks
group in the project, as they will have wrong paths and be shown
by Xcode as missing.
XCODE_LINK_BUILD_PHASE_MODE KNOWN_LOCATION moves non-target library
items with a known path into the "Link Binary With Libraries" build
phase, requiring a valid PBXFileReference. Framework items specified
without a directory component (e.g. $<LINK_LIBRARY:FRAMEWORK,Foundation>)
are stored as ItemIsPath::Yes in cmComputeLinkInformation, but their
value is just a bare name. This caused CreateXCodeFileReferenceFromPath
to CollapseFullPath the bare name against the current working directory,
producing a broken reference to a non-existent path that Xcode shows
as a missing file, and that results in failure to link the project.
We now check that a non-target framework item has a non-empty directory
component before allowing it into the link phase. Without a concrete
path we can't produce a valid PBXFileReference, so we fall back to
OTHER_LDFLAGS where the item is already correctly formatted as
-framework Name.
Find places that are currently relying on diagnostic-specific message
types to issue diagnostics and replace these with calls to the new
diagnostic methods.
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
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>
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.
This adds the following new arrays, which together capture all direct
dependencies and interface dependencies of a target:
- linkLibraries
- interfaceLinkLibraries
- compileDependencies
- interfaceCompileDependencies
- objectDependencies
- orderDependencies
Fixes: #21995, #25213
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
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.
Previously, it used to be possible to execute ctest --build-and-test
without specifying --build-project. When used with the Xcode generator,
this would work as long as there was only one .xcodeproj file in the
directory, where xcodebuild would then default to using that project.
The recent changes to support .xcworkspace files broke that logic, placing
a malformed pair of options "-project .xcodeproj" on the command line
instead of omitting the "-project" option altogether.
Fixes: #27090
Extend commit 844d79916a (cmake --build: Add support for driving Xcode
workspaces, 2025-06-02) to support multiple `--target` arguments.
`xcodebuild -scheme` cannot be repeated in a single call, so call it
multiple times instead.
Issue: #26958
Co-Authored-By: Craig Scott <craig.scott@crascit.com>
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>
Xcode automatically adds a flag matching the generated `LIBRARY_STYLE`:
* For SHARED libraries we've been duplicating `-dynamiclib` with a copy
in `CMAKE_SHARED_LIBRARY_CREATE_<LANG>_FLAGS`. Remove it for Xcode.
* For MODULE libraries we've been not duplicating `-bundle` only by accident.
Since commit 586a9427d3 (ENH: Created target property INSTALL_NAME_DIR...,
2006-02-24, v2.4.0~418) we've looked up `CMAKE_<LANG>_LINK_FLAGS`, meant
for EXECUTABLEs, instead of `CMAKE_SHARED_MODULE_CREATE_<LANG>_FLAGS`.
Switch to the latter, but remove `-bundle` for Xcode.
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
Some CoreFoundation headers included by the umbrella header, which we do
not need, use syntax that GCC does not support. Avoid including them.
GCC-Issue: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115880
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
Marc Chevrier
halx99
Tor Arne Vestbø
Brad King
Evan Wilde
Matthew Woehlke
Tyler Yankee
John Franklin Rickard
Timon Sassor
Cristiano Carvalheiro
Eduard Voronkin
Peter Steneteg
Craig Scott
AJIOB
Darryl Pogue
Ben Boeckel
Daniel Pfeifer
Stepanov Igor
Sergey Fedorov
Kitware Robot
Alexandra Cherdantseva