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.

Reply via email to