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 1389Shell 137Markdown 80Rust 802602 Definiciones

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>

f9e42c846b2260232ff3f9be13396d120f60f18b · por Sergio · (hace 2 d) · padre 69ae9e346 · ver el árbol en este commit

Delta semántico

Ninguna definición cambió: el cambio es de texto, documentación o datos.

1 archivos · +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