On Tue, Dec 11, 2018 at 09:54:06AM +0000, Atila Neves via Digitalmars-d-announce wrote: [...] > No reggae? https://github.com/atilaneves/reggae/
I recently finally sat down and took a look at Button, posted here a few years ago. It looked pretty good. One of these days I really need to sit down and take a good look at reggae. > dub is simple and has dependency management, and that's about it. > Speed? It's as slow as molasses and hits the network every time > unless explicitly told not to. Never mind if there's already a > dub.selections.json file and all of the dependencies are fetched > (which it could check but doesn't). According to Sönke's post elsewhere in this thread, these performance issues have been addressed in the latest version. I haven't tried it out to verify that yet, though. > Trying to do anything non-trivial in dub is a exercise in frustration. > The problem is that it's the de facto D package manager, so as soon as > you have dependencies you need dub whether you want to or not. After fighting with dub for 2 days (or was it a week? it certainly felt longer :-P) in my vibe.d project, I ended up just creating an empty dummy project in a subdirectory that declares a dependency on vibe.d, and run dub separately to fetch and build vibe.d, then I ignore the rest of the dummy project and go back to the real project root and have SCons build the real executable for me. So far, that has worked reasonably well, besides the occasional annoyance of having to re-run dub to update to the latest vibe.d packages. > dub works great if you're writing an executable with some dependencies > and hardly any other needs. After that... Yeah. Being unable to handle generated source files is a showstopper for many of my projects. As Neia said, while D has some very nice compile-time codegen features, sometimes you really just need to write an external utility that generates source code. For example, one of my current projects involves parsing GLSL source files and generating D wrapper code as syntactic sugar for calls to glUniform* and glAttrib* (so that I can just say `myshader.color = Vector(1, 2, 3);` instead of manually calling glUniform* with fiddly, error-prone byte offsets. While in theory I could use string imports and CTFE to do this, it's far less hairy to do this as an external step. Most build systems with automatic dependency extraction would fail when given this sort of setup, because they generally depend on scanning directory contents, but in this case the file may not have been generated yet (it would not be generated until the D code of the tool that generates it is first compiled, then run). So the dependency would be missed, resulting either in intermittent build failure or failure to recompile dependents when the generated code changes. It's not so simple to just do codegen as a special preprocessing step -- such tasks need to be treated as 1st class dependency tasks and handled natively as part of DAG resolution, not as something tacked on as an afterthought. T -- Music critic: "That's an imitation fugue!"