In commit e637744c51 (Xcode: Use "Link Binary With Libraries" to link
any library, 2019-07-10, v3.19.0-rc1~494^2~1) we accidentally added all
the library type files to "Link Binary With Libraries" build phase if
they were passed in as source files. Revert that change as any actually
linked libraries will be added to that build phase later in the
`AddDependAndLinkInformation` call.
Fixes: #21361
b6c60f14b6 macOS: Default to arm64 architecture on Apple Silicon hosts
383e81aa60 Tests: Teach RunCMake to ignore Xcode internal objc warnings
8f75912176 Tests: Enable Assembler test case when CMAKE_OSX_ARCHITECTURES has one value
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !5291
Detect `arm64` hardware using a method that pierces Rosetta. If
`CMAKE_OSX_ARCHITECTURES` is not set, pass explicit flags to the
toolchain to use `arm64` instead of letting the toolchain pick.
Fixes: #20989
The original Xcode build system did not properly re-link targets that consumed
object libraies. We worked around that with a post-build command on the object
libraries themselves that removed their consumers if out of date. The "new
build system" does not appear to need such help, so drop the workaround.
The target has not been generated since commit d92d51429e (BUG: fix for bug
6193, fix xcode depend helper, 2008-01-10, v2.6.0~553). Remove it from
the list of special targets.
Extend the `-T <toolset>` option to support a `buildsystem=` field with
the Xcode generator. Add a `CMAKE_XCODE_BUILD_SYSTEM` variable to
inform project code about the selected build system variant.
Do not attach a custom command to a target if it is already attached to one of
the target's dependencies. The command's output will be available by the time
the target needs it because the dependency containing the command will have
already been built.
Since commit fb45559e09 (Xcode: Process targets in depth-first order during
generation, 2018-07-19, v3.13.0-rc1~293^2) we generate a target only after
generating its dependencies. Therefore when visiting the custom commands in a
target, we can assume that custom commands in its dependencies have already
been visited.
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>
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
Xcode 12 beta 3 now warns about using the legacy build system.
Since generation of the build system is CMake's responsibility,
the warning is not relevant to our users. Suppress it.
Issue: #18088
When `CMAKE_OSX_ARCHITECTURES` is not specified, we add the Xcode
setting `ONLY_ACTIVE_ARCH = YES` with the intention of targeting the
native architecture of the host. However, the default `ARCHS` value
chosen by "Xcode 12 Universal Apps" includes multiple architectures.
Add an explicit `ARCHS` setting with value `$(NATIVE_ARCH_ACTUAL)`
to tell Xcode to use the host's native architecture only.
Fixes: #20893
Add external libraries as fileRefs to Xcode project and add those
references to Link Binary With Libraries build phase. This allows
linking .a, .o, .dylib, .framework and .tbd libraries through "Link
Binary With Libraries" build phase, as opposed to `OTHER_LINKER_FLAGS`.
This improves on the approach added by commit 58c05e1c73 (Xcode: Use
"Link Binary With Libraries" build phase when possible, 2020-06-12).
Try linking all target linked libraries through frameworks build phase
instead of linker flags, thus letting Xcode manage build product paths
correctly. Prevent adding duplicate entries to "Link Binary With
Libraries" build phase.
Add check for configuration-dependent linking - in case the library is
not present in all configurations revert back to linker flags which are
per-configuration.
This does change the order of libraries linked, but that does not seem
to matter for Apple linkers invoked by Xcode, even for static libraries.
The linker will go back and re-consider a static library from earlier
on the link line when more symbols from its objects are needed.
Fixes: #14185
Adds a flag to indicate that pipe output from a custom command should be
interpreted as UTF-8 encoded. This change does not introduce a public
way to set the flag, but generators that create internally-generated
commands know if they are calling cmake, which uses UTF-8 pipes.
MSBuild added support for interpreting output of PreBuildEvent,
PreLinkEvent, PostBuildEvent, and CustomBuildStep as UTF-8. This change
will appear in Visual Studio 16.6 Preview 3. It is opt-in, and you need
to add the StdOutEncoding tag. MSBuild treats these as property bags so
if we emit the tag for earlier versions of Visual Studio it would be
safely ignored. This change emits the StdOutEncoding tag and sets it to
UTF-8 whenever the custom command UTF-8 pipe flag is set. This fixes
globalization issues when the output from cmake contained characters
that required MSBuild to interpret as UTF-8 before displaying them.
