To be more consistent between genex and variables as well as
the forecomming LINK_GROUP genex, rename variable *_LINK_USING_<FEATURE>*
in *_LINK_LIBRARY_USING_<FEATURE>*
a2cfa2da4f GenEx/LINK_LIBRARY: Add features for framework support on Apple
40178f3c90 cmGlobalGenerator: Add helper to split framework path
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6967
Check that the file that is accessed via `file(STRINGS...)` truly
exists.
This is not the case in some EMSCRIPTEN/WebASM builds where we want to
overwrite the HDF5 find logic manually. The missing check here prevents
that one can overwrite the search logic in exotic environments.
Since commit f90d15458a (FindGLUT: Use pkg-config to find flags if
available, 2021-06-11, v3.22.0-rc1~469^2), the `GLUT_LIBRARIES` may come
from `pkg-config`, in which case they may be `-l` flags instead of
absolute paths. Propagate `GLUT_LIBRARY_DIRS` to GLUT::GLUT too.
Fixes: #23229
Recent MCR versions have the following `VersionInfo.xml`:
<version>9.11.0.1837725</version>
Fix parsing of multiple digits in the version components
so that we do not mistake this for version `9.1`.
Due to add_command() being a macro it introduced excessive and
nonobvious escaping in different parts of the script. Because of
one of such places the resulting script would have an erroneous
${TEST_LIST} if the user data (in test parameters) had a semicolon.
To eliminate this non-obvious escaping, add_command() was converted
to function. Updated the escaping accordingly.
Fixes: #23059
1e947fcb83 Merge branch 'backport-IntelLLVM-depfile-flags' into IntelLLVM-depfile-flags
a8b6bf9a38 IntelLLVM: Add dependencies on system header files on Windows
94f1bbdd54 Intel: Add dependencies on system header files on Windows
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6964
In commit a90d2a9eed (IntelLLVM: Add support for Intel LLVM-based
compilers, 2020-11-02, v3.20.0-rc1~89^2~20) the IntelLLVM depfile
generation flags were taken from `Platform/Windows-Intel-C`. Those
flags were added by commit a624a3e1b3 (Ninja: Use deps=gcc for Intel
Compiler on Windows, 2019-01-30, v3.14.0-rc1~30^2), which forgot to
account for commit 6d74e7870b (Ninja: Add dependencies on
system-provided header files, 2016-03-15, v3.6.0-rc1~265^2).
The `-QMD` option generates Makefile dependencies. The `-QMMD` option
generates Makefile dependencies, but excludes system header files.
Part of the BuildDepends test includes a header, cmake_pch.hxx, that
includes a second header, zot_pch.hxx. The test builds a pch file for
cmake_pch.hxx, touches zot_pch.hxx, then verifes that cmake_pch.hxx.pch
is regenerated based on the dependencies.
The cmake_pch.hxx contains `#pragma system_header` before it includes
zot_pch.hxx. `#pragma system_header` indicates that the portion of the
file following the pragma is to be treated as a system header.
When `-QMMD` is used to generate dependencies, the `#include` of
zot_pch.hxx is ignored because it `-QMMD` says to ignore system headers.
Using `-QMD` instead uses all headers when generating dependencies
and causes this test to pass. The Clang configuration in
Platform/Windows-Clang.cmake also uses the `-MD` option for generating
pre-compiled headers, instead of `-MMD`.
Signed-off-by: William R. Dieter <william.r.dieter@intel.com>
In commit a624a3e1b3 (Ninja: Use deps=gcc for Intel Compiler on Windows,
2019-01-30, v3.14.0-rc1~30^2) we forgot to account for commit 6d74e7870b
(Ninja: Add dependencies on system-provided header files, 2016-03-15,
v3.6.0-rc1~265^2).
To enable the management of incompatible $<LINK_LIBRARY> declarations,
add LINK_LIBRARY_OVERRIDE and LINK_LIBRARY_OVERRIDE_<LIBRARY> target
properties.
Before it would output a typed test as follows:
Suit/Type.Case
And now it would be:
Suit.Case<Type>
In case of NO_PRETTY_TYPES it would simply use the type number
instead of its text representation:
Suit.Case<0>
The change is introduced to make sure CTest outputs tests in a
similar fashion which is "*Suit.Case*" and angle brackets "<>"
emphasize that we are dealing with a typed (template) kind.
When there were many cases (two digits or more) the "prettier" would
fail to recognize the pretty part leaving the test name unprocessed.
The fix made sure the processing would work correctly, irrespective
of the case number.
Before the fix, for the following input:
TypedSuite/1. # TypeParam = int
case
TypedSuite/10. # TypeParam = char
case
The output would be:
TypedSuite/int.case
TypedSuite/10. # TypeParam = char.case
Now the output will be:
TypedSuite/int.case
TypedSuite/char.case
In commit fc3a1cbdd8 (CompilerID: Compiler extensions default detection,
2021-05-29, v3.22.0-rc1~52^2~2), extensions were assumed to be `OFF`
for Clang targeting the MSVC ABI. However, the `clang` and `clang++`
tools both seem to have extensions enabled by default even when
targeting the MSVC ABI.
This can be observed with the `RunCMake.CompileFeatures` test.
It fails with the GNU-like `clang/clang++` front-end, but removing
the above special case makes it pass. The test passes either way
with the MSVC-like `clang-cl` front-end.
This brings the patch step into line with all the others which already
had their own `USES_TERMINAL_<step>` keyword. All steps (including
patch) already have their own `LOG_<step>` keyword too, so the lack of
`USES_TERMINAL_PATCH` was inconsistent.
Before the fix the gtest_discover_tests() function would strip the
user data in test parameters (everything to the right of GetParam())
of spaces. Now the parameters aren't altered in any way.
Fixes#23058
Commit 14d8a276 (CUDA: Support nvcc 11.5 new -arch=all|all-major flags,
2021-08-17) added all and all-major options to CUDA_ARCHITECTURES. These are
fairly generic and likely to see real-world use by distributors. Thus it's
desirable to support these also for Clang and older NVCC versions.
The supported architectures are dependent on the toolkit version. We determine
the toolkit version prior to compiler detection. For NVCC we get the version
from the vendor identification output, but for Clang we need to invoke NVCC
separately.
The architecture information is mostly based on the Wikipedia list with the
earliest supported version being CUDA 7.0. This could be documented and
expanded in the future to allow projects to query CUDA toolkit version and
architecture information.
For Clang we additionally constrain based on its support.
Additionally the architecture mismatch detection logic is fixed, improved and
updated for generic support:
* Commit 01428c55 (CUDA: Fail fast if CMAKE_CUDA_ARCHITECTURES doesn't work
during detection, 2020-08-29) enabled CMAKE_CUDA_COMPILER_ID_REQUIRE_SUCCESS
if CMAKE_CUDA_ARCHITECTURES is specified. This results in
CMakeDetermineCompilerID.cmake printing the compiler error and our code for
presenting the mismatch in a user-friendly way being useless. The custom
logic seems preferable so go back to not enabling it.
* Commit 14d8a276 (CUDA: Support nvcc 11.5 new -arch=all|all-major flags,
2021-08-17) tried to support CMP0054 but forgot to add x to the interpolated
result. Thus the conditions would always evaluate to false. This is fixed as
a byproduct of removing NVIDIA specific checks, improving the error message
and replacing architectures_mode with a simpler architectures_explicit.
Visual Studio support omits testing the flags during detection due to
complexities in determining the toolkit version when using it.
A long-term proper implementation would be #23161.
Implements #22860.
Craig Scott