Since commit ffa010e32d (ci: Update Windows jobs to VS 2026, 2025-11-21,
v4.2.1~28^2) we link to a MSVC C++ runtime library that implements
`std::chrono::system_clock::now()` via `GetSystemTimePreciseAsFileTime`,
which is only available on Windows 8 and above. Restore support for
Windows 7 by reverting `windows-{x86_64,i386}` packaging from MSVC 14.50
to MSVC 14.44.
Fixes: #27446
faa88b28a5 Help: Add 4.2 release note about VS flag suppression
19527eb5c6 Merge branch 'doc-4.1-vs-flags' into doc-4.2-vs-flags
e2646b9926 Help: Add 4.1 release note about VS flag suppression
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !11489
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
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.
While I'm unsure about why `cmPackageInfoArguments` was originally
written the way it was, in its current form, the way command sub-parsers
work, the parser never considers arguments associated with a sub-parser
if the sub-parser keyword isn't present. This means that the arguments
associated with `cmPackageInfoArguments` are treated as unknown, and the
logic to reject them being set if `PACKAGE_INFO` is not present can
never actually execute. Therefore, remove it, and remove the associated
(and effectively useless) `enable` argument to its `Check` method.
Instead, ensure that the package name is actually specified. The only
case in which the parser will create the `optional` associated with the
sub-parser arguments is if the relevant keyword (i.e. `PACKAGE_INFO`) is
present. However, while the associated value is `NonEmpty`, the way we
are using the parser does not actually enforce this, and it looks like a
correct fix may be a breaking change. Therefore, enforce it manually for
now.
Extend commit fb3e7825f3 (StdIo: Restore Windows Console I/O modes on
exit, 2025-05-23, v4.1.0-rc1~114^2) to cover termination by Ctrl-C.
Fixes: #27427
a308ea38f3 Emscripten: Fix try_run to run the `.js` file and not the adjacent `.wasm`
ad91bc558a ci: Make node available to Emscripten tests
27cc5d58bf Tests/RunCMake/Emscripten: Add tests covering try_compile COPY_FILE
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !11451
Since commit 96d9b94a98 (Emscripten: Add platform modules, 2025-05-16,
v4.2.0-rc1~607^2~3) we've considered the `.wasm` to be the `try_compile`
output because we need `COPY_FILE` to get it for extracting `INFO:`
strings during our inspection checks. This breaks `try_run` because
`node`, used via `CMAKE_CROSSCOMPILING_EMULATOR`, expects the `.js`.
Revert to considering the `.js` to be the primary output file, but
switch to the `.wasm` in `COPY_FILE`'s implementation.
Fixes: #27421
Compiler inspection relies on `try_compile`'s `COPY_FILE` option to copy
the `.wasm` file because the `.js` does not have the `INFO:size` string.
Issue: #27421
Brad King