Brussels / 4 & 5 February 2023


Staging of Artifacts in a Build System

At a time where make was developed, a simple and computationally cheap solution to the problem of how to handle the relation between artifacts and files was needed. Each artifact is associated with a file in the filesystem and the timestamp of the file was used to determine which actions (recipes) need to be executed. Traditionally, to be backwards compatible with make, subsequent build systems also implemented this concept. However, there is no technical reason to do it like this. Instead, it even has a couple of advantages if this concept is abandoned and no association of artifacts with the filesystem is done. Nowadays, where content-addressable storage is a widely applied concept and actions are anyway executed in an isolated environment may it be in a separate directory or in a sandbox, this problem can be tackled by a complete separation between physical and logical paths, which is also called staging. Input and output paths of an individual action are abstracted away. Thus, each target has its own view of the world and can place generated artifacts at any logical path they like. Consuming targets may place these generated artifacts at a different logical location. This allows to define build targets independently of their actual location and in particular allows to refer to targets from other repositories. This simplifies the handling of different repositories. All what matters is how the target is defined and not where. This concept is implemented in an open-source build system, which is publicly available under the following link:


Photo of Sascha Roloff Sascha Roloff