sergio/takana

`bootstrap.sh` cortó con «Toolset 'cc' does not appear to support C++11». Puse `--with-toolset=cc`
suponiendo el nombre; `cc` no es uno de los suyos. Su propia ayuda lo dice cuatro líneas más abajo
en el mismo log:

    A special toolset; cxx, is available which is used as a fallback when a more specific
    toolset is not found and the cxx command is detected. The 'cxx' toolset will use the
    '--cxx' and '--cxxflags' options, if present.

⇒ `--with-toolset=cxx --cxx="$PWD/.zcxx"`, y el ejecutable va por `--cxx`, no por la variable `CXX`
que yo exportaba. Lo mismo en `b2` con `toolset=cxx`, para que la biblioteca se compile con el
mismo compilador que el motor.

Y **quito mi reescritura de `project-config.jam`**: la primera versión lo pisaba con un
`using gcc : : <envoltorio de zig>`, que es inventar un toolset que b2 no pidió. Bootstrap lo
escribe él con el toolset `cxx` y el compilador que se le dio — dejarlo es menos código y más
correcto. Es la misma figura que el `.pc` de `libhangul`: usar lo que upstream genera en vez de
fabricarlo de memoria.

El error estaba COMPLETO en el log del primer intento y no hizo falta nada más que leerlo hasta el
final — la ayuda del propio bootstrap nombraba el toolset correcto. Van dos veces hoy que la
respuesta estaba unas líneas por debajo del mensaje que miré.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

diff --git a/recipes/incoming-kde/boost.toml b/recipes/incoming-kde/boost.toml
index d94b47f2..f097ffe9 100644
--- a/recipes/incoming-kde/boost.toml
+++ b/recipes/incoming-kde/boost.toml
@@ -15,19 +15,26 @@ target   = "x86_64-linux-musl"
 link     = "dynamic"
 
 [build.phases]
-# `bootstrap.sh` compila `b2` (el motor de build de boost) con el compilador del sandbox. Se le pasa
-# el toolset explícito porque sin eso busca `g++`, que en este lab no existe.
+# `bootstrap.sh` compila `b2` (el motor de build de boost) con el compilador del sandbox.
+#
+# ⚠ **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`.
+#
+# 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.
 configure = '''
 set -e
 printf '#!/bin/sh\nexec /opt/zig/zig c++ -mcpu=baseline "$@"\n' > .zcxx; chmod +x .zcxx
-CXX="$PWD/.zcxx" ./bootstrap.sh --with-toolset=cc --with-libraries=iostreams --prefix=/usr
-# `project-config.jam` lo escribe bootstrap con el compilador que detectó; se reescribe la línea del
-# toolset para que b2 use el envoltorio de zig y no lo que haya encontrado en el PATH.
-printf 'using gcc : : %s/.zcxx ;\n' "$PWD" > project-config.jam
+./bootstrap.sh --with-toolset=cxx --cxx="$PWD/.zcxx" --with-libraries=iostreams --prefix=/usr
 '''
 compile = '''
 set -e
-./b2 -j"$(nproc)" --with-iostreams link=static runtime-link=static \
+./b2 -j"$(nproc)" toolset=cxx --with-iostreams link=static runtime-link=static \
   -sNO_BZIP2=1 -sNO_LZMA=1 -sNO_ZSTD=1 --prefix=/usr stage
 '''
 install = '''