fix(boost): no se usa `bootstrap.sh`, y el motivo está en su línea 229
Dos intentos fallaron adivinando cómo pasarle el compilador a bootstrap: primero
`--with-toolset=cc` («Toolset 'cc' does not appear to support C++11»), después `--cxx=`
(«unrecognized option»). **Dejé de adivinar y leí el guion**, que es lo que debí hacer al segundo
fallo:
bootstrap.sh:229 CXX= CXXFLAGS= "$my_dir/tools/build/src/engine/build.sh" ${TOOLSET}
**bootstrap LIMPIA `CXX` y `CXXFLAGS`** antes de llamar al motor — por eso exportarlas no servía de
nada. Y no acepta `--cxx`: sus opciones son `--with-toolset`, `--with-libraries`, `--prefix`… leídas
de su propio parser, no supuestas. El que SÍ acepta `--cxx` es el guion del motor
(`build.sh:272`), y bootstrap no le reenvía argumentos extra.
⇒ Se llama al motor directamente, que es lo único que bootstrap envuelve.
Y la segunda mitad, igual de medida: **el toolset de la BIBLIOTECA no es `cxx`.** `cxx` existe sólo
para compilar el motor b2 (`build.sh:416`). Para la biblioteca, b2 trae `clang.jam` y
`clang-linux.jam` — y **zig c++ ES clang**, así que `using clang : : <envoltorio>` es un MAPEO
correcto. Mi primer intento escribió `using gcc` apuntando al mismo envoltorio: eso sí era
inventarle un toolset, y lo quité antes de que llegara a construir.
El `using clang` lleva además `<archiver>` y `<ranlib>` apuntando a `zig ar`/`zig ranlib`: sin eso
b2 invoca los del PATH, que en este lab no son los de la cadena — es el mismo defecto que
`cargo-recipe-ar-wrapper` documenta para Rust.
**Tres intentos, tres adivinanzas evitables.** Las dos primeras salieron de suponer nombres de
opciones; la tercera, de leer el fichero. El patrón del día se repite: la respuesta estaba a unas
líneas del mensaje de error, o dentro del guion que estaba invocando.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Semántico sayk'uy
Mana ima sutichaypas t'ikrakurqanchu: qillqalla, yachachiylla utaq willaylla t'ikrakurqan.
1 qillqakuna · +22 −13
- recipes/incoming-kde/boost.toml +22 −13
diff --git a/recipes/incoming-kde/boost.toml b/recipes/incoming-kde/boost.toml
index f097ffe9..2478ae04 100644
--- a/recipes/incoming-kde/boost.toml
+++ b/recipes/incoming-kde/boost.toml
@@ -15,27 +15,36 @@ target = "x86_64-linux-musl"
link = "dynamic"
[build.phases]
-# `bootstrap.sh` compila `b2` (el motor de build de boost) con el compilador del sandbox.
+# ⚠ **NO SE USA `bootstrap.sh`, Y EL MOTIVO ESTÁ EN SU LÍNEA 229.** Dos intentos fallaron adivinando
+# cómo pasarle el compilador, y la respuesta estaba en leer el guion:
#
-# ⚠ **EL TOOLSET ES `cxx`, Y LO ADIVINÉ MAL LA PRIMERA VEZ.** Puse `--with-toolset=cc` y bootstrap
-# cortó con «Toolset 'cc' does not appear to support C++11» — `cc` no es uno de sus nombres. Su
-# propia ayuda lo dice: «A special toolset; cxx, is available which is used as a fallback when a
-# more specific toolset is not found… The 'cxx' toolset will use the '--cxx' and '--cxxflags'
-# options». O sea que el camino para un compilador que no es gcc/clang por nombre es ése, y se le
-# pasa el ejecutable por `--cxx`, no por la variable `CXX`.
+# CXX= CXXFLAGS= "$my_dir/tools/build/src/engine/build.sh" ${TOOLSET}
#
-# Y NO se reescribe `project-config.jam`: mi primera versión lo pisaba con un `using gcc : : …`
-# apuntando al envoltorio de zig, que es inventar. Bootstrap lo escribe con el toolset `cxx` y el
-# compilador que se le dio, y eso es lo que b2 tiene que usar también para la biblioteca.
+# bootstrap **LIMPIA `CXX` y `CXXFLAGS`** antes de llamar al motor, así que exportarlas no sirve; y
+# no acepta `--cxx` (sus opciones son `--with-toolset`, `--with-libraries`, `--prefix`… — leídas de
+# su propio `--help`, no supuestas). El que sí acepta `--cxx` es el guion del MOTOR (`build.sh:272`),
+# y bootstrap no le reenvía argumentos extra. ⇒ se llama al motor directamente, que es lo que
+# bootstrap envuelve.
+#
+# ⚠ Y el toolset de la BIBLIOTECA no es `cxx`: `cxx` existe sólo para compilar el motor b2
+# (`build.sh:416`). Para la biblioteca, b2 trae `clang.jam`/`clang-linux.jam`, y **zig c++ ES
+# clang** — así que `using clang : : <envoltorio>` es un MAPEO, no una invención. Mi primer intento
+# escribió `using gcc` apuntando al mismo envoltorio, que era inventarle un toolset.
configure = '''
set -e
printf '#!/bin/sh\nexec /opt/zig/zig c++ -mcpu=baseline "$@"\n' > .zcxx; chmod +x .zcxx
-./bootstrap.sh --with-toolset=cxx --cxx="$PWD/.zcxx" --with-libraries=iostreams --prefix=/usr
+printf '#!/bin/sh\nexec /opt/zig/zig ar "$@"\n' > .zar; chmod +x .zar
+printf '#!/bin/sh\nexec /opt/zig/zig ranlib "$@"\n' > .zranlib; chmod +x .zranlib
+./tools/build/src/engine/build.sh --cxx="$PWD/.zcxx" cxx
+[ -x ./tools/build/src/engine/b2 ] || { echo "boost: el motor b2 no se construyó" >&2; exit 1; }
+# El `using clang` lleva también archivador e indexador: sin ellos b2 invoca `ar`/`ranlib` del PATH,
+# que en este lab no son los de la cadena.
+printf 'using clang : : %s/.zcxx : <archiver>%s/.zar <ranlib>%s/.zranlib ;\n' "$PWD" "$PWD" "$PWD" > project-config.jam
'''
compile = '''
set -e
-./b2 -j"$(nproc)" toolset=cxx --with-iostreams link=static runtime-link=static \
- -sNO_BZIP2=1 -sNO_LZMA=1 -sNO_ZSTD=1 --prefix=/usr stage
+./tools/build/src/engine/b2 -j"$(nproc)" toolset=clang --with-iostreams \
+ link=static runtime-link=static -sNO_BZIP2=1 -sNO_LZMA=1 -sNO_ZSTD=1 --prefix=/usr stage
'''
install = '''
set -e