sergio/takana

1# pata-llimphi — el riel dibujado con llimphi — la cara del panel.
2#
3# ── POR QUÉ ESTA RECETA (2026-10-13) ────────────────────────────────────────────────────────────
4# El catálogo empaquetaba 35 componentes de tawasuyu y **ni pata ni churay**, que son el panel del
5# escritorio y el instalador. El síntoma que lo destapó: instalando con churay, «me montó un
6# busybox, luego dice que no hay pata» — no era un fallo de churay, era que no existía el paquete.
7
8name    = "pata-llimphi"
9version = "0.1.0"
10license = "MIT OR Apache-2.0"
11
12[source]
13repo   = "https://git.tawasuyu.net/tawasuyu/tawasuyu.git"
14commit = "619431cac9753cd55d0f9e2d99ff8efe7fab651b"
15# El monorepo COMMITEA su propio `vendor/` y el `cargo vendor` de takana lo pisaría.
16cargo_vendor_dir = ".hammer-cargo-vendor"
17
18[build]
19compiler = "zig-cc"
20target   = "x86_64-linux-musl"
21link     = "dynamic"
22# ⚠ \`link = "dynamic"\`: pinta, así que necesita \`dlopen\` de Vulkan/Wayland en runtime — mismo
23# motivo que \`llimphi-counter\`, que es la plantilla probada del stack llimphi.
24# ⚠ `--features llimphi-widget-scroll/std` NO es un adorno: el workspace declara ese widget con
25# `default-features = false`, así que `std` llega APAGADO a todo consumidor, y su código toma el
26# camino `libm::powf`/`libm::logf` bajo `cfg(not(feature = "std"))` con `libm` como dep OPCIONAL
27# que nadie enciende ⇒ `error[E0433]: cannot find module or crate `libm``.
28#
29# No les muerde en su repo porque un build `--workspace` enciende `std` por UNIFICACIÓN DE
30# FEATURES desde otro miembro; construir UN binario con `-p` —que es lo que hace una receta—
31# destapa el bug que el build completo esconde. Es la misma lección que `cadcraft.toml` anotó
32# sobre `eframe`: los features son aditivos y los enciende otro, así que leer el manifiesto de la
33# app da la respuesta equivocada.
34#
35# Y el crate mismo dice que la elección es de quien ensambla («Un widget NO elige backend: lo
36# elige quien ensambla la app»), así que que la RECETA elija `std` para un binario de Linux es
37# exactamente lo correcto, no un parche.
38flags    = ["-p", "pata-llimphi", "--bin", "pata-llimphi"]
39
40[build.phases]
41# ⚠ LOCKSTEP_XML_PATH — y acá el panic SÍ SE DISPARA, contra lo que dice `cadcraft.toml`.
42# Esa receta anotó el 2026-10-13 que «el panic de `zbus-lockstep-macros` NO se dispara en estas
43# versiones», generalizando desde que `vectorcraft` compiló sin el bloque. Medido hoy con las MISMAS
44# versiones —`atspi-common` 0.13.0 + `zbus-lockstep-macros` 0.5.2— este binario muere así:
45#
46#   error: custom attribute panicked        (×5)
47#   error[E0432]: unresolved imports `object_ref::ObjectRef`, …
48#
49# Los `E0432` son CONSECUENCIA, no causa: el `#[validate]` panica y los tipos nunca se generan, así
50# que el error que se lee está lejos del que importa. La cadena es `accesskit` → `atspi` →
51# `atspi-common`, cuyo `#[validate]` recorre `xml/` llamando `.extension().expect()` en cada entrada
52# y PANICA al toparse con el subdirectorio `xml/schemas/`. Apuntar la variable a un dir con sólo los
53# `.xml` lo evita.
54#
55# ⇒ Que una receta compile sin el bloque NO prueba que el bloque no haga falta: prueba que ESE
56# binario no llegó a esa rama del grafo de features. El comprobante del `ls` es a gritos a propósito
57# — un `cp` mudo dejaría la variable apuntando a un dir vacío y el panic volvería sin su causa.
58compile = '''
59set -e
60XMLDIR="$PWD/.atspi-lockstep-xml"
61mkdir -p "$XMLDIR"
62ls .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; }
63cp .hammer-cargo-vendor/atspi-common/xml/*.xml "$XMLDIR"/
64export LOCKSTEP_XML_PATH="$XMLDIR"
65printf '%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"
66chmod +x "$PWD/.hammer-zig-cc"
67RF="-C linker=$PWD/.hammer-zig-cc"
68rustc -vV | grep -q 'host: .*-alpine-' || RF="$RF -C link-self-contained=no"
69CC="$PWD/.hammer-zig-cc" RUSTFLAGS="$RF" cargo rustc --release --locked --offline --features llimphi-widget-scroll/std,llimphi-widget-text-input/std -p pata-llimphi --bin pata-llimphi -- -C target-feature=-crt-static
70'''
71
72[deps]
73# Mismo set que `churay-metal`: cliente Wayland con stack gráfico.
74# ⚠ `alsa-lib` añadido tras MEDIRLO: el riel pide `alsa.pc` en build (el `build.rs` del crate
75# `alsa`), y sin él muere con el mismo tipo de fallo que ya había dado `xkbcommon`. Es la tercera
76# vez en esta serie que una dep de sistema aparece sólo al construir — las dependencias directas
77# del `Cargo.toml` no las anuncian.
78# ⚠ Es `alsa-lib` para el BUILD; el servidor de audio de la distro es PipeWire, que es otra cosa
79# y otra decisión (ver la receta `pipewire`).
80# ⚠ `openssl`, `fontconfig` y `cmake` añadidos tras MEDIRLO igual que `alsa-lib` (2026-10-13): con
81# alsa resuelto, el build llegó 41 min más lejos y murió en `openssl-sys` —«Package 'openssl' was not
82# found in the pkg-config search path»—. Las `-sys` del grafo de este binario, por `cargo tree`:
83# alsa-sys · openssl-sys · yeslogic-fontconfig-sys · aws-lc-sys (compila su C con cmake) · zstd-sys
84# (vendorea) · wayland-sys (dlopen). Se declaran las que piden algo del sistema; las tres publican su
85# `.pc` o su binario, verificado en el store antes de relanzar.
86build = ["mesa", "wayland", "wayland-protocols", "libdrm", "libxkbcommon", "alsa-lib", "expat", "zlib", "zstd", "libffi", "pkgconf", "openssl", "fontconfig", "cmake"]