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
