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 -- Маленькие детки - маленькие бедки.