# OpenCC 1.4.2 — conversión entre chino SIMPLIFICADO y TRADICIONAL.
#
# ══ POR QUÉ ENTRA ══════════════════════════════════════════════════════════════════════════════
# Es la dep de `chttrans`, el addon de `fcitx5-chinese-addons` que convierte al vuelo lo que
# escribís. Sin él, `ENABLE_OPENCC=Off` y la distro sabe escribir chino **simplificado y nada más**:
# quien escribe en Taiwán, Hong Kong o Macao teclea el mismo pinyin y obtiene los caracteres
# equivocados. No es un adorno regional — es la mitad de los usuarios de chino escrito.
#
# ⚠ Y no es «un idioma más con otra fuente»: la conversión no es carácter a carácter. Hay
# correspondencias de uno a varios que dependen del SENTIDO de la palabra (el clásico 发 → 髮 pelo o
# 發 emitir), y por eso OpenCC lleva diccionarios de frases y no una tabla. Eso es lo que se compila
# en su fase `data`.
#
# ══ ES AUTOCONTENIDO, Y ESO SE COMPROBÓ ANTES DE ESCRIBIR LA RECETA ════════════════════════════
# OpenCC vendoriza TODAS sus deps dentro del árbol, con contenido real y sin un solo submódulo
# (medido sobre el tarball: `darts-clone` 4 ficheros, `marisa` 111, `rapidjson` 39, `tclap` 29; cero
# directorios vacíos; cero `FetchContent`/`file(DOWNLOAD)`). Sus perillas `USE_SYSTEM_*` vienen
# todas en `OFF`, así que por defecto usa lo vendorizado.
#
# ⇒ **Cero deps nuevas en el corpus.** Eso es lo que hace que valga la pena: el tradicional sale por
# una sola receta. Lo contrario de `librsvg`, que arrastraba la pila de introspección de GNOME.
#
# `BUILD_SHARED_LIBS=ON`: `chttrans` es un addon `.so` que el daemon abre con `dlopen`, y enlazarlo
# contra una `libopencc.a` no-PIC es el muro del 19-oct. Con `ON`, `marisa` y compañía se compilan
# PIC como objetos de la compartida.
#
# `ENABLE_GTEST=OFF` / `ENABLE_BENCHMARK=OFF`: los dos están ya en `OFF` por defecto, pero se pasan
# explícitos porque los árboles vendorizados de googletest y google-benchmark SÍ están presentes —
# o sea que un cambio de default los construiría de verdad, y serían minutos de compilación que no
# van a ninguna parte.
name    = "opencc"
version = "1.4.2"
license = "Apache-2.0"

[source]
tarball = "https://github.com/BYVoid/OpenCC/archive/refs/tags/ver.1.4.2/opencc-1.4.2.tar.gz"
sha256  = "8e5f5cf7fe195bd9b9be851adc9738c1ef7dc5c24441dd5878a56db4087a9a70"

[build]
compiler = "zig-cc"
target   = "x86_64-linux-musl"
link     = "dynamic"
flags    = []

[build.phases]
configure = '''
ZW="$PWD/.zwrap"; mkdir -p "$ZW"
# Envoltorio que reescribe `--target`: patrón canónico del repo para builds que inventan su triple.
printf '%s\n' '#!/bin/sh' 'for a do' 'case "$a" in --target=*) a=--target=x86_64-linux-musl ;; esac' 'set -- "$@" "$a"' 'shift' 'done' 'exec /opt/zig/zig cc -mcpu=baseline "$@"' > "$ZW/cc"
printf '%s\n' '#!/bin/sh' 'for a do' 'case "$a" in --target=*) a=--target=x86_64-linux-musl ;; esac' 'set -- "$@" "$a"' 'shift' 'done' 'exec /opt/zig/zig c++ -mcpu=baseline "$@"' > "$ZW/cxx"
chmod +x "$ZW/cc" "$ZW/cxx"
# `rm -rf build`: un `build/` fallido sobrevive en el árbol de fuentes reutilizado y el caché de
# cmake hace que el reintento repita el error viejo en dos segundos. Deuda latente de TODAS las
# recetas cmake del repo; acá se paga.
rm -rf build
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 \
  -DCMAKE_INSTALL_LIBDIR=lib \
  -DBUILD_SHARED_LIBS=ON -DOPENCC_ENABLE_INSTALL=ON \
  -DENABLE_GTEST=OFF -DENABLE_BENCHMARK=OFF \
  -DBUILD_DOCUMENTATION=OFF -DBUILD_PYTHON=OFF
'''
compile = "cmake --build build"
# Guardián: la `.so`, el `.pc` que busca el consumidor, y los DICCIONARIOS. El tercero es el que
# importa de verdad: `find_package(OpenCC 1.0.1 REQUIRED)` pasa con la biblioteca sola, y una
# OpenCC sin sus `.ocd2` **carga y no convierte nada** — simplificado entraría y simplificado
# saldría, sin error. Es la figura del artefacto que promete una función y no la tiene.
install = '''
set -e
DESTDIR=/out cmake --install build
so=$(find /out/usr/lib -name 'libopencc.so*' -type f 2>/dev/null | head -1)
[ -n "$so" ] || { echo "opencc: no quedó libopencc.so — chttrans es un .so y necesita la compartida" >&2; find /out -name 'libopencc*' >&2; exit 1; }
pc=$(find /out/usr/lib -name 'opencc.pc' 2>/dev/null | head -1)
[ -n "$pc" ] || echo "opencc: aviso — no hay opencc.pc; el consumidor usa find_package, así que no es fatal" >&2
d=$(find /out/usr/share/opencc -name '*.ocd2' 2>/dev/null | wc -l)
[ "$d" -gt 5 ] || { echo "opencc: sólo $d diccionario(s) .ocd2 — esperaba más de 5; sin ellos convierte la identidad en silencio" >&2; find /out/usr/share -maxdepth 3 2>/dev/null | head -20 >&2; exit 1; }
c=$(find /out/usr/share/opencc -name '*.json' 2>/dev/null | wc -l)
[ "$c" -gt 0 ] || { echo "opencc: no hay ninguna configuración .json (s2t, t2s…) — la API se nombra por config, no por diccionario" >&2; exit 1; }
echo "opencc: $(basename "$so") + $d diccionario(s) + $c configuración(es)"
'''

[deps]
# ⚠ `python3`: su CMakeLists hace `find_package(Python3 … Interpreter)` y el build murió con
# «Could NOT find Python3 (missing: Python3_EXECUTABLE Interpreter)». No lo había declarado porque
# `BUILD_PYTHON=OFF` me hizo pensar que python no entraba — y esa perilla sólo apaga los *bindings*;
# el intérprete lo usa igual para generar datos. Misma figura que `meson exige python3`: **una
# perilla que dice «sin python» no significa que el build no lo invoque.**
build = ["cmake", "samurai", "pkgconf", "python3"]