Incomplete build system
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long. 3.1KB

Most features mentioned in are currently unimplemented. One goal is to establish a checklist here.


This project aims to create a build automation tool that is language- and tooling-agnostic, somewhat portable, not too much of a hassle to use, and specialized for complex compile-time configuration.

In lieu of writing a custom description language, the build descriptor files will be written in Lua, and will call functions to manipulate data structures that the file describes. (This also provides freedom and scriptablity not found in many other build systems.)

This tool will not build projects by itself; rather, it will generate Ninja files, then invoke Ninja.


Configuration and file generation will (at least internally) be done in two separate passes.

Roughly, the workflow will be as follows: First, the project will be configured. In this step, a function in the root component’s (and its transitive component dependencies’) build file will be run which describes the predicates relating different configuration options. Configuration-time component dependencies will be dynamic (also specified via predicates), and will change as configuration options get changed.

Second, the build files will be generated from the given configuration. In this step, a different function will be run which descibes the dependency graph, which will then be converted to Ninja build files. Additionally in this step, any tools must be defined. (Tools are the actual Ninja rules for invoking tools, such as gcc.)

Third, Ninja will be used to build the project. This step is largely independent of this tool.

TODO: Decide whether component dependencies will be resolved at configure time or generation time.


The configuration dependency engine will be complicated enough to do SAT solving. As a result of this lofty goal, its implementation will be put off as the last feature to be implemented, unless sommebody gets bored.

Each configuration setting will have two intrinsic attributes: its value, and whether or not it exists. Existing is, by default, equivalent to the existence of the component. When an item does not exist, any predicate involving it is assumed to be satisfied and will not affect the build.

Predicates can be built with either of the two intrinsic attributes, including existence.


The simplest type of value will be an enumeration, whether it’s T/F, or a set of possible architectures. Predicates involving enumerations are whether or not they have a certain value.

The next type of value will be integers. A rudimentary theory of integers will be required, and predicates involving integers will concern equality and comparison.

There will also eventually be string values. Predicates about string values will include integer predicates about string length, prefixes and suffixes, and others as the need arises.


TODO Most of the burden of ensuring consistency between configuration options and build behavior will probably be left to the users.

Build Dependencies

TODO - probably via detectors written in Lua and a cache file Not an important feature for now. Push off until later.