On Thu, Apr 02, 2015 at 11:19:32AM -0700, Jeremy Powers via Digitalmars-d wrote: > On Wed, Apr 1, 2015 at 7:31 AM, Johannes Totz via Digitalmars-d < > digitalmars-d@puremagic.com> wrote: > > > On 31/03/2015 19:24, Andrei Alexandrescu wrote: > > > Probably not; we're looking at two different builds. The build to > > > be deployed has no unittest code at all. > > > > I'm starting to see this differently these days (basically since I > > started to use jenkins for everything): A build you haven't unit > > tested has implicitly failed. That means the release build that does > > not have any unit test bits is not deployable. Instead, compile as > > usual (both debug and release), and run unit tests against both > > (e.g. to catch compiler bugs in the optimiser). Then for > > deployment, drop/strip/remove/dont-package the unit test code. > > > > > This. > > I want to run unit tests as part of the build process, and I want my > release build to have unit tests run against it. If unit tests > haven't passed for a build, it's not release ready. But, I don't want > my release build to be bloated with unit test code. > > Related, unit tests often have dependencies that I _don't_ want as > part of my release build. Mocking frameworks are a good example.
So what do you want the compiler to do? Emit two executables, one containing the release, the other containing the unittests? Isn't that just a matter of running dmd with/without -unittest? T -- You have to expect the unexpected. -- RL