reggae 0.0.5

Reggae

A build system in D. This is alpha software, only tested on Linux and likely to have breaking changes made.

Usage

Reggae is actually a meta build system and works similarly to CMake or Premake. Those systems require writing configuration files in their own proprietary languages. The configuration files for Reggae are written in D.

From a build directory (usually not the same as the source one), type reggae -b <ninja|make> </path/to/project>. This will create the actual build system depending on the backend chosen, for Ninja or GNU Make. The project path passed must either:

1. Contain a a file named reggaefile.d with the build configuration
2. Be a dub project

Dub projects with no reggaefile.d will have one generated for them in the build directory.

How to write build configurations

The best examples can be found in the features directory since they're executable. Each reggaefile.d must contain one and only one function with a return value of type Build. This function can be generated automatically with the build template mixin. The Build struct is a container for Target structs, which themselves may depend on other targets.

Arbritrary build rules can be used. Here is an example of a simple D build reggaefile.d:

import reggae;
const mainObj  = Target("main.o",  "dmd -I$project/src -c $in -of$out", Target("src/main.d"));
const mathsObj = Target("maths.o", "dmd -c $in -of$out", Target("src/maths.d"));
const app = Target("myapp", "dmd -of$out $in", [mainObj, mathsObj]);
mixin build!(app);

That was just an example. To build D apps with no external dependencies, this will suffice:

import reggae;
alias app = dExe!(App("src/main.d", "myapp"),
                  Flags("-g -debug"),
                  ImportPaths(["/path/to/imports"])
                  );
mixin build!(app);

There are also other functions and pre-built rules for C and C++ objects.

Building Reggae

Reggae can build itself. To bootstrap, use dub. The Makefile bootstraps it in a bin directory. A Makefile included in a build system meant to replace it? I know.

Goals

1. No external dependencies, including on dub
2. Minimal boilerplate for writing build configurations
3. Flexibility for low-level tasks with built-in common tasks