DUB 0.9.20

[Jakob Ovrum]

On Friday, 6 December 2013 at 19:57:17 UTC, Sönke Ludwig wrote:
> Am 06.12.2013 19:40, schrieb Jakob Ovrum:
>> On Friday, 29 November 2013 at 17:02:22 UTC, Sönke Ludwig 
>> wrote:
>>>  - Builds are now cached and only rebuilt when necessary for 
>>> "dub build"
>>>    and "dub run".
>> 
>> Deleting the output binary and then immediately running `dub 
>> build`
>> again fails horribly here; it seems to think the binary is up 
>> to date
>> even though it doesn't even exist. (Windows/DMD/x86, library 
>> target)
>
> 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.

I actually tried `dub clean` as a guess, so that would be 
appreciated. But I have to say it's unintuitive behaviour 
compared to something like `make`. Users should not be concerned 
with the contents of a hidden directory. Deleting the output 
binary to force a rebuild is intuitive to me and probably a lot 
of other programmers. Perhaps just make it copy the up-to-date 
binary from the .dub/build directory to the output directory, 
displaying a note about it, possibly with a suggestion to use 
`dub clean`.

> They currently live in parallel in different sub folders of 
> .dub/build/
> and switching between different builds is just a matter of a 
> single copy
> of the target file, as long as the builds are up to date. I 
> didn't yet
> have issues with this approach, but on the other hand not much 
> thought
> has gone into this part, yet.

Tools like makefiles, IDE project files and indeed Dub itself 
cannot depend on the contents of the .dub/build directory. Having 
them exist in parallel is only useful for dependency management 
if they can actually be referenced.

"Switching between the builds" is not useful when the whole point 
is that they should be able to exist at the same time, so that 
debug builds can use debug binaries, and release builds use 
release binaries, without any non-trivial fuzz in between such as 
copying, which is a royal pain with many tools when you're trying 
to write platform-independent projects.

Is there a particular reason why `targetName` doesn't support 
suffixes? And is there a suffix to differentiate between debug 
and release builds? I currently have no idea how Dub deals with 
the debug/release distinction at all, I can't find any 
documentation for it.