tawasuyu

sergio/takana

> Una distribución Linux construida con un laboratorio funcional y hermético en el > sótano, y una terminal mutable, clásica y anárquica en el piso de arriba — diseñada > desde el suelo para que una IA programadora entienda, modifique y co…

TOML 604Rust 56Shell 36Markdown 281227 Sutichaykuna

corpus: uthash, nlohmann-json, jansson y x264 — las 4 deps que a OBS le faltaban

Las cuatro no existían en NINGUNA cola (medido cruzando el grafo, no con grep).
Van al corpus y no a una cola porque OBS es una app que quieren las cuatro
imágenes, y una receta resuelve sibling-first y después el catálogo PADRE, nunca
una cola hermana.

Verificadas por CONTENIDO del artefacto, no por exit 0 (regla 3 del repo):
 · uthash          5 cabeceras; no compila nada y la fase `compile` dice `true`
                   explícito, porque que una librería sea sólo cabeceras es un
                   hecho suyo, no un descuido de la receta.
 · nlohmann-json   pasa por CMake y no por un `cp` para que instale sus
                   nlohmann_jsonConfig/Targets.cmake: OBS hace find_package, y
                   copiar los .hpp a mano dejaría «está pero no lo encuentra».
 · jansson         libjansson.so.4.
 · x264            libx264.so.165 + x264.pc, y `asm: yes` — con SIMD, que es la
                   lección que ffmpeg acaba de costar hoy.

⚠ jansson trajo su propia trampa: la perilla es JANSSON_BUILD_SHARED_LIBS, NO la
estándar BUILD_SHARED_LIBS de CMake (CMakeLists.txt:5, default OFF). Con la
estándar el build sale exit 0 y sella un artefacto con SÓLO libjansson.a — la
receta diciendo link="dynamic" y el artefacto estático. Se vio mirando usr/lib/
del artefacto, no el código de salida.

c2feb3eab6e983e822b2c10924c5f9f694575999 · ruwaq Sergio · (1 killa ñawpaq) · tayta 323a675ed · kay commitpi sach'ata qhaway

Semántico sayk'uy

Mana ima sutichaypas t'ikrakurqanchu: qillqalla, yachachiylla utaq willaylla t'ikrakurqan.

4 qillqakuna · +165 −0

