DUB 0.9.20

[Sönke Ludwig]

Am 06.12.2013 22:55, schrieb Mathias Lang:
> Great work, thank you Sönke !
> 
> 
> 2013/12/6 Sönke Ludwig <sludwig at outerproduct.org
> <mailto:sludwig at outerproduct.org>>
> 
>     You need to delete the one in .dub/build/, the one in the target
>     directory is just a copy of that one. BTW there is now a "dub build
>     --force" switch, which forces a recompilation, and a "dub clean" command
>     will also be added later. 
> 
> 
> Did you ever consider letting users add their own "recipe" (in Makefile
> terminology).
> ie, let them extend dub the same way you can extend git: one would put a
> bash / D / FancyScriptLanguage script under [~/].dub/whatever/deploy,
> and calling dub deploy would call that script, passing it the
> package.json data.

Incidentally, I've planned to look into something like this (for
deployment), too, a few days ago. In the beginning, there was also the
plan to provide a mode to run an external tool using "dub tool
<executable>". The tool would then receive a bunch of environment
variables that describe the current package.

But regarding the git-like extensibility, I'm not sure if it's not
better to let extensions rather be separate tools ("dub-deploy") to
avoid naming conflicts or backwards compatibility issues between the
core package and extensions.

>  > Also, it would be nice if there was a way to output to a different
> 
>     > target name for debug vs release builds of a library. It's quite
>     common
>     > to have both live side-by-side, with the debug builds
>     differentiated by
>     > a suffix -d or similar.
> 
> That's something I found myself missing alot in D. Those little trick
> aren't much of a pain to implement on the tool side, but they're
> definitely a huge gain on the user side.

Do you actually need to have both binaries at the same time in the same
directory, or would copying it there just before starting up the
application also be enough? I'm asking because there will probably be no
single schema that all people will be happy with and considering the
issues that arise from that, I'd rather avoid that feature if the same
goals can be achieved differently.