`include-what-you-use` diagnostics, in practice, are specific to
the environment's compiler and standard library. Update includes
to satisfy IWYU for our CI job under Debian 12.
With this patch, the junit files written by ctest also contain the
test labels as testcase properties, see
https://github.com/testmoapp/junitxml#properties
The name for the property is "cmake_labels", where "cmake_"
is used namespace-like. This could be done the same way
if we export more properties to junit.
Also this makes it clear to consumers that this is coming
from cmake, and the list is a cmake-formatted string.
c4bb7fd4f3 cmPolicies: use `cmStrCat` for error message building
59eda7fa0a cmPolicies: use `cmStrCat` for string additions
0c8a2c4a86 cmPolicies: use character literals where possible
0cb4f08ddf cmPolicies: combine string literals where possible
Acked-by: Kitware Robot <kwrobot@kitware.com>
Tested-by: buildbot <buildbot@kitware.com>
Merge-request: !8650
Fix a typo from commit e522f8ca06 (cmTarget: factor out properties
initialized for target which compile, 2023-02-01, v3.27.0-rc1~577^2~13),
that broke this property.
Also update the test suite to use this upgrade as some level of
coverage.
Fixes: #25123
open.cdash.org was recently upgraded in preparation for the release of
CDash v3.2.0. This upgrade brought a change in behavior where CDash now
responds with HTTP 400 (bad request) rather than HTTP 200 (OK) for MD5
checksum mismatches during submission time.
This commit removes our usage of CURLOPT_FAILONERROR in
cmCTestSubmitHandler.cxx This was necessary to pass along the contents
of the request body ("md5 mismatch") in cases where the web server
(CDash) responds with an error status (400).
Fixes: #25121
In commit b6a5382217 (Ninja: depend on language module information files
directly, 2023-02-10), introduced via !8197, language-specific module
information files (`CMakeFiles/<target>.dir/<lang>Modules.json`) files
were added as real dependencies to the dyndep collation steps.
Previously, the behavior was to inform the collator of all possible
targets and search for the files manually ignoring those which did not
exist with ordering enforced by depending on the linker output of all
dependent targets. This behavior could lead to stale information being
used (e.g., if a target stops providing any targets) and also did not
reliably build everything needed on rebuilds. Afterwards, the internal
computation changed the dependency from all possible targets to an exact
set of "these targets might have modules" query, however one that did
not include `OBJECT` libraries since do not have `LinkEntry` items
internally (their objects are instead treated as source files).
As a stopgap measure, track `OBJECT` libraries in a separate list and
query them explicitly when gathering targets which may have interesting
information. Future work can add `LinkEntry` items to represent these
targets once all `LinkEntry` consumers have been audited to make sure
they are not surprised by any `OBJECT` library entries.
Fixes: #25112
faf36e65b9 cmMakefile: use single characters where possible
4fd80d5419 cmMakefile: use static string views in some locations
e41ff26735 cmMakefile: use `cmStrCat` where possible
2a74f641db cmGlobalGenerator: use single chars where possible
cfdb5c970c cmGlobalGenerator: use `cmStrCat` where possible
884c477545 cmCoreTryCompile: combine strings where possible
b8fd1cc8d9 cmCoreTryCompile: use single characters where possible
0b74471d62 cmCoreTryCompile: use `cmStrCat` where possible
Acked-by: Kitware Robot <kwrobot@kitware.com>
Tested-by: buildbot <buildbot@kitware.com>
Merge-request: !8640
Previously REAL_PATH would collapse paths before resolving any symlinks
so if `..` crossed a symlink the output from `REAL_PATH` would be wrong.
It looked like REAL_PATH did this by mistake since it was a side-effect
of ensuring we had an absolute path before resolving symlinks.
