Answers needed from those using D for Web Development, Web APIs and Services

[H. S. Teoh]

On Fri, Dec 22, 2017 at 06:21:04PM +0000, Russel Winder wrote:
> On Fri, 2017-12-22 at 09:42 -0800, H. S. Teoh via Digitalmars-d wrote:
> […]
> > that are a pain to manage. Yes I know dub does it "automatically",
> > but the problem with dub is that it tries to do too much -- it wants
> > to be a build system in addition to being a packaging system. The
> > former is OK, I guess, even though I really wish it was more
> > configurable in terms of how it manages local repository caches. But
> > as a build system, I'm sorry to say that dub sucks. Or at least, its
> > docs suck, 'cos I can't figure out how to make it do what I want.
> > After struggling with it for about a week or two, I threw in the
> > towel and went back to SCons.  Nowadays I only use dub for updating
> > vibe.d via a dummy blank project.
> > 
> […]
> 
> Just to reiterate, SCons D support now has a ProgramAllAtOnce builder
> for those that want to use Unit-Threaded in their D codebases using
> SCons.

For D projects, I've been finding that Command() has been the best tool
for me in terms of configuring exactly how I want things built. I used
to use (early versions of) your SCons D build tools (and thanks for
that!), but ultimately went back to Command() because I found it very
frustrating to have my builds break because of an incompatible change in
the D tooling whenever I upgrade SCons.  So until the SCons D tooling
API has stabilized, I'll probably hold off for the time being.

Also, for vibe.d projects, I've been finding the need to write my own
scanner in order to pick up Diet template (*.dt) dependencies, so that
builds would trigger correctly when Diet templates are changed. There is
no standard way to do this, unfortunately; so far I've been scanning for
`render!(.*)` lines, but this doesn't always work if `render` is
instantiated with parameters generated from CTFE.  Manual hardcoding has
been necessary to get this part of my dependency tree to work.

In the long term, I think an approach similar to tup will have to be
adopted. O(n) dependency scanning just doesn't cut it anymore for code
the size of today's large software projects. And with dynamic
dependencies (e.g. CTFE-dependent imports) that are bound to happen in D
code with heavy metaprogramming, there's really no sane way to manage
dependencies explicitly; you really need to just instrument the compiler
and record all input files it reads the way tup does.  I shouldn't be
needing to write custom scanners just to accomodate CTFE-generated
imports that may change again after a few more commits. It's SSOT
(single source of truth) all over again: the compiler is the ultimate
authority that determines which file depends on what, and having to
repeat this information in your build script (or independently derive it
via scanners) introduces fragility / incompleteness into your build
system.


> Also I have the beginnings of a Dub SCons tool for using Dub as a
> package manager in a SCons build.
[...]

That's nice, though for now, I'm sticking with manually updating my
dependencies when needed.  One thing I found annoying with dub was the
sheer amount of time it spent at startup to scan all dependencies and
packages and possibly downloading a whole bunch of stuff. The network
latency really kills the compile-test-debug cycle time.  I know there's
a switch to suppress this behaviour, but the initial dependency scanning
is still pretty slow even in spite of that.  When a 1-line change
requires waiting 15-20 seconds just to recompile, that really breaks my
workflow.

Plus, sometimes I *don't* want anything updated -- when debugging a
program, the last thing I want is for dub or the build script or
whatever to decide to link in a slightly different version of a library,
and suddenly I'm no longer sure if the new crash is caused by the
library or my own code, or the bug may now be masked by the slightly
different behaviour of an upgraded library.

I know that for people who want things done for them automatically and
handed over on a silver platter, dub is great.  Unfortunately, it
doesn't work for me. (But I also know that I don't represent typical
usage, so take all this with a grain of salt.)


T

-- 
Маленькие детки - маленькие бедки.