D compiles fast, right? Right??

[Jonathan M Davis]

On Sunday, April 01, 2018 01:25:41 Jonathan Marler via Digitalmars-d wrote:
> 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.

My point is that this is not a good solution for the problem of dependencies
having their unit tests included in your project. That should simply not be
happening.

Discussions of ways to tell the compiler to enable unit tests for some
modules and not others within your own project are IMHO therefore a separate
issue. Now, as for the specific proposal trying to solve the issue of
running only certain unit tests in your project, I think that it's overly
complicated once you start having to deal with stuff like exclusions. I'd
argue for simply compiling the module or modules that you care about with
-unittest and that you not use -unittest when compiling the other modules.
All of this is going to have to be controlled by whatever build system
you're using anyway, since it really doesn't scale to keep calling the
compiler directly like that, and once you're dealing with a build system
like dub or make or whatever, then it can have support for something like

dub test --only=foo

where it then compiles only the module foo with -unittest, and compiles the
rest with out -unittest. There shouldn't be any need to change dmd for that,
just the build tool.

But regardless, I don't think that such a feature is a good solution for the
problem of the unit tests from dependencies being compiled in. The compiler
should be fixed to take care of that.

- Jonathan M Davis