Cargo extendido: build.rs, install y subcomandos

Cargo parece una herramienta cerrada y en realidad es un protocolo abierto. Bajo la superficie de build y test hay tres mecanismos de extensión que multiplican lo que puede hacer sin que su núcleo crezca: los build scripts (build.rs), que ejecutan código tuyo antes de compilar; cargo install, que instala binarios de la comunidad en tu PATH; y una convención de una sola línea —cualquier ejecutable llamado cargo-algo en el PATH se invoca como cargo algo— que convierte a cualquiera en autor de un subcomando. De esa costura ha brotado un ecosistema —clippy, fmt, expand, machete, audit, nextest— que ninguna hoja de ruta central diseñó. Esta lección es sobre esa arquitectura de la extensibilidad.

build.rs: código que corre antes de compilar

Un build script es un fichero build.rs en la raíz del paquete. Cargo lo compila y lo ejecuta en tu máquina antes de compilar el crate, y se comunica con Cargo imprimiendo líneas con el prefijo cargo:: —la sintaxis de doble dos puntos de las ediciones recientes; el antiguo cargo: de un solo colon está obsoleto—.

use std::{env, fs, path::Path};

fn main() {
    // Recompila solo si cambia esta entrada, no en cada build:
    println!("cargo::rerun-if-changed=plantillas/tabla.txt");

    // Genera codigo en OUT_DIR para incluirlo desde el crate:
    let salida = env::var("OUT_DIR").unwrap();
    let destino = Path::new(&salida).join("tabla.rs");
    fs::write(&destino, "pub const N: usize = 256;").unwrap();

    // Enlaza una libreria nativa y define un cfg a medida:
    println!("cargo::rustc-link-lib=z");
    println!("cargo::rustc-cfg=tiene_zlib");
}

El código generado se incorpora con include!(concat!(env!("OUT_DIR"), "/tabla.rs")). Los usos canónicos: compilar código C con el crate cc, generar bindings de FFI con bindgen, incrustar tablas precalculadas o sondear el entorno. Las herramientas que el script necesita van en [build-dependencies], una sección aparte porque se compilan para tu máquina, no para el destino.

El caso más frecuente es compilar código C junto a tu crate, y el crate cc colapsa ese build.rs a unas líneas: detecta el compilador del sistema, aplica las banderas correctas y enlaza el resultado sin que toques un Makefile.

fn main() {
    cc::Build::new()
        .file("src/nativo.c")
        .opt_level(2)
        .compile("nativo");              // produce libnativo.a y la enlaza
    println!("cargo::rerun-if-changed=src/nativo.c");
}

cargo install y la extensibilidad por convención

cargo install compila un crate binario de crates.io y deja su ejecutable en ~/.cargo/bin, que sueles tener en el PATH. Es como se distribuyen las herramientas de línea de comandos escritas en Rust. La bandera --locked respeta el Cargo.lock que el autor publicó, garantizando una compilación reproducible en vez de resolver versiones nuevas.

cargo install ripgrep --locked      # instala el binario rg en ~/.cargo/bin
cargo install --path .              # instala el binario del crate actual
cargo install cargo-nextest --locked
cargo install --list                # que tienes instalado
cargo --list                        # que subcomandos reconoce cargo ahora mismo

Fíjate en el nombre cargo-nextest. Ahí está la regla que lo cambia todo: cualquier ejecutable llamado cargo-algo que esté en tu PATH se invoca como cargo algo. Cargo, al recibir un subcomando que no reconoce, busca un binario con ese nombre y se lo delega. No hay registro, ni permiso, ni coordinación: instalas cargo-nextest y, sin más, cargo nextest existe.

El ecosistema que emerge de la costura

Sobre esa convención ha crecido un catálogo de subcomandos que se sienten parte de Cargo aunque son proyectos independientes. clippy y rustfmt llegan como componentes de rustup; el resto se instalan con cargo install.

rustup component add clippy rustfmt
cargo clippy -- -D warnings         # lints como errores: imprescindible en CI
cargo fmt --check                   # verifica el formato sin tocar nada
cargo expand                        # muestra el codigo tras expandir las macros
cargo machete                       # dependencias declaradas y jamas usadas
cargo audit                         # vulnerabilidades conocidas via RUSTSEC
cargo semver-checks                 # comprueba que no rompes semver al publicar

Y la lista sigue: cargo deny aplica políticas de licencias y duplicados, cargo hack prueba el conjunto potencia de features, cargo flamegraph y cargo bloat diagnostican tiempo y tamaño, y cargo binstall baja binarios ya compilados en vez de recompilarlos. Todos obedecen la misma convención de nombres, y ninguno tuvo que pedir permiso al equipo de Cargo para existir.

flowchart TD
U[Escribes cargo algo] --> D[Cargo busca el subcomando]
D --> B[Integrado: build test run install]
D --> E[Externo: binario cargo-algo en el PATH]
E --> N[nextest audit machete expand semver-checks]
style D fill:#cba6f7,color:#11111b
style E fill:#f9e2af,color:#11111b