I want to enable unittests only at the top-level of a module compilation.

If I have a module

    top.d

that imports

    dep1.d
    dep2.d
    ...

which all contain unittests, how do I compile top.d with only the unittests for top.d enabled?

On Monday, 21 March 2016 at 10:29:36 UTC, Nordlöw wrote:
> I want to enable unittests only at the top-level of a module compilation.
>
> If I have a module
>
>     top.d
>
> that imports
>
>     dep1.d
>     dep2.d
>     ...
>
> which all contain unittests, how do I compile top.d with only the unittests for top.d enabled?

I think the easiest solution is to use http://dlang.org/spec/traits.html#getUnitTests and to run the tests you want manually.

On Monday, 21 March 2016 at 10:37:31 UTC, ZombineDev wrote:
> On Monday, 21 March 2016 at 10:29:36 UTC, Nordlöw wrote:
>> I want to enable unittests only at the top-level of a module compilation.
>>
>> If I have a module
>>
>>     top.d
>>
>> that imports
>>
>>     dep1.d
>>     dep2.d
>>     ...
>>
>> which all contain unittests, how do I compile top.d with only the unittests for top.d enabled?
>
> I think the easiest solution is to use http://dlang.org/spec/traits.html#getUnitTests and to run the tests you want manually.

This is quite annoying I feel.

There probably should be an option for the -unittest flag to only compile unittests for the source files I'm passing in, and not any of the tests in the -I import paths.

On Monday, 21 March 2016 at 11:36:10 UTC, wobbles wrote:
> This is quite annoying I feel.
>
> There probably should be an option for the -unittest flag to only compile unittests for the source files I'm passing in, and not any of the tests in the -I import paths.

I very much agree.

On Monday, 21 March 2016 at 15:11:31 UTC, Nordlöw wrote:
> On Monday, 21 March 2016 at 11:36:10 UTC, wobbles wrote:
>> This is quite annoying I feel.
>>
>> There probably should be an option for the -unittest flag to only compile unittests for the source files I'm passing in, and not any of the tests in the -I import paths.
>
> I very much agree.

This is because my project has grown beyond 30klines of code and at that scale not even D's speed is enough for getting fast incremental builds through dmd.

Therefore I've split my project into separate build using scons. With good dependency design I've reduced the build time from around 12 (via one single call to dmd) to 2 seconds.

I don't see any other solution for really large projects.

On Monday, 21 March 2016 at 15:15:41 UTC, Nordlöw wrote:
> This is because my project has grown beyond 30klines of code and at that scale not even D's speed is enough for getting fast incremental builds through dmd.

Note that lines of code isn't really important to build time...

$ time dmd -c -o- dom.d cgi.d web.d sha.d libssh2.d simpledisplay.d color.d minigui.d terminal.d characterencodings.d

real    0m1.063s
user    0m0.986s
sys     0m0.075s

$ wc dom.d cgi.d web.d sha.d libssh2.d simpledisplay.d color.d minigui.d terminal.d characterencodings.d
  6645  22789 173999 dom.d
  3994  16063 123572 cgi.d
  4921  18287 143876 web.d
   412   1407  10066 sha.d
   189    478   5357 libssh2.d
  8850  34060 274340 simpledisplay.d
  1163   4413  27268 color.d
  2785   8150  70996 minigui.d
  3834  13888 114827 terminal.d
   473   2819  18391 characterencodings.d
 33266 122354 962692 total




Yes, compiling 33,000 lines from my libs happened in about one second.


My experience with slow D builds tends to be that it is caused by CTFE, not by scale.

On Monday, 21 March 2016 at 15:15:41 UTC, Nordlöw wrote:
> I don't see any other solution for really large projects.

Except implementing memoized execution of unittests into dmd. Which I have discussed previously :)

On Monday, 21 March 2016 at 15:25:29 UTC, Adam D. Ruppe wrote:
> Yes, compiling 33,000 lines from my libs happened in about one second.
>
> My experience with slow D builds tends to be that it is caused by CTFE, not by scale.

These kinds of modules are very different from the ones I'm working on. Especially the ones in

https://github.com/nordlow/phobos-next

This because many of my algorithms/ranges/containers are unittested with lots of combinations of template parameters (types) for robustness. This inevitable requires lots of CT-logic evaluation and of course takes long to compile.

A compiler switch would significantly lower the iteration time in my workflow. 5-10 seconds => ~ 1 second.

Could somebody at least outline where in the DMD source I should start digging for this?

On Monday, 21 March 2016 at 10:29:36 UTC, Nordlöw wrote:
> I want to enable unittests only at the top-level of a module compilation.
>
> If I have a module
>
>     top.d
>
> that imports
>
>     dep1.d
>     dep2.d
>     ...
>
> which all contain unittests, how do I compile top.d with only the unittests for top.d enabled?

Version the unittests, perhaps.

module depN;

version (TestDeps)
unittest {
    // ...
}

Then dmd -unittest -version=TestDeps if you want them run.

On Thursday, 21 April 2016 at 12:35:42 UTC, Anonymouse wrote:
> Then dmd -unittest -version=TestDeps if you want them run.

This doesn't make things easier. I want to disable the builtin unittests of the modules I've imported. This requires me to add a

version(test_MODULE) unittest

in each module named MODULE.

This is really inconvenient.