fa4bed7844 cmPackageInfoReader: Don't crash if input is malformed
be99a82eee cmPackageInfoReader: Just use std::string
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !11390
Check all instances of converting a JSON value to a string to ensure
that we check first if the value is convertible, in order to avoid an
exception being thrown, which crashes CMake. Modify some instances to
report when we encounter such invalid values. (Many instances, however,
just silently ignore invalid values.)
Fixes: #27350
Change cmPackageInfoReader::SetMetaProperty to just take the property
name as a std::string. We end up constructing one when we call
cmTarget::SetProperty, so we might as well do it up front and be done
with it. (Before, we were converting a string_view to char*, which is
decidedly non-optimal.)
Improve how find_package reports the list of candidate package
configuration files that were considered but rejected to include a
reason for rejection. For CPS in particular, this allows the user to
tell if a CPS file was rejected due to a version mismatch, missing
required components, or because the file could not be read.
While we do not try to report more detail for why cmPackageInfoReader
rejected a file, the possible reasons are usually easy enough to
distinguish:
- The file is so malformed that we cannot read a JSON object.
- The schema version is not a version that CMake understands.
- The root object does not contain a string named "name".
- The root object does not contain an object named "components".
- Prefix resolution failed.
Three of these can only result from a file that fails schema validation.
Remove entries from the codespell ignore list that do not seem to be
present any more. Also, remove a deliberate typo and instead add a local
annotation to ignore it.
This list is still uncomfortably long, but unfortunately current
versions of codespell do not offer any granularity in between annotating
individual uses (which is not practical in most cases) or globally
ignoring words (which is overly broad and risks missing real errors).
Ignore RunCMake output regexes (i.e. *-stdout.txt, *-stderr.txt) when
checking spelling. Because these are regular expressions, they have a
higher likelihood of having false positives, and because they are
expected output, any text they contain ought to also appear in whatever
code generates it (or else, is probably text that depends on user input
and shouldn't be spell-checked anyway).
Clang 21 now enforces placement of the module declaration:
.../scan_properties/module.cxx:7:8: error: module
declaration must occur at the start of the translation unit
Refactoring in commit 3882718872 (VS: Decouple solution generation from
`.sln` file format, 2025-09-15, v4.2.0-rc1~154^2~3) accidentally dropped
Fortran targets from the generated VS Solution.
Fixes: #27346
Adds a "Step 0" to the tutorial which discusses minutia about where to
get CMake, how to run it, and most importantly deals at length with
various generator issues which aren't covered elsewhere.
Restore commit 4cb616fed6 (Tutorial: Provide a source archive when
published on cmake.org, 2022-04-27, v3.23.2~22^2). Its effects were
accidentally reverted by commit 9784834b4c (Help: Use `*.rst` extension
for included files, 2025-04-07, v4.1.0-rc1~354^2).
Reported-by: Vito Gamberini <vito.gamberini@kitware.com>
8fa4a4bf67 Makefiles: Position target-wide link flags consistently with other generators
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !11355
6a35c277d0 FindPython: Support getting DEBUG_POSTFIX without requiring Interpreter
43fec72adb Tests: Fix RunCMake.UseSWIG SetPOSTFIX case on Windows
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !11345
Give the actual exit code of the command from the snippet as intended;
currently, this always gives 0 for sub-commands like compile and link,
as well as `ctest`.
For now, the result in build snippets will be `null`.
When CPS export fails due to a dependency on an improperly named
external target, reiterate the "canonical namespace" in the error
message for clarity.
When given the name of a project that doesn't exist, report it as an
"unknown project" rather than an "invalid project". This is more
consistent with other, similar reporting.
