On Saturday, 31 March 2018 at 21:37:13 UTC, Jonathan M Davis
wrote:
On Saturday, March 31, 2018 08:28:31 Jonathan Marler via
Digitalmars-d wrote:
On Friday, 30 March 2018 at 20:17:39 UTC, Andrei Alexandrescu
wrote:
> On 3/30/18 12:12 PM, Atila Neves wrote:
>> Fast code fast, they said. It'll be fun, they said. Here's
>> a D
>>
>> file:
>> import std.path;
>>
>> Yep, that's all there is to it. Let's compile it on my
>> laptop:
>> /tmp % time dmd -c foo.d
>> dmd -c foo.d 0.12s user 0.02s system 98% cpu 0.139
>> total
>
> Could be faster.
>
>> That... doesn't seem too fast to me. But wait, there's more:
>> /tmp % time dmd -c -unittest foo.d
>> dmd -c -unittest foo.d 0.46s user 0.06s system 99% cpu
>>
>> 0.525 total
>
> Not fast. We need to make -unittest only affect the built
> module. Even though it breaks certain uses of
> __traits(getUnittests). No two ways about it. Who can work
> on that?
>
> Andrei
If you approve of the -unittest=<pattern> approach then
timotheecour has already offered to implement this. It's
pattern matching would work the same as -i and would also use
the "implied standard exclusions" that -i uses, namely,
-unittest=-std -unittest=-etc -unittest=-core
This would mean that by default, just passing "-unittest"
would exclude druntime/phobos just like "-i" by itself also
does.
And every time you used another library, you'd have the same
problem and have to add -unittest=- whatever for each and every
one of them, or you would have to use -unittest= with
everything from your application or library rather than using
-unittest. I really don't see how that scales well, and it's
way too manual and too easy to screw up. It might be a decent
idea for a workaround, but it's not a great solution.
IMHO, this is really something that should be handled by the
compiler. It simply shouldn't be compiling in the unittest
blocks for modules that you're not compiling directly. And if
that's done right, then this whole problem goes away without
having to make sure that every project you work on is
configured correctly to avoid pulling in the unit tests from
everything that it depends on.
And maybe figuring out what to do about __traits(getUnittests)
complicates things, but it seems like the fact that we're even
having this problem is due to a flaw in the design of D's unit
tests and that that should be fixed, not worked around.
- Jonathan M Davis
Let's make this conversation a bit more concrete, I'm not sure we
are discussing the exact same thing.
The proposed solution is to have -unittest mean "compile
unittests for all 'compiled modules' according to the pattern
rules". The default pattern rule is to include all modules
except druntime/phobos.
Say you have two "packages" foo and bar that contain modules
inside their respective directories. With the proposed
-unittest=<pattern> this is the semantics you would get.
dmd -unittest foo/*.d bar/*.d # compiles unittests for
foo/*.d and bar/*.d
dmd -unittest=foo foo/*.d bar/*.d # compiles unittests for
foo/*.d
dmd -unittest=bar foo/*.d bar/*.d # compiles unittests for
bar/*.d
dmd -unittest=foo.x foo/*.d bar/*.d # compiles unittests for
foo/x.d
dmd -unittest=-bar foo/*.d bar/*.d # compiles unittests for
foo/*.d
Note that the default behavior makes sense, but this mechanism
also allows you more fine-graned control to limit unittesting to
certain packages or modules. This degree of control would be
quite helpful to me, any of the previously listed use cases
represent valid scenarios that I would like to be able to do. Do
you have another solution that would provide this functionality?
I don't see any reason not to support these use cases.
