[phobos] Recent changes in unittests

[Andrei Alexandrescu]

The thundering silence in response to my concern below is that 
apparently one order of magnitude slowdown in unittesting speed is not 
important :o).

Anyhow, I posted 
https://github.com/D-Programming-Language/phobos/pull/1768 that attempts 
to make that better.

However, I have to question the rationale of the entire change. I think 
the right way to unittest is build ONE phobos module with -unittest, 
link it against libphobos, and run unittest. The symbols defined in that 
module will override the symbols defined by that same module inside the 
library, and the rest of the library will be pulled in appropriately.

This is exactly as unittests should be run - unittest one "unit" at a time.

Why have things been changed to painstakingly build one executable 
containing all modules built with -unittest?

If no good reason comes forward, I propose we change things.


Andrei


On 10/26/13 10:00 PM, Andrei Alexandrescu wrote:
> This seems to be http://goo.gl/NnX2Mq. It's quite a bummer because I
> have plenty of memory on my laptop and used this kind of command
> frequently:
>
> make generated/osx/debug/64/unittest/std/algorithm BUILD=debug MODEL=64
>
> In the old version that would build phobos in one invocation of dmd, and
> then only the unittest for algorithm. That all was a few seconds. Now
> the command (after only touching std/algorithm.d) takes 55 seconds, and
> trying different -jN options don't help much beyond freezing my machine
> for a few seconds.
>
> That's a huge pessimization, the kind that impacts working on Phobos
> significantly. Can we have some of both worlds, i.e. an option to enable
> compile-at-once vs. compile separately?
>
>
> Thanks,
>
> Andrei
>
> On 10/26/13 9:26 PM, Andrei Alexandrescu wrote:
>> Hello,
>>
>>
>> There have been some changes in the way phobos unittests are run, which
>> I must have missed. For the most part I'm noticing a significant
>> slowdown, and -j does not help as much as it used to.
>>
>> Is there a summary for these changes so I don't need to rummage through
>> the code?
>>
>>
>> Thanks,
>>
>> Andrei