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.

Reply via email to