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. > >> In the works for the next version is, among other things, a "dub test" >> [2] command which executes unit tests (and possibly other kinds of tests >> later) using a custom main() function, especially useful for automated >> testing and testing of libraries without a main() function. > > It has been said already in this thread, but for library targets it must > ignore the lack of a "main source file". It should go without saying > that libraries generally don't have such a thing. I'll work through that topic in the next days. If nothing requires it, the warning will be removed and "dub test" will auto generate such a file when needed. > > --- > > Also, it would be nice if there was a way to output to a different > target name for debug vs release builds of a library. It's quite common > to have both live side-by-side, with the debug builds differentiated by > a suffix -d or similar. 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.
