Remove the stdio handle inheritance suppression originally added by
commit f262298bb0 (... do not inherit pipes in child procs for ctest so
it can kill them, 2007-09-11, v2.6.0~1136). It's not clear what problem
it was trying to solve, was only done in `ctest` and not `cmake`, and
since commit 9c3ffe2474 (BUG: fix problem with stdout and stderr not
showing up in ms dos shells, 2007-09-25, v2.6.0~1066) has not been done
in `ctest` launched under interactive consoles.
Furthermore, the code has been spuriously breaking stdio when `ctest` is
started with both stdout and stderr connected to the same pipe, such as
when `ctest --launch` is used under `ninja`. This is because it used
`DuplicateHandle` with `DUPLICATE_CLOSE_SOURCE` on the stdout handle and
then the stderr handle. If the handles are the same, then the stderr
handle becomes invalid in between these operations, leading to
likely-undefined behavior. Since commit 96b3dd329e
(cmCTestLaunchReporter: Replace cmsysProcess with cmUVProcessChain,
2023-07-26, v3.28.0-rc1~138^2~2) this became more noticeable because
`uv_spawn` performs additional verification on stdio handles.
This could be fixed by instead suppressing inheritance via
SetHandleInformation(h, HANDLE_FLAG_INHERIT, 0);
However, the functionality no longer seems necessary, so remove it.
Our test case writes a NUL byte to the console to test its behavior.
The behavior of Windows Terminal differs from Windows Console Host
(conhost.exe). Detect which of these is in use at runtime and adjust
our expected result accordingly.
Upstream libuv supports passing file descriptors >= 3 to child processes
via `STARTUPINFOW` members reserved by the MSVC C run-time. However,
some programs use `GetStartupInfoW` to initialize a `STARTUPINFOW`
structure to pass to `CreateProcessW` without clearing the reserved
members. If we launch such programs with non-zero values in the
reserved members, the MSVC C run-time in *their* children may not
correctly associate the stdin/stdout/stderr streams' file descriptors
with the corresponding `HANDLE`s.
Patch our copy of libuv to avoid using the reserved members. This
restores `execute_process` support for the above-described programs as
we had prior to commit 5420639a8d (cmExecuteProcessCommand: Replace
cmsysProcess with cmUVProcessChain, 2023-06-01, v3.28.0-rc1~138^2~8).
It also enables support for such programs when launched by `ctest`.
Fixes: #25996Fixes: #25889
Refactoring in commit 7a4c02cb38 (cmGlobalGenerator: factor out
messaging for CMP0037, 2023-09-24, v3.28.0-rc1~39^2~7) incorrectly
switched to reporting the aliased target name instead of the invalid
name of the alias itself.
Fixes: #25979
Revert commit cabad8a37f (ExternalProject: Always use $<CONFIG> for
source files, 2023-02-02, v3.27.0-rc1~550^2~3) and restore
Xcode-specific behavior intentionally preserved by commit c111d440ce
(ExternalProject: Express per-config step stamp file paths using CONFIG
genex, 2022-06-08, v3.24.0-rc1~15^2). Unfortunately we still do not
have a test case, so leave a comment to avoid reverting this.
Issue: #23645
Issue: #23652
The C++ sources we use to test the compiler do not use modules.
Avoid requiring a compiler that can scan just to enable the language,
even when CMP0155 is NEW. The project may explicitly turn off
`CMAKE_CXX_SCAN_FOR_MODULES` before adding any targets.
Fixes: #25956
Previously, only `export()` calls in the same directory were noticed.
Also add a test that exports in a different directory than the target
itself resides in.
Fixes: #25813
Implement the target-wide `CXX_SCAN_FOR_MODULES`/`CMP0155` selection
with the `.vcxproj`-wide `ScanSourceForModuleDependencies` setting.
Set the per-source equivalent only when needed for a per-source
`CXX_SCAN_FOR_MODULES` property.
This approach enables Intellisense for interfaces imported from modules.
It is also more consistent with what a user might expect when
investigating the state of module scanning from the VS property panels.
Fixes: #25806Fixes: #25947
142a85f9c1 cxxmodules: use filesystem-safe export names in filenames
4452d41488 cmGeneratorTarget: add method to get a filesystem-safe export name
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !9474
2041f7c9bf cmGeneratorTarget: add the original target as a COMPILE_ONLY link
051c2110c8 Tests/CXXModules: test exporting modules which include headers
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !9469
C++ module support puts the export name in a filename. Export names with
`:` in them are not valid filenames on Windows. Add a method to escape
names as necessary.
See: #25828
Since libuv commit `83efa3dd71` (Reland "macos: use posix_spawn instead
of fork", 2022-03-02, v1.44.0~10), `uv_spawn` on macOS < 10.8
has been observed to cause kernel panics and/or resource exhaustion.
This became particularly noticeable in CMake since commit 5420639a8d
(cmExecuteProcessCommand: Replace cmsysProcess with cmUVProcessChain,
2023-06-01, v3.28.0-rc1~138^2~8). Prefer `fork` over `posix_spawn` in
libuv when targeting macOS < 10.8.
Fixes: #25414Fixes: #25818
Inspired-by: Ken Cunningham <kencu@macports.org>
We place the same target ordering dependencies on either the
`_autogen_timestamp_deps` target or the `_autogen` target.
Refactor the logic to avoid duplicating that code.
In commit aebfbcaa46 (AutoGen: Use depfiles for the XXX_autogen ninja
targets, 2020-01-14, v3.17.0-rc1~58^2) the `_autogen_timestamp_deps`
target was given target ordering dependencies through its custom command
rather than direct target dependencies as on the `_autogen` target.
Then commit 895fa3433f (cmQtAutoGenInitializer: support IMPLIB-only
imported targets, 2021-09-23, v3.22.0-rc1~80^2) converted some
target-level dependencies into file-level dependencies on the custom
command. This only works with a monolithic build graph like Ninja.
Since commit ebc9e448b3 (Autogen: Add depfile support for Makefiles,
2023-09-07, v3.28.0-rc1~101^2~1) we use the `_autogen_timestamp_deps`
target in Makefile generators too. This exposed the missing target
ordering dependency.
Fixes: #25766
Xcode passes a new `-use-frontend-parseable-output` flag to Swift that
conflicts with our `-parseable-output` flag. Use a different flag for
the test case.
Since commit 6a3059e66f (FindTIFF: bridge `tiff-config` into
FindTIFF-compatible interface, 2023-09-14, v3.28.0-rc1~87^2)
we try to find the upstream TIFF cmake package. However, it
is called `TiffConfig.cmake`, not `tiff-config.cmake`, so we
need to match the capitalization of the package name.
Brad King