For NVCC the compiler takes care of device linking when passed the "-dlink"
flag.
Clang doesn't support such magic and requires the buildsystem to do the work
that NVCC does behind the scenes.
The implementation is based on Bazel's device linking documentation:
7cabcdf073/third_party/nccl/build_defs.bzl.tpl (L259)Closes: #20726
357e2ef429 CheckSoureRuns: Add a unified way to check if a source runs
10ae907de0 CheckSoureCompiles: Add a unified way to check if a source compiles
f5c928f73c Add a test to verify '\' handling in CHECK_CXX_SOURCE_COMPILES
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Michael Hirsch, Ph.D. <michael@scivision.dev>
Merge-request: !5223
b8ecd4df5f ExternalProject: Use CMP0114 NEW behavior with Xcode "new build system"
fe258f6382 Tests: Skip RunCMake.XcodeProject device cases for Xcode "new build system"
1c3d2d0951 Tests: Skip Qt*Autogen.MocSkipSource case for Xcode "new build system"
542884e527 Tests: Update RunCMake.XcodeProject cases for Xcode "new build system"
832a78be2d Tests: Update BuildDepends test for Xcode "new build system"
ff76c51ec3 Tests: Update RunCMake.file case with workaround for Xcode "new build system"
1806cdd17c Tests: Avoid duplicate custom commands for Xcode "new build system"
8d5f4c4db9 Xcode: Switch to the "new build system" for Xcode 12 and above
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !5229
The TI compiler does not support C++98, only C++03
(based on manual of current version).
This change sets the C++98 option to C++03 based on the fact that it
is done this way for the SunPro compiler already.
Previously when CMAKE_CROSSCOMPILING was ON we'd end up not setting the target
directory if the non-scattered one didn't exist.
Fix this by assuming a scattered installation if the target directory isn't set
after the crosscompiling logic.
This is the same fix as commit 2c0d5d01ee (CUDA: Support scattered
installations when crosscompiling with Clang, 2020-09-14).
Extend the `-T <toolset>` option to support a `buildsystem=` field with
the Xcode generator. Add a `CMAKE_XCODE_BUILD_SYSTEM` variable to
inform project code about the selected build system variant.
Adds a set of sub commands to the string command for parsing JSON, the
JSON commands are: GET, TYPE, MEMBER, LENGTH, REMOVE, SET, and EQUAL.
Closes: #19501
`ExternalProject_Add_StepTargets` and `INDEPENDENT_STEP_TARGETS` have
some limitations and lack some sanity checks. They can cause confusing
build systems to be generated. The basic problems are:
* The notion of step independence is attached to the step target
rather than the step itself.
* The custom commands implementing the steps are duplicated in the
step targets and the primary targets. This can cause races.
It is also incompatible with the Xcode "new build system".
Fix this by introducing policy CMP0114 to change the way step target
dependencies are handled. Define independence from external
dependencies as a property of each individual step regardless of whether
there is a target for it. Add dependencies among the primary target and
the step targets such that each custom command only appears in one
target. When some steps are disconnected from the primary target, add
step targets for the steps commonly depended upon so that there is a
place to hold their custom commands uniquely.
Fixes: #18663
Previously when CMAKE_CROSSCOMPILING was ON we'd end up not setting the target
directory if the non-scattered one didn't exist.
Fix this by assuming a scattered installation if the target directory isn't set
after the crosscompiling logic.
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.
This may break existing projects that do not properly mark non-created
outputs with the `SYMBOLIC` property. Previously a chain of two custom
commands whose intermediate dependency is not created would put both
commands in a dependent project's Makefile even if the first command is
also in its dependency's Makefile. The first command would run twice
but the build would work. Now the second command needs an explicit
`SYMBOLIC` mark on its input to tell CMake that it is not expected to
exist. To maintain compatibility with projects that left out the mark,
add a policy activating the behavior.
