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.


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

Reply via email to