DUB 0.9.20

[Jakob Ovrum]

On Wednesday, 11 December 2013 at 09:47:27 UTC, Sönke Ludwig 
wrote:
> 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.

Nice.

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

That was exactly my point. They need to be able to live 
side-by-side in the targetPath directory. You replied and told me 
they do live side-by-side in the cache directory, which I don't 
think is relevant.

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

 From your reply I assumed you meant adding something like a 
post-build command to copy the debug binary from the .dub/build/ 
directory to the targetPath directory if I wanted to have both 
release and debug binaries exist in targetPath simultaneously.

Consider a simple makefile that depends on 
dependency/lib/libname.a for release builds and 
dependency/lib/lib/libname-d.a for debug builds, or an IDE 
project that's configured similarly, or a zip script that needs 
to include both etc. The scenarios are endless, it's quite common 
practice.

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

Right, if there was a build-type suffix and targetName supported 
it, I could do:

"targetName-debug": "mylib-d"

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

A reasonable default helps with the "just works" factor for new 
projects, but existing projects need the suffix to be 
configurable so it can be backwards-compatible. It's also more 
practical to let users choose what suffix to use rather than 
pursuing the "ultimate" suffix for satisfying users' taste.