Since commit 8f64df0a7c (CUDA: Generic all and all-major support,
2021-12-19, v3.23.0-rc1~23^2), setting `CUDA_ARCHITECTURES` to a value
other than `all` or `all-major` is ignored with NVCC 11.5+. Fix the
logic to return early only when actually using an "all" value.
Fixes: #23243
When given two source paths via `-S` or just directory paths prefer
the last one. When the paths are mixed always prefer the last `-S`
entry.
Fixes: #23238
Add missing `CMake_TEST_Qt{4,5}` conditions on Qt4 an Qt5 tests.
Configuring CMake with `-DCMake_TEST_Qt5=OFF` should prevent any
attempt to search for Qt5.
Fixes: #23239
f73457ca2e cmake: Ignore any empty "" command line arguments
67f97f5478 Tests: Add RunCMake helper to run cmake with raw execute_process args
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6980
libarchive's crypto library checks use its `config.h` inside the
`try_compile` project. Since commit ade3b16e63 (libarchive: Use KWIML
to get fixed-size integer types, 2020-06-01, v3.18.0-rc1~33^2),
that header depends on KWIML inside CMake. Add the include directory
for KWIML to the crypto library checks. Otherwise, they always fail
due to not finding the KWIML headers, and libarchive decides not
to link the crypto library.
libarchive has other code besides the hash algorithms that depends on
the crypto library if its ENABLE_OPENSSL option is enabled (which in
CMake is controlled by CMAKE_USE_OPENSSL). It seems to be missing some
conditions to link the crypto library in those cases, and instead relies
on at least one of the above-mentioned checks to pass. If they all
fail, and we are using system curl, we might not link the crypto
library.
Fixes: #23234
d92469e572 Help: Clarify how package resolve mode is intended to be used
f320a31087 cmake --build: prioritize --resolve-package-references over preset
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6984
Fix the test added by commit 61b9764b03 (CUDA: Allow both
CUDA_SEPARABLE_COMPILATION and CUDA_PTX_COMPILATION, 2021-09-17,
v3.23.0-rc1~516^2) to have a `project()` name matching what
is passed to CTest's `--build-project` option. Otherwise, on
VS builds, MSBuild warns:
MSBUILD : error MSB1009: Project file does not exist.
Other CUDA tests use a matching project name already.
Prior to commit 1d709ea2f5 (cmGeneratorTarget: Propagate backtraces from
INTERFACE_LINK_LIBRARIES, 2021-12-15, v3.23.0-rc1~228^2), the value of
`INTERFACE_LINK_LIBRARIES` was a single string. If an unquoted
generator expression passed to `target_link_libraries` contained `;` and
became multiple arguments, they would all accumulate as a single
`;`-separated list in the value of `INTERFACE_LINK_LIBRARIES`. Since
that commit, each argument to `target_link_libraries` is placed in
`INTERFACE_LINK_LIBRARIES` as a separate entry, as has long been the
case for `LINK_LIBRARIES`. That behavior change broke projects that were
accidentally relying on accumulation in `INTERFACE_LINK_LIBRARIES` to
produce complete generator expressions containing `;`.
Teach `target_link_libraries` to accumulate consecutive non-keyword
arguments into a single entry before placing them in `LINK_LIBRARIES` or
`INTERFACE_LINK_LIBRARIES`. For example, treat `a b c` as if they were
written as `"a;b;c"`. This restores the previously accidental support
for unquoted generator expressions in `INTERFACE_LINK_LIBRARIES`, and
also enables it for `LINK_LIBRARIES`.
For now, do not drop the `target_link_libraries` documentation that
recommends quoting generator expressions. Quoting is still important to
populate `LINK_LIBRARIES` in CMake 3.22 and below, and is also good
practice to keep generator expressions whole.
Fixes: #23203
Since commit daa6d2bc04 (ENH: updated handling of debug and optimized
target link libraries, 2006-11-29, v2.6.0~2471) the ancient
`<lib>_LINK_TYPE` compatibility lookup was done using the name of the
dependent target for which `target_link_libraries` is called, rather
than the name of the library dependency being considered. This code
probably does nothing. Remove it.
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
Improve the documentation added by commit ec8d37b3b1 (VS: Support
version specification in CMAKE_GENERATOR_INSTANCE, 2021-10-26,
v3.23.0-rc1~452^2~1).
Fixes: #23225
Add section headers for each signature, and a synopsis linking to them.
Re-order sections to introduce the main `export(TARGETS)` functionality
before mentioning the `export(EXPORT)` shorthand, which may be confused
with `install(EXPORT)`.
Fixes: #23221
This variable was added by commit 42f74df6d4 (Add basic Android platform
module, 2014-06-06, v3.1.0-rc1~416^2), but was not previously documented.
Fixes: #23227
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`.
Always using `_supported_components` causes conflicts when transitive
dependencies also set this variable, e.g., because the developers
followed these code samples.
An even more general approach could be to set
`_${CMAKE_FIND_PACKAGE_NAME}_supported_components` instead, but such a
change should then be applied to other variables for consistency.
Fixes: #23112
Brad King