gulpachek v0.2.2

gulpachek

Gulpachek is inspired by gulp and make. It's intended to provide the power and flexibility of javascript for creating a cross-platform make-like build system, consisting of buildable targets in a dependency tree.

Build System Model

The build system is defined by two components

1. A target dependency tree
2. A filesystem

Target Dependency Tree

At a high level, a target is something that can be built (like an object file, generated by compiling a C++ source file) and has an associated timestamp and unordered set of dependencies. Before a target can be built, it's dependencies must be built, and if any of the dependencies have a newer timestamp than the current target, then the current target must be built.

Filesystem

The filesystem is as you would expect: files and directories identified by a unique path. Paths can take three forms:

1. source

   Source paths identify files that are part of a project's source tree which is committed to version control systems and manually written by a developer. The build system should never modify these. They are identified with relative paths to the root of the source tree.

2. build

   Build paths identify files that are generated by the build system. The build system may read these files as inputs for generating other build files. They are identified with relative paths to the root of the build tree.

3. external

   External paths identify files that are installed on the hosting system, but are not defined by the project source tree. An example would be if a C++ program uses #include <iostream>, the iostream header would be an external file to that project, since the project almost certainly assumes that the file was already installed on the system and the location may vary relative to the build system. The build system should never modify these files. External paths are identified with absolute paths on the hosting system.

Scope

Build Scripts

Gulpachek targets the roles of the library developer as outlined in this webpage. Explicitly, the developer creating build files should be focusing on creating a well defined and predictable build of the project. If the developer automates generation of package files for distribution as build outputs, these are appropriate. While it is appropriate for a developer to generate install files for a package, gulpachek does not target installation itself. If a package manager like brew is used which favors source installs, the installer should run the gulpachek build script to generate well-defined outputs and then install those outputs to expected locations.

In terms of make, this is somewhat different than what you'll see in many existing projects. Many installers run ./configure followed by make install when installing from source. For package managers like chocolatey or apt, prebuilt binary packages are usually employed, so make install doesn't really make sense. make should build the project, and the installer can install the files where it wants without the build needing to know anything about every possible target system. Otherwise, the scope of the build system is too ambiguous and confusing.

C++ Builds

The low-level target and filesystem APIs are powerful, but likely too cumbersome for everyday projects. Higher level APIs should be developed to make certain platforms easier to develop. C++ is a first class citizen for gulpachek, meaning that the distribution ships with APIs to facilitate building C++ libraries and executables.