Git, the D package manager

[Sönke Ludwig via Digitalmars-d]

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.
>