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
* Change some functions to take `std::string` instead of
`const char*` in the following classes: `cmMakeFile`, `cmake`,
`cmCoreTryCompile`, `cmSystemTools`, `cmState`, `cmLocalGenerator`
and a few others.
* Greatly reduce using of `const char*` overloads for
`cmSystemTools::MakeDirectory` and `cmSystemTools::RelativePath`.
* Remove many redundant `c_str()` conversions throughout the code.
Clang incorrectly warns about a case where we initialize a variable
inside a condition in such a way that it will always be initialized
before we use it. Simply initialize the variable when defining it to
silence the warning.
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
