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
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.
Issue: #17570
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.
540d08f4 Autogen: Tests: Move QtAutoUicInterface test to QtAutogen/UicInterface
b1504f9f Autogen: Tests: Separate RerunRccDepends test
e9fcd154 Autogen: Tests: Separate RerunMocPlugin test
54b4ff2a Autogen: Tests: Separate RerunMocBasic test
4988746e Autogen: Tests: Separate Complex test
6ce6fd42 Autogen: Tests: Separate StaticLibraryCycle test
45b6776a Autogen: Tests: Separate SameName test
d7868687 Autogen: Tests: Separate MacOsFW test
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !1578
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.
The previous version had two bugs that caused the JIT runtime errors.
1. It was building the executable without separable compilation enabled
2. All kernel launches will fail if any kernel is missing a symbol, that
is why the call to file2_launch_kernel had to be removed
