Previously, only non-system include directories would be propagated to
Swift. This meant that if, for example, an IMPORTED target contained a
Swift module, that module would not be found by a Swift consumer.
Fixes: #28097
Evaluate the XCODE_EMBED_<type> target property through the generator
expression evaluator before building the copy-files phase. Xcode shares
one copy-files build phase across all configurations, so the embedded set
cannot vary by configuration. Reject any expression whose result depends
on the configuration, matching the existing per-source diagnostic.
Fixes#28082
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.
Follow-up commit 1fa2ec1bbd (Xcode: Use deterministic object ids for
targets, 2024-04-04, v3.30.0-rc1~263^2). Each target's product
PBXFileReference (the libfoo.a / foo entries under the Products group)
was created with a random object id on every regeneration. When a
CMake-generated Xcode project is embedded in another Xcode project, that
parent keeps the product reference's id in its remoteGlobalIDString; a
random id means the reference no longer resolves and the link falls back
to a bare `-l` flag (e.g. `ld: library 'foo' not found`).
Derive the product PBXFileReference id from the target name and the
build-tree-relative product path, the same hashing path already used for
the target object id. The id is now stable across regenerations and
independent of the absolute build tree location.
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
jcm
Marc Chevrier
Tor Arne Vestbø
Brad King
Matthew Woehlke
Anton Tokar
lapfelix
halx99
Evan Wilde
Tyler Yankee
John Franklin Rickard
Timon Sassor
Cristiano Carvalheiro
Eduard Voronkin
Peter Steneteg
Craig Scott
AJIOB
Darryl Pogue
Ben Boeckel
Daniel Pfeifer
Stepanov Igor