When specifying a pure C# target in the `target_link_libraries()` call to
another C++ target, a `<ProjectReference>` was setup for it (we wanted this)
but also a corresponding `.lib` was added under `<AdditionalDependencies>`
(we didn't want this).
This change introduces a check that prevents `.lib` linker options from
being used when the corresponding target for that library is a C# target.
Fixes: #17678
Previously, code wrote out empty tags for `<DebugInformationFormat>`
like so:
<DebugInformationFormat></DebugInformationFormat>
This gets corrected by Visual Studio 2017 when saving the solution. The
correction appears as:
<DebugInformationFormat>
</DebugInformationFormat>
In the spirit of keeping the XML structure as close to what Visual
Studio expects as possible, a newline is inserted after the opening tag
in the empty case.
506fda1c Genex: Enable COMPILE_LANGUAGE for INCLUDE_DIRECTORIES with VS and Xcode
c2f79c98 Genex: Enable COMPILE_LANGUAGE for COMPILE_DEFINITIONS with VS and Xcode
0795d25b cmVisualStudio10TargetGenerator: Factor out include dir computation
1ab4d186 cmLocalVisualStudio7Generator: Clarify variable name of compiled language
07e1a743 cmLocalVisualStudio7Generator: Clarify condition for target that compiles
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !1657
The MSVC CUDA build customizations before CUDA 9 would not explicitly
add the -x cu option when building. This caused .cpp and .c files
invoked with CudaCompile to be compiled as host code and not
cuda. Now when we detect CUDA < 9 we will explicitly add this
option to correct this bug.
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
Add `VS_SHADER_DISABLE_OPTIMIZATIONS` and `VS_SHADER_ENABLE_DEBUG`
source file properties to control these settings on `.hlsl` files in the
VS generator.
Fixes: #17406
std::{begin,end} are part of C++11, std::{cbegin,cend} are part of C++14
and an standard compliant implementation has been introduced within the
'cm' namespace: cm::{cbegin,cend}.
std::size is only part of C++17, hence exposing a compliant implementation
within namespace cm (cm::size).
where possible, the standard implementations are reused.
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.
