Deployment
make deploy creates release archives for Linux, Windows, macOS, and embedded Linux. It builds a Docker image from deploy/Dockerfile, mounts the repository read/write at /proj, and runs deploy/deploy.sh. Generated files are written to .deploy/.
Run make deploy-clean to remove .deploy/.
The image is based on debian:trixie-slim. It installs the latest stable Zig compiler together with Make, LLVM tools, Wine, Zip, XZ, and the other archive tools required by the deployment script.
Release targets
Build output is written to .deploy/build/<target>/. Binary archives are written to .deploy/archives/bin/, and developer archives are written to .deploy/archives/dev/.
Desktop targets:
i686-linux-muslandi686-linux-gnux86_64-linux-muslandx86_64-linux-gnuaarch64-linux-muslandaarch64-linux-gnux86_64-windows-gnuandaarch64-windows-gnux86_64-macosandaarch64-macos
Embedded Linux targets:
mips-linux-musleabimipsel-linux-musleabiarm-linux-musleabi
All musl releases are statically linked. The embedded targets are for small Linux devices with limited ROM and RAM. They are built with -Oz to minimize binary size. mips is big-endian MIPS and mipsel is little-endian MIPS. The 32-bit ARM target uses the soft-float EABI and has no FPU requirement. Linux GNU releases are dynamically linked against glibc. Windows releases use the GNU Windows target supplied by Zig.
The deployment script invokes zig cc -target <target> for every target.
Build version
The deployment script obtains the release version from the Makefile version target. Every deployment build uses the normal Makefile build rules, which pass that version to both C command-line programs as -DSQUINCH_VERSION. The deployment script does not define a version independently.
For every archive, the deployment script copies src/unsquinch.sh into the target build directory and updates the copied script's SQUINCH_VERSION to the Makefile version. It never modifies src/unsquinch.sh in place. The Windows archives include the script for use through WSL.
Archives and debugging symbols
Binary archives use friendly names such as Squinch_1.0_Linux-x64.tar.xz, Squinch_1.0_Linux-arm32-static.tar.xz, and Squinch_1.0_Windows-arm64.zip. Static Linux and embedded releases add the -static suffix. Developer archives use names such as squinch_1.0_dev_x86_64-linux-gnu.tar.xz. The version always includes major and minor numbers, and includes a bugfix number only when it is non-zero.
Linux and macOS archives use the .tar.xz format. Windows archives use the .zip format. Every archive contains the complete AGPL-3.0-or-later and Apache-2.0 texts as LICENSE-AGPL-3.0-or-later and LICENSE-Apache-2.0. Binary archives contain squinch, unsquinch, unsquinch.sh, and LICENSE, which identifies their licensing. Windows binary archives contain squinch.exe, unsquinch.exe, unsquinch.sh, and LICENSE.
Each target build directory contains both release binaries, their separate debugging symbols, a build-info.txt file, and an obj/ directory with build object files. Developer archives include the complete target build directory and LICENSE, which identifies their licensing, except that they exclude obj/. They also include src/compress.c, src/compress.h, src/decompress.c, and src/decompress.h. The archive therefore provides the release binaries, debugging symbols, build information, standalone C API sources, and unsquinch.sh without object files.
ELF releases use .debug files and GNU debug links. macOS releases use .dSYM bundles. Windows releases use .debug files and PDB files.
Release verification
Before Docker builds any release target, make deploy runs the complete local make test suite. The native-architecture glibc and statically linked musl Linux targets then run against their final stripped binaries. The native-architecture Windows target runs stages 1, 2, and 5 through Wine. Stages 3 and 4 are not run during deployment. Non-native targets are only compiled and inspected.
GNU Linux and macOS releases are built and inspected in the Docker image. Non-native Linux and macOS releases are not executed there. Windows releases use Wine only when their CPU architecture matches the Docker container architecture.