Sergio
e852f48491
Barrido de TEXTO puro: 1427 líneas de comentario TOML. Cero ArtifactHash movidos, y eso está MEDIDO, no deducido: hasheé las 741 antes y después y los ficheros de hashes son idénticos byte a byte (723 con hash real + 18 que ya no hasheaban de antes). El guardián valió la pena: el primer barrido, filtrando por 'la línea empieza con #', movió el hash de helix, lsof y steam-runtime-sniper. La causa es que una fase se escribe como compile = <triple> ... <triple> y sus comentarios de SHELL también empiezan con #, pero viven dentro del VALOR — y las fases sí entran en hash_inputs. El barrido ahora calcula los rangos de las cadenas multilínea de TOML y no entra ahí. Quedan intactos a propósito: .hammer-zig-cc y .hammer-cargo-vendor (literales dentro de fases), hammerd, hammer-recover y toda ruta que empiece por /
24 lines
927 B
TOML
24 lines
927 B
TOML
# Importada de nixpkgs por `takana import-nix` (Etapa G). PUNTO DE PARTIDA, no final:
|
|
# - el build usa el lab de takana (zig-cc / musl estático), NO el stdenv de nix ⇒ revisá
|
|
# compiler/link/phases y adaptá hasta que compile.
|
|
# - las deps van con su nombre NIX; remapealas a las recetas del corpus si difieren.
|
|
name = "xplr"
|
|
version = "1.1.0"
|
|
license = "MIT"
|
|
|
|
[source]
|
|
repo = "https://github.com/sayanarijit/xplr"
|
|
commit = "db0e781f14ba4ab0242beb36ace87b679c744d4e"
|
|
|
|
# GUETO gcc: xplr embebe mlua-sys (compila Lua en C); bajo zig-cc el link falla con símbolos de
|
|
# unwinding sueltos (_Unwind_GetCFA/_Unwind_DeleteException, de libgcc). compiler="gcc" usa el musl
|
|
# gcc de Alpine que aporta su runtime de unwinding.
|
|
[build]
|
|
compiler = "gcc"
|
|
target = "x86_64-linux-musl"
|
|
link = "static"
|
|
flags = ["--bin", "xplr"]
|
|
|
|
[build.phases]
|
|
install = "mkdir -p /out/usr/bin && cp target/release/xplr /out/usr/bin/xplr"
|