This is getting to be (or rather, *continuing* to be) a royal PITA:

https://github.com/rejectedsoftware/vibe.d/issues/673

I don't mean to pick on Vibe.d in particular, but can we have a solution (that doesn't involve obscure corners of druntime, or demanding everyone use the same build system) for running our unittests *without* triggering a cascading avalanche of unittests from ALL third party libs that don't cooperate with the [frankly] quite clumsy version(mylib_unittests) hack?!

On Tue, 09 Sep 2014 22:13:57 -0400
Nick Sabalausky via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

write build tool that is capable of doing that...

On Wednesday, 10 September 2014 at 02:14:39 UTC, Nick Sabalausky wrote:
> This is getting to be (or rather, *continuing* to be) a royal PITA:
>
> https://github.com/rejectedsoftware/vibe.d/issues/673
>
> I don't mean to pick on Vibe.d in particular, but can we have a solution (that doesn't involve obscure corners of druntime, or demanding everyone use the same build system) for running our unittests *without* triggering a cascading avalanche of unittests from ALL third party libs that don't cooperate with the [frankly] quite clumsy version(mylib_unittests) hack?!

A while ago, I though about adding an optional module/package whitelist as a compiler flag, something like -unittest=myapp,mylib.important. Never really got to implementing it, or even thinking about the implications in any details.

David

On Wednesday, 10 September 2014 at 02:29:41 UTC, David Nadlinger wrote:
> A while ago, I though about adding an optional module/package whitelist as a compiler flag, something like -unittest=myapp,mylib.important. Never really got to implementing it, or even thinking about the implications in any details.

s/compiler/rdmd/

On 9/9/2014 10:21 PM, ketmar via Digitalmars-d wrote:
> On Tue, 09 Sep 2014 22:13:57 -0400
> Nick Sabalausky via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> write build tool that is capable of doing that...
>

???
If you think that's reasonable when it's the COMPILER that inserts all those calls (or druntime, whatever), then go ahead with it yourself.

Seriously, DMD needs a "--omit-unittest=some.package.*". I'd try a PR myself (I'd have *already* tried), but last time I brought it up the whole idea was completely shot down in favor of both the version(mylib_unittests) hack (which people don't fucking use half the time, sometimes deliberately) and some goofy druntime trickery (ie, writing your own test runner and getting it to druntime before druntime gets to the "run unittests" phase. Seriously? That's *preferable* to a "--omit-unittest=some.package.*"??).

On 9/9/2014 10:37 PM, Nick Sabalausky wrote:
> On 9/9/2014 10:21 PM, ketmar via Digitalmars-d wrote:
>> On Tue, 09 Sep 2014 22:13:57 -0400
>> Nick Sabalausky via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>>
>> write build tool that is capable of doing that...
>>
>
> ???
> If you think that's reasonable when it's the COMPILER that inserts all
> those calls (or druntime, whatever), then go ahead with it yourself.
>

Well, ok, I guess it could be done with separate invocations of DMD, but that has non-trivial implications for build performance, and templates probably could still fuck it all up anyway.

On Wednesday, 10 September 2014 at 03:00:48 UTC, Nick Sabalausky wrote:
> separate invocations […] and templates probably could still fuck it all up anyway.

If so, then this is either a critical bug in DMD, or an issue with your code (e.g. due to version(unittest) use).

I'm aware of the issues that affect some ways of doing incremental compilation, but that's mostly a different story.

David

On 9/9/2014 11:07 PM, David Nadlinger wrote:
> On Wednesday, 10 September 2014 at 03:00:48 UTC, Nick Sabalausky wrote:
>> separate invocations […] and templates probably could still fuck it
>> all up anyway.
>
> If so, then this is either a critical bug in DMD, or an issue with your
> code (e.g. due to version(unittest) use).
>
> I'm aware of the issues that affect some ways of doing incremental
> compilation, but that's mostly a different story.
>
> David
>

I was thinking about something like this:

//a.d
import b.d;
alias x = Foo!whatever;

//b.d
struct Foo(Arg) {
    void foo() {...}
    unittest { /+...unittest foo()...+/ }
}

// Attempt to exclude module b's unittests, except...aren't
// they compiled when module a's is compiled? The first
// dmd invocation here has no idea module b will be compiled
// without the -unittest flag.
>dmd -c -unittest a.d
>dmd -c b.d   // Duplicate a whole buttload of processing here
>dmd a.o b.o

I think, libraries should support compilation without unittests, i.e. write unittests outside of templates. But then one may want to test every template instantiation, if it makes sense and intended.

It's questionable that testing every template instantiation is intended: you can't do the same for templated functions.