The Google test framework allows to write the results into an XML file
since commit 315edd2c14 (GoogleTest: Add XML_OUTPUT_DIR parameter,
2020-03-06, v3.18.0-rc1~538^2~2). This file is passed on the command
line: `--gtest_output=xml:FILE_NAME`.
The module allows to specify a directory to save those files with
**TEST_XML_OUTPUT_PARAM**.
If the option is set, the filename will be set to
`${prefix}${pretty_suite}.${pretty_test}${suffix}.xml`.
The pretty names contain parameters for the tests, if
value-parameterized tests are used. These parameters may not be safe to
use in file names.
There are two possible options:
1. sanitize the file name
2. omit the values and use the internal numbering of gtest
This commit chose option 2. The testname needs to be a valid C++
identifier and should therefore be reasonable for a filename.
Note that the generated names contain slashes. This will lead to
subdirectories, but works on both Linux and Windows.
Fixes: #20877
When using a Visual Studio generator, we do not know the path to
`CMAKE_CUDA_COMPILER` until after the compiler id detection project
extracts it. However, based on the VS toolchain configuration we know
that the compiler id will be NVIDIA, so use that to drive the CUDA
architecture flag logic. After the main compiler id step we know
`CMAKE_CUDA_COMPILER`, so `CMAKE_CUDA_COMPILER_TOOLKIT_ROOT` can then be
computed.
The result variable was `CUDAToolkit_NVCC_EXECUTABLE` instead of
`_CUDA_NVCC_EXECUTABLE`, which the rest of the code used. Also, we can
simply `set()` the `_CUDA_NVCC_EXECUTABLE` value without searching.
Fixes: #20847
14ac7e82bd Help: Explicitly say transaction, don't abbreviate to trans
cf1010f71b Help: Correct and condense examples for VS_SOLUTION_DEPLOY
8c3b02c3f3 Help: Add missing cross-referencing for generator expressions
6ba04f157a Help: Formatting, crossref for FRAMEWORK_MULTI_CONFIG_POSTFIX_<CONFIG>
83df16dee7 Help: Add missing PCH_WARN_INVALID docs and related cleanups
3a04b0fb8d Help: Fix formatting error and consistency for gtest_discover_tests()
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4915
The ability to disable adding architectures completely for packaging purposes
and cases requiring passing the architectures flags explicitly has been
requested.
Support a false value for CUDA_ARCHITECTURES and CMAKE_CUDA_ARCHITECTURES
for this purpose.
Implements #20821.
Clang isn't very good at finding the installed CUDA toolkit.
The upstream recommendation is that we should pass the toolkit explicitly.
Additionally:
* Avoids Clang having to search for the toolkit on every invocation.
* Allows the user to use a toolkit from a non-standard location by simply
setting CUDAToolkit_ROOT. The same way as with FindCUDAToolkit.
Clang wants the directory containing the device library and version.txt as the
toolkit path.
We thus pass the newly introduced CUDAToolkit_LIBRARY_ROOT as the toolkit path.
We save CUDAToolkit_ROOT_DIR and CUDAToolkit_LIBRARY_ROOT on Clang to have them
available in try_compile() and avoid unnecessary re-searching or a possibly
different installation being found in FindCUDAToolkit.
This however means that the selected toolkit can't be changed after the initial
language enablement.
We now determine CUDA compiler ID before doing actual detection, as we don't
want to spend time finding the CUDA toolkit for NVIDIA.
Implements #20754.
We can avoid searching for this since CUDAToolkit_TARGET_DIR always contains
the include/ directory. But add a warning just in case.
Also apply this in CMakeDetermineCUDACompiler for Clang code.
On scattered installations version.txt and nvvm are located at this location.
This may be useful to users and will allow us in the future to parse
version.txt instead of invoking nvcc to figure out the CUDA toolkit version.
We also add it to CMakeDetermineCUDACompiler in preparation for future use by
Clang code.
A portion of FindCUDAToolkit was previously split in commit 76ef19fd
(FindCUDAToolkit: Factor out discovery code into a separate file, 2020-04-22)
out into Internal/CUDAToolkit to allow re-use of the code in
CMakeDetermineCUDACompiler for Clang support.
This has turned out to be a bad solution due to Clang requiring quite a bit of
special handling and special handling for NVCC leaking out from
Internal/CUDAToolkit into the Clang code using it.
Thus it seems better to re-unify this code and duplicate the parts of the code
necessary for Clang where it's required. This will help us get logic correct
for both NVCC and CUDA handling. We can still unify the common parts in the
future once the code has matured.
Fix the regex syntax added by commit c24791f016 (FindOpenSSL: Detect
OpenSSL 3.0.0, 2020-05-27, v3.17.3~1^2). Add missing escapes.
Test with `openssl-3.0.0-alpha3`.
While at it, also unset a temporary variable after use.
This ended up after the searching after commit 76ef19f (FindCUDAToolkit: Factor
out discovery code into a separate file, 2020-04-22).
Move it back to where it was and should be.
__compiler_clang() doesn't call __compiler_gnu() if we're emulating MSVC. Thus
CMAKE_DEPFILE_FLAGS_CUDA remains unset and compiling doesn't work, due to NVCC
dependency injection workaround in CMakeCUDAInformation.cmake, which triggers
for Ninja if they're not set.
Always set the depfile flags to fix this. Most other compiler modules seem to
do the same.
We don't distinguish real/virtual architectures during compiler detection.
If the user passes -DCMAKE_CUDA_ARCHITECTURES="70-virtual" we'll test with only
the real architecture.
If it works "architectures" will end up as "70". We check equality using
strings, so this fails and we incorrectly throw an error.
Fix this by comparing against CMAKE_CUDA_ARCHITECTURES with the specifiers
stripped.
We need to deduplicate tested_architectures for the same reason in case the
user specified something like "70-real;70-virtual".
Brad King