In commit 76a08cd253 (COMPILE_WARNING_AS_ERROR: Add options to treat
warnings as errors, 2022-04-21, v3.24.0-rc1~173^2) we formatted the
options table entries as command-line string fragments. Since they are
part of the `CMAKE_${lang}_COMPILE_OPTIONS_*` tables, they should be
formatted as `;`-separated lists of compiler options.
9cdf4c9be4 gitlab-ci: update macOS jobs to use Xcode 14.0
5d2c2b2558 Tests: Update RunCMake.XcodeProject iOS cases for Xcode 14.0
12c6fec6b4 Xcode: Drop CMAKE_INTDIR= definition in Swift targets
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !7732
In commit ab9ad2a6a0 (ctest: report make-level errors to CDash when
using launchers, 2020-09-24, v3.19.0-rc1~84^2~1) we taught CTest to
capture and report errors from the build command when using launchers.
This had the unintended side effect of reporting a separate build error containing
the full build output when the build command returns non-zero. To fix this problem,
we now only report build command errors from CTest launchers when no other
more specific build errors are found.
Fixes: #23991
8fc822e13a file: Avoid strange istringstream crash in cmake.org binaries on Alpine Linux
31f158e4c8 cmStringAlgorithms: Add functions to parse strings to long long integers
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: buildbot <buildbot@kitware.com>
Merge-request: !7698
Somehow using `istringstream` and `operator >>` to parse an integer
crashes on Alpine Linux, at least when compiled with the settings we use
for the official `cmake.org` Linux binaries. Since commit fd0c285b12
(file: Fix types of the OFFSET and LIMIT arguments, 2022-01-04,
v3.23.0-rc1~133^2), this causes the `file(READ)` command to crash when
parsing its `LIMIT` or `OFFSET` argument. Parse the input string with
our dedicated helper to avoid the crash.
Fixes: #23872
When FetchContent_MakeAvailable() populates a dependency for which
find_package() integration is enabled, all future calls to find_package()
MUST succeed using the contents of the redirection directory. The
generated config version file was not handling calls where the EXACT
keyword was given, resulting in such calls rejecting the redirection
directory's contents and continuing its search. It is not allowed to do
that. Fix the generated file to also set PACKAGE_VERSION_EXACT to
true so that calls with EXACT now accept it, as was originally intended.
Fixes: #23950
The unset() command was using __cmake_contentNameLower before that
variable was restored from the __cmake_fcCurrentVarsStack. That means
if there had been a nested call to FetchContent_MakeAvailable(), the wrong
variable name would have been cleared (the nested name instead of the
one from the current call). That would have left the variable set upon return,
blocking the dependency provider from seeing any further calls to
FetchContent_MakeAvailable() in the current variable scope or below for the
current dependency.
The following `module.f90` file
module mymodule
contains
subroutine mysub()
end subroutine
end module
when compiled with `flang-new` (from LLVM 15.0.0) generate the
`_QMmymodulePmysub` symbol.
$ flang-new -c module.f90
$ nm module.o
0000000000000000 T _QMmymodulePmysub
This commit fixes the regular expressions accordingly.
Print an error message for invalid values of
`CTEST_CUSTOM_TEST_OUTPUT_TRUNCATION` in a ctest dashboard script.
The option was added by commit 140704d443 (ctest: add option for
output truncation, 2022-03-07, v3.24.0-rc1~513^2).
Fixes: #23869
We've made several attempts to add a dummy symbol to `mocs_compilation.cpp`
when there are no automoc sources:
* commit 4a9daae483 (automoc: silence linker warning on macos,
2022-05-25, v3.24.0-rc1~55^2)
* commit 844244ccdc (automoc: avoid compiler warnings in linker-warning-
silencing code, 2022-08-10, v3.24.1~6^2)
* commit fc8628389f (automoc: avoid more compiler warnings in linker-
warning-silencing code, 2022-08-29)
The last attempt derives a symbol name from the path to the source
file, but that breaks reproducible builds because it is not stable
w.r.t. the location of the build tree. Revert all these attempts
for the 3.24 release series, and return to what 3.23 and below did.
Further investigation will be needed to resolve the original issue.
Fixes: #23937
Issue: #23551, #23823, #23823
CMAKE_FIND_LIBRARY_PREFIXES and CMAKE_FIND_LIBRARY_SUFFIXES have
different behavior when undefined and when defined but empty:
Empty means to use an empty prefix/suffix while undefined means to
use a hardcoded default for the platform we are running on.
Unfortunately, set(a ${b}) will undefine a when b is empty,
meaning that when targeting a platform where either of these variables
is empty (e.g. Windows where CMAKE_FIND_LIBRARY_PREFIXES is empty)
the unpatched FindZLIB code ends up unsetting that variable, causing
all subsequent find_library calls to use the hardcoded default
for the runtime platform (e.g. "lib" for CMAKE_FIND_LIBRARY_PREFIXES
on Linux).
On the other hand, set(a "${b}") will always define a to be empty but
defined so we have to do this dance to fully preserve the state of these
variables.
The `ctest_test` and `CTestCommandLine` truncation tests had multiple problems:
- escape expected result string to avoid regex matching
- specify the truncation size
- pass the truncation mode correctly into the test definition
- use unique test names
Issue: #23868