Modify the `export(EXPORT)` and `install(PACKAGE_INFO)` commands to
actually enforce that certain arguments must be non-empty. With respect
to `export`, this is mainly targeted at CPS export, but ends up
affecting all flavors of `export(EXPORT)` because that is the level at
which argument parsing is performed.
Also, add unit tests to verify that the new rejection of arguments with
missing or empty values is working, update the existing tests due to
changes in error reporting, and remove no-longer-needed manual
validation of an empty `PACKAGE_INFO` argument.
Modify argument handling in `HandleExportMode` to explicitly allow an
empty `NAMESPACE`. In practice, this was already the case because we
weren't actually checking for the parsing errors that would cause the
`NonEmpty` decoration to reject an empty value, but we want to be able
to do that going forward, and changing the behavior for `NAMESPACE`
would potentially break legitimate uses. (In particular, one of our unit
tests relies on the current behavior.)
Tweak ArgumentParser::ParseResult to store errors as a set, rather than
concatenating them. Add a new method that a) also optionally checks for
unknown arguments, and b) reports errors using the `SetError` method of
`cmExecutionStatus`, which allows callers to `return false`, which is
less surprising when an error occurs. This improves consistency at call
sites, reduces duplication by moving the common task of complaining
about unknown arguments to a reusable method, and also produces somewhat
more concise messages in the case that multiple errors occurred.
Note that, for some reason, the parser is sometimes generating duplicate
errors, hence the use of a set rather than a list.
Add a utility function to strip whitespace from a `string_view`. This is
identical to the existing `cmTrimWhitespace`, but does not allocate a
new `string`, instead returning the result as another `string_view`.
There are exactly two places that use `ParseResult::AddKeywordError`:
the parser itself, and the `set` command. Adjust the format of the
message generated by the latter to be consistent with the former.
Only force a compile PDB directory when PCH reusing. This avoids
affecting behavior in unrelated situations. However, PCH reuse requires
a known path so that the `copy_idb_pdb` logic can accurately generate
the copy instructions so that MSVC's rule that PCH use must use the same
PDB file can be adhered to.
Also revert the test suite adaptations from commit f78f592b78 (pchreuse:
defer target existence enforcement to generation time, 2025-06-16,
v4.2.0-rc1~481^2~4).
Fixes: #27401
When we pass a PDB output directory to the compiler in a path that
requires quoting, the trailing backslash must be escaped to be parsed
correctly by the compiler, e.g., `cl /Fd"path\with space\\"`. However,
`fbuild` does not parse this correctly when extracting `/Fd`. Work
around that bug by using a trailing forward slash in quotes instead.
Since commit 7db3dbddb2 (VS: Suppress MSBuild default flags not
specified by project or user, 2025-06-02, v4.1.0-rc1~69^2) we suppress
the `-Zc:inline` default flag when the project/user does not specify it.
That triggers an apparent bug in VS 2019 with v142 toolset versions
before 14.29 in which MSBuild fails when both `-Zc:inline` and `-nologo`
are suppressed. This happens when `CMAKE_VERBOSE_MAKEFILE` is enabled,
such as in `try_compile` projects like our builtin compiler inspection.
Since `-nologo` is incidental, avoid suppressing it if `-Zc:inline` is
also suppressed. Limit this workaround to relevant toolset versions.
Fixes: #27439
Revert commit 1a8712d31a (cmGeneratorTarget: always provide a compile
PDB filename, 2025-11-24). It changed our long-standing conditions for
when a naming a compiler-generated `.pdb` file is explicitly named.
It also caused some `BuildDepends` and `RunCMake.BuildDepends` failures
in VS builds that went unnoticed before merging.
Issue: #27401
71a4e34d97 fileAPI: Expose CMAKE_<LANG>_COMPILER_ARG1
1e02926c9a fileAPI: Refactor toolchains schema to prepare for new version
3caa572c05 fileAPI: Output more info for test failures
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !11419
Compiler arguments coming from CC environment variables or multi-element
CMAKE_<LANG>_COMPILER variables set by toolchain files were previously not
exposed in the file API. Among other possible problems, this caused clients
to determine wrong system include paths and built-in preprocessor macros by
calling the compiler without these important arguments.
This is fixed by adding an optional "commandFragment" attribute to the
compiler description in the `toolchains` object, containing these arguments
as a command line fragment. This is already the form in which they are
internally stored in the CMAKE_<LANG>_COMPILER_ARG1 variable, so all that is
required is adding this variable to the set of exported variables, besides
some logic to omit it if empty.
Issue: #22568
Remove literal text "subcommand" from error messages. This addresses the
other use of this and improves consistency (see preceding commit). Also,
omit some unnecessary articles, which also improves consistency.
Remove literal text "subcommand" from error messages. Most other
commands report errors like "<command> <subcommand> <message>", where
the message does not include the literal text "subcommand". The `export`
command was one of two exceptions to this.
