Los comandos

Cada subcomando, sus opciones, el código de salida que devuelve y qué imprime en una terminal o en una tubería.

Todos los comandos encuentran tu proyecto subiendo desde el directorio actual, así que funcionan desde cualquier subdirectorio.

molto bench, molto migrate y molto update existen en la CLI y salen con 5: el comando se reconoce, el comportamiento no está implementado. update se queda así a propósito — molto add <nombre> es la actualización, igual que lo es npm install.

El parser acepta --opt valor, --opt=valor, -o valor y flags booleanos. Todo lo que va tras -- se reenvía al programa bajo molto run. --help y --version vienen de serie.

Empezar un proyecto

molto new my_app   # un directorio nuevo con manifiesto, src/, include/, tests/ y .gitignore
molto init         # lo mismo, en el directorio donde ya estás

Ninguno de los dos sobrescribe un archivo que ya exista, y ninguno inicializa git.

Construir y ejecutar

molto build                 # en build/debug/
molto build -p release      # en build/release/
molto run -- --flag valor   # construye, ejecuta y reenvía todo lo que va tras --
molto test                  # por defecto, un binario por archivo de tests/

molto run propaga literalmente el código de salida del programa, y reporta 128 + N cuando muere por la señal N. Es el único comando cuyo código de salida no es de Molto.

-j <n> limita el pool de workers; si no está, usa todos los núcleos. Se rechaza salvo que sea un número entre 1 y 1024, y nunca se registra ni entra en la huella: dos builds que sólo se diferencien en -j producen los mismos objetos.

Estructura de salida

build/ y .bin/ son de Molto y están en el gitignore. Molto.lock se genera y se commitea. molto clean borra build/; molto clean --all borra además .bin/. Ninguno toca ~/.molto.

compile_commands.json lo escribe un build, y manda el último: molto build cubre src/ más las dependencias, molto test cubre eso y tests/, y -p release deja una base de datos que describe release. fmt y lint no escriben ninguna. Se escribe incluso cuando el build falla.

Códigos de salida

Un warning de lint se reporta y aun así sale con 0. Sólo la severidad error hace fallar el comando.

Qué imprime un build

Todo va a stderr, así que molto build > log sigue mostrando el build y molto run > out captura sólo tu programa.

En una terminal dibuja un inventario, luego una región viva, y retira la región cuando el trabajo para:

 ◆ registry   sqlite3 v3.50.3
 ◇ modules    network
 ● project    62 files
 ○ cached     20 files

 ● project    services/build_service.c
 ◆ sqlite3    btree.c
 … and 5 more
 ████████░░░░░░░░  22%  47/210

Una dependencia ocupa una línea, tenga las fuentes que tenga: un paquete es una unidad de trabajo. Nada que ya esté al día se lista; se cuenta en cached, así que una reconstrucción sin cambios son tres líneas y ninguna región.

Redirige stderr —una tubería, un archivo, un job de CI— y obtienes una línea por fuente, sin región, sin barra y sin una sola secuencia de escape. Ese es el registro completo, y es lo que la CI debería guardar. NO_COLOR=1 quita el color en una terminal pero no la región, que va de movimiento. El cursor nunca se oculta, así que Ctrl-C deja la terminal como la encontró.

Una unidad que falla se reporta en un marco con la línea de código, un cursor bajo el carácter que la herramienta señaló y un pie que dice de quién era el código. El diagnóstico entero se compone y se entrega al informe en una sola llamada, así que dos workers nunca pueden entrelazarse. Un build que falla no imprime línea de Finished.

Variables de entorno

Molto imprime un aviso en stderr cuando se usa C_COMPILER, porque un compilador elegido a mano nunca se contrastó con [target].requires.

Dónde entra pickup

Molto no elige compilador. Un manifiesto declara las capacidades que necesita el código; pickup responde qué binario local las proporciona, y la respuesta se cachea en la base de datos del workspace: la pregunta se hace una vez, no en cada build.

pickup list       # todas las toolchains de esta máquina
pickup doctor     # qué impide construir aquí, y cómo arreglarlo
pickup install clang
pickup tools      # el formateador y el linter, y dónde están

Si pickup resolve reporta un runtime_dirs para una toolchain que instaló él, lo que Molto enlaza lleva el -rpath consigo, así que el binario sigue ejecutándose vaya donde vaya.

Plataforma

Sólo POSIX, y a propósito: usa fork/exec, flock y sysconf directamente, y la CI corre Ubuntu. Windows y macOS se prometieron para la 0.2, se movieron a la 0.4 y siguen aparcados hasta que el ecosistema tenga suficiente profundidad en una plataforma como para merecer portarlo a tres.