On 12/22/19 5:22 PM, Per Nordlöw wrote:
> On Sunday, 22 December 2019 at 15:23:32 UTC, Martin Nowak wrote:
>> Glad to announce the first beta for the 2.090.0 release, ♥ to the 48 contributors.
>>
>> http://dlang.org/download.html#dmd_beta
>> http://dlang.org/changelog/2.090.0.html
>>
>> As usual please report any bugs at
>> https://issues.dlang.org
>>
> 
> I've gotten very used to running my app via
> 
>      dub run --compiler=dmd --build=unittest
> 
> in order to, with short iterations, run tests and the application at the same time.
> 
> Changing this behaviour via
> 
> https://dlang.org/changelog/2.090.0.html#unittest-default
> 
> is, to me, an usually disruptive change.

It's a long overdue change IMO. The original intention was to have it switched on version 2.080, but I forgot about it. Most of the time, if you are unittesting, you aren't building exactly production code, so there's no reason to run the main function.

Most people used to do this:

```
version(unittest) void main() {}
else
int main(string[] args) {
   ... // normal application
}
```

Which is somewhat embarrassing for the language to have to do this.

> 
> I tried changing to
> 
>      dub run --compiler=dmd --build=unittest -- --DRT-testmode=run-main
> 
> but it still doesn't run the application after the unittests are run.

The issue is that dub is built with D! So dub is actually consuming that option without trying to.

There's an open bug on it: https://github.com/dlang/dub/issues/1280

> Have I missed something or is this a known problem with dub? If so, do I have any alternative to brute-forcing the problem with
> 
>      dub run --compiler=dmd --build=unittest
>      dub run --compiler=dmd --build=debug
> 
> which, for me, doubles my development iteration time.

Option a: don't use dub run.

dub build --compiler=dmd --build=unittest && ./application --DRT-testmode=run-main

Option b: you can also set a DRT switch inside your code:

https://dlang.org/phobos/rt_config.html

e.g.:

extern(C) __gshared string[] rt_options = [ "testmode=run-main"];

There are far more people who run unittests as a separate step from running their application. If unittests pass, then there's no distinguishable output from a build without unittests. I can totally imagine accidentally shipping code with unittests in it without intending to.

But I can totally see your use case during development. It should work with dub run, I hope it gets fixed.

-Steve

On 12/22/19 4:04 PM, Steven Schveighoffer wrote:
> I haven't tested, but the frameworks should be fine.

FYI, here is where d-unit overrides the behavior:

https://github.com/linkrope/dunit/blob/e78971a27395169158458e3ab1c35b61c67079f4/src/dunit/framework.d#L772-L775

Doing this prevents any unittest from being run before main, so the default behavior will be ignored.

-Steve

On Sunday, 22 December 2019 at 22:22:26 UTC, Per Nordlöw wrote:
>
> Have I missed something or is this a known problem with dub? If so, do I have any alternative to brute-forcing the problem with
>
>     dub run --compiler=dmd --build=unittest
>     dub run --compiler=dmd --build=debug
>
> which, for me, doubles my development iteration time.

If it's something common enough, I suggest just creating an alias such as `dubtest` which does `dub test --compiler=dmd && dub run --compiler --build=debug`.
Should you want to change compiler, you can make it a function that takes an argument.

The druntime issue with `--DRT` is something that is on the map, and should be fixed soon, but I can't promise it will be fixed before the release, as it requires a druntime fix.
Alternatively, some other bugs need to be fixed for the druntime fix to be truly efficient.

On 12/22/19 8:23 PM, Mathias Lang wrote:
> On Sunday, 22 December 2019 at 22:22:26 UTC, Per Nordlöw wrote:
>>
>> Have I missed something or is this a known problem with dub? If so, do I have any alternative to brute-forcing the problem with
>>
>>     dub run --compiler=dmd --build=unittest
>>     dub run --compiler=dmd --build=debug
>>
>> which, for me, doubles my development iteration time.
> 
> If it's something common enough, I suggest just creating an alias such as `dubtest` which does `dub test --compiler=dmd && dub run --compiler --build=debug`.
> Should you want to change compiler, you can make it a function that takes an argument.
> 
> The druntime issue with `--DRT` is something that is on the map, and should be fixed soon, but I can't promise it will be fixed before the release, as it requires a druntime fix.
> Alternatively, some other bugs need to be fixed for the druntime fix to be truly efficient.

