On Wednesday, 11 December 2013 at 09:47:27 UTC, Sönke Ludwig
The current GIT master version now outputs a clearer message,
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
(maybe a better name would be "cache" or "build-cache"). IDE
and external tools shouldn't ever look at it. The final build
will be located in the specified "targetPath", which is where
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
projects will usually use their own way of storing different
results. Are there any other tools you are thinking about which
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
They are just different "build types" which pass different
flags to the
compiler. Everything else stays the same. The build cache is
- but assuming it does its job right, it shouldn't change the
of the (re)build process.
Right, if there was a build-type suffix and targetName supported
it, I could do:
Regarding the suffixes (or pre-/infixes), the foremost issue is
suit everyone's taste ("d"/"debug"/"dbg") without going crazy
required configuration on package.json. That plus that I
understood why this is really needed to solve the problem. I'd
prefer a simple (to the outside) solution that "just works"
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.