Este artículo examina qué debe ofrecer un sistema de compilación y expone el enfoque del proyecto civ, una herramienta escrita en alrededor de mil líneas de código que invoca un proceso de Lua en sandbox para interpretar configuraciones. El autor parte de una idea central: un sistema de compilación es un programa que toma como entradas código fuente, binarios y configuración, y produce archivos, binarios y configuración siguiendo una estructura de carpetas concreta para una plataforma destino. De ahí deriva dos principios rectores. Primero, todas las entradas y salidas de cada fase de la compilación deben ser explícitas en algún lugar, crítica que dirige contra Make por ser esencialmente una colección de scripts de shell con sintaxis oscura y dependiente de plataforma. Segundo, las entradas y salidas deben poder configurarse de forma programática para adaptarse a distintos sistemas destino, rasgo que equipara con Bazel, aunque señala que este último es un monolito complejo que optó por bifurcar Python como lenguaje de configuración.
La propuesta de civ resuelve esto con un concentrador llamado "sys hub": una biblioteca de compilación con una API mínima y bien definida cuyos internals pueden intercambiarse según la plataforma. Mediante archivos .luk, fragmentos de Lua en sandbox, el usuario declara sus dependencias y el sistema las traduce en llamadas a scripts concretos, como sys/cc/build.lua. Sobre esa base, el artículo plantea la creación de un "hubrepo", un repositorio de control de versiones que actúa como capa adicional y convierte a civ en un gestor de paquetes: cuando una dependencia no está en la configuración local, se busca en el hubrepo y, si es remota, se descarga. El proyecto bloquea versiones concretas mediante un archivo .civ.lockfile y las contribuciones se gestionan con parches revisados y fusionados automáticamente por un bot, siempre que pasen las pruebas y un formato de código.