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.
The properties added by commit 4a62e3d97c (macOS: Add
OSX_COMPATIBILITY_VERSION and OSX_CURRENT_VERSION properties,
2020-01-24, v3.17.0-rc1~80^2~1) are general-purpose for all platforms
using Mach-O formats and not just on OS X. Rename them accordingly.
The properties are new to the CMake 3.17 release so we can rename
them without compatibility concerns.
Fixes: #20442
Since commit d4d0dd0f6a (cmLinkLineComputer: Add ComputeLinkLibs
overload with backtraces, 2019-09-13, v3.16.0-rc1~87^2~4), backtraces
have been collected by `ComputeLinkLibs` by looking back through the
link implementation libraries for one matching the text of the link line
item. This is slow in projects with long link lines.
Instead, teach `cmComputeLinkDepends` and `cmComputeLinkInformation` to
carry backtrace information explicitly along with the text of each item.
Fixes: #20322
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 `-Wmost` flag was added by commit 97a51d2172 (ENH: add more xcode
stuff, 2005-01-27, v2.4.0~2396), along with a couple others, as part of
very early work on the Xcode generator. I suspect that the flags were
part of Xcode's project creation wizard. However, they are not
appropriate for CMake-based projects because we already have our own
mechanisms for specifying flags desired by the project or user.
Simply drop the flags.
Fixes: #13516
