This package implements a meta-build system in D, with the build
descriptions in D. At its core is a set of data definitions that
allow a user to specify arbitrary build descriptions at compile-time,
including the usage of functions that only run at run-time (so a
build can, for example, automatically include every file in a
directory).
The build is contained in a reggaefile.d file, which must define
one and only one function returning an object of type Build. This function is usually generated from the provided build template mixin for maximum convenience.
A Build struct only serves as a top-level container for
$(Target) structs. Each one of these can include other dependent
$(Target) structs recursively and form the basis of the build
descripton. The build module contains these data definitions,
please refer to the documentation therein for more information.
As well as these low-level data definitions, reggae provides built-in
high-level rules to automate common build system tasks for D, C, and
C++. These can be found in the reggae.rules package and its
subpackages. There is also a reggae.rules.dub package for accessing
targets defined in/by dub.
Right now the objectFile and objectFiles rules generate
the appropriate commands to build an object file (or object files
in the case of the latter) for a given source language. There is
no current mechanism to support other languages as plugins but
that's how it's planned to be in the future.
End-users will probably not use objectFile directly, there
are higher level rules for compiling all or nearly all source
files in a directory and its subdirectories. For D there is even
a rule to compile, link and find all dependencies for a D executable
called dExe. There are many examples in the Cucumber tests.
Reggae works by using backends. Currently, there are three: the
ninja, make and binary backends. The first two generate files for
those two build systems in the same manner as CMake and Premake
do. The latter produces a binary executable that when run will check
dependencies and execute build commands as appropriate.
This module contains the core data definitions that allow a build
to be expressed in. Build is a container struct for top-level
targets, Target is the heart of the system.
This package implements a meta-build system in D, with the build descriptions in D. At its core is a set of data definitions that allow a user to specify arbitrary build descriptions at compile-time, including the usage of functions that only run at run-time (so a build can, for example, automatically include every file in a directory).
The build is contained in a reggaefile.d file, which must define one and only one function returning an object of type Build. This function is usually generated from the provided build template mixin for maximum convenience.
A Build struct only serves as a top-level container for $(Target) structs. Each one of these can include other dependent $(Target) structs recursively and form the basis of the build descripton. The build module contains these data definitions, please refer to the documentation therein for more information.
As well as these low-level data definitions, reggae provides built-in high-level rules to automate common build system tasks for D, C, and C++. These can be found in the reggae.rules package and its subpackages. There is also a reggae.rules.dub package for accessing targets defined in/by dub.
Right now the objectFile and objectFiles rules generate the appropriate commands to build an object file (or object files in the case of the latter) for a given source language. There is no current mechanism to support other languages as plugins but that's how it's planned to be in the future.
End-users will probably not use objectFile directly, there are higher level rules for compiling all or nearly all source files in a directory and its subdirectories. For D there is even a rule to compile, link and find all dependencies for a D executable called dExe. There are many examples in the Cucumber tests.
Reggae works by using backends. Currently, there are three: the ninja, make and binary backends. The first two generate files for those two build systems in the same manner as CMake and Premake do. The latter produces a binary executable that when run will check dependencies and execute build commands as appropriate.