The RUN step that baked an OPUS_DISABLE_INTRINSICS patch into
cargo-xwin's override.cmake was inert from the start: cargo-xwin
rewrites that file from scratch on every \`cargo xwin build\` invocation
(src/compiler/clang_cl.rs line ~444 uses include_bytes! to overwrite
it), so anything baked at image build time gets wiped at runtime.
The libopus SSE4.1/SSSE3 compile failure is now fixed upstream at the
source level by the vendored audiopus_sys patch (see
vendor/audiopus_sys/opus/CMakeLists.txt and the MSVC_CL distinction
for clang-cl). Remove the dead RUN step and leave a breadcrumb
comment pointing at the real fix location.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The previous 'patch the toolchain file' approach (234a798, 48d2bd4) did
write the SSE flags into the COMPILE_FLAGS list correctly in the baked
image, but the CMakeCache.txt from the libopus configure ended up
without them in CMAKE_C_FLAGS, so cmake's final compile commands
didn't see them either. Most plausible explanation: cmake-rs passes
`-DCMAKE_C_FLAGS=…` on the command line, and its assembly of that
string happens outside the toolchain's FORCE set path, so the
toolchain patch never propagated.
Switch to a different lever: cargo-xwin already ships a tiny
`override.cmake` loaded via CMAKE_USER_MAKE_RULES_OVERRIDE. That
file is the right place to manipulate the compile-command
`CMAKE_C_COMPILE_OBJECT` / `CMAKE_CXX_COMPILE_OBJECT` templates —
it runs after cmake has initialised its compile rules but before
any source is compiled. Append two string(REPLACE '<FLAGS>' '<FLAGS>
/clang:-msse4.1 /clang:-mssse3 /clang:-msse3 /clang:-msse2') lines
to that file so every C and C++ compile command generated by cmake
gets the SSE feature flags inline, no matter what the project's
CMAKE_C_FLAGS is set to.
This is the CMake equivalent of a compiler wrapper and works
regardless of how cmake-rs / cargo-xwin / libopus juggle their
respective flag variables.
Two parallel paths to build wzp-desktop.exe for x86_64-pc-windows-msvc:
scripts/Dockerfile.windows-builder
Debian 12 base, matches scripts/Dockerfile.android-builder's layout:
- apt: build-essential, cmake, ninja-build, llvm, clang, lld, nasm,
libssl-dev, node 20 LTS
- rust stable + x86_64-pc-windows-msvc target
- cargo-xwin pre-installed
- Pre-warmed ~/.cache/cargo-xwin layer: creates a throwaway cargo
project and runs `cargo xwin build` once during image build so the
MSVC CRT + Windows SDK (~1.5 GB) is baked into an image layer.
Saves ~4 minutes off every cold cross-compile run.
- Builder user uid 1000 to match existing bind-mount perms on
SepehrHomeserverdk.
scripts/build-windows-docker.sh
Same pattern as scripts/build-tauri-android.sh but for Windows:
- Fires a remote build on SepehrHomeserverdk via ssh + heredoc
- Mounts the shared cargo-registry + cargo-git cache + a
target-windows dir (separate from the android target cache so
different triples don't stomp each other)
- Runs npm install + npm run build for the frontend dist, then
cargo xwin build --release --target x86_64-pc-windows-msvc
--bin wzp-desktop inside the container
- Uploads the resulting .exe to rustypaste (via the .env token on
the remote, same as android script) and fires ntfy.sh/wzp
notifications at start + completion
- scp's the .exe back to target/windows-exe/wzp-desktop.exe locally
- --image-build flag triggers a fire-and-forget `docker build` of
the Dockerfile.windows-builder on the remote (used once after the
Dockerfile changes). The image is already built at the moment of
this commit — sha256:f3895cb2fde7
scripts/build-windows-cloud.sh
Kept as an alternative cross-compile path using a fresh Hetzner VM
(cx33, 8 vCPU, 8 GB — bumped from cx23 after the smaller size OOM'd
mid-rustc). The docker-on-SepehrHomeserverdk path is now the
preferred fast path because the image has a pre-warmed xwin cache
and a persistent cargo target volume, making warm builds ~3 minutes
vs the cloud path's ~20 minutes cold each run. The cloud script
stays around for when we want a truly isolated environment.
Both scripts notify via ntfy.sh/wzp and upload to paste.dk.manko.yoga
so the user can pick up the artefact + see status without polling.
