Split release into sign (windows-latest, environment: release) and
release jobs. Signs both .7z.exe via Azure Trusted Signing before
attaching to the release. Tags starting with v publish; other tags
produce draft releases for testing the pipeline.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Rename release archives from .exe to .7z.exe. Build the new source
Docker target and produce a reproducible source.tar of all upstream
tarballs, attached as both a CI artifact and a release asset.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Adds an optional "source" Docker target that collects all upstream
source tarballs for producing a source.tar release artifact. BuildKit
skips it unless explicitly requested via --target source.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
In DepsLog::Load(), the file offset used for truncation-based recovery
was advanced past each record immediately after reading its bytes from
disk, but before validating the record's semantic correctness (e.g. the
path checksum or node-id range checks). When a record was structurally
complete but semantically invalid, recovery truncated the file to an
offset that included the bad record, so it was never removed.
This created an infinite cycle: every build would load the deps log, hit
the corrupt record, "recover" by truncating everything after it (but not
the record itself), then append new dependency records that would be
destroyed by the next build's recovery. The result was spurious rebuilds
on every invocation.
Move the offset update to the end of the loop body, after all validation
has passed. Now when a record fails validation, the offset still points
before it, and truncation correctly removes it.
(This patch has been submitted upstream.)
The breakpoint manager normalizes incoming setBreakpoints paths with
GetActualCaseForPath, but SourceFileLoaded and GetBreakpoints use
paths from CollapseFullPath, which preserves whatever case the caller
provided. On case-insensitive filesystems these can differ for the
same file, so the unordered_map keys do not match and breakpoints are
silently missed.
On macOS (HFS+) GetActualCaseForPath is a no-op, so the setBreakpoints
path passes through unmodified. If the DAP client sends "Test.cmake"
but cmake was invoked with "cmake -P test.cmake", the breakpoint is
stored under "Test.cmake" while GetBreakpoints looks up "test.cmake".
On Windows GetActualCaseForPath *does* normalize, but only in
HandleSetBreakpointsRequest. The breakpoint is stored under the
canonical "Test.cmake", while SourceFileLoaded and GetBreakpoints
still receive "test.cmake" from CollapseFullPath. The keys disagree
from the opposite direction.
Add a NormalizePath helper and apply it in all three public entry
points so that every map key goes through the same transformation.
On non-Windows it uses GetRealPath (wrapping realpath(3), which
returns the actual filesystem case on macOS and resolves symlinks on
Linux). On Windows the existing GetActualCaseForPath is retained.
I wrote this new tool yesterday after reading about "cmake --debugger"
the night before, and it's already been powerful and useful. In the past
this would be a month-long project, but in 2026 it only takes a day.
SHFileOperationWhas has a subtle, easy-to-misuse interface that does not
follow its own documentation. It says FO_DELETE skips relative paths,
but that's definitely not the case at least on some versions of Windows.
I rarely care about the status of the x86 builds, so this commit only
runs them if the x64 builds succeed. If the x64 build is successful but
the x86 build is not, the cache for the x64 build should kick in and the
x86 build should follow shortly after, if it's necessary to iterate on
it.
Updated the GitHub Actions workflow so x86 only runs after x64 succeeds.
Changed:
- Split the old matrix job into two explicit jobs: build-x64 and build-x86.
- Added needs: build-x64 on the x86 job, which enforces the dependency.
Aliases remain small because size is important and they are already
maximum speed. The distribution is ~10MB (~22%) larger, but C++ builds
with this toolchain are ~25% faster.
By breaking independent parts of the build into stages breaks implied
dependencies between those parts. A tool built later will not require
rebuilding when earlier unrelated tools are changed. That includes
upgrades to require new downloads. Most tools can be upgraded without
requiring unnecessary rebuilds.
