From fad71087d8b59276681d23952a242a7b0d126a69 Mon Sep 17 00:00:00 2001 From: Sergio Date: Sat, 12 Sep 2026 19:22:52 +0000 Subject: [PATCH] =?UTF-8?q?receta:=20btop=20=E2=80=94=20monitor=20de=20rec?= =?UTF-8?q?ursos=20en=20TUI,=20sellado?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit btop b3:d1e3d3111d306e158f2269ba3ecb4852d7d095f688e707db54381dbb3b26e34f Dos cosas que valían el viaje: - `configure = 'true'` NO es relleno. btop 1.4.x trae CMakeLists.txt *y* Makefile; el autodetector del lab ve el primero y generaba `cmake -S . -B _build`, que muere con `cmake: not found` (cmake es una receta del corpus, no una herramienta del lab). Apagar la fase de configure es lo que elige la vía soportada por upstream. - C++20 (, ) compila y ENLAZA ESTÁTICO con la libc++ de zig, sin gueto gcc. Se puede porque btop no enlaza ninguna librería C++ del corpus: todo su C++ es suyo. El binario sale con -D_LIBCPP_HARDENING_MODE, o sea libc++ de verdad y no libstdc++. --- recipes/btop.toml | 35 +++++++++++++++++++++++++++++++++++ 1 file changed, 35 insertions(+) create mode 100644 recipes/btop.toml diff --git a/recipes/btop.toml b/recipes/btop.toml new file mode 100644 index 00000000..879a4981 --- /dev/null +++ b/recipes/btop.toml @@ -0,0 +1,35 @@ +# btop 1.4.7 — monitor de recursos en TUI (CPU/mem/disco/red/procesos). C++20, Makefile. +# +# ── POR QUÉ ENTRA SI YA ESTÁ `bottom` ────────────────────────────────────────────────────────── +# No se solapan del todo: `bottom` (Rust) es el monitor de la cola CLI y btop es el que la gente +# busca por nombre. Pesa un binario y cero deps de runtime — el corpus ya tiene `ncurses`, pero +# btop NO la usa: dibuja con secuencias ANSI propias. +# +# ── C++20 CON LA libc++ DE ZIG, Y POR QUÉ ESO NO ES GRATIS ──────────────────────────────────── +# btop es C++20 (``, ``) y upstream compila con g++. Acá el compilador es zig-cc, +# que trae **libc++** (`std::__1::`), no la libstdc++ de GNU — ver [[cxx-runtime-debe-coincidir]]. +# Eso es seguro porque btop NO enlaza ninguna librería C++ del corpus: todo su C++ es suyo. Si +# algún día pidiera una, habría que decidir el runtime primero y la receta después. +name = "btop" +version = "1.4.7" +license = "Apache-2.0" + +[source] +repo = "https://github.com/aristocratos/btop" +commit = "6e39144aaf5a6bc01b9f795010b0914431067183" + +[build] +compiler = "zig-cc" +target = "x86_64-linux-musl" +link = "static" + +[build.phases] +# ⚠ `configure = "true"` NO ES RELLENO. btop 1.4.x trae CMakeLists.txt **y** Makefile, y el +# autodetector del lab ve el primero ⇒ generaba un `cmake -S . -B _build` que muere con +# `cmake: not found` (cmake es una receta del corpus, no una herramienta del lab). La vía +# soportada por upstream es el Makefile; apagar la fase de configure es lo que la elige. +configure = 'true' +# STATIC=true es la perilla de upstream para el binario estático; el `LDFLAGS=-static` del lab no +# alcanza porque el Makefile arma su propia línea de enlace. +compile = 'make STATIC=true VERBOSE=true' +install = 'make install DESTDIR=/out PREFIX=/usr'