Am 02.03.2013 09:19, schrieb Jonathan M Davis: > On Saturday, February 16, 2013 18:10:21 Sönke Ludwig wrote: >> With the recent talk about Orbit, I thought it is time to also announce >> the package manager that we have been working out based on the simple >> VPM system that has always been in vibe.d. I don't really like stepping >> into competition with Jacob here (*), but the approach is different >> enough that I think it should be put on the table. > > I justed messing around with dub on one of my projects, and at first glance, > I > like what I'm seeing. Hopefully, it'll be a good replacement for the ad-hoc > build setups that I typically use. However, while the package format > documentation seems to be fairly complete, the usage documentation is still > sorely lacking: > > http://registry.vibed.org/usage
Agreed, there also needs to be a brief introduction how dub accomplishes to usual tasks. > > As it stands, I don't even have a clue what the various directories that get > generated are for, let alone something like how the docs target is supposed > to > work (I just get errors from it about one of the files it generates not being > executable). The "docs" target was just a quick draft added to have meaningful list of standard built types and hasn't really been tested. I'll fix it right away. > > There should also probably clear examples of how to set up an application vs > a > library. It seems to want to set up an application by default, and I assume > that you make it a library by mucking with dflags in the configuration file, > but > how that jives with having an executable with -unittest, I don't know. As it stands, there are just two modes of operation: 1. invoking dub on a project will build it as an application (any "source/app.d" file is assumed to contain the main() function) 2. any dependent package is assumed to be a library and gets compiled in without its "source/app.d" file. This is currently tied to the simplified workflow that I use. Although I find this to be a quite nice approach in general and it covers most uses nicely, support to specify explicit library types will be added later. > > And if dub is supposed to work with build scripts or other build tools as > some > of your posts here imply, then that definitely needs to be documented, > because > I don't see anything of the sort. It's not yet implemented, although trivial. > > So, it looks like it has a good start, but without better instructions, it's > going to be a bit hard to use it properly it seems. > Right now everything has to be extended a bit to handle the different use cases and project structures that came up until now in a comfortable way. I hope this to settle down in one or two weeks and then I'll write up a proper introduction on that page and make a quick announcement.
