9.3 Forjado

Esta traducción fue asistida por IA y revisada superficialmente. Si encuentras errores o algo no suena natural, escríbeme — lo agradezco.

El artefacto ha pasado la puerta. Los tests pasan, el puerto se prueba a sí mismo, el libro de cuentas se mantiene, la puerta se cierra limpiamente. Todo esto - en el taller, con una build de depuración: sin optimizaciones, con los nombres de función y números de línea que necesita el depurador y el usuario no. El taller no es el mundo. Lo que sale a él se ensambla con otras reglas.

Lo que necesitas

cargo build es una build de depuración. El compilador tiene prisa: sin optimizaciones, todo se conserva. El binario tq en target/debug/ pesa 21 megabytes. Dentro - los nombres de cada función, números de línea de fuente, datos para el depurador. El usuario no necesita nada de eso.

cargo build --release activa un perfil distinto. El compilador deja de tener prisa: aplica optimizaciones, elimina código muerto. El perfil puede configurarse en el Cargo.toml raíz

• ahí es donde defines qué significa “release” para este proyecto. Dos ajustes tienen el mayor efecto.

lto = true - optimización en tiempo de enlazado. Normalmente cada crate se compila por separado; el enlazador une los archivos objeto después. Con lto = true, el compilador ve el grafo completo del programa en el momento del enlazado: elimina funciones que nadie llama, inlinea funciones pequeñas, elimina ramas que nunca se ejecutan. El binario es más pequeño y se ejecuta más rápido.

strip = true - descarta los símbolos de depuración del binario final. Nombres de función, rutas de fuente, números de línea - nada de eso lo necesita el usuario.

La construcción

Añade una sección al Cargo.toml raíz después de [workspace]:

[profile.release]
lto = true
strip = true

En el Makefile, añade un objetivo en la sección BUILD, antes de clean:

## release: build optimized stripped binaries
.PHONY: release
release:
	@cargo build --release -p tq-cli -p tq-api
	@ls -lh target/release/tq target/release/tq-api

El resultado

$ make release
    Finished `release` profile [optimized] target(s) in 53.72s
-rwxrwxr-x 1 user user 1.1M target/release/tq
-rwxrwxr-x 1 user user 1.7M target/release/tq-api

target/debug/tq pesaba 21 megabytes. target/release/tq - 1,1. Veinte veces más pequeño. El binario de depuración es un borrador con anotaciones al margen. Lo que sale del taller es la pieza terminada.

El artefacto terminado se ejecuta sin Rust:

$ ./target/release/tq list
$ ./target/release/tq-api

tasks.json persiste entre ejecuciones - los datos de capítulos anteriores siguen ahí.

make ci verifica la corrección. make release construye lo que se envía.

El código completo de tq para este capítulo está en 9-shippable/03-forged/.

Lore: Lo que contiene la build de depuración

En una build de depuración el binario contiene una sección .debug_info - datos en formato DWARF. Contiene nombres de variables y funciones, rutas de archivos fuente, números de línea, tipos. El depurador (gdb, lldb) lee esta sección para mostrar “te has detenido en la línea 42 de store.rs” en lugar de “te has detenido en la dirección 0x4a3f12”. strip = true elimina esta sección; el comportamiento del programa no cambia.

Puedes eliminar solo una parte: strip = "debuginfo" elimina los datos de depuración pero conserva los nombres de símbolo - útil si necesitas perfilar una build de release.

[profile.release] acepta muchos ajustes: opt-level, codegen-units, panic, overflow-checks y otros. La combinación correcta depende de la tarea - un sistema embebido, una aplicación de servidor y una CLI requieren compromisos distintos. La lista completa con explicaciones está en la documentación de Cargo.