On Wednesday, 29 April 2015 at 11:46:57 UTC, Dicebot wrote:
> Which is exactly why "all source builds with same flags" is the only reasonable compilation model for D.

If you compile all libraries in unittest mode, you get full set of unit tests from those libraries and the proposed change doesn't affect you in the least, it only affects linking with a library compiled in release mode.

On Wednesday, 29 April 2015 at 14:10:32 UTC, Kagamin wrote:
> On Wednesday, 29 April 2015 at 11:46:57 UTC, Dicebot wrote:
>> Which is exactly why "all source builds with same flags" is the only reasonable compilation model for D.
>
> If you compile all libraries in unittest mode, you get full set of unit tests from those libraries and the proposed change doesn't affect you in the least, it only affects linking with a library compiled in release mode.

The core of Nick proposal (and what he does in his own libraries) is to not compile tests of dependnecies even when those are all compiled at once in -unittest mode. He uses `version(MyLibUnittest)` to disable all those completely and to run all tests you need to provide full set of such version flags for each dependency (transitively). This is what affects me and what I don't see implemented as a default.

(P.S. release and -unittest are not exclusive in D, I presume you have meant "release non-test mode" :P)

On 4/29/15 7:43 AM, Dicebot wrote:
> On Wednesday, 29 April 2015 at 04:53:47 UTC, Steven Schveighoffer wrote:
>> or rdmd -main -unittest -> fail to build because the templated unit
>> test doesn't work on your code. Good luck with that.
>
> I will create an upstream PR to fix it, problem solved. Have never had a
> need to do so though, not even a single time.
>
> Also : can you please point me again what part of RBT causes compilation
> slowdowns with version(unittest)? I looked through and found only
> runtime checks.

It's runtime checks that slow down, the unit test compilation is not slow (although it was at one point, but that was for the proper full unit tests).

> And for that "move out of the aggregate" + "runtime test
> filtering" does what you want.

Move out of the aggregate makes it oh so ugly. I want my unit tests right where they belong.

Runtime test filtering seems like it adds more complexity to the system unnecessarily. All I need is a way to say "yes compiler, I want to run those templated unit tests I imported" or "no compiler, I don't want to do that". What the default is really isn't important.

>> Again, there are so many reasons I should not have to worry about unit
>> tests in my library being run with your code. That's on you. I didn't
>> write it for your code to run, if you want to run it, run my unit test
>> script.
>
> If you don't wan't to run it, filter it out in the test runner. I assure
> you, there are at least as much reasons why I shouldn't worry if you
> actually run tests for your library and how those need to be run. Both
> defaults can be circumvented.

I don't *care* if you run it. But the compiler shouldn't force you to. The funny thing is, you DON'T run imported non-template unit tests, because the compiler doesn't make you (and actually doesn't allow you to). So why should this be any different? A unit test is supposed to test the unit, not the world.

-Steve

On Wednesday, 29 April 2015 at 15:00:53 UTC, Dicebot wrote:
> The core of Nick proposal (and what he does in his own libraries) is to not compile tests of dependnecies even when those are all compiled at once in -unittest mode.

If they are compiled in unittest mode, all their unittests are compiled and run. What's problem?

> He uses `version(MyLibUnittest)` to disable all those completely and to run all tests you need to provide full set of such version flags for each dependency (transitively). This is what affects me and what I don't see implemented as a default.

If the enhancement is implemented, that hack with versions won't be needed, all tests will be plain unittests, which will suit both you and Nick.

On 04/28/2015 07:04 PM, Dicebot wrote:
>
> I do want do test everything as part of my app tests, including all
> possible dependencies, transitively.

Even Phobos?

> This is awesome default. With a
> simple `rdmd -main -unittest` call I can ensure that certain app/module
> works correctly without having to trust maintainers of dependencies to
> run tests regularly and without even knowing what those dependencies
> are. It is beautiful in its simplicity which makes it good default.
>

On Thursday, 30 April 2015 at 02:26:19 UTC, Steven Schveighoffer wrote:
> On 4/29/15 7:43 AM, Dicebot wrote:
>> On Wednesday, 29 April 2015 at 04:53:47 UTC, Steven Schveighoffer wrote:
>>> or rdmd -main -unittest -> fail to build because the templated unit
>>> test doesn't work on your code. Good luck with that.
>>
>> I will create an upstream PR to fix it, problem solved. Have never had a
>> need to do so though, not even a single time.
>>
>> Also : can you please point me again what part of RBT causes compilation
>> slowdowns with version(unittest)? I looked through and found only
>> runtime checks.
>
> It's runtime checks that slow down, the unit test compilation is not slow (although it was at one point, but that was for the proper full unit tests).

Then test separation + custom runtime filter fixes the issue without language changes.

>> And for that "move out of the aggregate" + "runtime test
>> filtering" does what you want.
>
> Move out of the aggregate makes it oh so ugly. I want my unit tests right where they belong.
>
> Runtime test filtering seems like it adds more complexity to the system unnecessarily. All I need is a way to say "yes compiler, I want to run those templated unit tests I imported" or "no compiler, I don't want to do that". What the default is really isn't important.

It is exactly the other way around. Implementing such compile-time filtering would mean adding totally new feature to the language, considerably complicating version system which is very simple right now. And remembering all the issues we had with -allinst it will take a while to figure out. You need something better than "ugly" to justify such language change. Especially when there is a working solution within existing rules - even if it seems ugly, it is achievable without language changes and addresses the issue.