# wasi-libc-headers — SÓLO los headers de wasi-libc, para ROMPER el ciclo del bootstrap wasm.
#
# EL CICLO: `wasi-libc` necesita `libclang_rt.builtins-wasm32.a` para enlazar, y
# `wasi-compiler-rt` necesita los headers de wasi-libc para compilar. Ninguno de los dos puede ir
# primero. Se rompe por acá: los headers NO necesitan compilar nada —el target
# `copy-include-headers.stamp` sólo copia ficheros— así que esta receta sale sin builtins y le da a
# `wasi-compiler-rt` el `CMAKE_SYSROOT` que le falta.
#
# ⚠ POR QUÉ ESTE COMMIT Y NO EL DE `wasi-libc`: acá se pinea `ac020b86` (viejo) y en `wasi-libc`
# `3f7eb4c7` (nuevo), igual que Alpine. NO es un descuido. El árbol instala los headers en
# `sysroot/include/$(TARGET_TRIPLE)`, y el TRIPLE POR DEFECTO cambió entre los dos commits:
# `wasm32-wasi` en el viejo, `wasm32-wasip1` en el nuevo. El toolchain file de wasi-sdk que usa
# `wasi-compiler-rt` fija `wasm32-wasi`, así que con el árbol nuevo clang buscaría
# `include/wasm32-wasi` y encontraría `include/wasm32-wasip1` — sysroot vacío y build muerto.
# El artefacto FINAL que consume firefox es el de `wasi-libc` (wasip1, el triple que clang 22.1
# usa de verdad); éste es andamio de bootstrap y muere acá.
#
# Verificado: el sha512 de este tarball coincide byte a byte con el que publica Alpine en su
# APKBUILD de `wasi-compiler-rt` — o sea que la descarga está contrastada contra una fuente
# independiente, no sólo consigo misma.
name    = "wasi-libc-headers"
version = "0.20250521"
license = "Apache-2.0 WITH LLVM-exception AND MIT AND CC0-1.0 AND BSD-2-Clause"

[source]
# Tarball `/archive/<commit>` de GitHub: se genera al vuelo, pero va pineado por COMMIT (no por tag
# móvil) y su sha256 está fijado acá, así que un cambio de bytes falla ruidosamente en el fetch.
# El repo trae un `.gitmodules` con `tools/wasi-headers/WASI`, que en el tarball llega VACÍO: es el
# generador de headers desde la espec WASI, y su salida ya está commiteada en el árbol. El Makefile
# no lo toca. No hace falta modo git.
tarball = "https://github.com/WebAssembly/wasi-libc/archive/ac020b86fd44bafe60aa4fa12f407d16e3731329.tar.gz"
sha256  = "d44bd7fa456aa42c1494767e5ffa00cdbab182d8497a577592a6562629f6f49e"

[build]
compiler = "clang"

[deps]
build = ["make"]

[build.phases]
configure = "true"
# `install-include-headers.sh` necesita un shell POSIX y `find`; los dos están en el lab.
compile = 'make build/wasm32-wasi/copy-include-headers.stamp'
install = '''
set -e
mkdir -p /out/usr/share/wasi-sysroot-bootstrap
cp -a sysroot/. /out/usr/share/wasi-sysroot-bootstrap/

# GUARDIÁN. El target de la stamp es un `touch`: si el script de copia fallara sin salir con
# error, la stamp existiría igual y esta receta sellaría un sysroot VACÍO — que es un cache-hit
# envenenado, no un fallo (regla 3 del CLAUDE.md). Se exige un header concreto, no el directorio.
test -f /out/usr/share/wasi-sysroot-bootstrap/include/wasm32-wasi/stdlib.h || {
  echo "!! el sysroot de bootstrap no tiene include/wasm32-wasi/stdlib.h" >&2
  echo "   (¿cambió TARGET_TRIPLE por defecto en este commit de wasi-libc?)" >&2
  ls -R /out/usr/share/wasi-sysroot-bootstrap 2>/dev/null | head -30 >&2
  exit 1
}
echo "guardián: headers wasm32-wasi presentes ($(find /out/usr/share/wasi-sysroot-bootstrap -name '*.h' | wc -l) .h)"
'''