Git, the D package manager

Sönke Ludwig via Digitalmars-d digitalmars-d at puremagic.com
Thu Feb 5 08:14:10 PST 2015


Am 05.02.2015 um 16:51 schrieb Atila Neves:
> On Thursday, 5 February 2015 at 15:46:57 UTC, Sönke Ludwig wrote:
>> Am 03.02.2015 um 09:51 schrieb ketmar:
>>> On Tue, 03 Feb 2015 02:19:55 +0000, Martin Nowak wrote:
>>>
>>>> There seems to be a general scepticism against dub and I wonder what
>>>> the
>>>> reasons are.
>>>
>>> 'cause it really sux as a build tool.
>>>
>>
>> Just to state the design perspective for a little bit of rationale:
>> DUB is not designed to be a build tool itself, but rather to operate
>> on a meta level, able to invoke other build tools or to generate
>> foreign build descriptions, similar to what CMake and similar systems
>> do. This is the reason why its own build system is rather simple (i.e.
>> hasn't received enough work to be more comprehensive) and doesn't yet
>> support things like incremental builds (there are additional reasons
>> for this, though). It's meant to provide a convenient default
>> functionality, but doesn't claim to be fully featured.
>
> Which is fair enough. I want to contribute and write a fully featured
> one, though. Either as a plugin, a self-contained tool that builds on
> dub or something else. How do you suggest I proceed, if at all?
>
> Atila

I think my personal favorite would be to directly improve the existing 
build system [1]. This would have the strongest impact, as everyone 
using DUB would directly profit. We'd still have to decide if/how the 
build functionality should be separated into another executable or 
shared library, but that wouldn't invalidate the existing work.

Directly creating a separate tool that invokes "dub describe" to get the 
required build information would of course have the advantage of 
explicitly separating building from package meta information gathering 
right from the start. But it has the disadvantage that it requires some 
more work up front to convert the JSON back into a more manageable 
runtime representation and we'd have to think about how this will all 
fit together in the long run (e.g. does the user invoke the build tool 
directly or does DUB do that? Or do we maybe implement some git-like 
plug-in functionality, so that "dub build" calls "dub-build" internally?)

[1]: 
https://github.com/D-Programming-Language/dub/blob/master/source/dub/generators/build.d


More information about the Digitalmars-d mailing list