# churay-metal — la cara del instalador que pinta por DRM SIN GPU — la que sirve en la máquina que no tiene aceleración.
#
# ── POR QUÉ ESTA RECETA (2026-10-13) ────────────────────────────────────────────────────────────
# El catálogo empaquetaba 35 componentes de tawasuyu y **ni pata ni churay**, que son el panel del
# escritorio y el instalador. El síntoma que lo destapó: instalando con churay, «me montó un
# busybox, luego dice que no hay pata» — no era un fallo de churay, era que no existía el paquete.

name    = "churay-metal"
version = "0.1.0"
license = "MIT OR Apache-2.0"

[source]
repo   = "https://git.tawasuyu.net/tawasuyu/tawasuyu.git"
commit = "619431cac9753cd55d0f9e2d99ff8efe7fab651b"
# El monorepo COMMITEA su propio `vendor/` y el `cargo vendor` de takana lo pisaría.
cargo_vendor_dir = ".hammer-cargo-vendor"

[build]
compiler = "zig-cc"
target   = "x86_64-linux-musl"
link     = "dynamic"
# ⚠ \`link = "dynamic"\`: pinta, así que necesita \`dlopen\` de Vulkan/Wayland en runtime — mismo
# motivo que \`llimphi-counter\`, que es la plantilla probada del stack llimphi.
flags    = ["-p", "churay-metal", "--bin", "churay-metal"]

[build.phases]
# ⚠ LOCKSTEP_XML_PATH — y acá el panic SÍ SE DISPARA, contra lo que dice `cadcraft.toml`.
# Esa receta anotó el 2026-10-13 que «el panic de `zbus-lockstep-macros` NO se dispara en estas
# versiones», generalizando desde que `vectorcraft` compiló sin el bloque. Medido hoy con las MISMAS
# versiones —`atspi-common` 0.13.0 + `zbus-lockstep-macros` 0.5.2— este binario muere así:
#
#   error: custom attribute panicked        (×5)
#   error[E0432]: unresolved imports `object_ref::ObjectRef`, …
#
# Los `E0432` son CONSECUENCIA, no causa: el `#[validate]` panica y los tipos nunca se generan, así
# que el error que se lee está lejos del que importa. La cadena es `accesskit` → `atspi` →
# `atspi-common`, cuyo `#[validate]` recorre `xml/` llamando `.extension().expect()` en cada entrada
# y PANICA al toparse con el subdirectorio `xml/schemas/`. Apuntar la variable a un dir con sólo los
# `.xml` lo evita.
#
# ⇒ Que una receta compile sin el bloque NO prueba que el bloque no haga falta: prueba que ESE
# binario no llegó a esa rama del grafo de features. El comprobante del `ls` es a gritos a propósito
# — un `cp` mudo dejaría la variable apuntando a un dir vacío y el panic volvería sin su causa.
compile = '''
set -e
XMLDIR="$PWD/.atspi-lockstep-xml"
mkdir -p "$XMLDIR"
ls .hammer-cargo-vendor/atspi-common/xml/*.xml >/dev/null 2>&1 || { echo "no hay .hammer-cargo-vendor/atspi-common/xml/*.xml — ¿cambió el vendoreo o la versión de atspi? sin esto zbus-lockstep-macros panica en xml/schemas/" >&2; exit 1; }
cp .hammer-cargo-vendor/atspi-common/xml/*.xml "$XMLDIR"/
export LOCKSTEP_XML_PATH="$XMLDIR"
printf '%s\n' '#!/bin/sh' 'for a do' 'case "$a" in --target=*) a=--target=x86_64-linux-musl ;; esac' 'set -- "$@" "$a"' 'shift' 'done' 'exec zig cc -mcpu=baseline "$@"' > "$PWD/.hammer-zig-cc"
chmod +x "$PWD/.hammer-zig-cc"
# El lock del subworkspace pinea `blake3 1.8.7` y el vendor —derivado del lock del workspace RAÍZ,
# en el MISMO commit— trae 1.8.5: churay-metal está excluido del workspace y su lock se actualizó
# sin el de arriba. Offline eso no avisa, falla a los 27 s con «failed to select a version».
# Tirando el lock, cargo resuelve contra lo que el vendor tiene de verdad.
rm -f 02_ruway/churay/churay-metal/Cargo.lock
RF="-C linker=$PWD/.hammer-zig-cc"
rustc -vV | grep -q 'host: .*-alpine-' || RF="$RF -C link-self-contained=no"
CC="$PWD/.hammer-zig-cc" RUSTFLAGS="$RF" cargo rustc --release --offline \
  --manifest-path 02_ruway/churay/churay-metal/Cargo.toml -- -C target-feature=-crt-static
'''

install = '''
set -e
# El subworkspace tiene `target/` propio, pero el sandbox puede fijar CARGO_TARGET_DIR: se
# buscan los dos sitios en vez de suponer uno, que es la diferencia entre instalar y fallar
# al final de una compilación larga.
for d in 02_ruway/churay/churay-metal/target/release target/release; do
  if [ -x "$d/churay-metal" ]; then
    install -Dm755 "$d/churay-metal" /out/usr/bin/churay-metal
    exit 0
  fi
done
echo "no encontre el binario churay-metal en ninguno de los dos target/" >&2
exit 1
'''

[deps]
# El set de deps sale de `recipes/churay.toml`, la receta de la cara *hybrid* que OTRO AGENTE ya
# tenía escrita (sin commitear) con esta lista probada. Adoptarla en vez de adivinarla es lo que
# evita repetir su trabajo mal: mi primera versión salió sin `[deps]` y por eso no construyó.
# ⚠ `openssl`, `fontconfig` y `cmake` añadidos tras MEDIRLO igual que `alsa-lib` (2026-10-13): con
# alsa resuelto, el build llegó 41 min más lejos y murió en `openssl-sys` —«Package 'openssl' was not
# found in the pkg-config search path»—. Las `-sys` del grafo de este binario, por `cargo tree`:
# alsa-sys · openssl-sys · yeslogic-fontconfig-sys · aws-lc-sys (compila su C con cmake) · zstd-sys
# (vendorea) · wayland-sys (dlopen). Se declaran las que piden algo del sistema; las tres publican su
# `.pc` o su binario, verificado en el store antes de relanzar.
# alsa-lib: MEDIDO el 13-oct — esta receta murio a los 38 min con «Package alsa was not
# found in the pkg-config search path». El cargo tree del host NO lo habia mostrado para este
# binario, asi que el hecho manda sobre la medicion: el grafo del commit pineado trae alsa-sys.
build = ["mesa", "wayland", "wayland-protocols", "libdrm", "libxkbcommon", "alsa-lib", "expat", "zlib", "zstd", "libffi", "pkgconf", "openssl", "fontconfig", "cmake"]