In commit 99d09ec45a (VS: Suppress MSBuild default link flags not
specified by project or user, 2025-06-17, v4.1.0-rc1~6^2) we removed our
default `-subsystem:...` link flag from `SHARED` and `MODULE` libraries
in Visual Studio generators for consistency with command-line generators.
However, unlike other flag suppressions for #27004, this change did not
just suppress MSBuild defaults, but actually changed flags the generator
was previously adding itself.
For the linker subsystem flag, consistency across generators should
perhaps achieved by adding the flag in other generators instead of
removing it from Visual Studio generators. Restore the previous
behavior pending further investigation.
Issue: #27466Fixes: #27464
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
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.
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
In commit 96d9b94a98 (Emscripten: Add platform modules, 2025-05-16,
v4.2.0-rc1~607^2~3) this flag was added as part of an attempt to support
shared libraries without requiring projects to set much themselves. That
attempt was reverted by commit d361bf365e (Emscripten: Drop hard-coded
-sMAIN_MODULE and -sSIDE_MODULE flags, 2025-09-18, v4.2.0-rc1~146^2).
Also avoid hard-coding `-fPIC`. `POSITION_INDEPENDENT_CODE` is already
enabled for shared library targets. Projects can enable it themselves
where `-fPIC` is needed outside of shared libraries.
Fixes: #27424
Issue: #27240
As of commit f78f592b78 (pchreuse: defer target existence enforcement to
generation time, 2025-06-16) via !10887, the compile PDB directory is
always set. Some codepaths used the total computation as a signal to
build the path themselves. But the filename was not specified, so the
resulting filename ended up changing. Always create the filename as
expected.
Fixes: #27401
Extend commit e301cbffcc (ExternalProject: Set environment variables,
2025-04-09, v4.2.0-rc1~480^2) and commit 9cb590b843 (ExternalProject:
Fix lists and empty commands with environment modification, 2025-09-11,
v4.2.0-rc1~9^2) to match `_` in environment modification operation
names.
Fixes: #27409
Extend commit e6aa7742b0 (VS: Generate .slnx files for VS 2026,
2025-09-17, v4.2.0-rc1~151^2) to add the `Type=` attribute on SLNX
`<Project>` elements.
Fixes: #27392
At the time of commit e6aa7742b0 (VS: Generate .slnx files for VS 2026,
2025-09-17, v4.2.0-rc1~151^2), the VS 18 Insiders edition did not offer
support for specifying a default startup project in `.slnx` files.
This has since been added, so use it.
Fixes: #27387
`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 13. Some patterns:
* Types named in virtual `override` signatures no longer require
includes since the overridden signature already names them.
* A function argument's type needs to be included even if its constructor
is called only by implicit conversion. For example, constructing a
`std::function` from a lambda now requires `<functional>`.
* Some prior mysterious `<type_traits>` inclusions are no longer required.
Since commit 5420639a8d (cmExecuteProcessCommand: Replace cmsysProcess
with cmUVProcessChain, 2023-06-01, v3.28.0-rc1~138^2~8) we've
occasionally observed immediate timeouts on processes that take longer
than the timeout to start, even though we only start the timer after the
child processes start. The problem is that:
* `uv_loop_init` initializes `uv_loop_t`'s cached "now" time.
* Starting processes takes time but does not update the "now" time.
* `uv_timer_start` computes expiry relative the cached "now" time,
so short timers may be expired as soon as they are started.
* `uv_run` invokes expired timer callbacks before polling for I/O
or process completion, so we "timeout" immediately.
Fix this by updating the cached "now" time via `uv_update_time` just
before starting timers. This is needed only for timers that start
before the `uv_run` event loop. Update our `uv_timer_ptr` wrapper
to make all callers consider the choice when calling `start()`.
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
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).
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
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.
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
Brad King