• Andrei Alexandrescu (26/26) May 19 2019 Just realized... this.
• Walter Bright (1/1) May 19 2019 I use -unittest -main all the time. It's why I added it :-)
• Adam D. Ruppe (6/9) May 19 2019 Not bad.
• Jonathan Marler (3/14) May 19 2019 I solved that with rund...have you tried it?
• Adam D. Ruppe (15/16) May 19 2019 No, I thought rund was just a fixed rdmd. Does it run the tests

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

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!

Walter Bright <newshound2 digitalmars.com> writes:

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

Adam D. Ruppe <destructionator gmail.com> writes:

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!

Jonathan Marler <johnnymarler gmail.com> writes:

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

Adam D. Ruppe <destructionator gmail.com> writes:

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.