The zero config D build tool.
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.
$ 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
.
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.
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.*
Dabble can support several different build types, with several regular types built in. By default, there are 4 build types availible:
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.
A target is a linked executable or binary; the final product after the compiling of the modules.
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).
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.