Just realized... this.

Today if you build with -main a program that has a main() function, you get:

__main.d(1): Error: only one main allowed, -main switch added another main(). Previously found main at xyz.d(42)

But it makes sense to allow (and ignore) main if -unittest is also provided. Essentially -unittest -main means "build for unittesting and a no-op main".

This should be easy to implement and a simple step to take toward better unittesting.

Again, the overarching belief is that unit testing is part of the build process. The way it should go is that compile/run/unittest is part of the build cycle. Integration testing is somewhere in between and not easy to automate generically. Then of course running would be the last step.

Once with have -unittest -main going, we can write a script a la rdmd called e.g. dmd-build that does (stylized):

1. Start dmd compile/link in background (no unittest), output to ${thebinary}.tmp, output to ${thebinary}.log
2. Build ${thebinary}.unittest with -main -unittest
3. If errors => abort
4. Run ${thebinary}.unittest
5. If errors => abort
6. Fetch the exit code of the background process
7. If errors => output ${thebinary}.log to stderr, abort
8. Delete ${thebinary}.log
9. Rename ${thebinary}.tmp to ${thebinary}
10. Success!

I use -unittest -main all the time. It's why I added it :-)

On Sunday, 19 May 2019 at 13:31:12 UTC, Andrei Alexandrescu wrote:
> But it makes sense to allow (and ignore) main if -unittest is also provided. Essentially -unittest -main means "build for unittesting and a no-op main".

Not bad.

My only concern here is build time, if we are running the compiler twice for a successful build (this is why many of us avoided rdmd), but the background parallel idea could solve that.

I say let's try it!

On Sunday, 19 May 2019 at 17:28:31 UTC, Adam D. Ruppe wrote:
> On Sunday, 19 May 2019 at 13:31:12 UTC, Andrei Alexandrescu wrote:
>> But it makes sense to allow (and ignore) main if -unittest is also provided. Essentially -unittest -main means "build for unittesting and a no-op main".
>
> Not bad.
>
> My only concern here is build time, if we are running the compiler twice for a successful build (this is why many of us avoided rdmd), but the background parallel idea could solve that.
>
> I say let's try it!

I solved that with rund...have you tried it?

https://github.com/dragon-lang/rund

On Sunday, 19 May 2019 at 17:42:58 UTC, Jonathan Marler wrote:
> I solved that with rund...have you tried it?

No, I thought rund was just a fixed rdmd. Does it run the tests too?

Specifically what I'm worried about is the separate instantiations of the compiler for:

1) dmd -options allcode.d
2) dmd -unittest -main allcode.d

Andrei's idea includes running both those simultaneously, which I believe has potential, just I wanna benchmark build times too. Cuz with the status quo -unittest, it is possible to use one build for both that maybe - maybe - can be worth it for faster builds.

I did a quick test and it hit me with a 15% cost, even when parallelized. But, maybe the code could be written better, and maybe 15% is worth it.