diff --git a/recipes/jansson.toml b/recipes/jansson.toml
new file mode 100644
index 00000000..96b2149a
--- /dev/null
+++ b/recipes/jansson.toml
@@ -0,0 +1,41 @@
+# jansson 2.14.1 — JSON en C. Entra por OBS: `libobs` la usa para leer/escribir sus perfiles y
+# escenas.
+#
+# CMake y no autotools: el tarball de release trae `configure`, pero la fuente por commit (ADR 0006)
+# NO — `configure` lo genera `autoreconf`, que pediría el stack autotools entero en `[deps]`. El
+# árbol trae `CMakeLists.txt` de primera clase, así que se usa ése y el cierre queda en cmake+ninja.
+#
+# `-DJANSSON_BUILD_DOCS=OFF` porque su default ON invoca sphinx, que no está en el corpus; y
+# `-DJANSSON_WITHOUT_TESTS=ON` para no compilar el árbol de tests, que no aporta al artefacto.
+#
+# ⚠ LA PERILLA ES `JANSSON_BUILD_SHARED_LIBS`, **NO** `BUILD_SHARED_LIBS`. jansson declara la suya
+# propia (`CMakeLists.txt:5`, default OFF) y NO mira la estándar de CMake. Con `-DBUILD_SHARED_LIBS=ON`
+# el build sale con exit 0 y sella un artefacto que trae SÓLO `libjansson.a` — o sea que la receta
+# dice `link = "dynamic"` y el artefacto es estático, y nadie se entera hasta que un `.so` que la
+# consume muere por PIC. Verificado mirando el `usr/lib/` del artefacto, no el código de salida:
+# es la misma familia que el `link=static` que miente por libtool.
+#
+# Fuente por commit: `v2.14.1` es un tag ANOTADO ⇒ esto es el `^{}` pelado.
+name    = "jansson"
+version = "2.14.1"
+license = "MIT"
+
+[source]
+repo   = "https://github.com/akheron/jansson.git"
+commit = "ed5cae4ed0621ef409510f94270c9f8f263736d0"
+
+[build]
+compiler = "zig-cc"
+target   = "x86_64-linux-musl"
+# DINÁMICO: OBS carga `libobs.so` y sus plugins como objetos compartidos, y una jansson `.a` sin PIC
+# dentro de un `.so` es el fallo que ya costó caro en gdk-pixbuf. Compartida y sin sorpresas.
+link  = "dynamic"
+flags = []
+
+[build.phases]
+configure = 'cmake -B build -G Ninja -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Release -DJANSSON_BUILD_SHARED_LIBS=ON -DJANSSON_BUILD_DOCS=OFF -DJANSSON_WITHOUT_TESTS=ON -DJANSSON_EXAMPLES=OFF'
+compile   = 'cmake --build build'
+install   = 'DESTDIR=/out cmake --install build'
+
+[deps]
+build = ["cmake", "samurai", "pkgconf"]
diff --git a/recipes/nlohmann-json.toml b/recipes/nlohmann-json.toml
new file mode 100644
index 00000000..8ccf3e91
--- /dev/null
+++ b/recipes/nlohmann-json.toml
@@ -0,0 +1,35 @@
+# nlohmann-json 3.12.0 — JSON para C++ moderno, sólo cabeceras. Entra por OBS, que la usa en
+# `libobs` y en varios plugins.
+#
+# Sólo cabeceras, pero SÍ pasa por CMake y no por un `cp`: el proyecto genera e instala
+# `nlohmann_jsonConfig.cmake` + `nlohmann_jsonTargets.cmake`, y OBS los consume con
+# `find_package(nlohmann_json REQUIRED)`. Copiar los `.hpp` a mano dejaría las cabeceras presentes y
+# el `find_package` fallando — un «está pero no lo encuentra» que se diagnostica mal.
+#
+# `-DJSON_BuildTests=OFF` porque su default es ON **cuando es el proyecto raíz**, que es justo
+# nuestro caso, y arrastra la descarga de un framework de test — red dentro del sandbox, que es
+# exactamente lo que un build hermético no puede hacer.
+#
+# Fuente por commit (ADR 0006): `v3.12.0` es un tag ANOTADO ⇒ esto es el `^{}` pelado, no el sha del
+# objeto tag.
+name    = "nlohmann-json"
+version = "3.12.0"
+license = "MIT"
+
+[source]
+repo   = "https://github.com/nlohmann/json.git"
+commit = "55f93686c01528224f448c19128836e7df245f72"
+
+[build]
+compiler = "zig-cc"
+target   = "x86_64-linux-musl"
+link     = "static"
+flags    = []
+
+[build.phases]
+configure = 'cmake -B build -G Ninja -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Release -DJSON_BuildTests=OFF'
+compile   = 'cmake --build build'
+install   = 'DESTDIR=/out cmake --install build'
+
+[deps]
+build = ["cmake", "samurai", "pkgconf"]
diff --git a/recipes/uthash.toml b/recipes/uthash.toml
new file mode 100644
index 00000000..66f31122
--- /dev/null
+++ b/recipes/uthash.toml
@@ -0,0 +1,38 @@
+# uthash 2.3.0 — tablas hash, listas y arrays dinámicos como MACROS de C. Entra por OBS: `libobs`
+# la usa para sus diccionarios internos.
+#
+# ══ NO COMPILA NADA, Y POR ESO LA FASE `compile` ES UN `true` ══════════════════════════════════
+# uthash es SÓLO cabeceras (`src/*.h`): no hay librería, ni `.a`, ni `.so`, ni `.pc`. Un consumidor
+# la usa con `#include <uthash.h>` y nada más. La receta se limita a copiar las cabeceras a
+# `/usr/include`, que es exactamente lo que hace el `uthash-dev` de Alpine.
+#
+# El `compile = "true"` no es un placeholder olvidado: hammer exige las tres fases, y dejarlo vacío
+# o ausente se lee peor que dejarlo explícito. Que una receta no compile nada es un hecho de la
+# librería, no un descuido.
+#
+# `link` es INERTE acá (no hay nada que ligar) pero se declara igual porque entra en `hash_inputs`:
+# omitirlo tomaría el default y ataría el hash a un default que puede cambiar.
+#
+# Fuente por commit (ADR 0006): `v2.3.0` es un tag LIGERO (una sola ref en `ls-remote`, sin `^{}`)
+# ⇒ este sha ES el commit.
+name    = "uthash"
+version = "2.3.0"
+license = "BSD-1-Clause"
+
+[source]
+repo   = "https://github.com/troydhanson/uthash.git"
+commit = "e493aa90a2833b4655927598f169c31cfcdf7861"
+
+[build]
+compiler = "zig-cc"
+target   = "x86_64-linux-musl"
+link     = "static"
+flags    = []
+
+[build.phases]
+configure = "true"
+compile   = "true"
+install   = "mkdir -p /out/usr/include && cp src/uthash.h src/utlist.h src/utarray.h src/utstring.h src/utringbuffer.h /out/usr/include/"
+
+[deps]
+build = []
diff --git a/recipes/x264.toml b/recipes/x264.toml
new file mode 100644
index 00000000..03df7aa8
--- /dev/null
+++ b/recipes/x264.toml
@@ -0,0 +1,51 @@
+# x264 (rama stable, 2025) — codificador H.264. Entra por OBS: el plugin `obs-x264` hace
+# `find_package(Libx264 REQUIRED)` y `plugins/CMakeLists.txt` lo agrega SIN condicional, así que no
+# hay OBS sin esto.
+#
+# ══ NI TAGS NI RELEASES: SE PINEA UN COMMIT DE `stable` ════════════════════════════════════════
+# x264 no publica releases ni tags; upstream mueve `master` y `stable` y las distros pinean un
+# commit. Acá se pinea el de `stable`, que es la rama que upstream considera apta para consumo. El
+# sha lo vuelve inmutable, que es lo único que el ADR 0006 exige: la fuente tiene que ser la MISMA
+# mañana, no tiene que tener nombre bonito.
+#
+# ══ `configure` PROPIO, NO AUTOTOOLS ═══════════════════════════════════════════════════════════
+# El `configure` de x264 es un script escrito a mano: no acepta `--build/--host` ni las variables de
+# autotools, y toma el compilador por `--extra-cflags`/`CC`. Mismo caso que ffmpeg.
+#
+# `--disable-asm` NO se pone: nasm está en el corpus y un codificador sin SIMD es el error que
+# acabamos de pagar en ffmpeg. Se declara `nasm` en `[deps]` justamente para que el ensamblador esté
+# y la SIMD entre.
+#
+# `--disable-cli`: OBS consume la LIBRERÍA (`libx264.so` + `x264.h` + `x264.pc`); el binario `x264`
+# no lo usa nadie y sólo agrega superficie.
+name    = "x264"
+version = "0.165-stable"
+license = "GPL-2.0-or-later"
+
+[source]
+repo   = "https://code.videolan.org/videolan/x264.git"
+commit = "b35605ace3ddf7c1a5d67a2eb553f034aef41d55"
+
+[build]
+compiler = "zig-cc"
+target   = "x86_64-linux-musl"
+# DINÁMICO: quien la consume es `obs-x264.so`, un MÓDULO cargado por dlopen. Una x264 `.a` sin PIC
+# dentro de un `.so` es exactamente el cuadro de gdk-pixbuf.
+link  = "dynamic"
+flags = []
+
+[build.phases]
+configure = '''
+ZW="$PWD/.zwrap"; mkdir -p "$ZW"
+cat > "$ZW/cc" <<'W'
+#!/bin/sh
+exec hammer-zig-cc "$@"
+W
+chmod +x "$ZW/cc"
+CC="$ZW/cc" ./configure --prefix=/usr --enable-shared --disable-cli --disable-opencl
+'''
+compile = 'make -j"$(nproc)"'
+install = 'make DESTDIR=/out install'
+
+[deps]
+build = ["nasm", "pkgconf"]