On Wednesday, 4 February 2015 at 19:15:16 UTC, Jacob Carlborg
wrote:
On 2015-02-02 09:09, Vladimir Panteleev wrote:
Even if I had faith that dub was a perfectly polished piece of
software,
it doesn't solve any problems I have with building D programs,
and in
fact would make said task more complicated. Here's why.
1. rdmd
rdmd is a simple and effective way to build D programs, and
I'm sad to
see its use declining.
rdmd leverages two things: D's module system, and the
compiler's import
search path. Dub's design seems to ignore both of the above.
I think one of the biggest advantage of Dub is the registry,
code.dlang.org.
Another thing is it supports a cross-platform way of configure
a build. Just take a simple thing as linking a static library
will most likely look different on different platforms. Also,
you most likely need a wrapper script that calls rdmd with all
arguments. There's basically no language that works on both
Windows and Posix out of the box. The only choice is to either
go with one file for Posix (shell script) and one for Windows
(batch files). Or you could go with D, which seems a bit
overkill for just a passing a couple of flags.
It depends on how you define "out of the box", I guess. I can
(and have) easily build C and C++ on Windows, Linux and Mac OS X
with CMake. Static library? Here you go:
add_library(mylib STATIC foo.cpp bar.cpp)
Done. Pretty sure it's the same with premake, gradle, ...
D might be overkill for passing a couple of flags, but then you
always have rdmd. Unless you have package dependencies, then you
use dub, with the already mentioned caveats. But it's not
overkill when your build has an autogenerated file that gets
built from a D binary that includes some other files which...
You get the idea. dub's lack of features is only mildly annoying
for my current D projects, they're small. I end up waiting a
little longer for builds. But if I had a large codebase, which I
would if I had a D-based startup, I'd need a hell of a lot more.
Atila
