On Fri, Feb 09, 2018 at 05:13:51PM -0500, Nick Sabalausky (Abscissa) via Digitalmars-d wrote: > 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.
Really? I haven't had too much trouble with it. I've been updating vibe.d from git master occasionally, and the worst that has happened is that I need to run `dub build --force` to force rebuild of all dependent libraries, and/or parse dub's output to update the list of libraries / import paths in my build script. Sometimes updating Phobos will break the build because of changes in template symbols and what-not, but so far `dub build --force` has been the escape ticket. The biggest up-front cost is to generate that initial list of import paths and libraries needed to get the thing to build. It's not *hard*, but does require parsing the last few (very long) lines of dub output (IIRC you need -v to see it). But since that list changes from time to time, I'm actually tempted to write a script to parse the dub output and generate the import/library list automatically. Then it will become painless to build things this way. :-D > 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. Yeah, more and more, it's giving me the impression of being a walled garden. You either have to buy into it wholesale, or you're left out in the cold. :-( It wouldn't have been such a bad proposal if said walled garden had nice things going for it... but given dub's limitations, it feels almost like a prison sentence. T -- Two wrongs don't make a right; but three rights do make a left...
