Skip to content
Sönke Ludwig edited this page Jul 14, 2015 · 1 revision

Extensibility through DUB packages

Basic idea

Extensions should be usable as a general tool to extend DUB's feature set during the build generation phase. This means that they can influence most aspects of the build before the build actually happens. This includes modifying and augmenting the build settings, adding or removing dependencies, running custom commands, adding new files, etc.

Just to demonstrate the concept, here is a possible syntax of how such extensions would be used in the package description (SDL format):

name "test-package"

ext:generate-versions-module file="source/test/versions.d"

ext:ssh-deploy platform="linux-x86_64-ldc" {
  url "admin@example.com:/site"
  files "test" "config.json" "public/**"
}

ext:generate-apk platform="linux-arm-gdc" {
   // ...
}

Extensions live in their own namespace to avoid conflicts with DUB's integrated directives. Their identifier is subject to the same rules as package names. Each extension can accept an arbitrary set of parameters (converted to a Json representation internally) and can be restricted to a certain set of platforms using platform specifiers. Extensions can also occur inside "configuration" blocks.

Whenever DUB encounters an "ext:" directive, it will look for a package named "dub-ext-" using the usual package lookup mechanism (preferring local packages and falling back to any registered package registry). Once found, it will build the package, which has to have a target type of "dynamicLibrary". This library is then loaded dynamically and searched for a single exported function extern(D) dub.extension.Extension dubExtension();. Extension is defined as the following interface:

module dub.extension;

// WIP
interface Extension {
    void processRecipes(PackageRecipe[] recipes);
    void processTarget(ref BuildSettings build_settings);
    // ...
}

Extension versions

Extension versions will be stored in dub.selections.json and are subject to the usual upgrade rules. Exception directives accept an optional version="..." attribute to control the range of accepted versions. If omitted, any version ("*") is accepted and the latest release version is preferred.

You can’t perform that action at this time.