On Saturday, December 15, 2018 10:27:36 AM MST Neia Neutuladh via
Digitalmars-d-learn wrote:
> On Sat, 15 Dec 2018 17:19:05 +0000, Timoses wrote:
> > Running `dub test` will output:
> > Running ./unit-test-library writeln: unittest All unit tests have been
> > run successfully.
> >
> > Why is the `shared static this()` not executed?
>
> Run `dub clean; dub test -v` and you'll see that main.d isn't compiled
> into the test library.
>
> dub test substitutes its own main() function over yours. In order to do
> this, it needs to not compile in your main() and to compile in its own.
> dmd doesn't have an option to replace main(), so dub drops that entire
> source file.
Yeah. I hate how dub does this. I've been bitten by it on multiple
occasions, and it's really easy to miss that this is happening. It probably
would have been better if it required you to deal with main when the target
type is an executable, resulting in a linker error when you didn't provide
one. Instead, a number of us do stuff like
version(unittest) void main() {}
void main()
{
...
}
thinking that it's working, but whatever tests in the module with main
simply don't get run, because that module isn't compiled in. Maybe dub
should check the module with main to see if it contains any unittest blocks
and print out warning if it does, but even if it did, it actually wouldn't
have caught this case, because it involves a static constructor, not a
unittest block.
Anyway, the way that dub deals with this probably makes it so that the best
thing to do in general is to make it so that the module with main is pretty
much literally something like
int main(string[] args)
{
import somemodulename;
return realmain(args);
}
But of course, that just makes it so that you're less likely to accidentally
do something like create a static this which won't be called with -unittest
when you already know that that sort of thing is a problem with dub test. It
doesn't help those folks who aren't aware of this behavior or who forget it.
- Jonathan M Davis
