These scripts are only useful for building the distributed broot binaries hosted on the deployment server. If you just want to install or build broot for yourself, you don't need anything here — see https://dystroy.org/broot/install.

They may be run from anywhere; each resolves paths against the repo root.

No single machine can build every target (macOS needs a Mac, armv7-musl needs Linux), so a release is built on both and assembled through a staging server.

1. Commit, then on each machine (Mac and Linux):

   ./build-scripts/build-all-targets.sh
   

   Builds this host's targets and pushes build/ to the staging server, keyed by <version>-<commit>. Targets already staged under that key are skipped, so a re-run after a failure only builds what's missing; --force rebuilds them all. Any new commit changes the key, so everything is rebuilt.

2. On one machine, assemble and package:

   ./build-scripts/release.sh
   

   Fetches the staged artifacts, checks every target is present, verifies each binary, and produces broot_<version>.zip.

3. Publish:

   ./build-scripts/deploy.sh
   

   rsyncs build/ and the zip straight into the download directory on the server. Nothing goes through ~/dev/www/dystroy: that tree mirrors the whole site on each machine, so pushing it from one machine republishes its stale copy of everything the other machines deployed. Previous zips are left in place, so old versions stay downloadable.

   It then runs website/deploy.sh, last, so the site never describes a version whose binaries aren't online yet.

Staging and deploy settings come from build-scripts/_local.sh (see below). Without it, release.sh builds locally on a single host and deploy.sh won't run.

A dirty tree doesn't block either step, but both ask first: build-all-targets.sh offers to stage it anyway (recorded in a <version>-<commit>.dirty marker beside the staging dir, and already-staged targets are then rebuilt rather than reused), and release.sh reports every host that staged uncommitted work before packaging. Set BROOT_YES=1 to answer yes to all of it without a terminal.

build-scripts/_local.sh holds per-machine settings and is gitignored, so it never travels through git — recreate it on each machine that builds or deploys. It's sourced by _common.sh.

Set only what a machine actually needs (e.g. BROOT_VM_SHARED only where you run win-deploy.sh). A full example:

# build-scripts/_local.sh  — per machine, gitignored

# Staged multi-host release builds (set on both the Mac and the Linux box):
BROOT_STAGE_HOST=dystroy.org
BROOT_STAGE_DIR=staging/broot-staging        # relative to ssh home, or absolute

# Publishing, on whichever machine runs deploy.sh:
BROOT_DEPLOY_TARGET="dys@dystroy.org:prod/www.dystroy.org/broot/download"

# Only if you use these on this machine:
BROOT_WWW_DIR="$HOME/dev/www/dystroy"              # termux-deploy.sh
# BROOT_VM_SHARED="$HOME/dev/storage/vm/shared"    # win-deploy.sh
# BROOT_PUB_DIR="$BROOT_WWW_DIR/pub"               # termux-deploy.sh

• build-target.sh <filter> — build one target (--list to see them), e.g. ./build-scripts/build-target.sh aarch64-apple-darwin
• build.sh — quick local cargo build --release --features clipboard,sixel
• win-deploy.sh, termux-deploy.sh — build and push a single Windows / Android binary
• fix-win-toolchain.sh — Linux-only mingw fixup (unused with the current setup)
• _common.sh, _targets.sh — sourced libraries, not run directly