Which language futures make D overcompicated?

[H. S. Teoh]

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...