On 02/09/2018 02:01 PM, H. S. Teoh wrote:


Currently, my vibe.d project has a subdirectory containing an empty
dummy dub project, the sole purpose of which is to declare vibe.d
dependencies so that `dub build` in that subdirectory will fetch and
build vibe.d and whatever else it may depend on, and build it into a
linkable state.  Once that's done, I leave dub aside and use SCons to
actually build and link my program with the libraries built by dub.
This resulted in an instant improvement in my build times by (at least)
half, as well as free me from needless network lookups when I'm actually
coding locally and don't *need* to be upgrading dependent libraries.


I'm kind of envious of that approach, and REALLY tempted to adopt it myself, but there are some unfortunate probelms with it (which are incidentally the exact same reasons I eventually conformed and begrudgingly strated using dub as my main build tool, as much as I dislike doing so):

1. From a compiler command-line perspective, trying to incorporate vibe.d in a project that isn't built with dub proved in my experience to be a royal pain. And then upgrading to newer versions of vibe.d had a tendency to break it in non-obvious ways.

2. If you want your project (especially if it's a lib) to participate in the the dub package repository ecosystem, you pretty much have to support dub as a build tool. Otherwise, anyone who DOES use dub as a build tool will have major trouble trying to use your lib.

So even as a package manager, dub is viral. And the unfortunate consequence of that is that it completely divides D package ecosystem in two.

Reply via email to