With the Ninja generator we may invoke `cmake_symlink_library` with
different slash conventions (`/` versus `\`) for different arguments.
Fix comparison of the paths/names given to tolerate this.
Fixes: #17579
4b7618d1 CUDA: Fix CUDA_STANDARD selection via cxx_std_11 with CXX_STANDARD
1d2d9c18 cmMakefile: Refactor determining a targets C++ standard level
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !1590
1f3933d3 Address code review feedback
14ebad53 Use IMAGE_FILE_HEADER and add missing Arm 32bit images support
8950183b Add Arm64 support to COFF symbol export feature
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !1603
In the AutogenInfo.cmake file the separator for nested lists
was `@LSEP@` which led to a speed regression because the `@`
character triggered an (unsuccessful) expression evaluation.
By setting the policy version of the CMake instance in the
`_autogen` target to 3.9, the OLD `@` evaluating behavior
controlled by policy CMP0053 is disabled.
Also the nested lists separator string is changed to `<<<S>>>`,
which solves the problem twofold.
Closes#17570
7ab9a625 Makefiles: Drop 'requires' step and its supporting infrastructure
5f2e2c38 Makefiles: Avoid nested make calls for Fortran module dependencies
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !1523
When C++ features require a certain C++/CUDA level, verify or update the
standard level target property for each language independently.
While at it, add missing rejection of invalid `CUDA_STANDARD` property
values.
Co-Author: Brad King <brad.king@kitware.com>
Fixes: #17519
The 'requires' step was used to provide implicit dependencies between
the generated Fortran module files and a Fortran target that needs these
module files to ensure the correct compilation order. After recent
refactoring to resolve all dependencies explicitly through `.mod.stamp`
make targets, the separate 'requires' step is not needed anymore.
Makefiles generated by cmake use a series of nested calls to build
`*.provides.build` targets that are used when the 'requires' step is
needed. That leads to significant degradation of the build time for
incremental builds. Re-arrange dependencies to eliminate the nested
calls.
Explicit `.mod.stamp` targets introduced by this commit could lead to
situation when a stamp file always older than its dependency. This
happens during the incremental build when building of an updated Fortran
source produces a module file that has no differences from the stored
stamp file. In such case `cmake_copy_f90_mod` will be triggered on each
new build to compare a module file with the corresponding stamp file.
This behavior is expected and can not be changed without nested calls
that slow down the build. The copy-if-different check is much cheaper
than an entire nested make call.
Refactoring in commit 66419bc046 (CTest: convert timeouts to
std::chrono::duration, 2017-11-20) changed out "infinite" timeout to a
value not representable by a 64-bit integer. This causes undefined
behavior when e.g. KWSys Process converts the duration to a `long` to
interact with system APIs. Use the old `1.0e7` maximum value.
The ratio of ticks to seconds for this type is 1, so we can just use its
`count()` directly. This also avoids converting through the integer
representation of `std::chrono::milliseconds`, which has a much smaller
allowed range.
Drop our `cmsysProcess_SetTimeout` wrapper as it is now very thin.
