Add policy CMP0137 to propagate both our builtin variables and those
listed by `CMAKE_TRY_COMPILE_PLATFORM_VARIABLES` to `try_compile`
whole-project builds.
Inspired-by: Alexander Neumann <Alexander.Neumann@hamburg.de>
Fixes: #23219
Add `COMPILE_WARNING_AS_ERROR` target property and supporting
`CMAKE_COMPILE_WARNING_AS_ERROR` variable.
`COMPILE_WARNING_AS_ERROR` is initialized by
`CMAKE_COMPILE_WARNING_AS_ERROR`. It is a boolean variable. If it is
true, it expands to a different flag depending on the compiler such that
any warnings at compile will be treated as errors.
Supports compiler ids that I could find a relevant flag for.
Add a `CMAKE_WATCOM_RUNTIME_LIBRARY` variable to control the
runtime library selection. Add policy CMP0136 to switch to
in place of the old hard-coded default flags.
Fixes: #23178
Add the option to keep the current filestamps when extracting an
archive in ExternalProject_Add.
Enabling this option makes the behavior consistent with how
ExternalProject_Add is used when checking out code from revision
control instead of an archive.
Fixes: #22746
c5b56b35c2 cmInstallExportGenerator: expose the temporary directory
c107760417 cmNinjaTargetGenerator: support msvc-style deps discovery for scanning
64c15ec018 cmNinjaTargetGenerator: add flags for scanning based on the fileset type
aaa18f15cf cmTarget: add support for querying all file set names
cc4e19710d cmGlobalNinjaGenerator: use an extention based on the modmapfmt
97a68198c9 cmGlobalNinjaGenerator: escape `:` in module names
499009b79c cmTarget: avoid creating export entries if they don't exist
0513a1fe10 cmInstallGenerator: use CMake-private variables in generated code
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Tested-by: buildbot <buildbot@kitware.com>
Merge-request: !7214
Allow FetchContent_MakeAvailable() to try a call to
find_package() first, or redirect a find_package() call to
FetchContent_MakeAvailable(). The user can set variables
to control which of these are allowed or tried by default.
Fixes: #21687
This needs to be known so that C++ module properties for the install can
be staged beside the other files.
Always perform the MD5 transformation (in non-bootstrap builds) so that
the path can be computed prior to generation (where it used the longest
configuration name to detect too-long paths). Update tests to expect the
always-present MD5 value. Note that this improves robustness of the test
suite as testing in a too-long path may have triggered the MD5
conversion anyways.
9916d4dd44 cmTarget: factor out fileset type handling
79d6b928a3 RunCMake/target_sources: test `HEADERS` file sets via generic props
d74f9599f6 cmTarget: require filesets to be of the right type
5da4fe30a9 cmTarget: factor out fileset property manipulation
c89580487b cmTarget: pass candidate strings by const-ref
64ea1a272c messages: remove screamake from comments and errors
Acked-by: Kitware Robot <kwrobot@kitware.com>
Tested-by: buildbot <buildbot@kitware.com>
Merge-request: !7145
CUDA's cupti library has its headers in a seperate directory on a
standard CUDA install, but `CUDA::cupti` only adds the default cuda
include directory.
Issue: #22761
Several tests specify use of C++98 mode since commit b0f277db38 (HP aCC:
record compiler flag for Ansi C++98 support for version 3.80 onwards,
2014-04-15, v3.1.0-rc1~550^2). The motivating use case for those
changes was dropped by commit 49640d3629 (HP-UX: Drop support for
building CMake on HP-UX, 2017-08-04, v3.10.0-rc1~304^2), so remove the
use of C++98 mode too. Also remove code that, on some compilers, used
C++11 instead of C++98, because we can now just use their default mode.
Verifying the architectures during compiler identification is redundant,
and requires a lot more up-front information than we should need.
It also causes unsupported architectures to break the compiler id and
version detection, so the resulting output from CMake does not report
the compiler version, which is useful information to know why the
specified architectures are not supported.
The "detecting compiler ABI info" and "check for working compiler" steps
already pass `CMAKE_CUDA_ARCHITECTURES` into their test projects.
Therefore we can just drop the earlier architecture testing. Bad
architectures will be reported as a not-working compiler, and the
output will include the compiler's error message.
This reverts the approach from:
* commit 19cc5bc296 (CUDA: Throw error if user-specified architectures
don't work, 2020-05-26, v3.18.0-rc1~79^2)
* commit 650c1029a0 (CUDA: Detect non-working user-specified architectures
on NVCC, 2020-05-28, v3.18.0-rc1~51^2)
* commit 01428c5560 (CUDA: Fail fast if CMAKE_CUDA_ARCHITECTURES
doesn't work during detection,
2020-08-29, v3.19.0-rc1~241^2).
Their goal was in part to avoid waiting until the test for working
compiler to detect unsupported architectures. However, experience has
shown that failing earlier is more trouble than it's worth.
Fixes: #23161
Issue: #20756
Brad King