# 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.
name    = "json-c"
version = "0.18"

[source]
tarball = "https://s3.amazonaws.com/json-c_releases/releases/json-c-0.18.tar.gz"
sha256  = "876ab046479166b869afc6896d288183bbc0e5843f141200c677b3e8dfb11724"
patches = ["cmake-version.patch"]

[build]
compiler = "zig-cc"
target   = "x86_64-linux-musl"
link     = "static"
flags    = []

[build.phases]
configure = 'cmake -B build -DBUILD_SHARED_LIBS=OFF -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Release'
compile   = 'cmake --build build'
install   = 'DESTDIR=/out cmake --install build'


# ── SIN `[deps]` CONSTRUÍA POR ACCIDENTE ────────────────────────────────────────────────────────
# Esta receta no declaraba NADA, y aun así sellaba — porque el rootfs del laptop trae `cmake` y
# `make` instalados, así que el sandbox los encontraba «de prestado». En el worker, que no los trae,
# muere con `/bin/sh: cmake: not found` y **exit 127**, el mismo código que engaña en el caso de
# meson: se lee como «cmake no está» y lo que falta es DECLARARLO, no instalarlo.
#
# Salió a la luz construyendo `sway`, que depende de json-c: el fallo no estaba en sway ni en la
# receta que se estaba escribiendo, sino en una dep de tercer nivel que llevaba tiempo mintiendo.
#
# ⇒ El arreglo es declarar la herramienta, **NUNCA engordar el rootfs del worker**: engordarlo haría
#   que el build dependa de qué hay instalado en una máquina concreta, que es exactamente lo que
#   rompe la reproducibilidad. Y una receta que sólo construye en la máquina del autor es una bomba
#   de relojería: funciona hasta que alguien más la toca.
#
# `make` va además de `cmake` porque el generador por defecto de cmake en Unix es «Unix Makefiles»
# ⇒ `cmake --build build` invoca `make` por debajo.
[deps]
build = ["cmake", "make", "pkgconf"]
