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
The new Xcode 12 build system does not support recursive
invocation. Therefore lazily triggered builds for the
corresponding platform which run during the `install` target
fail with:
```
error: unable to attach DB: error: accessing build database
```
While looking for a work-around we conditionally disable those
tests.
Issue: #21206
The Xcode "new build system" selects different architectures for device
builds than the old build system does. Skip those tests on Xcode 12+
pending further investigation.
Issue: #21206
The Xcode 'new build system' rejects empty signing identities unless
signing is explicitly marked as not allowed. Update test cases where we
turn off signing to explicitly disallow it too.
Also turn off signing in the XCTest test.
OBJECT and STATIC libraries (framework or non-framework) do not use
this build phase. Not all items to be linked use this build phase either.
Co-Authored-By: Craig Scott <craig.scott@crascit.com>
The XcodeRemoveExcessiveISystem test runs
`find_package(ZLIB)` which returns an SDK-relative
path to `zlib.tlb`. When the test switches the SDK
for building to something different than the SDK used
for configuration the linker rightfully complains about
the mismatch.
The fix is to configure and build with the same SDK.
INTERFACE libraries were created with the intention of collecting usage
requirements for use by other targets via `target_link_libraries`.
Therefore they were not allowed to have SOURCES and were not included in
the generated buildsystem. In practice, this has become limiting:
* Header-only libraries do have sources, they just do not compile.
Developers should be able to edit those sources (the header files)
in their IDE.
* Header-only libraries may need to generate some of their header
files via custom commands.
Some projects work around these limitations by pairing each interface
library with an `add_custom_target` that makes the header files and
custom commands appear in the generated buildsystem and in IDEs.
Lift such limitations by allowing INTERFACE libraries to have SOURCES.
For those with sources, add a corresponding build target to the
generated buildsystem.
Fixes: #19145
Populate `CMAKE_Swift_IMPLICIT_INCLUDE_DIRECTORIES` with the macOS SDK's
include directory so that we filter such implicit directories out of
Swift targets.
Fixes: #19845
When CMAKE_XCODE_GENERATE_TOP_LEVEL_PROJECT_ONLY is set on
Xcode generator created post build scripts which tried to call
XCODE_DEPEND_HELPER.make script in subproject.
But XCODE_DEPEND_HELPER.make don't exist in
subprojects when mentioned option is set on.
Fixes: #20262
The target property introduced by commit 413b71485a (Xcode: Create Xcode
schemes per target, 2019-03-11, v3.15.0-rc1~347^2) was accidentally not
initialized by `CMAKE_XCODE_GENERATE_SCHEME` for custom targets. Fix it
and update the test.
Fixes: #19759
