Previous Entry Share Next Entry
Impressions of dub

This week I've made my first uses of of dub, a package manager for D programs which happens to be getting more attention than Orbit which in turn has been around longer and looks to have a more thorough approach. I've been mostly using makefiles especially after DSSS died.

For my most recent project I've switched to using dub and just want to pass along some information from my usage.

Installation was simple, dub is a single executable, all I had to do was place it in /usr/local/bin and it was ready to go. But that is really just a one or three time thing.

libosm is intended to become a basic library, but there is an example and likely more to come. I had to make some adjustments to the layout. The source code needed to be moved into a source directory under the name of the project. I started by placing the example in the app.d suggested file.

The first issue I came to was that I have a dependency on a library not in the dub's repository and not installed (I'm refering to ProtocolBuffers). I chose to go with the quick and dirty solution already used in the makefile, point to the parent directory for imports and the library.

I addressed the example/lib problem by using configurations. Best I can tell this isn't an intended situation for dub to handle, but it works. Since dub always selects the first configuration by default I had to re-add some details about my library so that it would select building a library by default.

The osm example was moved to a sibling directory of source, 'examples.' I renamed it to "dump" as that is all it really does. The configuration adds that examples directory as a "sourcePaths" and I included where to find libdprotobuf.

The approach allows for having multiple executables in one package. This is clearly not a design goal of dub, but it doesn't seem completely unreasonable. While I can understand the desire, it has been fairly common for me to have projects where I'll build multiple executables. Generally this is due to poor library/program separation it is just not been worth trying to separate out yet another library used by about 4 other programs.

  • 1
> I addressed the example/lib problem by using configurations.

Each example is supposed to have own `package.json` and refer to parent project via relative path dependency. That way one can simply run `dub` inside example dir.

// Dicebot

  • 1

Log in

No account? Create an account