SalastilandClaude Opus 5
03d821cd52
npm run deploy stopped building the daemon, with "rustup could not choose a version of cargo to run" - which reads like rust is missing and is not. rustup installs a shim, and the shim finds the real toolchain through CARGO_HOME and RUSTUP_HOME. On the XDG layout those point under ~/.local/share rather than ~/.cargo, so they are named by environment variables a login shell sets and an npm script never sees. The shim then has nowhere to look. The distribution's own /usr/bin/cargo does run, which makes it look like the answer, and for a native build it is. It is also the wrong one: it carries no cross-compilation targets, so a Windows build through it fails with "can't find crate for `core`" - which in turn reads like a broken checkout. Each wrong answer points at the other, which is why this has been worked around by hand all week instead of fixed. So the XDG locations are filled in when nothing else has, rustup's shim is preferred because it is the toolchain carrying the targets, and every candidate is asked `--version` rather than assumed - that question being the only thing that tells a working toolchain from a shim that cannot find one. The Linux build goes through the same script as the Windows one now, since it had the same problem and no reason to solve it differently. Both were verified through npm rather than from a shell that already had the right environment, which is the only way this bug is visible at all. Co-Authored-By: Claude Opus 5 <[email protected]>
38 lines
1.5 KiB
Bash
Executable File
38 lines
1.5 KiB
Bash
Executable File
#!/usr/bin/env sh
|
|
# Builds the Windows daemon and puts it where the packager expects it.
|
|
#
|
|
# Two things make this its own script rather than a line in package.json.
|
|
#
|
|
# The packager reads nobilis/target/release/nobilis.exe, but a cross-build
|
|
# writes to nobilis/target/x86_64-pc-windows-gnu/release/. Nothing connects
|
|
# those, so `pack:win` would happily bundle whatever .exe happened to be at the
|
|
# first path - which, on a machine that has been cross-building for days, is
|
|
# something old. That is the same shape of bug as an AppImage shipping a stale
|
|
# daemon, and it is worse here: it only shows up as "unknown method" on
|
|
# somebody else's computer.
|
|
#
|
|
# And it has to be a cargo that works, which is not the same as the one named
|
|
# `cargo` - see find-cargo.sh.
|
|
set -eu
|
|
|
|
TARGET=x86_64-pc-windows-gnu
|
|
SRC_DIR="$(cd "$(dirname "$0")/.." && pwd)"
|
|
MANIFEST="$SRC_DIR/nobilis/Cargo.toml"
|
|
|
|
. "$SRC_DIR/scripts/find-cargo.sh"
|
|
|
|
echo "building the Windows daemon with $CARGO"
|
|
"$CARGO" build --release --target "$TARGET" --manifest-path "$MANIFEST"
|
|
|
|
BUILT="$SRC_DIR/nobilis/target/$TARGET/release/nobilis.exe"
|
|
WANTED="$SRC_DIR/nobilis/target/release/nobilis.exe"
|
|
|
|
# Not merely "did cargo exit 0": a build that fails after having produced an
|
|
# executable once leaves the old one in place, and copying that forward is how
|
|
# a stale daemon gets shipped.
|
|
[ -f "$BUILT" ] || { echo "no $BUILT - the build did not produce one" >&2; exit 1; }
|
|
|
|
mkdir -p "$(dirname "$WANTED")"
|
|
cp -f "$BUILT" "$WANTED"
|
|
echo "daemon -> $WANTED"
|