v0.02

The desktop for AmigaOS 3.x, AmigaOS 4 and AROS: wena-amigaos-m68k, wena-amigaos4-ppc, wena-aros-x86

• scripts/build_desktop_amiga.sh TARGET OUTPUT compiles the desktop in the
  pinned amigadev/crosstools image of each into one static executable: the
  image's SDL2 2.30 on AmigaOS 4 (PowerPC ELF); SDL2 2.32.10 with AROS's own
  port (SDL2-2.32.10-aros.diff from aros-development-team/contrib, without
  OpenGL) on AROS x86-64 (relocatable ELF); and on AmigaOS 3.x the SDL2 fork
  DevilutionX ships for 68040 with FPU and an RTG card (HUNK). Images and
  sources are pinned by digest and SHA-256.
• SQLite runs there without WAL, mmap or file locks, through an amiga VFS
  that keeps AmigaDOS names such as PROGDIR:x as they are. Wena's
  journal_mode=WAL then simply stays delete; other platforms keep WAL.
• The platform code knows Volume: paths, keeps the board in
  PROGDIR:wena.sqlite (ENV: is a RAM disk), publishes a new workspace with
  dos.library Rename() (which never replaces), retries settings writes
  because AmigaDOS Rename() does not replace, keeps the collapse preferences
  file within the original FFS's 30 characters, asks locale.library for the
  language and runs on a 1 MB stack (AmigaOS 4 $STACK cookie, libnix
  __stack, AROS NewStackSwap).
