sergio/takana

1# json-c 0.18 — lib C base (de-Alpinizada, Etapa G). compiler=zig-cc (migrado de gcc, matar-gcc 2026-07-16), configure-split, estático.
2name    = "json-c"
3version = "0.18"
4license = "MIT"
5
6[source]
7tarball = "https://s3.amazonaws.com/json-c_releases/releases/json-c-0.18.tar.gz"
8sha256  = "876ab046479166b869afc6896d288183bbc0e5843f141200c677b3e8dfb11724"
9patches = ["cmake-version.patch"]
10
11[build]
12compiler = "zig-cc"
13target   = "x86_64-linux-musl"
14link     = "static"
15flags    = []
16
17[build.phases]
18configure = 'cmake -B build -DBUILD_SHARED_LIBS=OFF -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Release'
19compile   = 'cmake --build build'
20install   = 'DESTDIR=/out cmake --install build'
21
22
23# ── SIN `[deps]` CONSTRUÍA POR ACCIDENTE ────────────────────────────────────────────────────────
24# Esta receta no declaraba NADA, y aun así sellaba — porque el rootfs del laptop trae `cmake` y
25# `make` instalados, así que el sandbox los encontraba «de prestado». En el worker, que no los trae,
26# muere con `/bin/sh: cmake: not found` y **exit 127**, el mismo código que engaña en el caso de
27# meson: se lee como «cmake no está» y lo que falta es DECLARARLO, no instalarlo.
28#
29# Salió a la luz construyendo `sway`, que depende de json-c: el fallo no estaba en sway ni en la
30# receta que se estaba escribiendo, sino en una dep de tercer nivel que llevaba tiempo mintiendo.
31#
32# ⇒ El arreglo es declarar la herramienta, **NUNCA engordar el rootfs del worker**: engordarlo haría
33#   que el build dependa de qué hay instalado en una máquina concreta, que es exactamente lo que
34#   rompe la reproducibilidad. Y una receta que sólo construye en la máquina del autor es una bomba
35#   de relojería: funciona hasta que alguien más la toca.
36#
37# `make` va además de `cmake` porque el generador por defecto de cmake en Unix es «Unix Makefiles»
38# ⇒ `cmake --build build` invoca `make` por debajo.
39[deps]
40build = ["cmake", "make", "pkgconf"]