The change in commit v3.9.0~3^2 (Xcode: Add "outputPaths" to custom
command script build phase, 2017-07-13) was meant to support Xcode 9's
new build system. However, without matching "inputPaths", Xcode will
not re-run the build phase if its outputs have already been generated.
This broke the old Xcode build system too.
Revert the change for now so at least the old Xcode build system works.
Further investigation will be needed to add proper support for Xcode 9's
new build system.
Fixes: #17178
This is needed for Xcode 9's "New Build System", whose release notes
mention "that output must be declared as an explicit output by the
script which generates it" in reference to outputs of custom script
build phases.
When calculating Object Library paths take a look at the
`XCODE_EMIT_EFFECTIVE_PLATFORM_NAME` property to enable builds with
different SDKs. Otherwise a hard-coded architecture could be chosen.
Fixes: #16040
We only define `INTERPROCEDURAL_OPTIMIZATION` behavior for C, CXX, and
Fortran languages. Do not try to enable support for other languages.
Furthermore, each language builds with a different compiler, so check
for support by CMake and the compiler for each language independently.
Fixes: #16944
`xcodebuild` occasionally hangs on some macOS machines (and can be
reproduced independent of CMake). It only happens a few times in 1000
runs, but configuration of a large project calls `try_compile` many
times and therefore frequently hangs due to this problem. I've been
unable to reproduce the hang when using a scheme to build, so always
generate a scheme in `try_compile` projects to work around the problem.
Issue: #16752
This addresses duplicate file reference warnings from xcodebuild caused
by the same file reference being a member of both the target's group and
the top-level Resources group. Since resources are already a member of
their associated target's group the top-level Resources group isn't
strictly necessary, and removing it results in a project structure
closer to that of a current Xcode project template.
Fixes: #15272
Move addition of IPO flags into `cmLocalGenerator::AddLanguageFlags`
because all call sites of that need the IPO flags, but not all were
following the call with `AppendFeatureOptions`.
Add a `HasKnownObjectFileLocation` method returning whether we know the
exact location of object files produced by the native build system.
This is true everywhere except on Xcode when an architecture placeholder
is used.
We can do this only with Xcode 5 and above where we list the object
library files in the per-config link line value. On older Xcode
versions we list the object files as sources so that dependencies work
correctly, but that does not allow per-config objects. (Xcode may allow
per-config source exclusion but only by base name.)
229abfc8 cmGeneratorTarget: Drop unused UseObjectLibraries method
63fbf587 Xcode: Inline relevant parts of UseObjectLibraries
1afacebe Xcode: Do not add Object Libraries source group on Xcode >= 5
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !698
1d829c86 Use quotes for non-system includes
26ee9e42 CPack: drop CPack prefix for includes
5afac50f cmConfigure: Ensure separate include block in headers
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !691
dfa8263f Implement interprocedural optimization for GNU compilers
1588a577 Add policy CMP0069 to enforce INTERPROCEDURAL_OPTIMIZATION
a7575700 Refactoring: s,GetFeatureAsBool,IsIPOEnabled,
e05835c3 CheckIPOSupported: Visual Studio and Xcode generators do not support IPO
Acked-by: Kitware Robot <kwrobot@kitware.com>
Reviewed-by: Brad King <brad.king@kitware.com>
Reviewed-by: Nils Gladitz <nilsgladitz@gmail.com>
Merge-request: !568
Previously the `INTERPROCEDURAL_OPTIMIZATION` target property was
honored only for the Intel compiler on Linux and otherwise ignored. In
order to add support for more compilers incrementally without changing
behavior in the future, add a new policy whose NEW behavior enforces the
`INTERPROCEDURAL_OPTIMIZATION` property. Add flags for supported
compilers and otherwise produce an error.
77139e32 Swift: Simplify mixed test case to make it version agnostic
c03141c0 Swift: Default to Swift 3.0 with Xcode 8.3 and later
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !638
Always use the dependency tracker Makefile to ensure targets that
depend on object libraries are up-to-date. For all other target
types we use the hack only for Xcode < 5.
Fixes: #16615
Xcode seems to have troubles to track target dependecies to
object files. This may lead to stale targets as reported in
issue #16615.
As a work-around the pre-Xcode 5 dependecy tracker hack with
post-build make files is extended to also take object libraries
into account.
When building with multiple SDKs within one project Xcode requires
the usage of ${EFFECTIVE_PLATFORM_NAME} to put temporary and build
outout into separate directories. For example an iOS device and
simulator build use two different SDKs (iphoneos and iphonesimulator).
In the past cmake tries to detect embedded toolchains that could
possibly use simulators and emitted EFFECTIVE_PLATFORM_NAME (EPN)
at the proper locations. In #16253 Mark noticed that if he
uses macosx and iphoneos in combination the necessary EPN is not
emitted. This is because CMake by default assumes macosx SDK which
does not trigger EPN emission.
The fist naive approach - enabling EPN unconditionally revealed that
then the EPN leaks into generator expressions like $<TARGET_FILE:xxx>
which might be a regression and thus is unacceptable.
The next approach was to add an CMake property to enable EPN emission
unconditionally. This solved the reported problem.
But the EPN leakage also happened for the embedded toolchains already
without anyone noticing. So the control property was turned into a
tri-state one:
* No definition: EPN is activated for embedded toolchains like before
* ON: EPN is always emitted
* OFF: EPN is never emitted
That approach gives the user the chance to disable EPN for embedded
toolchains and restores generator expression functionality for those.
Closes: #16253
Brad King