DUB 0.9.20

[Sönke Ludwig]

Am 09.12.2013 17:52, schrieb 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`.

The current GIT master version now outputs a clearer message, stating
that the existing binary from ".dub/build/.../" is used. It also
suggests to use "--force" to force a rebuild.

> 
>> 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.

The .dub/build/ folder is purely meant for DUB's built-in build system
(maybe a better name would be "cache" or "build-cache"). IDE projects
and external tools shouldn't ever look at it. The final build result
will be located in the specified "targetPath", which is where every
other entity except the build system should expect it.

> 
> "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.

I don't get this. The copying will be done by dub automatically and IDE
projects will usually use their own way of storing different build type
results. Are there any other tools you are thinking about which depend
on the presence of multiple build types?

> 
> 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.

They are just different "build types" which pass different flags to the
compiler. Everything else stays the same. The build cache is briefly
described in
https://github.com/rejectedsoftware/dub/wiki/Separate-compilation-and-caching-of-dependencies
- but assuming it does its job right, it shouldn't change the semantics
of the (re)build process.

Regarding the suffixes (or pre-/infixes), the foremost issue is how to
suit everyone's taste ("d"/"debug"/"dbg") without going crazy for the
required configuration on package.json. That plus that I haven't yet
understood why this is really needed to solve the problem. I'd by far
prefer a simple (to the outside) solution that "just works" without any
required configuration.