dud: A build and dependency tool for the D programming language

Dud is meant to be a reasonable drop in replacement for dub.

IMHO the dub codebase is hard to get into and high coupled. Meaning that, if you fix one thing you might break another.

Dud's implementation tries to be boring. Dud is to be written in a declarative and functional style.

Dud has two aims, be a dub replacement. Not a 100% compatible drop in replacement, but something that does the same thing as dub as long as you stay in the tasteful bounds of what dub allows. The other goal I had in mind was, that IMO at some point a D compiler will become a background daemon, that only compiles diffs in source. Not on a per file bases, but rather that the bulk of the compilation results, ast etc. is stored in memory. This compiler daemon will need to understand dub files, and dud as a library should be usable for this purpose. This is the reason the cli for dud itself is quite small, and should stay that way. One might think of it as a library first approach. This does not mean the end user cli experience should suffer. Good error messaged and good dependency resolution information, especially on failure to resolve dependency, is a must. Therefore I decided to use the dependency resolution algorithm developed for the Dart package manager pub (https://github.com/dart-lang/pub/blob/master/doc/solver.md).

Testing is paramount. The target should be 100% coverage by unittests.

For that to make sense expressions like

cond1 && cond2 && (cond3 || cond4)

should be written/rewritten to

cond1
    && cond2
    && (cond3
        || cond4
    )

.

On top of the unittests there is already code that pulls in all packages from code.dlang.org and test them. Not only parsing the dub.sdl and dub.json files but also trying to resolve them.

At some point, dud actually needs build something. Currently, I think the best bet is to look reggae and for instance generate ninja files to then actually build the software.

At least for now I would like the dependency to anything else but phobos to a minimum. Darser is used to generate the parser for sdl files, but the generation of the parser happens before compile time and the resulting classes are checked into the repo, so I think this is okay for now.

Also, so far the code tries to stay away from newer D features like stricter memory safety. This does not mean the code is not memory safe, it only means that these features are not needed in dud right now, and to a degree, I think that it would be a code smell if those features are required to make dud memory safe.

Features

Most things do not work and are not even implemented yet. Currently, the focus is on getting the data structures correct.

Given the below displayed list of dub features, dud's current feature set is extremely limited.

Package creation

• [ ] init

Build, test and run

• [ ] run
• [ ] build
• [ ] test
• [ ] generate
• [ ] describe
• [ ] clean
• [ ] dustmite

Package management

• [ ] fetch
• [ ] add
• [ ] remove
• [ ] upgrade
• [ ] add-path
• [ ] remove-path
• [ ] add-local
• [ ] remove-local
• [ ] list
• [ ] search
• [ ] add-override
• [ ] remove-override
• [ ] list-overrides
• [ ] clean-caches
• [x] convert

Documentation

See Contributing section

Contributing

PRs or issues are always welcome!

Building

To build dud run:

$ dub build

Each subpackage should be buildable with the same shell command.

Testing

To test the individual subpackages run:

$ dub test

in the subpackage folder.

To execute the excessive tests -- Excessive, in this case means, downloading all packages from code.dlang.org, creating a folder for each tag for each package and running tests on all of them -- run:

$ cd testdata
$ make // This requires ~ 63GB of disk space
$ cd ../sdlang
$ dub --config=ExcessiveTests
$ cd ../pkgdescription
$ dub --config=ExcessiveTests

It is not indented that dud can ingest all dub.(sdl|json) found, instead the idea is to have a large, real world test set.