This was missed in commit ee83165923 (cmake: Explicitly normalize
input paths as they exist on disk, 2024-10-17, v4.0.0-rc1~597^2),
causing `CMAKE_CURRENT_LIST_FILE` in `cmake -P` scripts to be
regressed by the KWSys behavior change merged by commit e9bd437a43
(Merge branch 'upstream-KWSys' into normalize-input-paths,
2024-10-24, v4.0.0-rc1~589^2~1).
Issue: #27750
This was broken by refactoring in commit dab5e6ebb1 (introduce
cm::CMakeString class as helper for string() command, 2025-10-06,
v4.3.0-rc1~510^2~2).
Fixes: #27749
The Debian `lintian` tool reported the dbgsym package issue as
`md5sums-lists-nonexistent-file`.
The DEB generator writes `md5sums` entries by stripping a top-level prefix
from each packaged file path. That used `CPACK_TEMPORARY_DIRECTORY`, which
works for regular debs but not for dbgsym packages.
Dbgsym package files are collected from `GEN_DBGSYMDIR` and passed to
`DebGenerator` with `WorkDir` rooted there. Because the `md5sums` writer
stripped `TemporaryDir` instead, the prefix did not match and absolute
staging paths leaked into `md5sums`.
Strip `WorkDir` instead. That is the actual root of `PackageFiles` for both
regular deb and dbgsym package generation, so `md5sums` entries stay
relative in both cases.
When indexing occurs twice at exactly the same time, there was a possibility
for snippets to show up in more than one index file, and therefore to be
removed by one indexing process while another indexing process ran a user
callback which needed to read the file.
Add a file locking mechanism around indexing to prevent it from happening
concurrently within a project build tree.
Fixes: #27741
The POSIX pipe read wrappers stored the return of ::read() into an
unsigned result, so a negative count (e.g. EBADF from a concurrent
close on another thread) became SIZE_MAX. ContentReader::buffer()
would then try to grow its deque by ~18 exabytes and crash with
either std::length_error (glibc) or a stack smash (libc++). Treat
any non-positive ::read() return as EOF/error, close the pipe, and
return 0 so the peer's SessionThread observes a clean empty payload.
cmDebuggerPipeClient is test-only infrastructure; production cmake
is always the pipe server. Production close() assumes sequential
access, which holds in normal use (the adapter destructor joins
SessionThread before closing the connection). The new abrupt-
disconnect test however needs to wake a sibling thread blocked in
read() on the same fd, which Linux ::close() does not do.
Add a ShutdownForTesting() method that calls shutdown(SHUT_RDWR)
without freeing the fd, so any concurrent blocking read wakes
with a clean zero-length return. On Windows, CloseHandle already
cancels pending overlapped I/O, so the helper just forwards to
close(). Use it from testProtocolWithPipesAbruptDisconnect in
place of close().
When a DAP client closes the pipe (or crashes), getPayload() returns an
empty functor without triggering the onError handler, so SessionActive
is never set to false and the session thread spins in a tight loop at
100% CPU. Handle the empty-payload case with the same cleanup performed
by the onError and DisconnectRequest handlers.
testProtocolWithPipesAbruptDisconnect drives the DAP handshake and then
closes the client side of the pipe without sending a DisconnectRequest.
The test deliberately avoids ReportExitCode so that no concurrent write
triggers the dap::Session error handler and masks the busy-loop
condition; if the SessionThread spins on EOF, the adapter destructor
blocks in SessionThread.join() and the test fails on a 10-second
timeout.
Fixes: #27743
ISPC target names containing dots, such as `avx10.2dmr-x16`, produce
output files with underscores in the ISA suffix (e.g. `_avx10_2dmr`).
The `ComputeISPCObjectSuffixes` function did not account for this,
causing a mismatch between the predicted and actual object file names.
Replace dots with underscores in the extracted target suffix to match
ISPC's `ISAToString()` behavior. Also add mappings for `sse4.1`
and `sse4.2` target name variants, which ISPC both maps to `sse4`.
1b946dfbfe Merge branch 'backport-4.2-find_package-stack' into find_package-stack
e8ae3645db Merge branch 'backport-4.2-find_package-stack' into find_package-stack
aae02ee60a find_package: Share package information among copies of package stack
a789c21100 Merge branch 'backport-4.2-find_package-stack' into find_package-stack
9387988626 find_package: Save package information only after successfully loading it
561ece2407 cmFindPackageStack: Restore pure value semantics
e935ed22fb find_package: Share package information among copies of package stack
5aa649d5f6 find_package: Save package information only after successfully loading it
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Tested-by: buildbot <buildbot@kitware.com>
Merge-request: !11887
Since commit ae373e93fb (install(PACKAGE_INFO): Add version and location
to package dependencies, 2025-07-31, v4.2.0-rc1~340^2) we add package
information to the current package's stack entry as it is discovered.
However, a nested package can cause the current package's stack entry to
be replaced by a copy with a new ordering index due to commit c6e6861e63
(install(EXPORT): Export find_dependency() calls, 2023-11-07,
v3.29.0-rc1~439^2~1). Depending on whether imported targets were
created by the current package before finding the nested package, the
`CurrentPackageInfo` pointer is either invalidated, or left pointing at
only one of multiple copies.
Fix this by sharing a single instance of package information with all
copies of the current package's stack entry. Keep a mutable pointer
to the current package's information only while it is still pending.
This also avoids the need to expose mutation from the package stack.
Add a test that exposes the previously-invalidated pointer to dynamic
analysis tools.
Fixes: #27730
If a package configuration file sets `<PackageName>_FOUND` to false,
the package is considered not found. Do not save its package info.
Note that this exposes an existing pointer invalidation on nested
`find_package` calls, which will be fixed in following commits.
Issue: #27730
A stack entry's storage may be shared by other copies, so mutation is
incompatible with value semantics. We've migrated the motivating use
case to another approach.
Revert commit b3873b8272 (cmFindPackageStack: Allow controlled mutation,
2025-07-29, v4.2.0-rc1~438^2) and commit f2bdc2176f (cmStack: New,
mutable stack class, 2025-07-29, v4.2.0-rc1~438^2~1). Record their
parent as a second parent of this commit so `git blame` can see the
original history of the restored content.
If a package configuration file sets `<PackageName>_FOUND` to false,
the package is considered not found. Do not save its package info.
Note that this exposes an existing pointer invalidation on nested
`find_package` calls, which will be fixed in following commits.
Issue: #27730
Since commit ae373e93fb (install(PACKAGE_INFO): Add version and location
to package dependencies, 2025-07-31, v4.2.0-rc1~340^2) we add package
information to the current package's stack entry as it is discovered.
However, a nested package can cause the current package's stack entry to
be replaced by a copy with a new ordering index due to commit c6e6861e63
(install(EXPORT): Export find_dependency() calls, 2023-11-07,
v3.29.0-rc1~439^2~1). Depending on whether imported targets were
created by the current package before finding the nested package, the
`CurrentPackageInfo` pointer is either invalidated, or left pointing at
only one of multiple copies.
Fix this by sharing a single instance of package information with all
copies of the current package's stack entry. Keep a mutable pointer
to the current package's information only while it is still pending.
This also avoids the need to expose mutation from the package stack.
Add a test that exposes the previously-invalidated pointer to dynamic
analysis tools.
Fixes: #27730
c386aaebf8 FILE_SET: install and export SOURCES file set type
5c5b68f44e FILE_SET: Add support for the SOURCES type
5697bcced0 BT<> and cmLocalGenerator: Add helpers functions
42ca2a2062 cmEvaluatedTargetProperty: put declarations in namespace cm
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !11863