On Thursday, March 15, 2018 07:17:47 H. S. Teoh via Digitalmars-d wrote: > On Thu, Mar 15, 2018 at 12:14:12PM +0000, Jacob Carlborg via Digitalmars-d wrote: > > On Thursday, 15 March 2018 at 05:22:45 UTC, Seb wrote: > > > Hmm how would this solve the StdUnittest use case? I.e. that > > > templated phobos unittests and private unittest symbols are compiled > > > into the users unittests? > > > > > > See also: > > > > > > https://github.com/dlang/phobos/pull/6202 > > > https://github.com/dlang/phobos/pull/6159 > > > > I would hope this would be solvable without the having the user do > > something, like `-unittest=<pattern>`. > > [...] > > Even that would be preferable to the current situation.
Being able to run easily run the unit tests for a specific module without much effort would be nice, but as far as the overall unittest problem goes, it doesn't really fix it, just work around it. And if all we're looking for is a workaround, we can always use a project-specific version identifier and version off the unit test code - and that works right now without any compiler changes. It gives full control of the situation and gives essentially what we really want in terms of the resulting binary. It also ensures that projects importing you're library don't end up with your unit test code in their project no matter how they compile theirs (short of figuring out your project-specific version identifier and explicitly compiling with it for some, weird reason anyway). It's just a really sucky thing to have to do. I was forced to do it with dxml though due to a weird linker error that projects importing dxml got when building their unit tests. What we really want is essentially what such a project-specific version identifier does but without having to use a project-specific identfier. - Jonathan M Davis