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.
