sergio/takana

1# boost 1.86.0 — HEADERS-ONLY. kactivitymanagerd usa Boost.Container (header-only) ⇒ sólo necesita
2# Boost_INCLUDE_DIR. No compilamos las libs de boost (b2): copiamos el árbol `boost/` a /usr/include.
3#
4# ⚠ **UN CONSUMIDOR EN MODO CONFIG TIENE QUE DECLARAR LA VARIANTE — leer esto antes de pelearse.**
5# Esta receta construye con `runtime-link=static`, y el paquete cmake que genera `b2` **etiqueta**
6# esa variante. Un `find_package(Boost … CONFIG)` la encuentra y la RECHAZA si el consumidor no
7# afirma que la quiere:
8#
9#     Found package configuration file:
10#       /usr/lib/cmake/boost_iostreams-1.86.0/boost_iostreams-config.cmake
11#     but it set boost_iostreams_FOUND to FALSE … No suitable build variant has been found.
12#     The following variants have been tried and rejected:
13#     * libboost_iostreams.a (static runtime, Boost_USE_STATIC_RUNTIME not ON)
14#
15# ⇒ el consumidor pasa `-DBoost_USE_STATIC_RUNTIME=ON -DBoost_USE_STATIC_LIBS=ON`. Las dos cosas son
16# CIERTAS de este artefacto, no un truco para callar al config: acá sólo se publica la `.a` y se
17# enlaza el runtime estáticamente. El error de arriba es la fuente autorizada de qué pedir.
18#
19# **Y no se arregla del lado de boost**: pasarlo a `runtime-link=shared` cambiaría el artefacto
20# compartido y con él a `kactivitymanagerd`, que hoy anda porque lo busca en modo MÓDULO y a
21# `FindBoost` la variante no le importa. El dato vive en el consumidor porque es el consumidor el
22# que elige cómo enlaza.
23name    = "boost"
24version = "1.86.0"
25# licencia: LICENSE_1_0.txt en la raíz del tarball pineado: Boost Software License 1.0
26license = "BSL-1.0"
27
28[source]
29tarball = "https://archives.boost.io/release/1.86.0/source/boost_1_86_0.tar.bz2"
30sha256  = "1bed88e40401b2cb7a1f76d4bab499e352fa4d0c5f31c0dbae64e24d34d7513b"
31
32[build]
33compiler = "zig-cc"
34target   = "x86_64-linux-musl"
35link     = "dynamic"
36
37[build.phases]
38# ⚠ **NO SE USA `bootstrap.sh`, Y EL MOTIVO ESTÁ EN SU LÍNEA 229.** Dos intentos fallaron adivinando
39# cómo pasarle el compilador, y la respuesta estaba en leer el guion:
40#
41#     CXX= CXXFLAGS= "$my_dir/tools/build/src/engine/build.sh" ${TOOLSET}
42#
43# bootstrap **LIMPIA `CXX` y `CXXFLAGS`** antes de llamar al motor, así que exportarlas no sirve; y
44# no acepta `--cxx` (sus opciones son `--with-toolset`, `--with-libraries`, `--prefix`… — leídas de
45# su propio `--help`, no supuestas). El que sí acepta `--cxx` es el guion del MOTOR (`build.sh:272`),
46# y bootstrap no le reenvía argumentos extra. ⇒ se llama al motor directamente, que es lo que
47# bootstrap envuelve.
48#
49# ⚠ Y el toolset de la BIBLIOTECA no es `cxx`: `cxx` existe sólo para compilar el motor b2
50# (`build.sh:416`). Para la biblioteca, b2 trae `clang.jam`/`clang-linux.jam`, y **zig c++ ES
51# clang** — así que `using clang : : <envoltorio>` es un MAPEO, no una invención. Mi primer intento
52# escribió `using gcc` apuntando al mismo envoltorio, que era inventarle un toolset.
53configure = '''
54set -e
55# ⚠ **EL ENVOLTORIO REESCRIBE `--target`, Y ES EL PATRÓN CANÓNICO DEL REPO (30 recetas lo usan).**
56# El guion del motor de b2 le pasa `--target=x86_64-pc-linux` al compilador, y zig lo rechaza:
57#     error: unable to parse target query 'x86_64-pc-linux': UnknownOperatingSystem
58# zig quiere el triple con ABI (`x86_64-linux-musl`); `x86_64-pc-linux` no la lleva. Mi primer
59# envoltorio era un `exec zig c++ "$@"` pelado y por eso moría. La respuesta estaba en el propio
60# catálogo —`churay-metal`, `pata-*` y 27 más traen exactamente este bucle— y es la cuarta vez hoy
61# que lo que buscaba estaba a un `grep` de distancia.
62printf '%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 "$@"' > .zcxx
63chmod +x .zcxx
64printf '#!/bin/sh\nexec /opt/zig/zig ar "$@"\n' > .zar; chmod +x .zar
65printf '#!/bin/sh\nexec /opt/zig/zig ranlib "$@"\n' > .zranlib; chmod +x .zranlib
66./tools/build/src/engine/build.sh --cxx="$PWD/.zcxx" cxx
67[ -x ./tools/build/src/engine/b2 ] || { echo "boost: el motor b2 no se construyó" >&2; exit 1; }
68# El `using clang` lleva también archivador e indexador: sin ellos b2 invoca `ar`/`ranlib` del PATH,
69# que en este lab no son los de la cadena.
70printf 'using clang : : %s/.zcxx : <archiver>%s/.zar <ranlib>%s/.zranlib ;\n' "$PWD" "$PWD" "$PWD" > project-config.jam
71'''
72compile = '''
73set -e
74./tools/build/src/engine/b2 -j"$(nproc)" toolset=clang --with-iostreams \
75  link=static runtime-link=static -sNO_BZIP2=1 -sNO_LZMA=1 -sNO_ZSTD=1 --prefix=/usr stage
76'''
77install = '''
78set -e
79# ⚠ **`b2 install`, NO un `cp` a mano — y la diferencia es `BoostConfig.cmake`.**
80#
81# Esta receta copiaba las cabeceras y la `.a` con `cp` tras un `b2 stage`, y así **boost no se podía
82# encontrar en modo CONFIG**: `stage` sólo deja los binarios en `stage/lib`, no genera el paquete
83# cmake. Eso no se notó mientras el único consumidor fue `kactivitymanagerd`, que lo busca en modo
84# MÓDULO (el `FindBoost.cmake` de cmake, que trabaja por cabeceras y bibliotecas sueltas).
85#
86# `libime` lo pide así, y el `CONFIG` es EXPLÍCITO:
87#
88#     find_package(Boost 1.61 CONFIG REQUIRED COMPONENTS iostreams)    ← CMakeLists:45
89#
90# Con `CONFIG`, cmake **no usa `FindBoost` nunca**: exige un `BoostConfig.cmake`. El fallo era
91#
92#     Could not find a package configuration file provided by "Boost"
93#       (requested) BoostConfig.cmake / boost-config.cmake
94#
95# ⇒ `b2 install` sí lo genera (lo hace `tools/boost_install` desde boost 1.70). **No se asume: el
96# guardián de abajo lo exige**, porque si upstream lo cambiara el artefacto se sellaría igual y el
97# fallo saldría dentro de libime, culpando a libime de algo que es de acá.
98#
99# `--prefix=/out/usr` en vez de `DESTDIR`: b2 **no honra `DESTDIR`** (es su propio sistema de build,
100# no make). Los configs que genera calculan sus rutas relativas a sí mismos, así que son
101# reubicables y no se quedan con `/out` pegado.
102./tools/build/src/engine/b2 -j"$(nproc)" toolset=clang --with-iostreams \
103  link=static runtime-link=static -sNO_BZIP2=1 -sNO_LZMA=1 -sNO_ZSTD=1 --prefix=/out/usr install
104
105n=0
106for f in /out/usr/lib/libboost_iostreams*.a; do [ -f "$f" ] && n=$((n+1)); done
107if [ "$n" -eq 0 ]; then
108  echo "boost: b2 no instaló libboost_iostreams*.a — esta receta existe para eso, NO sello" >&2
109  ls -R /out/usr/lib 2>/dev/null | head -20 >&2
110  exit 1
111fi
112[ -f /out/usr/include/boost/version.hpp ] || { echo "boost: faltan las cabeceras (include/boost/version.hpp)" >&2; exit 1; }
113# El guardián nuevo, y el motivo de este cambio: el paquete cmake.
114cfg=$(find /out/usr/lib/cmake -name 'BoostConfig.cmake' 2>/dev/null | head -1)
115[ -n "$cfg" ] || { echo "boost: no quedó ningún BoostConfig.cmake — un consumidor con find_package(Boost CONFIG) no lo encontraría (es lo que pide libime)" >&2; find /out/usr/lib -maxdepth 2 -type d 2>/dev/null | head -20 >&2; exit 1; }
116# Y el componente: el config puede existir sin que `COMPONENTS iostreams` resuelva.
117comp=$(find /out/usr/lib/cmake -name 'boost_iostreams-config.cmake' 2>/dev/null | head -1)
118[ -n "$comp" ] || { echo "boost: hay BoostConfig.cmake pero no boost_iostreams-config.cmake — find_package(... COMPONENTS iostreams) fallaría" >&2; ls -R /out/usr/lib/cmake 2>/dev/null | head -30 >&2; exit 1; }
119echo "boost: cabeceras + $n lib(s) de iostreams + $(basename "$(dirname "$cfg")")/BoostConfig.cmake"
120'''
121
122[deps]
123# `zlib` por el filtro gzip de iostreams, que es el único que se deja encendido.
124build = ["zlib"]