sergio/takana

1# wasi-libc-headers — SÓLO los headers de wasi-libc, para ROMPER el ciclo del bootstrap wasm.
2#
3# EL CICLO: `wasi-libc` necesita `libclang_rt.builtins-wasm32.a` para enlazar, y
4# `wasi-compiler-rt` necesita los headers de wasi-libc para compilar. Ninguno de los dos puede ir
5# primero. Se rompe por acá: los headers NO necesitan compilar nada —el target
6# `copy-include-headers.stamp` sólo copia ficheros— así que esta receta sale sin builtins y le da a
7# `wasi-compiler-rt` el `CMAKE_SYSROOT` que le falta.
8#
9# ⚠ POR QUÉ ESTE COMMIT Y NO EL DE `wasi-libc`: acá se pinea `ac020b86` (viejo) y en `wasi-libc`
10# `3f7eb4c7` (nuevo), igual que Alpine. NO es un descuido. El árbol instala los headers en
11# `sysroot/include/$(TARGET_TRIPLE)`, y el TRIPLE POR DEFECTO cambió entre los dos commits:
12# `wasm32-wasi` en el viejo, `wasm32-wasip1` en el nuevo. El toolchain file de wasi-sdk que usa
13# `wasi-compiler-rt` fija `wasm32-wasi`, así que con el árbol nuevo clang buscaría
14# `include/wasm32-wasi` y encontraría `include/wasm32-wasip1` — sysroot vacío y build muerto.
15# El artefacto FINAL que consume firefox es el de `wasi-libc` (wasip1, el triple que clang 22.1
16# usa de verdad); éste es andamio de bootstrap y muere acá.
17#
18# Verificado: el sha512 de este tarball coincide byte a byte con el que publica Alpine en su
19# APKBUILD de `wasi-compiler-rt` — o sea que la descarga está contrastada contra una fuente
20# independiente, no sólo consigo misma.
21name    = "wasi-libc-headers"
22version = "0.20250521"
23license = "Apache-2.0 WITH LLVM-exception AND MIT AND CC0-1.0 AND BSD-2-Clause"
24
25[source]
26# Tarball `/archive/<commit>` de GitHub: se genera al vuelo, pero va pineado por COMMIT (no por tag
27# móvil) y su sha256 está fijado acá, así que un cambio de bytes falla ruidosamente en el fetch.
28# El repo trae un `.gitmodules` con `tools/wasi-headers/WASI`, que en el tarball llega VACÍO: es el
29# generador de headers desde la espec WASI, y su salida ya está commiteada en el árbol. El Makefile
30# no lo toca. No hace falta modo git.
31tarball = "https://github.com/WebAssembly/wasi-libc/archive/ac020b86fd44bafe60aa4fa12f407d16e3731329.tar.gz"
32sha256  = "d44bd7fa456aa42c1494767e5ffa00cdbab182d8497a577592a6562629f6f49e"
33
34[build]
35compiler = "clang"
36
37[deps]
38build = ["make"]
39
40[build.phases]
41configure = "true"
42# `install-include-headers.sh` necesita un shell POSIX y `find`; los dos están en el lab.
43compile = 'make build/wasm32-wasi/copy-include-headers.stamp'
44install = '''
45set -e
46mkdir -p /out/usr/share/wasi-sysroot-bootstrap
47cp -a sysroot/. /out/usr/share/wasi-sysroot-bootstrap/
48
49# GUARDIÁN. El target de la stamp es un `touch`: si el script de copia fallara sin salir con
50# error, la stamp existiría igual y esta receta sellaría un sysroot VACÍO — que es un cache-hit
51# envenenado, no un fallo (regla 3 del CLAUDE.md). Se exige un header concreto, no el directorio.
52test -f /out/usr/share/wasi-sysroot-bootstrap/include/wasm32-wasi/stdlib.h || {
53  echo "!! el sysroot de bootstrap no tiene include/wasm32-wasi/stdlib.h" >&2
54  echo "   (¿cambió TARGET_TRIPLE por defecto en este commit de wasi-libc?)" >&2
55  ls -R /out/usr/share/wasi-sysroot-bootstrap 2>/dev/null | head -30 >&2
56  exit 1
57}
58echo "guardián: headers wasm32-wasi presentes ($(find /out/usr/share/wasi-sysroot-bootstrap -name '*.h' | wc -l) .h)"
59'''