The solution is already available since 2.084. Dub just needs to ignore DRT options.

See info about rt_cmdline_enabled here: https://dlang.org/phobos/rt_config.html

-Steve

On Sunday, 22 December 2019 at 20:30:06 UTC, berni44 wrote:
> On Sunday, 22 December 2019 at 19:00:15 UTC, Eugene Wissner wrote:
>> Probably differen email addresses. You can set an email address locally for the repository in .git/config. Or just add an alias: https://github.com/dlang/tools/blob/master/.mailmap
>
> git config -l reveals only one address (which is set at global level; there is no local and no systemwide email address). It's the same I use in github. In bugzilla I use a different one, but I guess, that this is not relevant.

It looks like you made a commit via the GitHub UI. By default it uses a default generated (<...>@users.noreply.github.com) email address. You can change this in your GitHub user settings.

Anyhow, I went ahead and made a PR to "reduce" you to only one person ;-)

https://github.com/dlang/tools/pull/388

For future readers, here's how I found out the other email address:

$ ./contributors.d -f git "v2.075.0..master" | grep -i berni

On Sunday, 22 December 2019 at 23:05:20 UTC, Steven Schveighoffer wrote:
> extern(C) __gshared string[] rt_options = [ "testmode=run-main"];
>
> There are far more people who run unittests as a separate step from running their application. If unittests pass, then there's no distinguishable output from a build without unittests. I can totally imagine accidentally shipping code with unittests in it without intending to.

Thanks.

So what is now the difference between

    dub run --build=unittest

and

    dub test

?

On Monday, 23 December 2019 at 21:59:42 UTC, Per Nordlöw wrote:
> On Sunday, 22 December 2019 at 23:05:20 UTC, Steven Schveighoffer wrote:
>> extern(C) __gshared string[] rt_options = [ "testmode=run-main"];
>>
>> There are far more people who run unittests as a separate step from running their application. If unittests pass, then there's no distinguishable output from a build without unittests. I can totally imagine accidentally shipping code with unittests in it without intending to.
>
> Thanks.
>
> So what is now the difference between
>
>     dub run --build=unittest
>
> and
>
>     dub test
>
> ?

dub test doesn't run the actual program only unittests are far as I can tell.

On Tuesday, 24 December 2019 at 05:59:35 UTC, Soulsbane wrote:
> dub test doesn't run the actual program only unittests are far as I can tell.

Correct, but that is from 2.090 the behaviour of

    dub run --build=unittest

aswell. This seems strange to me.

I would like to see a new built-in build target in dub, say

    dub run --build=unittest-debug

, that mimics the behaviour of

    dub run --build=unittest

prior to 2.090.

On 12/23/19 4:59 PM, Per Nordlöw wrote:
> On Sunday, 22 December 2019 at 23:05:20 UTC, Steven Schveighoffer wrote:
>> extern(C) __gshared string[] rt_options = [ "testmode=run-main"];
>>
>> There are far more people who run unittests as a separate step from running their application. If unittests pass, then there's no distinguishable output from a build without unittests. I can totally imagine accidentally shipping code with unittests in it without intending to.
> 
> Thanks.
> 
> So what is now the difference between
> 
>      dub run --build=unittest
> 
> and
> 
>      dub test
> 
> ?

dub test adds its own main function and unittest handler (and actually the function is based on the old unittest system, so it won't print the tests run or number of failures. It usually only works for libraries which don't have a main function.

-Steve

On Sunday, 22 December 2019 at 15:23:32 UTC, Martin Nowak wrote:
> As usual please report any bugs at
> https://issues.dlang.org

Not sure, if this is a bug, but --DRT-testmode=run-main seems to have no effect here.

Example:

---
import std.stdio;

unittest
{
    assert(1==1);
}

void main(string[] argv)
{
    writeln("X");
}
---

$> dmd -unittest -g -run test.d
1 unittests passed
$> dmd -unittest --DRT-testmode=run-main -g -run test.d
1 unittests passed

In both cases main is not executed. I thought, in the second one it should...