• Verified here: all three build, link statically and pass the format checks
  (scripts/check_release_executable.py now knows HUNK, static PowerPC ELF
  and AROS's relocatable ELF); the desktop with the exact Amiga SQLite options
  and VFS creates and reopens a board on Linux. Not run on an Amiga or an
  emulator yet. Tests: amiga-desktop, debug-log, build-entrypoints.

Thanks to xet7.

The desktop for Android and iOS: wena-android-arm64.apk and wena-ios-arm64.ipa

• scripts/build_desktop_android.sh OUTPUT_APK builds libmain.so - the
  desktop with SDL2 2.32.10 and SQLite linked in - with SDL's own Java glue and
  a small fi.wekan.wena.WenaActivity, directly with the NDK, javac, d8,
  aapt2, zipalign and apksigner (no Gradle). Min SDK 21, target SDK 37,
  16 KB-page aligned. It is signed with the release key from the repository
  secrets, or a debug key with a warning.
• scripts/build_desktop_ios.sh OUTPUT_IPA builds SDL2 for iOS with CMake and
  links Payload/Wena.app (iOS 15 or newer), unsigned: re-sign it with your
  own certificate, AltStore or Sideloadly. Apps built with the iOS 27 SDK must
  use scenes, which SDL 2 does not, so client/platform/ios/scene.m puts
  SDL's windows into the app's scene.
• On a phone the board lives in the app's own data folder
  (SDL_GetPrefPath), the language comes from the system, the board is laid
  out in density-independent units and drawn at native pixels, touches land
  where they are drawn, the keyboard shows only while a field is edited, and a
  failure is shown in a message box. On Android a new workspace is published
  with rename() after checking nothing is there, because SELinux refuses
  link() in the app's folder.
• Verified here: the APK passed the smoke test in the Android 17 (API 37)
  emulator, on a second run and after an update over itself, and a card was
  added by touch; the Simulator app passed on iOS 27.0 and 26.5. Real phones,
  Android 5-16 and Xcode 16 builds are verified by use and the release run.
  scripts/check_release_executable.py checks the APK's only library is
  arm64 libmain.so loading Android's own libraries, and the IPA's Wena
  loads only iOS's frameworks. Tests: mobile-desktop, debug-log,
  build-entrypoints.

Thanks to xet7.

Every release file is the desktop GUI, one self-contained wena-TARGET per platform, from one workflow

• release-all.yml is the only release workflow. release-desktop.yml, the
  .github/release/*.sh scripts and client/main.c are gone: the program they
  released printed one line in a terminal. Every target in config/targets.tsv
  is now the native Nuklear desktop, named after its platform -
  wena-linux-amd64, wena-windows-amd64.exe, wena-freebsd-amd64 - and
  attached beside one SHA256SUMS, without a .sha256 per file or a separate
  notices archive.
• 28 platforms: Linux amd64, arm64, armhf, armel, i686, riscv64, ppc64le,
  s390x and mips64le; FreeBSD amd64, arm64 and riscv64; NetBSD and OpenBSD
  amd64 and arm64; DragonFly BSD and Haiku amd64, built natively in virtual
  machines (cross-platform-actions v1.6.0, scripts/build_desktop_release_vm.sh);
  macOS arm64 and amd64; Windows amd64, i686 and arm64; and, below, AmigaOS
  3.x, AmigaOS 4, AROS, Android and iOS.
• SDL2 and SQLite are linked into each one from the pinned sources, as before;
  the licenses of everything in it are now compiled in too
  (scripts/generate_notices.py), and wena --licenses prints them.
• wena2 log: linux-armel and linux-mips64le stopped at once, because the
  debian:bookworm image no longer lists those CPUs. They build in Debian's
  per-architecture images, arm32v5/debian:bookworm and
  mips64le/debian:bookworm, with the same glibc 2.36. Under QEMU, loading
  Mesa's DRI driver crashes on MIPS64 (SIGBUS) before Wena draws anything,
  whichever Gallium driver is chosen, so that one X11 smoke test keeps Mesa's
  driver unloaded and uses SDL's software renderer. Every X11 smoke test now
  checks the application's own exit status rather than xvfb-run's.
• Two compile errors that would have stopped the BSD builds, found by
  compiling every desktop source against FreeBSD 15.1, OpenBSD 7.9 and NetBSD
  10.1 headers (tests/test_bsd_sources.py, suite bsd-sources): an unused
  static helper in server/executable_path.c on FreeBSD, NetBSD and DragonFly
  (-Werror), and NetBSD's <sys/sysctl.h> needing _NETBSD_SOURCE.
• ./build.sh build TARGET builds the same release file into release/ the
  way the workflow does: Linux targets in the workflow's own container image
  (scripts/toolchain.py and the workflow are checked to agree), Windows with
  MinGW-w64 (arm64 with the pinned llvm-mingw, now also on macOS), macOS with
  Xcode. A BSD or Haiku target builds on that system itself.
• Verified here: macOS arm64 and amd64 built, ran headless twice and printed
  their licenses; Windows amd64, i686 and arm64 built and were checked
  self-contained; linux-arm64 and linux-armel built and passed the headless
  and X11 smoke tests in their containers, and linux-mips64le too, under QEMU. The BSD and Haiku virtual-machine builds, the Windows runs and
  the other Linux CPUs are verified by the next release run. Tests:
  release-workflow, target-catalog, toolchain, build-entrypoints,
  source-structure, bsd-sources, with negatives (the wena2 image, a target
  left out of the workflow, the two BSD errors, a stray release file).

Thanks to xet7.

The desktop compiles its migrations in and reads nothing from its own file

• It assembled the migration bundle from a footer appended to its executable,
  found through the executable's path, and opened an appended translation
  catalog only to check that it was there. An app bundle, an APK, a signed
  iOS app and Amiga's PROGDIR: either cannot carry appended bytes or cannot
  find the file reliably, and OpenBSD has no /proc to find it with. The
  bundle now comes from the compiled registry, checked against its own
  SHA-256 (wena_sqlite_compiled_bundle); nothing is appended.
• tests/test_compiled_bundle.sh (suite compiled-bundle) checks the bundle
  against config/migrations-lock.json, NULL arguments, and that neither the
  desktop nor its build reads or appends a footer. The runtime and
  embedded-migration suites test the server's footer reader with a fixture
  instead of the removed terminal program.

Thanks to xet7.

build.sh and build.bat install what a build needs on macOS, Windows, Ubuntu, Debian and Fedora

• scripts/toolchain.py runs before every build and installs what is
  missing with the computer's own package manager: Homebrew on macOS, apt on
  Debian and Ubuntu, dnf on Fedora, Chocolatey or else winget on Windows.
  build.sh and build.bat install Python 3 first when it is missing.
• Per target: gcc, Debian's cross-compilers with their C library, MinGW-w64,
  Docker (started when it is not running, with QEMU on arm64 Linux) for
  AmigaOS and AROS, and the Android NDK r29. The NDK is downloaded from Google
  and checked against the size and SHA-1 in Google's own repository manifest
  before it is unpacked into .tools. iOS uses an installed Xcode through
  DEVELOPER_DIR without changing which one is selected.
• Where this computer has no compiler for a Linux target (Fedora, macOS,
  Windows), it is built in an Ubuntu 24.04 container with Ubuntu's compiler.
  The container's name is a hash of its package list, so a changed list
  builds a new one.
• On Windows, Git for Windows provides sh and file, a native MinGW-w64 gcc
  builds the Windows target, MSYS2 provides SDL2, SQLite and gcc for the
  desktop, and a python3 shim lets the release scripts call Python.
  android-arm64.sh uses the NDK's prebuilt compiler for this computer
  instead of always Linux's.
• build all builds every target this computer can build and lists the
  others with the reason, such as iOS without Xcode. install TARGET|all|desktop
  installs without building. WENA_NO_INSTALL=1 only checks.
• windows-amd64.sh accepts both ways file words a PE executable: file 5.46
  (Fedora 42) puts "Windows" before "x86-64".
• Verified on this Mac: all ten release targets and the desktop built after
  installing what was missing. On fresh Ubuntu 24.04, Debian 12 and Fedora 42
  containers, starting without Python, these all built: the host target,
  Windows amd64 and the desktop, plus armhf cross-built on Ubuntu and
  Debian. Windows was not run here. tests/test_toolchain.py covers each
  package manager and each target with fakes, including what is refused:
  an NDK download that fails its checksum, a zip entry outside its folder,
  a failed install and WENA_NO_INSTALL.

Thanks to xet7.

The macOS, iOS, AmigaOS, AROS and Android release builds compile again

• v0.01's release-all.yml built six of its ten targets' compilers into
  errors before a line of Wena was compiled.
• macOS arm64, macOS amd64 and iOS arm64: clang, found with xcrun --find
  and run by path, has no SDK of its own and found no <stdio.h>. It now
  comes from the macosx or iphoneos SDK and gets that SDK's
  -isysroot.
• AmigaOS 3.x m68k: libnix and sys/types.h declare static inline
  functions, and inline is not a C89 keyword; -Dinline=__inline__ keeps
  -std=c89 -pedantic-errors for Wena's own code.
• AROS x86: the image's gcc has no include path. It gets
  --sysroot=/opt/x86_64-aros and the ISO C headers in aros/stdc ahead of
  the aros/posixc layer, which does not compile as C89.
• Android arm64: sdkmanager is not on PATH on the ubuntu-24.04 runner; the
  NDK step runs it from $ANDROID_HOME/cmdline-tools/latest/bin.
• Verified here: the failures reproduced, then macOS arm64 and amd64,
  AmigaOS and AROS built with wena.py build and passed their release
  checks. iOS (no iphoneos SDK here) and Android are verified by the next
  release run. tests/test_release_workflow.py pins each fix and fails
  against the old scripts.

Thanks to xet7.