dmd -unittest=<pattern> (same syntax as -i)

Jonathan M Davis newsgroup.d at jmdavisprog.com
Thu Mar 15 14:43:33 UTC 2018


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



More information about the Digitalmars-d mailing list