On 02/09/2018 06:03 PM, H. S. Teoh wrote:
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.
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
Yea, *that's* the stuff that gave me trouble. It was also the motivation
for my "dub describe --data=..." PR, but afterwords I felt like that
still wasn't quite as good as I wanted, and dub's internal code just
didn't seem designed to handle that sort of thing anyway (though maybe
that's improved now?).
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.
Definitly. A big part of the problem was, at least in the early days,
the author was very clear that it expressly wasn't intended to cover the
needs of 100% of packages, just like 99% or whatever. On top of that,
certain design considerations which were *intended* to avoid
fragmentation within the dub package ecosystem had the unintended
consequence of forcing a divide between "dub packages which have the
luxury of playing by dub's rules" and "non-dub packages which *don't*
have that luxury". I think that's ultimately what led to the probelms we
have with dub, and I think solving them properly requires undoing years
fundamental dub design was that built directly upon those early
philosophies.
