sergio/takana

El modelo de lenguaje de libime no es código propio: es un kenlm recortado que
entra por submódulo (src/libime/core/kenlm ← kpu/kenlm). Un archive de GitHub no
materializa submódulos, así que el árbol llegaba con ese directorio vacío:

    CMake Error at src/libime/core/CMakeLists.txt:12 (add_library):
      No SOURCES given to target: kenlm
    CMake Error at tools/CMakeLists.txt:1 (add_executable):
      No SOURCES given to target: libime_slm_build_binary

La biblioteca Y las herramientas de datos, las dos por el mismo hueco.

takana sí materializa submódulos, pero sólo con repo+commit: lee .gitmodules y
los SHA de gitlink y archiva cada uno en su subruta
(fetch::materializar_submodulos). Con tarball no hay nada que leer, porque el
que los pierde no es el clon sino `git archive` — una entrada gitlink no emite
nada al tar, por diseño.

Misma trampa que yoga en fcitx5, resuelta del otro lado a propósito: allá el
submódulo es de un tercero con su propio release ⇒ receta aparte con su tarball
pineado; acá kenlm se compila DENTRO de libime (el add_library(kenlm) es de
libime) ⇒ no hay receta que sacar, hay que traer el árbol completo. El criterio
es de quién es el código, no la forma del submódulo.

⚠ Y yo tenía el dato y lo leí mal: midiendo el pico de RAM corrí
`ls …/core/kenlm/lm/*.cc | wc -l`, salió 0, y lo leí como «me equivoqué de ruta»
en vez de «está vacío porque es un gitlink». El cero era la respuesta correcta a
la pregunta que no me hice; costó una vuelta entera de la cadena.

Y en los dos consumidores de boost, la variante declarada: el paquete cmake que
genera b2 etiqueta `runtime-link=static` y la RECHAZA si el consumidor no la
pide —

    * libboost_iostreams.a (static runtime, Boost_USE_STATIC_RUNTIME not ON)

— así que entra -DBoost_USE_STATIC_LIBS=ON -DBoost_USE_STATIC_RUNTIME=ON. Las
dos afirmaciones son CIERTAS de ese artefacto. No se arregla del lado de boost
porque eso volvería a tocar un artefacto compartido.

Verificado: libime sella con 9 bibliotecas y las 4 herramientas de datos.

diff --git a/recipes/fcitx5-chinese-addons.toml b/recipes/fcitx5-chinese-addons.toml
index b957f93b..866a2575 100644
--- a/recipes/fcitx5-chinese-addons.toml
+++ b/recipes/fcitx5-chinese-addons.toml
@@ -116,6 +116,7 @@ cmake -B build -G Ninja -Wno-dev \
   -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/usr \
   -DCMAKE_INSTALL_LIBDIR=lib \
   -DPKG_CONFIG_ARGN=--static \
+  -DBoost_USE_STATIC_LIBS=ON -DBoost_USE_STATIC_RUNTIME=ON \
   -DENABLE_OPENCC=On -DENABLE_DATA=On -DENABLE_TOOLS=On \
   -DENABLE_GUI=Off -DENABLE_BROWSER=Off -DENABLE_CLOUDPINYIN=Off \
   -DENABLE_TEST=Off
diff --git a/recipes/libime.toml b/recipes/libime.toml
index 37fdfd10..0afd3033 100644
--- a/recipes/libime.toml
+++ b/recipes/libime.toml
@@ -44,9 +44,37 @@ name    = "libime"
 version = "1.1.17"
 license = "LGPL-2.1-or-later"
 
+# ⚠ **FUENTE GIT Y NO TARBALL, Y ES OBLIGATORIO: `kenlm` ES UN SUBMÓDULO.**
+# El modelo de lenguaje de libime no es código propio — es un kenlm recortado que entra por
+# submódulo (`.gitmodules`: `src/libime/core/kenlm` ← `https://github.com/kpu/kenlm.git`). Un
+# archive de GitHub **no materializa submódulos**, así que con el tarball el árbol llegaba con ese
+# directorio VACÍO y cmake cortaba así:
+#
+#     CMake Error at src/libime/core/CMakeLists.txt:12 (add_library):
+#       No SOURCES given to target: kenlm
+#     CMake Error at tools/CMakeLists.txt:1 (add_executable):
+#       No SOURCES given to target: libime_slm_build_binary
+#
+# O sea: la biblioteca Y las herramientas de datos, las dos por el mismo hueco.
+#
+# ⇒ `takana` **sí** materializa submódulos, pero sólo con fuente `repo`+`commit`: lee `.gitmodules`
+# y los SHA de gitlink y archiva cada uno en su subruta (`fetch::materializar_submodulos`). Con
+# `tarball` no hay nada que leer. Es la MISMA trampa que `yoga` en fcitx5, resuelta del otro lado:
+# allá el submódulo es de un tercero con su propio release, así que se pineó su tarball en una
+# receta aparte; acá kenlm se compila DENTRO de libime (`add_library(kenlm …)` es de libime), así
+# que no hay receta que sacar — hay que traer el árbol completo.
+#
+# ⚠ **Y yo tenía el dato y lo leí mal.** Midiendo el pico de RAM de la campaña corrí
+# `ls …/libime-1.1.17/src/libime/core/kenlm/lm/*.cc | wc -l`, salió **0**, y lo interpreté como
+# «me equivoqué de ruta» en vez de «el directorio está vacío porque es un gitlink». El cero era la
+# respuesta correcta a la pregunta que no me hice. Es el defecto que este repo tiene documentado
+# como *leí hasta donde me daba la razón*, y costó una vuelta entera de la cadena.
+#
+# El commit es el del tag `1.1.17` (`git/refs/tags/1.1.17` ⇒ `50de2779…`), no una rama: la versión
+# de arriba y esto nombran lo mismo.
 [source]
-tarball = "https://github.com/fcitx/libime/archive/refs/tags/1.1.17/libime-1.1.17.tar.gz"
-sha256  = "6af056717edf99be8d4b83717de01b6404398d2fc47a301b609ca7d31331cafb"
+repo   = "https://github.com/fcitx/libime"
+commit = "50de277992132ff59a6da64c88318f2a51a08f3d"
 
 [build]
 compiler = "zig-cc"
@@ -67,6 +95,7 @@ cmake -B build -G Ninja -Wno-dev \
   -DCMAKE_C_COMPILER="$ZW/cc" -DCMAKE_CXX_COMPILER="$ZW/cxx" \
   -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/usr \
   -DPKG_CONFIG_ARGN=--static \
+  -DBoost_USE_STATIC_LIBS=ON -DBoost_USE_STATIC_RUNTIME=ON \
   -DENABLE_DATA=Off -DENABLE_TOOLS=On -DENABLE_TEST=Off -DENABLE_DOC=Off
 '''
 compile = "cmake --build build"