From c2feb3eab6e983e822b2c10924c5f9f694575999 Mon Sep 17 00:00:00 2001 From: Sergio Date: Fri, 4 Sep 2026 16:27:24 +0000 Subject: [PATCH] =?UTF-8?q?corpus:=20uthash,=20nlohmann-json,=20jansson=20?= =?UTF-8?q?y=20x264=20=E2=80=94=20las=204=20deps=20que=20a=20OBS=20le=20fa?= =?UTF-8?q?ltaban?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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. --- recipes/jansson.toml | 41 ++++++++++++++++++++++++++++++ recipes/nlohmann-json.toml | 35 ++++++++++++++++++++++++++ recipes/uthash.toml | 38 ++++++++++++++++++++++++++++ recipes/x264.toml | 51 ++++++++++++++++++++++++++++++++++++++ 4 files changed, 165 insertions(+) create mode 100644 recipes/jansson.toml create mode 100644 recipes/nlohmann-json.toml create mode 100644 recipes/uthash.toml create mode 100644 recipes/x264.toml 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 ` 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"]