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
Since commit 11da882a12 (Apple: Introduce separate system name for iOS,
tvOS, and watchOS, 2018-01-15, v3.14.0-rc1~14^2~1) we support setting
`CMAKE_SYSTEM_NAME` to `iOS`. Existing iOS toolchain files already
set `IOS` as a short-hand variable, so do the same here.
- Remove code signing requirements for non-macOS
- Do not set deployment target for non-macOS
- Build static library for compiler feature detection for non-macOS
- Use framework to run CompilerId tests for watchOS
- Port tests to new SDK handling
- Add new Apple cross-compiling section to toolchain documentation
Closes: #17870
Add `XCODE_SCHEME_*` target properties and associated variables
`CMAKE_XCODE_SCHEME_*` to initialize them on target creation.
Map each target property value to an associated Xcode scheme entry.
Co-Author: Martin Sander <mail@martin-sander.de>
Fixes: #17919
Run the `clang-format.bash` script to update all our C and C++ code to a
new style defined by `.clang-format`. Use `clang-format` version 6.0.
* 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.
Since commit v3.11.0-rc1~467^2 (VS,Xcode: Add CMakeLists.txt sources
without mutating targets, 2017-10-18) we do not add `CMakeLists.txt` to
target sources but instead generate references to them directly. This
broke projects that explicitly specify their `CMakeLists.txt` file as a
source file because the explicit entry is no longer consolidated with
the generated one.
Teach the relevant generators to avoid duplicating `CMakeLists.txt`
source references and add test cases.
Fixes: #17828
In case CMAKE_XCODE_GENERATE_TOP_LEVEL_PROJECT_ONLY has been enabled
generate only the root-level ZERO_CHECK target so targets in
subdirectories pick up the root generator target of ZERO_CHECK.
For the case that CMAKE_XCODE_GENERATE_TOP_LEVEL_PROJECT_ONLY is not
enabled more investigation and a proper and final fix is still needed.
Issue: 14297
