Two issues with non-release builds:
* git describe --always falls back to a commit SHA (e.g. abc123) on
branches without a recent tag. The old ${GIT_VERSION:1} stripped
the first character unconditionally -- fine for v2.8.0 -> 2.8.0,
but produced bc123 from a SHA. Use ${GIT_VERSION#v} instead so the
v is removed only when present.
* source.tar is a release artifact, not a CI artifact -- the source
Docker target build, the tar extraction, and the artifact upload
were running on every push. Gate the three steps on
startsWith(github.ref, 'refs/tags/') so non-release builds skip
them entirely.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Ever since w64devkit began forcing bigobj by default, it has been
incompatible with cgo. I patched go to support bigobj, but unfortunately
upstream the patch ran in to bureaucracy/difficulties and I ran out of
patience to get it through. So that means it's not really an option to
use upstream go binaries, it must build from source. Bootstrapping go is
not difficult, but it has grown more tedious as more required stages
have been added to the bootstrap chain.
So, to spare myself some tedium, I have created
bootstrap-go-toolchain.sh. It builds the latest version of go, from
source, using only w64devkit's gcc compiler. It also adds my bigobj
patches to the toolchain, so cgo works properly.
Adds aas-sign as a Windows binary in $PREFIX/bin/ so users can sign
their own PE outputs with Azure Trusted Signing from inside the
toolchain. Same source as build-aas-sign (the Linux helper used at
release time); on Windows aas-sign's CMakeLists uses WinHTTP + BCrypt
instead of mbedtls, so the build is self-contained.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Adds a CLI-only NSIS install for compiling .nsi scripts. Skips the
GUI wizards (makensisw, the NSIS installer creator) and documentation.
Path-resolution problem: makensis at $PREFIX/bin/makensis.exe would
auto-detect NSISDIR=$PREFIX (parent dir of bin), so NSIS would look
for $PREFIX/{Include,Stubs,Plugins,...} -- collides with w64devkit's
own $PREFIX/include on Windows's case-insensitive filesystem. Solve
by installing the real makensis under $PREFIX/share/nsis/bin/, where
auto-detection lands correctly on $PREFIX/share/nsis. A small alias
EXE at $PREFIX/bin/makensis.exe (built from the existing alias.c)
exec's it. Fully relocatable, no env vars.
New stages: dl-nsis, build-nsis. SCons + python3 only inside
build-nsis (not base) to avoid cache invalidation. TARGET_ARCH
derived from $ARCH at build time so the same Dockerfile works for
x64 and x86 -- no variant-x86.patch hunk needed.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The busybox-w32 mingw64u_defconfig sets CONFIG_BASH_IS_ASH=y so the
ash shell is also installed under the name "bash". That collides
with any real bash on PATH (e.g. Git for Windows). Flip the Kconfig
"choice" to BASH_IS_NONE and drop bash from the alias list. The shell
is still available as ash and as sh.
CONFIG_ASH_BASH_COMPAT etc. (bash-style features inside ash) are
unrelated and remain enabled.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
quilt is the only C++20 source in the project and pulls in libstdc++
headers, so its compile takes much longer than the other ~10 -nostdlib
C utilities built inline in `final`. Splitting it out lets BuildKit
cache it independently -- it's now only rebuilt when src/quilt.cpp
itself changes, rather than on every final-stage cache miss.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Drop busybox-005-disable-utf8-check.patch, now handled upstream.
Add a join.exe alias for the new join applet.
busybox-w32 gained crond and crontab applets, but I have decided to
disable them. It also gained a uuidgen applet, but we already have a
more complete, more appropriate implementation.
https://frippery.org/busybox/release-notes/FRP-6075.html
Sign every PE inside the toolchain (~250 .exe and .dll), pack, then
sign the resulting self-extracting archive. All signing runs at
docker run time so the bulk of the build remains fully cacheable
and secrets never enter image layers.
Stage layout:
- dl-aas-sign / build-aas-sign: SHA-pinned source tarball with
vendored mbedtls + nlohmann/json, built with the base image's
Debian gcc.
- final: assembly only (drop the trailing 7z + CMD).
- signed (new): COPY aas-sign + sign-and-pack.sh, CMD runs the
script at docker run time. Reads AZURE_CLIENT_ID/TENANT_ID and
the GitHub OIDC env vars from -e flags.
- pack (new, default target): RUN 7z + CMD cat sfx archive.
Behaviorally identical to the old final.
The release workflow rebuilds --target signed for each arch
(reusing the same GHA cache scope as the unsigned pack build),
then docker runs the image to produce the signed package on
stdout.
Replace the windows-latest sign job (azure/login + azure/artifact-
signing-action) with a single Linux release job that uses
skeeto/aas-sign@v1.0.0. aas-sign handles the GitHub OIDC -> Azure
exchange directly, so the Azure CLI step is no longer needed and the
signed-artifact handoff to a separate release job collapses into one
step.
Also align the draft logic with sibling projects (dcmake, elfeed2,
stackcalc): tags vX.Y.Z-rcN are pipeline-test runs published as draft
prereleases; tags vX.Y.Z publish immediately.
archive: false makes upload-artifact override the user-supplied name:
parameter with the file's actual filename, so download-artifact can't
find artifacts named w64devkit-x64-unsigned, source-tarball, etc. Match
the artifact name to the filename so uploads and downloads agree.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Bumps GCC from 15.2.0 and adjusts the build for the new release:
- Drop the obsolete stdcall-align patch, no longer needed.
- Configure with --enable-tls so libstdc++ uses native Windows TLS
rather than emutls. This is an ABI break: object files built with
earlier w64devkit releases cannot be linked against new builds.
- Import gcc-dynamic-load-tzdb.patch (originally from
redpanda-cpp/mingw-lite, by CyanoHao) so that libstdc++'s C++20
std::chrono::current_zone() Windows backend resolves
GetDynamicTimeZoneInformation at runtime via LoadLibrary/
GetProcAddress. Without this, _WIN32_WINNT < 0x0600 builds fail
to compile tzdb.cc.
- Add gcc-libgfortran-mapview.patch to replace the new
MapViewOfFileExNuma call in libgfortran's caf_shmem with
MapViewOfFileEx, which mingw-w64 declares for older Windows
targets. NUMA_NO_PREFERRED_NODE makes the two calls equivalent,
so no functional change.
Now the clean target deletes this entire directory, so we can't miss
cleaning up vulkan related build artifacts. Previously, make -f
llama.mak clean would not remove
ggml/src/ggml-vulkan/vulkan-shaders/vulkan-shaders-gen.cpp.gen.o
Upstream commit 6990e2f1 changed common/build-info.cpp.in from just defining globals:
int LLAMA_BUILD_NUMBER = ...;
char const *LLAMA_COMMIT = ...;
to also defining functions:
int llama_build_number(void)
const char * llama_commit(void)
const char * llama_build_info(void)
To fix this, now we generate w64dk-build-info.cpp from the provided
common/build-info.cpp.in template.
dcmake now sets _WIN32_WINNT internally, so drop the matching
define from variant-x86.patch for the dcmake build.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
GitHub is going to remove node 20 from Actions:
https://github.blog/changelog/2025-09-19-deprecation-of-node-20-on-github-actions-runners/
All the actions versions have been upgraded to the latest major versions
available, ahead of the Node 20 deprecation
Move Azure signing from the old Trusted Signing preview action to
Artifact Signing v1, update azure/login to v3, and bump
actions/download-artifact to v8.
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.
