Build settings
Build settings influence the command line options passed to the compiler and linker. All settings are optional.
Most (but not all) settings support platform specifications to only apply the settings on certain targets.
Additionally it is possible to use environment variables inside of build setting values using dollar notation. Any variable not matching a predefined name will be taken from the program environment. To denote a literal dollar sign, use $$
. Refer to the specification for more details.
dependencies
...
dependency "vibe-d" version="~>0.9.5"
dependency "localdep" path="../localdep" optional=true default=true
dependency "remote" repository="git+https://example.org/remote.git" version="a1b2c3d4"
dependency "modified" version="~>1.2.3" {
dflags "--special-flag" "-O4"
}
Arguments: "name" ...
Adds one dependency for every used dependency
directive to the project.
...
"dependencies": {
"vibe-d": "~>0.9.5",
"localdep": {
"path": "../localdep",
"optional": true,
"default": true
},
"remote": {
"repository": "git+https://example.org/remote.git",
"version": "a1b2c3d4"
},
"modified": {
"version": "~>1.2.3",
"dflags": ["--special-flag", "-O4"]
}
}
Type: T[string]
List of project dependencies given as pairs of "<name>" : <version-spec>
This setting does not support platform specifications.
Version specifications
A dependency can contain a number of attributes that are used for versioning:
version="<version-specified>"
- The version specification as used for the simple form.
Specifies a version range to fetch from the registry or local providers
or for dependencies with therepository
attribute set, this specifies the exact commit hash. (commitish)path="<path-to-package>"
- Use a folder to source a package from.
References a package in a specific path. This can be used in situations where a specific copy of a package needs to be used. Examples of this include packages that are included as GIT submodules, or packages in sub folders of the main package, for example when splitting up module functionality.optional=true
- Indicates an optional dependency.
With this set totrue
, the dependency will only be used if explicitly selected in dub.selections.json. If omitted, this attribute defaults tofalse
.default=true
- Choose an optional dependency by default.
With this set totrue
, the dependency will be chosen by default if no dub.selections.json exists yet. If omitted, this attribute defaults tofalse
. Note that this only has an effect ifoptional
is also set totrue
.repository="git+https://example.org/repository.git"
- clone a git repository as dependency.
This also requires theversion
attribute to be set to the git commit hash (7 to 40 hex characters).
Supported since DUB v1.23.0- Since DUB v1.24.0, build settings fields (as described in this document) can also be applied to dependencies through the dependency directive.
Note that as of v1.24.0 onlydflags
is supported.
A dependency version specification can either be a simple string for the version or a more complex variant, allowing more control.
- Simple variant:
"<name>": "<version-specifier>"
This is the usual way to specify a dependency. - Complex variant:
"<name>" : { "<attribute>": "<value>"[, ...] }
The following attributes can be used to control how a dependency is resolved and further processed:"version": "<version-specified>"
- The version specification as used for the simple form.
Specifies a version range to fetch from the registry or local providers
or for dependencies with therepository
attribute set, this specifies the exact commit hash. (commitish)"path": "<path-to-package>"
- Use a folder to source a package from.
References a package in a specific path. This can be used in situations where a specific copy of a package needs to be used. Examples of this include packages that are included as GIT submodules, or packages in sub folders of the main package, for example when splitting up module functionality."optional": true
- Indicates an optional dependency.
With this set totrue
, the dependency will only be used if explicitly selected in dub.selections.json. If omitted, this attribute defaults tofalse
."default": true
- Choose an optional dependency by default.
With this set totrue
, the dependency will be chosen by default if no dub.selections.json exists yet. If omitted, this attribute defaults tofalse
. Note that this only has an effect if the"optional"
attribute is also set totrue
."repository": "git+https://example.org/repository.git"
- clone a git repository as dependency.
This also requires theversion
attribute to be set to the git commit hash (7 to 40 hex characters).
Supported since DUB v1.23.0- Since DUB v1.24.0, build settings fields (as described in this document) can also be applied to dependencies through the
"dependencies": {}
attributes.
Note that as of v1.24.0 onlydflags
is supported.
Version specifiers
Version specifiers define a range of acceptable versions. They can be specified in any of the following ways:
- Restrict to a certain minor version:
"~>2.2.13"
, equivalent to">=2.2.13 <2.3.0"
- Restrict to a certain major version:
"~>2.2"
, equivalent to">=2.2.0 <3.0.0"
- Require a certain version:
"==1.3.0"
- Require a minimum version:
">=1.3.0"
- Require a version range:
">=1.3.0 <=1.3.4"
- Match any released version (equivalent to
">=0.0.0"
):"*"
- Use a GIT branch (discouraged, use repository + version instead):
"~master"
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: "*"
Hint
Dependency resolution and further notes are also summarized on the dependencies specification page.
systemDependencies
A textual description of the required system dependencies (external C libraries) required by the package. As of DUB v(unreleased / unimplemented) this will be visible on the registry and will be displayed in case of linker errors.
This value is purely informational and does not affect building.
This setting does not support platform specifications.
targetType
Specifies a specific target type.
This setting does not support platform specifications.
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 build anything and doesn't generate an output file. This is useful for packages that are supposed to drag in other packages or sub packages using "dependency" directives. |
"executable" |
Generates an executable binary. (e.g. .exe on Windows) |
"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. For details, see Build Hooks |
"staticLibrary" |
Forces output as a static library container. (e.g. .lib / .a file) |
"dynamicLibrary" |
Forces output as a dynamic/shared library. (e.g. .dll / .dylib / .so ) |
For more information about the target types, refer to the specification.
targetName
Sets the base name of the output file; type and platform specific pre- and suffixes are added automatically.
Defaults to the package name
.
This setting does not support platform specifications.
Examples:
For more information how built executables and objects are named see the target types specification.
targetPath
The destination path of the output binary.
This setting does not support platform specifications.
For more information how built executables and objects are named see the target types specification.
workingDirectory
A fixed working directory from which the generated executable will be run.
This setting does not support platform specifications.
subConfigurations
...
subConfiguration "avrd" "atmega1284p"
subConfiguration "vibe-d/tls" "botan"
subConfiguration ":subpackage" "FromRoot"
Arguments: "<dependency>" "<configuration>"
Locks the dependency (first argument) to a specific configuration (second argument); see also the configurations specification.
...
"subConfigurations": {
"avrd": "atmega1284p",
"vibe-d/tls": "botan",
":subpackage": "FromRoot"
}
Type: string[string]
Locks the dependencies to specific configurations; a map from package name to configuration name, see also the configurations specification.
This setting does not support platform specifications.
buildRequirements
List of required settings for the build process.
The following values are recognized for each value in the setting array:
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 |
"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. |
buildOptions
List of build option identifiers. (corresponding to compiler flags)
This setting provides a compiler agnostic way to specify common compiler options/flags.
Note
many of these options are implicitly managed by the buildRequirements
setting and most others usually only occur in buildType blocks.
The following values are supported:
Value | Description | Corresponding DMD flag |
Corresponding LDC flag |
Corresponding GDC flag |
---|---|---|---|---|
"debugMode" |
Compile in debug mode (enables contracts) | -debug |
-d-debug |
-fdebug |
"releaseMode" |
Compile in release mode (disables assertions and bounds checks) | -release |
-release |
-frelease |
"coverage" |
Enable code coverage analysis to be written when the app has finished running | -cov |
-cov |
-fprofile-arcs -ftest-coverage |
"coverageCTFE" |
Enable code coverage analysis (including code executed at compile-time via CTFE) | -cov=ctfe |
-cov=ctfe |
n/a |
"debugInfo" |
Enable symbolic debug information (e.g. so that GDB can show function names, parameters and show linked source code) | -g |
-g |
-g |
"debugInfoC" |
Enable symbolic debug information in C compatible form | -g |
-gc |
-g |
"alwaysStackFrame" |
Always generate a stack frame | -gs |
-disable-fp-elim |
n/a |
"stackStomping" |
Perform stack stomping | -gx |
n/a | n/a |
"inline" |
Perform function inlining | -inline |
-enable-inlining -Hkeep-all-bodies |
-finline-functions |
"noBoundsCheck" |
Disable all bounds checking | -noboundscheck |
-boundscheck=off |
-fno-bounds-check |
"optimize" |
Enable optimizations | -O |
-O3 |
-O2 |
"profile" |
Emit profiling code | -profile |
-fdmd-trace-functions |
-pg |
"profileGC" |
Emit GC profiling information | -profile=gc |
n/a | /na |
"unittests" |
Compile unit tests | -unittest |
-unittest |
-funittest |
"verbose" |
Verbose compiler output | -v |
-v |
-v |
"ignoreUnknownPragmas" |
Ignores unknown pragmas during compilation | -ignore |
-ignore |
-fignore-unknown-pragmas |
"syntaxOnly" |
Don't generate object files | -o- |
-o- |
-fsyntax-only |
"warnings" |
Enable warnings, enabled by default (use "buildRequirements" to control this setting) | -wi |
-wi |
-Wall |
"warningsAsErrors" |
Treat warnings as errors (use "buildRequirements" to control this setting) | -w |
-w |
-Werror -Wall |
"ignoreDeprecations" |
Do not warn about using deprecated features (use "buildRequirements" to control this setting) | -d |
-d |
-Wno-deprecated |
"deprecationWarnings" |
Warn about using deprecated features, enabled by default (use "buildRequirements" to control this setting) | -dw |
-dw |
-Wdeprecated |
"deprecationErrors" |
Stop compilation upon usage of deprecated features (use "buildRequirements" to control this setting) | -de |
-de |
-Werror -Wdeprecated |
"betterC" |
Compile in betterC mode | -betterC |
-betterC |
-fno-druntime |
"lowmem" |
Enable the garbage collector for the compiler(dmd/ldc), reducing the compiler memory requirements but increasing compile times. | -lowmem |
-lowmem |
n/a |
libs
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").
On Posix platforms dub will try to find the correct linker flags by first checking if they exist using pkg-config --exists <lib>
and then inject their corresponding linker flags reported by pkg-config instead of the guessed compiler specific library argument.
See also: platform specifications
sourceFiles
Additional files passed to the compiler - can be useful to add certain configuration or platform dependent source files that are not contained in the general source folder.
Supports glob matching patterns to match multiple files at once.
sourcePaths
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)
Relationship with import paths
Note that you usually also need to define "importPaths" as "sourcePaths" don't influence those and are required to make source files able to import each other.
A source file as found through sourceFiles
and sourcePaths
is what is being passed to the compiler to compile into object code and eventually also link into an executable or library. Without being added to import files it may not be possible to import these source files from each other.
excludedSourceFiles
Files that should be removed for the set of already added source files (takes precedence over "sourceFiles" and "sourcePaths")
Supports glob matching patterns to match multiple files at once.
mainSourceFile
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 specifications.
copyFiles
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.
Supports glob matching patterns to match multiple files at once.
extraDependencyFiles
A list of globs matching files to be checked for rebuilding the dub project.
Usually this setting is not required as all source files, import files and string import files are already checked for updates. However this may be useful when working on repeatedly updating static libraries that are compiled into your project.
Supports glob matching patterns to match multiple files at once.
versions
A list of D's custom conditional compilation versions to be defined during compilation.
In the source code they can then be queried like this:
Note: (optional) dependencies being present already have the Have_*
version defined.
debugVersions
A list of D's custom debug condition identifiers to be defined during compilation
Similar to versions
in the source code they can then be queried like this:
// avoids tainting dependees' unittests with sourceLibrary dependencies
debug (SQLTests)
{
unittest
{
assert(everythingWorks());
}
}
importPaths
Additional import paths to search for D modules (the source/ folder is used by default as a source folder, if it exists)
It's recommended to put all source paths into the import paths so that sources can import each other.
Additional import paths can be defined for example for used library code that is linked in externally. If using code from only imported paths, but not linking in the object files that contain the actual definitions, linker errors may occur.
This corresponds to adding -I
flags in DMD.
stringImportPaths
Additional import paths to search for string imports (the views/
folder is used by default as a string import folder, if it exists)
These folders are where import("filename.ext")
statements are going to look for their passed in files.
This corresponds to adding -J
flags in DMD.
Example usage in D code:
// loading files to be embedded into the executable:
static immutable string[] mirrors = import("mirrors.txt").split("\n");
// embedded binary file into the executable: (e.g. load GTK resources, load embedded DLL, etc.)
static immutable ubyte[] resources = cast(immutable(ubyte)[])import("resources.gresource");
<binary content>
preGenerateCommands
A list of shell commands that is always executed before project generation is started.
These commands are run on dub build
, dub run
and dub generate
Hint
This command is also executed even if the package would not require recompilation or when generating e.g. makefiles.
If you write to files that are observed by source files, import paths, string import paths or extraDependencyFiles, this package will rebuild.
If you want to update source files on rebuild, you can use preBuildCommands
.
For more information about the build cycle and injecting commands into the build process, see hooks.
postGenerateCommands
A list of shell commands that is always executed after project generation is finished
These commands are run on dub build
, dub run
and dub generate
For more information about the build cycle and injecting commands into the build process, see hooks.
preBuildCommands
A list of shell commands that is executed before the package is built
These commands are run before the build process on dub build
and dub run
(if not already up-to-date)
For more information about the build cycle and injecting commands into the build process, see hooks.
postBuildCommands
A list of shell commands that is executed after the package is built
These commands are run after the build process on dub build
and dub run
(if not already up-to-date)
For more information about the build cycle and injecting commands into the build process, see hooks.
preRunCommands
A list of shell commands that is executed always before the project is run
These commands are run on dub run
For more information about the build cycle and injecting commands into the build process, see hooks.
postRunCommands
A list of shell commands that is executed always after the project is run
These commands are run on dub run
For more information about the build cycle and injecting commands into the build process, see hooks.
dflags
Additional flags passed to the D compiler
Note
These flags are usually specific to the compiler in use, but a set of flags is automatically translated from DMD to the selected compiler
Use build options for a compiler-agnostic way of manipulating the build.
lflags
Additional flags passed to the linker - note that these flags are usually specific to the linker in use
injectSourceFiles
Source files that will be compiled into binaries that depend on this package, no matter what targetType the package has.
For details, see Build Hooks
Warning
this should be under a permissive license (like Boost) or you risk infecting a users binary with an incompatible license.
Supports glob matching patterns to match multiple files at once.
Example:
Injected source files will import files from the context of the project that depends on the dependency defining them.
Created: August 5, 2022