gioser

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 1184Shell 70Rust 62Markdown 501503 Definitions

fix(fcitx5): el cache de cmake del intento fallido envenenaba todos los reintentos

Tras arreglar el cierre de `.pc` que de verdad faltaba, el build volvió a morir con EL MISMO error
—`PkgConfig::Cairo … target was not found`— y en **2 segundos**: «Generating done (0.0s)».

La causa es que el árbol de fuentes (`work/sources/<receta>-<sha>`) **se reusa entre builds** —es
caché por diseño— así que el `build/` del intento anterior sobrevive con su `CMakeCache.txt`. Y
`pkg_check_modules` cachea su resultado: en la segunda corrida no vuelve a preguntar a pkg-config y
**no recrea el target importado**, de modo que `PkgConfig::Cairo` sigue ausente aunque el `.pc` ya
resuelva. El cache incluso muestra `pkgcfg_lib_Cairo_cairo:FILEPATH=/usr/lib/libcairo.a` — las libs
resueltas y el target igual sin crear.

⇒ `rm -rf build` antes de configurar. No es higiene: es corrección. **Una receta tiene que ser
idempotente sobre un árbol de fuentes reusado**, y ésta no lo era.

⚠ Y no es particular de fcitx5: **toda receta de este repo que haga `cmake -B build` sin limpiar
tiene el mismo defecto latente.** No se nota mientras el primer intento salga bien — se nota el día
que uno falla, y entonces el reintento miente repitiendo el error viejo. Es la figura de
«el cache-hit congela regresiones» dentro de cmake, y me costó un viaje completo: di por buena una
corrección correcta porque el síntoma no se movió.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

8a3664d6cdab3a9660d08e3ab1929ba11a1e4511 · by Sergio · (3 d ago) · parent ad9c74dd9 · browse the tree at this commit

Semantic delta

No definition changed: this change is text, documentation or data.

1 files · +14 −0

diff --git a/recipes/fcitx5.toml b/recipes/fcitx5.toml
index 93bcd0a6..e3d8d308 100644
--- a/recipes/fcitx5.toml
+++ b/recipes/fcitx5.toml
@@ -74,6 +74,20 @@ ZW="$PWD/.zwrap"; mkdir -p "$ZW"
 printf '#!/bin/sh\nexec /opt/zig/zig cc -mcpu=baseline "$@"\n'  > "$ZW/cc"
 printf '#!/bin/sh\nexec /opt/zig/zig c++ -mcpu=baseline "$@"\n' > "$ZW/cxx"
 chmod +x "$ZW/cc" "$ZW/cxx"
+# ⚠ **BORRAR `build/` ANTES DE CONFIGURAR, Y NO ES HIGIENE: ES CORRECCIÓN.** El árbol de fuentes
+# (`work/sources/<receta>-<sha>`) se REUSA entre builds — es caché por diseño—, así que un `build/`
+# de un intento anterior sobrevive con su `CMakeCache.txt`. Y `pkg_check_modules` cachea su
+# resultado: en la segunda corrida no vuelve a preguntar a pkg-config y **no recrea el target
+# importado**, así que `PkgConfig::Cairo` sigue ausente aunque el `.pc` ya resuelva.
+#
+# Medido el 2026-10-19 y cuesta un viaje entero: tras arreglar las deps que faltaban de verdad, el
+# build volvió a morir con EL MISMO error en **2 segundos** —«Generating done (0.0s)»— reusando el
+# cache del fallo anterior. Un primer fallo envenena todos los reintentos y el mensaje no lo dice:
+# es la figura de [[cache-congela-regresiones]] dentro de cmake.
+#
+# ⚠ Y esto NO es particular de fcitx5: toda receta de este repo que haga `cmake -B build` sin
+# limpiar tiene el mismo defecto latente. No se nota mientras el primer intento salga bien.
+rm -rf build
 cmake -B build -G Ninja -Wno-dev \
   -DCMAKE_C_COMPILER="$ZW/cc" -DCMAKE_CXX_COMPILER="$ZW/cxx" -DCMAKE_ASM_COMPILER="$ZW/cc" \
   -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/usr \