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.
Tweak `cmMessenger` to also show the "warning is for project developers"
notice for all diagnostics that are descendants of the `CMD_AUTHOR`
category. When doing so, also show both command-line options which can
suppress the message.
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.
Update expected test output to account for the new format of diagnostic
messages. These changes were applied entirely by `sed` using the
following commands:
- `/Use -Wno-dev to suppress/s/-Wno-dev/-Wno-author/g`
- `s/Warning [\\][(]dev[\\][)]/Warning \\(author\\)/g`
- `s/CMake Deprecation Warning/CMake Warning \\(deprecated\\)/g`
This is not a complete fix, but covers a significant fraction of the
needed changes, and this commit is strictly automated changes.
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 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
The OLD behaviors of all policies are deprecated, but only by
documentation. Add an explicit deprecation diagnostic for policies
introduced in CMake 3.25 and below to encourage projects to port
away from setting policies to OLD.
Skip the `CMAKE_OSX_ARCHITECTURES` validation added by commit db409e5e68
(APPLE: Check if compilers respect CMAKE_OSX_ARCHITECTURES, 2024-05-04,
v3.30.0-rc1~15^2) if the value contains a placeholder, since we do not
know the real value.
Fixes: #26128
The `RunCMake.XcodeProject` has many cases and occasionally fails
due to timeout. Move iOS and other device-specific cases to a new
`RunCMake.XcodeProject-Device` test.
For policy-specific tests, use the version before the policy was
introduced. Otherwise, use 3.5 where possible.
Also, remove `cmake_minimum_required()` and `project()` calls from
individual cases where they are handled by `CMakeLists.txt`.
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.
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
This use case was fixed by commit a7fb4bc475 (Xcode: Set build product
locations using CONFIGURATION_BUILD_DIR, 2022-09-28). Add a test to
verify the fix.
Fixes: #23970
9cdf4c9be4 gitlab-ci: update macOS jobs to use Xcode 14.0
5d2c2b2558 Tests: Update RunCMake.XcodeProject iOS cases for Xcode 14.0
12c6fec6b4 Xcode: Drop CMAKE_INTDIR= definition in Swift targets
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !7732
Previously we set `SYMROOT` to tell Xcode where to place the build
products. However, the "clean" operation in the Xcode "new build
system" expects that only Xcode creates the `SYMROOT` directory or
contents inside it. Since we create that directory, "clean" fails.
We now explicitly set `CONFIGURATION_BUILD_DIR` and `TARGET_TEMP_DIR`
instead of letting Xcode compute their values from `SYMROOT`, so we no
longer need to set the latter. Drop the now-unnecessary `SYMROOT`.
Fixes: #22550
Refactoring in commit a2cfa2da4f (GenEx/LINK_LIBRARY: Add features for
framework support on Apple, 2022-02-10, v3.24.0-rc1~661^2) accidentally
removed a `GetParentDirectory` call. Restore it.
Fixes: #23891
The fix from commit eafe740ead (FindXCTest: Fix output directory for
test bundle with new build system, 2021-02-09, v3.19.5~5^2) is not
necessary with Xcode 12.5, which seems to have changed/fixed the
behaviour again.
Fixes: #22462
These have been added to:
GCC_PREPROCESSOR_DEFINITIONS
OTHER_CFLAGS
OTHER_LDFLAGS
This is to allow Cocoapods to work correctly as it uses xcconfig files to alter build settings in Xcode, and requires these build settings to inherit from their parent, not overwrite.
Xcode 12 doesn't allow nested builds within the same build directory.
That means we can no longer do an install by building the install target
when IOS_INSTALL_COMBINED is true. We can, however, still do an install
by running the cmake_install.cmake script or executing cmake --install,
since there is no outer build and therefore the associated SDK can be
built as a sub-build.
The non-build methods previously didn't work when
IOS_INSTALL_COMBINED was true because the generated install script
and the CMakeIOSInstallCombined script both made certain assumptions
that relied on being part of a build. Those assumptions are now
removed. A side-effect of this work is that cpack now also works from the
command line when IOS_INSTALL_COMBINED is true.
Relates: #21282Fixes: #20023
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
Support of 'new build system' in Xcode fixes indirectly few issues
which were caused by workaround with `XCODE_DEPEND_HELPER.cmake`
autogenerated script.
This patch adds test which is originated from issue #20260 and
reproduces this issue when 'new build system' is disabled.
Fixes: #20260
Anton Tokar
lapfelix
Brad King
Matthew Woehlke
Tor Arne Vestbø
Timon Sassor
AJIOB
Stepanov IgorandCraig Scott
Alexandra Cherdantseva
Cristiano Carvalheiro
Ilya Kulakov
Ross Kilgariff
Marc Chevrier
Mikko Sivulainen
PatriceJiang
Harry Mallon
Gregor Jasny
Jake Turner
Gregor Jasny
Yauheni Khnykin
Danny Parker
Gusts Kaksis