| DUB(1) | The D Language Foundation | DUB(1) |
dub - Package and build management system for D
dub [--version] [COMMAND] [OPTIONS...] [-- [APPLICATION ARGUMENTS...]]
Manages the DUB project in the current directory. DUB can serve as a build system and a package manager, automatically keeping track of project's dependencies - both downloading them and linking them into the application.
If no explicit configuration is given, an existing "unittest" configuration will be preferred for testing. If none exists, the first library type configuration will be used, and if that doesn't exist either, the first executable configuration is chosen.
When a custom main file (--main-file) is specified, only library configurations can be used. Otherwise, depending on the type of the selected configuration, either an existing main file will be used (and needs to be properly adjusted to just run the unit tests for 'version(unittest)'), or DUB will generate one for library type configurations.
Finally, if the package contains a dependency to the "tested" package, the automatically generated main file will use it to run the unit tests.
visuald - VisualD project files sublimetext - SublimeText project file cmake - CMake build scripts build - Builds the package directly
An optional package name can be given to generate a different package than the root/CWD package.
All usual options that are also used for build/run/generate apply.
When --data=VALUE is supplied, specific build settings for a project will be printed instead (by default, formatted for the current compiler).
The --data=VALUE option can be specified multiple times to retrieve several pieces of information at once. A comma-separated list is also acceptable (ex: --data=dflags,libs). The data will be output in the same order requested on the command line.
The accepted values for --data=VALUE are:
main-source-file, dflags, lflags, libs, linker-files, source-files, versions, debug-versions, import-paths, string-import-paths, import-files, options
The following are also accepted by --data if --data-list is used:
target-type, target-path, target-name, working-directory, copy-files, string-import-files, pre-generate-commands, post-generate-commands, pre-build-commands, post-build-commands, requirements
It will create a copy of all involved packages and run dustmite on this copy, leaving a reduced test case.
Determining the desired error condition is done by checking the compiler/linker status code, as well as their output (stdout and stderr combined). If --program-status or --program-regex is given and the generated binary is an executable, it will be executed and its output will also be incorporated into the final decision.
Explicit retrieval/removal of packages is only needed when you want to put packages in a place where several applications can share them. If you just have a dependency to add, use the `add` command. Dub will do the rest for you.
Without specified options, placement/removal will default to a user wide shared location.
Complete applications can be retrieved and run easily by e.g. $ dub fetch vibelog --cache=local $ dub run vibelog --cache=local
This will grab all needed dependencies and compile and run the application.
Note: DUB does not do a system installation of packages. Packages are instead only registered within DUB's internal ecosystem. Generation of native system packages/installers may be added later as a separate feature.
Explicit retrieval/removal of packages is only needed when you want to put packages in a place where several applications can share them. If you just have a dependency to add, use the `add` command. Dub will do the rest for you.
Without specified options, placement/removal will default to a user wide shared location.
Complete applications can be retrieved and run easily by e.g. $ dub fetch vibelog --cache=local $ dub run vibelog --cache=local
This will grab all needed dependencies and compile and run the application.
Note: DUB does not do a system installation of packages. Packages are instead only registered within DUB's internal ecosystem. Generation of native system packages/installers may be added later as a separate feature.
Running "dub add <package>" is the same as adding <package> to the "dependencies" section in dub.json/dub.sdl. If no version is specified for one of the packages, dub will query the registry for the latest version.
This will update the versions stored in the selections file (dub.selections.json) accordingly.
If one or more package names are specified, only those dependencies will be upgraded. Otherwise all direct and indirect dependencies of the root package will get upgraded.
Any packages registered using add-path will be preferred over packages downloaded from the package registry when searching for dependencies during a build operation.
The version of the packages will be determined by one of the
following:
- For GIT working copies, the last tag (git describe) is used to
determine the version
- If the package contains a "version" field in the package
description, this is used
- If neither of those apply, "~master" is assumed
The version of the package is either determined automatically (see the "add-path" command, or can be explicitly overwritten by passing a version on the command line.
See 'dub add-path -h' for a way to register multiple local packages at once.
Warning: Beware that any formatting and comments within the package recipe will get lost in the conversion process.
dub.sdl, dub.json
Copyright (c) 1999-2022 by The D Language Foundation
http://code.dlang.org/docs/commandlinehttp://code.dlang.org/docs/commandline
dmd(1), rdmd(1), dub-init(1), dub-run(1), dub-build(1), dub-test(1), dub-lint(1), dub-generate(1), dub-describe(1), dub-clean(1), dub-dustmite(1), dub-fetch(1), dub-install(1), dub-add(1), dub-remove(1), dub-uninstall(1), dub-upgrade(1), dub-add-path(1), dub-remove-path(1), dub-add-local(1), dub-remove-local(1), dub-list(1), dub-search(1), dub-add-override(1), dub-remove-override(1), dub-list-overrides(1), dub-clean-caches(1), dub-convert(1)
| 2022-08-13 | The D Language Foundation |