Design: Use cases and Requirements
This page contains a loose collection of use-cases and requirements for the build system that should inform the architecture of the system.
Many existing build tools suffer from an artificial split into build stages (e.g., "configure", "build"), as some build parameters (including dependencies) need to be determined before the proper build can start. This causes all sorts of issues, from a pollution of the language (make uses a mix of languages akin to C "preprocessing" and "compiling", and parses makefiles multiple times if dependency files are included)
Conceptually these tasks are all similar: they perform some action (often involving the compilation of source files), set some variables, then move on to dependent tasks that consume those values. Thus it's best if they could all be treated the same, with the scheduling being flexible enough to allow for parameters (features) to be set late in the process, and more artefacts being injected into the dependency graph as the graph is being processed by the scheduler.
While we normally think of a build process as something automated and non-interactive, the process of developing the build infrastructure for a given project, and the debugging if the behaviour is unexpected, suggest an interactive use, where users can do the build iteratively, while inspecting intermediate states of artefacts as the process progresses. There are two interfaces that allow Faber to support this:
-
an interactive Python shell
Faber can stop right after the project's fabscripts have been processed, but before anything is updated yet, hading the user back control via a (nested) Python interpreter, allowing him to inspect artefacts or features, and invoking
update()methods individually. -
a GUI frontend
Similarly to the shell interface, a GUI could present the state of the project right after the fabscripts have been read in, letting any further action be driven by a user's interaction with the GUI.
