sergioandClaude Opus 5
b344c5803b
zstd 12M→2M (−83%) · ncurses 6M→2M (−67%) · expat 2M→1M (−50%). Cero ficheros vacíos y **las tres REPRODUCEN**. La maquinaria de la etapa 4 queda validada de punta a punta: activar → construir en la granja → verificar con why-differs. LA DEP DE binutils VA EXPLÍCITA, y es la decisión de diseño de esta etapa. El paso de strip usa `strip --strip-debug -D` de binutils. Se podría hacer que el lab lo materialice solo, sin tocar las recetas — pero entonces la VERSIÓN de binutils sería un input INVISIBLE: dos corridas con binutils distintos darían artefactos distintos con el mismo hash. Los `deps` sí entran en `hash_inputs`, así que declararlo es lo único que mantiene el invariante. Cuesta una edición mecánica por receta; el invariante no se negocia por comodidad. EXCLUSIONES, y son exactamente dos: `binutils` y `make`. binutils provee el strip y depende de make ⇒ activarles el split los haría necesitarse a sí mismos para construirse. No es preferencia, es la circularidad. (Las recetas CERRADAS POR DECISIÓN tampoco se tocan.) POR TANDAS Y NO DE GOLPE: activar re-hashea la receta a propósito y en cascada todo lo que dependa de ella. Hacerlo sobre las 775 candidatas a la vez dejaría el corpus entero sin sellar al mismo tiempo — días de granja antes de poder verificar NADA, y el disco aguantando artefactos viejos y nuevos a la vez. Por tandas se mide, se verifica y se poda entre medias, que es lo que hace la campaña reversible. La primera tanda NO se tomó del orden alfabético que propone el script: ésas son CLIs Go/Rust que ya vimos que no reconstruyen en el worker (necesitan red para sus módulos), y validar la maquinaria con recetas que fallan por otro motivo no habría probado nada. Se eligieron tres paquetes C con artefacto presente. Para las tandas grandes hay que resolver antes el acceso a red de los módulos Go/Rust, o restringirse a lo que reconstruye. Estado: 775 candidatas, 5 desplegadas (bison y appstream del piloto + estas 3). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
25 lines
1.0 KiB
TOML
25 lines
1.0 KiB
TOML
# zstd 1.5.7 → libzstd.a (C, Makefile). Lib FUNDACIONAL: zstd-sys está en MONTONES de crates Rust
|
|
# (compresión moderna) + cola C. De-Alpinizada: compiler=zig-cc (migrado de gcc, matar-gcc 2026-07-16), build de lib/ (no CLI), estático.
|
|
name = "zstd"
|
|
version = "1.5.7"
|
|
license = "BSD-3-Clause OR GPL-2.0-only"
|
|
[source]
|
|
tarball = "https://github.com/facebook/zstd/releases/download/v1.5.7/zstd-1.5.7.tar.gz"
|
|
sha256 = "eb33e51f49a15e023950cd7825ca74a4a2b43db8354825ac24fc1b7ee09e6fa3"
|
|
[build]
|
|
compiler = "zig-cc"
|
|
target = "x86_64-linux-musl"
|
|
link = "static"
|
|
|
|
# Split de la info de depuración (SDD 23 etapa 4). Entra en `hash_inputs`: re-hashea a propósito.
|
|
strip_debug = true
|
|
flags = []
|
|
[build.phases]
|
|
# CFLAGS con -fPIC: el libzstd.a lleva objetos PIC ⇒ enlazable dentro de .so (Mesa liga libzstd en
|
|
# sus bibliotecas compartidas; sin PIC: «R_X86_64_PC32 ... recompile with -fPIC»). PIC es superset.
|
|
compile = 'make -C lib libzstd.a CFLAGS="-O3 -fPIC"'
|
|
install = 'make -C lib install PREFIX=/usr DESTDIR=/out'
|
|
|
|
[deps]
|
|
build = ["binutils"]
|