The set of compile flags used for a target's C and C++ sources is based
on the linker language. By default this is always the C++ flags if any
C++ sources appear in the target, and otherwise the C flags. Therefore
we can define the `COMPILE_LANGUAGE` generator expression in
`INCLUDE_DIRECTORIES` to match the selected language.
This is not exactly the same as for other generators, but is the best VS
and Xcode can do. It is also sufficient for many use cases since the
set of include directories for C and C++ is frequently similar but may
be distinct from those for other languages like CUDA.
Fixes: #17435
The set of compile flags used for a target's C and C++ sources is based
on the linker language. By default this is always the C++ flags if any
C++ sources appear in the target, and otherwise the C flags. Therefore
we can define the `COMPILE_LANGUAGE` generator expression in
`COMPILE_DEFINITIONS` to match the selected language.
This is not exactly the same as for other generators, but is the best VS
and Xcode can do. It is also sufficient for many use cases since the
set of definitions for C and C++ is frequently similar but may be
distinct from those for other languages like CUDA.
Issue: #17435
Some generators auto-generate targets. For example VS generators create
the ALL_BUILD target. Add the ability to mark targets as generator
provided and return that info through cmake-server codemodel.
The changes are mostly converting old-style explicit iterator for loops
into ranged for statements. A number of for loops had already been
changed over, but local variables had been left behind instead of being
absorbed into the ranged for statement, so these have been cleaned up
too. A couple of minor improvements were made in areas already being
updated by the for loop changes to slightly simplify the code or to
avoid unnecessary conversions between `const char*` and `std::string`.
Rather than injecting `CMakeLists.txt` files into each target's
`SOURCES`, teach the generators to add them during generation using
dedicated code. This avoids mutating the original targets, and avoids
polluting `$<TARGET_PROPERTY:foo,SOURCES>` with generator-specific
content.
This also avoids listing the `CMakeLists.txt` sources in the results of
`CMAKE_DEBUG_TARGET_PROPERTIES==SOURCES` so the `RunCMake.TargetSources`
test no longer needs a separate case for IDEs.
Fix issues diagnosed by clang-tidy [readability-else-after-return]
These were mostly only showing up on OSX.
Signed-off-by: Matthias Maennich <matthias@maennich.net>
Fix issues diagnosed by clang-tidy [modernize-use-override].
These occurrences are only showing up on OSX.
Signed-off-by: Matthias Maennich <matthias@maennich.net>
Fix remaining occurrences of the issue addressed in commit 5962db4389
(Use C++11 nullptr, 2017-08-22) that are only showing up on macOS.
Signed-off-by: Matthias Maennich <matthias@maennich.net>
We now require C++11 support including `override`. Drop use of
the old compatibility macro. Convert references as follows:
git grep -l CM_OVERRIDE -- '*.h' '*.hxx' '*.cxx' |
xargs sed -i 's/CM_OVERRIDE/override/g'
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
