Am 02.02.2015 um 23:15 schrieb Nick Sabalausky:
On 02/02/2015 03:09 AM, Vladimir Panteleev wrote:
1a. rdmd and D's module system:
[...]
In contrast, Dub's default modus operandi is to blindly send to the
compiler all *.d files found in the "src" folder, whether they're
actually used or not. Not only can this be slower if not all modules are
always used, but it also won't work if the source code contains multiple
entry points, forcing you to write complicated configuration files (i.e.
do the computer's work for it).
This is one of my biggest beefs with dub, too, and constantly causes me
trouble. (I love that dub exists as a package manager, but I REALLY
dislike that it tries to be build system too. Especially since I don't
like the way its build functionality works.)
Short answer: This is required to properly support other build systems/IDEs.
In theory, dub does have the --rdmd switch to make it select source
files in a sane manner (by deferring to rdmd), but unfortunately it
doesn't get well-tested and frequently breaks:
https://github.com/D-Programming-Language/dub/issues/492
Briefly looking at it, I'm pretty sure that this is actually a DMD/RDMD
issue. The import statements for the internal event driver recently have
been made function local to speed up compilation. And if nothing has
changed, DMD simply doesn't output function local dependencies with -o-,
so that RDMD fails to include the proper modules.
1b. rdmd and D's search path
rdmd does not have any additional parameters to set up for where it
needs to look for source files, because it relies on the compiler's
search mechanism. Thus, if you can build your program with rdmd, "dmd
-o- program" will succeed, and usually vice versa.
In contrast, Dub builds its own search path using its JSON configuration
files, and has no equivalent of "dmd -o-".
There is no simple way to syntax-check just one file in a project when
using Dub. I rely on this a lot in my workflow - I configured a
syntax-check key in my editor, which I use almost as often as I save. A
syntax check (dmd -o-) is much faster than a full build, as it skips
parsing other parts of the project, code generation, and linking.
My #1 beef with Dub: It desperately needs a way to *just* obtain the
-o/-version/etc args to be passed directly into dmd/rdmd/ldmd/gdmd/etc.
Without that, dub is useless as a MERE package manager. It's either
packaging AND building, or nothing. (Ever try to use a recent version of
vibe.d in a project that *doesn't* use dub as its build system? PITA. It
isn't even recommended to do so.)
There is "dub describe" for this. There is also a pending feature to
support the use of shell variables instead of piping everything to stdout.
I tried to add that feature one time, but I had trouble grokking the
relevant section of dub's source :(
There's also one other big thing I don't like about it: It needlessly
reinvents and renames dmd's entire set of command switches. That isn't
even needed for ldc/gdc anyway since, last I heard, the ldmd and gdmd
wrappers exist. I pushed to get the *actual* compiler switched accepted
by dub, and the feature made it in, but trying to use it generates a big
giant warning for all your library's users complaining that the feature
*shouldn't* be used. Thus completely defeating the point. Argh.
The question is how tight everything should be bound to DMD. For
example, does SDC have an sdmd wrapper? The goal was to make the package
description independent of the compiler used to build it (at least in
most cases). An alternative way to using an own way to describe build
options would of course have been to always rely on DMD's option format
and translate as required (which is supported, as you already
mentioned). But that will in turn feel strange to anyone not using DMD.
Again, I love that Dub (and especially it's package repository) exists.
But dub just tries to hard to impose it's own way.
