`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
