NOTE: this describes the SDLang version of the package file format. See also the specification based on JSON.

Every DUB package should contain a dub.sdl (or dub.json) file in its root folder. This file contains meta-information about the project and its dependencies. This information is used for building the project and for deploying it using the registry. The following sections give an overview of the recognized settings and their meaning. Note that any unknown settings are ignored for backwards compatibility reasons.

The package format described here is based on SDLang, a simple declarative language with a lean syntax and an XML-like structure with tags, attributes, and values. In contrast to the JSON based format, all the directives described in the following section can be used multiple times and will override or append values, depending on their meaning.

A typical example of a simple application that requires no platform specific setup:

// dub.sdl can contain comments!
name "myproject"
description "A little web service of mine."
authors "Peter Parker"
homepage ""
license "GPL-2.0"
dependency "vibe-d" version="~>0.7.23"

Please keep the description concise (not more than 100 characters) and avoid including unspecific information such as the fact that the package is written in D. The same goes for the package name - since all DUB packages are written in D, it's usually better to avoid mentioning D explicitly, unless the package is for example a high-level wrapper around a C/C++ library.


Global settings

In addition to the settings listed here, all build settings are allowed at the global scope.

Name Arguments Description
name [required] "<name>" Name of the package, used to uniquely identify the package. Must be comprised of only lower case ASCII alpha-numeric characters, "-" or "_".
description [required for publishing] "<text>" Brief description of the package
homepage "<url>" URL of the project website
authors "<author1>" ["<author2>" [...]] List of project authors (the suggested format is either "Peter Parker" or "Peter Parker ≶>")
copyright "<text>" Copyright declaration string
license [required for publishing] "<license spec>" License(s) under which the project can be used - see the license specification section for possible values
subPackage "<path>" or { ... } Defines a sub-package using either a path to a sub directory, or in-place - see the sub package section for more information
configuration "<name>" { ... } Speficies a build configuration (chosen on the command line using --config=...) - see the configurations section for more details
buildType "<name>" { ... } Defines an additional custom build type or overrides one of the default ones (chosen on the command line using --build=...) - see the build types section for an example
x:ddoxFilterArgs "<arg1>" ["<arg2>" [...]] Specifies a list of command line flags usable for controlling filter behavior for --build=ddox [experimental]

Sub packages

A package may contain an arbitrary number of additional publicly visible packages. These packages can be defined using subPackage directives in the main dub.sdl file. They can be referenced by concatenating their name with the name of the main package using a colon as the delimiter (i.e. "main-package-name:sub-package-name").

The typical use for this feature is to split up a library into a number of parts without breaking it up into different code repositories:

name "mylib"
targetType "none"
dependency "mylib:component1" version="*"
dependency "mylib:component2" version="*"
subPackage "./component1/"
subPackage "./component2/"


name "component1"
targetType "library"


The sub directories /component1 and /component2 then contain normal packages and can be referred to as "mylib:component1" and "mylib:component2" from outside projects. To refer to sub packages within the same repository use the "*" version specifier.

It is also possible to define the sub packages within the root package file, but note that it is generally discouraged to put the source code of multiple sub packages into the same source folder. Doing so can lead to hidden dependencies to sub packages that haven't been explicitly stated in the "dependencies" section. These hidden dependencies can then result in build errors in conjunction with certain build modes or dependency trees that may be hard to understand.

