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