Dabble

The zero config D build tool.

Building

Dabble comes with a Makefile to bootstrap the build. After building for the first time using make, you can use the Dabble binary found in the bin directory of the project home.

Usage

$ Dabble

Built executables will be in bin and static libraries in lib.

Dabble will then parse the source files in the src directory to generate a dependency tree. The results of this will then be written to the .dabble/modules directory.

If dabble gets anything wrong, or the build fails when it shouldn't have, delete the .dabble directory, as it does not contain any information that cannot be regerated by dabble.

Dabble can build itself without configuration, and can build libraries such as Derelict3 and Tango-D2 with minimal configuration.

root_path

The first time that dabble is run, it will try and detect the root directory of the project. This is usually quite successfull (well it works for dabble itself) but Dabble will ask for confirmation before initializing the directory, as it is impossible to be 100% sure.

The src path if the relative path to the directory that contains the .d files. Dabble will try and automatically detect this, but it may get it wrong sometimes. If it does, edit the core.src_dir entry in .dabble.conf.

Configuration

The aim of Dabble is to not require any editing of configuration files to build a standard D project. However, it is not uncommon for projects to require non-standard build options. Dabble tries to support those, and build configuration can be done in the .dabble.conf file. All files generated by dabble are ini format, even if they do not carry the .ini suffix.

Operating systems

Configuration of dabble based on operating system type can be done by adding a os.<osname> section to .dabble.conf. The os name should be the string representation of the OS enum in phobos std.system.

Adding an ignore entry into an operating system section will tell dabble to ignore modules that match that glob. This happens before parsing, so dmd will never see ignored files. For example, to build tango-d2 on linux, we need to exclude the sys.win32 package, so the .dabble.conf file contains the following:

[os.linux]
ignore=sys.win32.*

Build Types

Dabble can support several different build types, with several regular types built in. By default, there are 4 build types availible:

• default -> -inline
• release -> -inline -release -O
• debug -> -debug -g
• unittest -> -unittest -g

You can specify the build type to use by passing it's name as the first argument to the Dabble executable.

You can add a new built type by adding a section named build.<buildtype>, and filling in the compile_flags and link_flags values.

Target configuration

A target is a linked executable or binary; the final product after the compiling of the modules.

Autodetection

Dabble automatically detects "root" modules; modules that only import other modules and are not imported by any modules. These modules are linked aswell as compiled, and the generated executable is placed in the $ROOT_DIR/bin directory. The excutable name will be the name of the module with the name of the current build type appended, unless the module name is main, in which case the executable name will be the name of the project (the core.name entry in .dabble.conf).

Manual specification

One main downside of autodetections is that it usually fails when building libraries. To get around this, one can manually specify targets. For each target add a section named target.<targetname> in .dabble.conf. In that section you can specify the properties of the target. Look at this example for the .dabble.conf I use to build Derelict3:

[target.libDerelictSDL2]
glob=derelict.sdl2.*

The glob value is a glob that matches the module names of the modules that will be linked to create the target. Later on more options will be availible, such as globs of modules to ignore, and external libraries to staticly link to etc. etc.

If you want to specify the targets for a specific build type, add the targets you wish build as a csv to the targets value in the build.<buildtype> section. i.e.

[build.release]
targets=target1, target2

If the buildtype section doesn't have a targets entry, all targets will be built.