name "mylib"
targetType "none"
dependency "mylib:component1" version="*"
subPackage {
	name "component1"
	targetType "library"
	sourcePaths "component1/source"
	importPaths "component1/source"


License specifications

The license setting should only contain one of the standard license identifiers if possible. At a later point in time, DUB may use this information to validate proper licensing in dependency hierarchies and output warnings when licenses don't match up. Multiple licenses can be separated using the term "or" and for versioned licenses, the postfix "or later" is allowed to also include any later version of the same license.

The standard license identifiers are: public domain, AFL-3.0 (Academic Free License 3.0), AGPL-3.0 (Affero GNU Public License 3.0), Apache-2.0, APSL-2.0 (Apple Public Source License), Artistic-2.0, BSL-1.0 (Boost Software License), BSD 2-clause, BSD 3-clause, EPL-1.0 (Eclipse Public License), GPL-2.0, GPL-3.0, ISC, LGPL-2.1, LGPL-3.0, MIT, MPL-2.0 (Mozilla Public License 2.0), MS-PL (Microsoft Public License), MS-RL (Microsoft Reciprocal License), OpenSSL (OpenSSL License), SSLeay (SSLeay License), Zlib (zlib/libpng License)

Any other value is considered to be a proprietary license, which is assumed to be incompatible with any other license. If you think there is a license that should be included in this list, please file a quick bug report. Please also note that pure D bindings of C/C++ libraries should specify the same license as the original library, although a stricter but compatible license can be used, too.

Some example license specifications:

"GPL-2.0 or later"
"GPL-2.0 or later or proprietary"
"GPL-2.0 or LGPL-3.0"
"LGPL-2.1 or proprietary"

Build settings

Build settings influence the command line options passed to the compiler and linker. All settings are optional.

Name Arguments Description
dependency "<name>" ... Adds a single dependency of the given name, attributes are used to configure the version/path to use - see next section for how version specifications look like. Use multiple dependency directives to add more than one dependency.
systemDependencies "<text>" A textual description of the required system dependencies (external C libraries) required by the package. This will be visible on the registry and will be displayed in case of linker errors.
targetType "<type>" Specifies a specific target type - this setting does not support the platform attribute
targetName "<name>" Sets the base name of the output file; type and platform specific pre- and suffixes are added automatically - this setting does not support the platform attribute
targetPath "<path>" The destination path of the output binary - this setting does not support the platform attribute
workingDirectory "<path>" A fixed working directory from which the generated executable will be run - this setting does not support the platform attribute
subConfiguration "<dependency>" "<configuration>" Locks a dependency (first argument) to a specific configuration (second argument); see also the configurations section - this setting does not support the platform attribute
buildRequirements "<requirement1>" ["<requirement2>" [...]] List of required settings for the build process. See the build requirements section for details.
buildOptions "<option1>" ["<option2>" [...]] List of build option identifiers (corresponding to compiler flags) - see the build options section for details.
libs "<lib1>" ["<lib2>" [...]] A list of external library names - depending on the compiler, these will be converted to the proper linker flag (e.g. "ssl" might get translated to "-L-lssl")
sourceFiles "<pattern1>" ["<pattern2>" [...]] Additional files passed to the compiler - can be useful to add certain configuration dependent source files that are not contained in the general source folder
sourcePaths "<path1>" ["<path2>" [...]] Allows to customize the path where to look for source files (any folder "source" or "src" is automatically used as a source path if no sourcePaths setting is specified) - note that you usually also need to define "importPaths" as "sourcePaths" don't influence those
excludedSourceFiles "<pattern1>" ["<pattern2>" [...]] Files that should be removed for the set of already added source files (takes precedence over "sourceFiles" and "sourcePaths") - Glob matching can be used to pattern match multiple files at once
mainSourceFile "<path>" Determines the file that contains the main() function. This setting can be used by dub to exclude this file in situations where a different main function is defined (e.g. for "dub test") - this setting does not support platform suffixes
copyFiles "<pattern1>" ["<pattern2>" [...]] A list of globs matching files or directories to be copied to targetPath. Matching directories are copied recursively, i.e. "copyFiles": ["path/to/dir"]" recursively copies dir, while "copyFiles": ["path/to/dir/*"]" only copies files within dir.
versions "<version1>" ["<version2>" [...]] A list of D versions to be defined during compilation
debugVersions "<version1>" ["<version2>" [...]] A list of D debug identifiers to be defined during compilation
importPaths "<path1>" ["<path2>" [...]] Additional import paths to search for D modules (the source/ folder is used by default as a source folder, if it exists)
stringImportPaths "<path1>" ["<path2>" [...]] Additional import paths to search for string imports/views (the views/ folder is used by default as a string import folder, if it exists)
preGenerateCommands "<cmd1>" ["<cmd2>" [...]] A list of shell commands that is executed before project generation is started
postGenerateCommands "<cmd1>" ["<cmd2>" [...]] A list of shell commands that is executed after project generation is finished
preBuildCommands "<cmd1>" ["<cmd2>" [...]] A list of shell commands that is executed always before the project is built
postBuildCommands "<cmd1>" ["<cmd2>" [...]] A list of shell commands that is executed always after the project is built
dflags "<flag1>" ["<flag2>" [...]] Additional flags passed to the D compiler - note that these flags are usually specific to the compiler in use, but a set of flags is automatically translated from DMD to the selected compiler
lflags "<flag1>" ["<flag2>" [...]] Additional flags passed to the linker - note that these flags are usually specific to the linker in use

Inside of build setting values, it is possible to use variables using dollar notation. Any variable not matching a predefined name will be taken from the program environment. To denote a literal dollar sign, use $$. The predefined variables are:

Variable Contents
$PACKAGE_DIR Path to the package itself
$ROOT_PACKAGE_DIR Path to the root package of the build dependency tree
$<name>_PACKAGE_DIR Path to the package named <name> (needs to be part of the build dependency tree)

Platform specifications

Platform specific settings are supported through the use of the "platform" attribute. Platform attributes contain dash separated platform identifiers, as defined in the D language reference, but converted to lower case. The order of these suffixes is os-architecture-compiler, where any of these parts can be left off. Examples:

// used on all platforms
versions "PrintfDebugging"
// only applies if compiled with DMD
dflags "-vtls" platform="dmd"
// only used when building for X86-64
versions "UseAmd64Impl" platform="x86_64"
// only used on Posix systems (Linux, OS X, FreeBSD etc.)
libs "ssl" "crypto" platform="posix"
// applies if compiled for Windows, X86-64 using DMD
sourceFiles "lib/win32/mylib.lib" platform="windows-x86_64-dmd"

Version specifications

A version specification can consist of a number of attributes, mainly the "version" attribute:

Version specifiers define a range of acceptable versions. They can be specified in any of the following ways:

Numbered versions are formatted and compared according to the SemVer specification. The recommended way to specify versions is using the ~> operator as a way to balance between flexible upgrades and reducing the risk of code breakage.

Whenever you refer to (sub) packages within the same repository, use the "any version" version specifier: "*"

Target types

The following values are recognized for the targetType setting:

Value Description
"autodetect" Automatically detects the target type. This is the default global value and causes dub to try and generate "application" and "library" configurations. Use of other values limits the auto-generated configurations to either of the two. This value is not allowed inside of a configuration block.
"none" Does not generate an output file. This is useful for packages that are supposed to drag in other packages using "dependency" directives.
"executable" Generates an executable binary
"library" Specifies that the package is to be used as a library, without limiting the actual type of library. This should be the default for most libraries.
"sourceLibrary" This target type does not generate a binary, but rather forces dub to add all source files directly to the same compiler invocation as the dependent project.
"staticLibrary" Forces output as a static library container.
"dynamicLibrary" Forces output as a dynamic/shared library.

Build requirements

The following values are recognized as array items in the "buildRequirements" setting:

Value Description
"allowWarnings" Warnings do not abort compilation
"silenceWarnings" Don't show warnings
"disallowDeprecations" Using deprecated features aborts compilation
"silenceDeprecations" Don't show deprecation warnings
"disallowInlining" Avoid function inlining, even in release builds
"disallowOptimization" Avoid optimizations, even in release builds
"requireBoundsCheck" Always perform bounds checks
"requireContracts" Leave assertions and contracts enabled in release builds
"relaxProperties" Do not enforce strict property handling (removes the -property switch) [deprecated, recent versions of DUB never issue -property]
"noDefaultFlags" Does not emit build type specific flags (e.g. -debug, -cov or -unittest). Note that this flag should never be used for released packages and is indended purely as a development/debugging tool. Using "-build=plain" may also be a more appropriate alternative.

Build options

The "buildOptions" setting provides a compiler agnostic way to specify common compiler options/flags. Note that many of these options are implicitly managed by the "buildRequirements" setting and most others usually only occur in buildType block. It supports the following values:

Value Description Corresponding DMD flag
"debugMode" Compile in debug mode (enables contracts) -debug
"releaseMode" Compile in release mode (disables assertions and bounds checks) -release
"coverage" Enable code coverage analysis -cov
"debugInfo" Enable symbolic debug information -g
"debugInfoC" Enable symbolic debug information in C compatible form -gc
"alwaysStackFrame" Always generate a stack frame -gs
"stackStomping" Perform stack stomping -gx
"inline" Perform function inlining -inline
"noBoundsCheck" Disable all bounds checking -noboundscheck
"optimize" Enable optimizations -O
"profile" Emit profiling code -profile
"unittests" Compile unit tests -unittest
"verbose" Verbose compiler output -v
"ignoreUnknownPragmas" Ignores unknown pragmas during compilation -ignore
"syntaxOnly" Don't generate object files -o-
"warnings" Enable warnings, enabled by default (use "buildRequirements" to control this setting) -wi
"warningsAsErrors" Treat warnings as errors (use "buildRequirements" to control this setting) -w
"ignoreDeprecations" Do not warn about using deprecated features (use "buildRequirements" to control this setting) -d
"deprecationWarnings" Warn about using deprecated features, enabled by default (use "buildRequirements" to control this setting) -dw
"deprecationErrors" Stop compilation upon usage of deprecated features (use "buildRequirements" to control this setting) -de
"property" Enforce property syntax - deprecated -property


In addition to platform specific build settings, it is possible to define build configurations. Build configurations add or override build settings to the global ones. To choose a configuration, use dub --config=<name>. By default, the first configuration that matches the target type and build platform is selected automatically. The configurations are defined by adding a "configuration" directive.

If no configurations are specified, dub automatically tries to detect the two default configurations "application" and "library". The "application" configuration is only added if at least one of the following files is found: source/app.d, source/main.d, source/<package name>/app.d, source/<package name>/main.d, src/app.d, src/main.d, src/<package name>/app.d, src/<package name>/main.d. Those files are expected to contain only the application entry point (usually main()) and are only added to the "application" configuration.

When defining a configuration's platform, any of the specifiers described in build settings may be combined to make the configuration as specific as necessary.

The following example defines "metro-app" and "desktop-app" configurations that are only available on Windows and a "glut-app" configuration that is available on all platforms.

name "somepackage"

configuration "metro-app" {
	platforms "windows"
	targetType "executable"
	versions "MetroApp"
	libs "d3d11"

configuration "desktop-app" {
	platforms "windows"
	targetType "executable"
	versions "DesktopApp"
	libs "d3d9"

configuration "glut-app" {
	// works on any platform
	"targetType": "executable"
	"versions": "GlutApp"

You can choose a specific configuration for certain dependencies by using the "subConfiguration" directive:

	dependency "somepackage" version=">=1.0.0"
	"subConfiguration" "somepackage" "glut-app"

If no configuration is specified for a package, the first one that matches the current platform is chosen (see the "platforms" setting below).

Configuration block specific settings

In addition to the usual build settings, the following settings are recognized inside of a configuration block:

Name Arguments Description
platforms "<spec1> ["<spec2>" [...]] A list of platform specifiers to limit on which platforms the configuration applies

Build types

By default, a set of predefined build types is already provided by DUB and can be specified using dub build --build=<name>:

Name Build options
debug "debugMode" "debugInfo"
release "releaseMode" "optimize" "inline"
unittest "unittests" "debugMode" "debugInfo"
docs "syntaxOnly", plus dflags "-c" "-Dddocs"
ddox "syntaxOnly", plus dflags "-c" "-Df__dummy.html" "-Xfdocs.json"
profile "profile" "optimize" "inline" "debugInfo"
cov "coverage" "debugInfo"
unittest-cov "unittests" "coverage" "debugMode" "debugInfo"

The existing build types can be customized and new build types can be added using the global buildType directive. Any of the low level build settings (excluding "dependencies", "targetType", "targetName", "targetPath", "workingDirectory", "subConfigurations") can be used inside those. The build settings specified here will later be modified/augmented by the package/configuration specific settings.

An example that overrides the "debug" build type and defines a new "debug-profile" type:

name "my-package"
buildType "debug" {
	buildOptions "debugMode" "debugInfo" "optimize"
buildType "debug-profile" {
	buildOptions "debugMode" "debugInfo" "profile"