On 9/16/2011 11:18 AM, Andrej Mitrovic wrote:
I'd like to turn some attention to unittests, which don't seem to work
with static libraries. Consider:
..\main.d:
import mylib.test;
void main()
{
auto x = foo();
}
..\mylib\test.d
module mylib.test;
int foo() { return 1; }
unittest { assert(0); }
$ dmd -unittest main.d mylib\test.d&& main.exe
core.exception.asserter...@mylib.test(5): unittest failure
So far so good. It even works if I don't reference foo() from within
main(), even though the "unittest.d" file in Phobos has this comment
about it:
"// Bring in unit test for module by referencing function in it"
I think that comment might be outdated.
But now try it with a static library:
$ cd mylib
$ dmd -unittest -lib test.d
$ cd..
$ dmd -unittest main.d mylib\test.lib&& main.exe
The unittests from the library don't run.
There's a bug about this in bugzilla somewhere (I just can't seem to
find it now), but it doesn't seem to be getting much attention. Since
unittests are first-class citizens in D, I really hope we can get this
working soon. Cheers.
I think the main issue here is that a module that is compiled to a
library, is split into a lot of small "object files" (one for each
function or global variable) before being combined to the library. This
allows the linker to just take the actually referenced parts and leave
out anything that is never called.
The unit tests are only referenced from the module info, so it might
work if you have a reference to it in your main executable.
Another workaround would be to build the library in two steps, compiling
to normal object files first, then binding these to a library (shameless
ad: "separate compile and link" in Visual D):
dmd -unittest -c -od. test1.d test2.d
dmd -lib -oftest.lib test1.obj test1.obj
so it avoids breaking up the modules. the -od. is needed to not just
build a single object file.
