Compare commits

..
Author SHA1 Message Date
2c3b8637f5
docs: install from the Catcrafts Flatpak repo
The README leads with the Flatpak install, keeps the native loop as the
way to build from source, and drops the tarball, musl and makepkg text
that no longer describes anything CI produces. The install layout shows
the /app tree and the per-app cache directory.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
2026-10-02 23:18:11 +02:00
47d6d2ccd1
feat(ci): build and publish the Flatpak
One job replaces the tarball pipeline. On a pull request it builds the
Flatpak with flatpak-builder, which runs the bootstrap, the self-host
build and the test suite inside the sandbox, and smoke-tests the result
with `crafter-build --version` and the hello-world example. On a push to
master it also bundles the build, promotes it into the live repo as the
`beta` branch and refreshes the rolling `latest` prerelease. On a tag
X.Y.Z it promotes as `stable`, refuses to proceed unless the metainfo's
newest release is that version, and publishes a release whose notes are
that entry's description.

The job runs on the `flatpak` runner label: the privileged forgejo-runner
on the Hetzner box, with the Sdk install, the flatpak-builder state and
the repo's web root as volumes. The state volume is what keeps a normal
run short: flatpak-builder rebuilds the LLVM and WASI modules only when
their sources change. The live repo is canonical and never built into;
builds are promoted with build-commit-from, then build-update-repo signs
and prunes it and generates static deltas.

The musl job, the per-march tarballs, the toolchain packages the runner
used to install and the PKGBUILD go: the Flatpak is the one artifact.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
2026-10-02 23:18:11 +02:00
2 changed files with 0 additions and 25 deletions

View file

@ -154,11 +154,6 @@ modules:
url: https://github.com/WebAssembly/wasi-sdk.git
tag: wasi-sdk-34
disable-submodules: true
# The compiler-rt sub-build gets the C target but not the ASM target, so
# its two wasm/*.S stubs come out as host objects when the driving clang
# does not default to wasm32. Reported upstream; drop once wasi-sdk has it.
- type: patch
path: wasi-sdk-asm-target.patch
- type: git
url: https://github.com/WebAssembly/wasi-libc.git
commit: 2e6fb9d8ee0cdf9e431fbcabe8af3115de000a13

View file

@ -1,20 +0,0 @@
wasi-sdk-sysroot.cmake: tell the compiler-rt sub-build the ASM target too
The sub-build gets CMAKE_C_COMPILER_TARGET but nothing for the ASM
language, so compiler-rt's wasm/*.S stubs (the setjmp/longjmp and C++
exception tags) are assembled for the host when the driving clang is not
a wasm-default build. wasm-ld then warns that the archive members are
neither Wasm objects nor bitcode, and code that needs the tags fails to
link. wasi-sdk's own toolchain hides this because its clang defaults to
wasm32-wasip1; the sysroot-only mode against a host clang does not.
--- a/cmake/wasi-sdk-sysroot.cmake
+++ b/cmake/wasi-sdk-sysroot.cmake
@@ -107,6 +107,7 @@
-DCOMPILER_RT_BUILD_ORC=OFF
-DCOMPILER_RT_BUILD_GWP_ASAN=OFF
-DCMAKE_C_COMPILER_TARGET=${target}
+ -DCMAKE_ASM_COMPILER_TARGET=${target}
-DCMAKE_C_FLAGS=${WASI_SDK_CPU_CFLAGS}
-DCMAKE_CXX_FLAGS=${WASI_SDK_CPU_CFLAGS}
-DCMAKE_ASM_FLAGS=${WASI_SDK_CPU_CFLAGS}