El manifiesto

Todas las claves que lee Project.toml, qué emiten en la línea de comandos y los límites que se niega a sobrepasar.

Un único Project.toml vive en la raíz del proyecto. Todos los comandos lo buscan subiendo desde el directorio actual, así que molto build funciona desde cualquier subdirectorio.

La regla sobre la que descansa el archivo entero:

Molto descubre tus fuentes; no descubre tus ajustes de build.

Cada archivo .c, .cpp y .cc bajo src/ y tests/ se compila automáticamente: nunca enumeras archivos. Los include, los defines, las librerías y la disposición de los tests son únicamente lo que diga este archivo. Nada se deduce de la estructura de directorios, y no hay vuelta atrás a un Makefile.

Las rutas relativas de include y test.sources se resuelven contra la raíz del proyecto, nunca contra el directorio desde el que lanzaste el comando. flags se pasa literalmente por contrato y nunca se reescribe.

Lo que escribe molto new

[package]
name = "my_app"
version = "0.1.0"

[target]
std = "c17"
include = ["include"]

[profile.debug]
opt_level = 0
debug_info = true

[profile.release]
opt_level = 3
debug_info = false

Eso es un proyecto completo. No hay un segundo archivo ni un paso generador.

[package]

name y version llegan a cada unidad de traducción como MOLTO_PKG_NAME y MOLTO_PKG_VERSION, así que un programa puede reportar su propia versión sin una cabecera que mantener sincronizada.

artifact se rechaza en vez de aceptarse y luego ignorarse: static y shared necesitarían ar, -shared y -fPIC, y nada de eso existe todavía.

[target]

compiler es una preferencia de fabricante, no un binario. Nombrar un fabricante en vez de una ruta es lo que mantiene portable un manifiesto: gcc es la versión 9 en una máquina y la 14 en otra. Cualquier cosa fuera de esa lista es un error.

std elige el modo; requires declara lo que tiene que funcionar de verdad. Aceptar -std=c2x no es lo mismo que implementarlo: un compilador puede tragarse el flag y aun así rechazar [[nodiscard]]. Molto le pregunta a pickup qué toolchain local demuestra cada capacidad compilando un programa que la usa, y cachea la respuesta en .bin/wsdb. --refresh-toolchain vuelve a preguntar.

Omitir std hereda el valor por defecto del compilador, que cambia según la toolchain y la versión. Decláralo.

Para un flag de enlazado que no es una librería —-Wl,... o -pthread en tiempo de compilación— usa flags, no link.

Molto elige el driver de C para .c y el de C++ para .cpp y .cc, ambos de la misma toolchain resuelta, así que un proyecto mixto nunca mezcla compiladores. Un proyecto con C++ cuya toolchain no tiene driver de C++ se reporta de entrada, no se descubre al enlazar.

[test]

per_file construye un ejecutable por archivo de tests/, cada uno enlazado contra los objetos del proyecto menos src/main.c, y cada uno con su propio main(). La salida va a build/<perfil>/tests/<nombre>.

single enlaza todo en un solo binario, en build/<perfil>/tests/<paquete>_tests. Es lo que necesita un framework que registra sus casos y es dueño de main().

Un framework que vive fuera de src/ no se compila en absoluto salvo que sources lo nombre. Esa es la causa más habitual de que un build de tests falle con los símbolos del propio framework.

[profile.*]

Existen cuatro perfiles: debug (el de por defecto), release, bench y custom. Se elige con molto build --profile release; la salida va a build/<perfil>/.

Valores por defecto cuando la tabla no está:

Cambiar cualquier ajuste de compilación provoca una recompilación: Molto registra el comando exacto de cada objeto y reconstruye cuando difiere.

[env]

[env]
MY_APP_LOG = "debug"

Las claves son nombres de variables y los valores tienen que ser cadenas. Se exportan a las invocaciones del compilador y el enlazador, y al programa bajo molto run y molto test. Las variables se establecen en el proceso hijo después del fork, así que el entorno de Molto nunca se modifica y el [env] de un proyecto no puede colarse en otro.

Límites

Sobrepasar uno es un error del manifiesto, nunca un recorte silencioso: perder un flag produciría un build en verde con opciones que no pediste.

Las claves desconocidas se descartan sin avisar

Una errata en el nombre de una clave simplemente desaparece. Si un ajuste parece no tener efecto, revisa primero cómo está escrito.

El manifiesto tolera claves desconocidas porque la RFC-0003 especifica tablas que este binario aún no implementa, y rechazarlas descartaría manifiestos que son válidos por diseño.

La excepción son [deps] y [dev-deps], que fallan en cerrado: una clave desconocida, dos orígenes o un rango de versiones es un error que nombra la dependencia. Igual hacen format.json y linter.json. Una dependencia mal leída es una dependencia que en silencio no está.

Especificado pero no implementado

Si vienes de un Makefile

Lee CFLAGS y LDFLAGS y coloca cada pieza bajo la clave que le corresponde. Frente a un Makefile que pasa -Iinclude -D_DEFAULT_SOURCE -Wall -Wextra -Wpedantic y construye sus tests como un solo binario:

[target]
std      = "c2x"
requires = ["attr_nodiscard"]
defines  = ["_DEFAULT_SOURCE"]
include  = ["include"]
flags    = ["-Wall", "-Wextra", "-Wpedantic"]

[test]
mode    = "single"
sources = ["modules/moltest/src"]
include = ["modules/moltest/include"]

Ese es el manifiesto del propio Molto, menos los perfiles: el repositorio se construye con su propia herramienta.

Resolución de problemas