Seriously that makes no sense, almost everybody has it own hack to have a different main when building for unitests, and we look like clown.

We all like to talk about language feature and all, but seriously, this kind of thing is what hurts us the most. We kind of live with it because we all have our workaround here, but really, it looks stupid to anyone that don't the tricks, and really, it should looks silly to anyone that knows the trick.

Can I have my unittest build do not complain if there is no main and not run main ?

On Wednesday, October 26, 2016 05:24:45 deadalnix via Digitalmars-d wrote:
> Seriously that makes no sense, almost everybody has it own hack to have a different main when building for unitests, and we look like clown.
>
> We all like to talk about language feature and all, but seriously, this kind of thing is what hurts us the most. We kind of live with it because we all have our workaround here, but really, it looks stupid to anyone that don't the tricks, and really, it should looks silly to anyone that knows the trick.
>
> Can I have my unittest build do not complain if there is no main and not run main ?

Ideally, the -unittest build would just replace main (whatever it was) or run something instead of main without actually starting main, and if there were no main, it wouldn't complain about the lack thereof.

That being said, using -main when unit testing libraries and declaring main in applications to look something like

version(unittest) void main() {}
else int main(string[] args) {...}

doesn't seem like all that big a deal to me. Not ideal, but not a big deal.

Regardless, I really don't think that it ever makes sense to actually run main after running the unit tests. So, in that sense, what dmd does with -unittest is downright weird. I assume that it just seemed like the easiest way to integrate them though and that that's why it was done that way. And I wouldn't mind it if it were fixed so that declaring main for unit tests was not required and that main never actually ran after the unit tests. However, I bet that if we changed it, _someone_ would complain. Someone always does, even if the change makes perfect sense and the previous behavior didn't.

- Jonathan M Davis

On Wednesday, 26 October 2016 at 05:32:51 UTC, Jonathan M Davis wrote:
> That being said, using -main when unit testing libraries and declaring main in applications to look something like
>
> version(unittest) void main() {}
> else int main(string[] args) {...}
>
> doesn't seem like all that big a deal to me. Not ideal, but not a big deal.
>

It is. once you need to put that in the file, there is a ton of automation that can't happen anymore.

Also, to anyone outside this forum, it feels like this: https://www.youtube.com/watch?v=szdbKz5CyhA

> Regardless, I really don't think that it ever makes sense to actually run main after running the unit tests. So, in that sense, what dmd does with -unittest is downright weird.

It indeed never makes any sense to do it that way.

> However, I bet that if we changed it, _someone_ would complain. Someone always does, even if the change makes perfect sense and the previous behavior didn't.
>

Well obviously, but that's not a good reason.

On Wednesday, 26 October 2016 at 05:24:45 UTC, deadalnix wrote:
> Seriously that makes no sense, almost everybody has it own hack to have a different main when building for unitests, and we look like clown.
> [...]
> Can I have my unittest build do not complain if there is no main and not run main ?

What would be possible is a "-fdmain" switch (force dummy main). Its role would be: if a functionDeclaration named "main" is present then this normal "main" is not used (technically erased from the AST or something like that). Then acts like "-main".

If I understand correctly the real problem happens when modules have to be tested but the real program "main()" must be skipped. All the other scenarios can be handled easily. For example an IDE can lookup in the AST and automatically add "-main" when the "main" declaration misses (and obviously if "-unittest" is defined).

On Wednesday, 26 October 2016 at 08:15:44 UTC, Basile B. wrote:
> What would be possible is a "-fdmain" switch (force dummy main). Its role would be: if a functionDeclaration named "main" is present then this normal "main" is not used (technically erased from the AST or something like that). Then acts like "-main".

Just using `-main` has worked well enough for me

On Wednesday, 26 October 2016 at 09:22:23 UTC, pineapple wrote:
> On Wednesday, 26 October 2016 at 08:15:44 UTC, Basile B. wrote:
>> What would be possible is a "-fdmain" switch (force dummy main). Its role would be: if a functionDeclaration named "main" is present then this normal "main" is not used (technically erased from the AST or something like that). Then acts like "-main".
>
> Just using `-main` has worked well enough for me

For me too but once again I think that the issue is when you wish to test functions defined in the module where's main() is declared and when the main() content should be skipped. In this case stuff like "version(unittest) return 0;" must be added at the beginning of the main().

On Wednesday, 26 October 2016 at 05:32:51 UTC, Jonathan M Davis wrote:
> However, I bet that if we changed it, _someone_ would complain.

Let them complain.

At some point, we gotta rip off the band aid, let it go, the past is in the past.

On Wednesday, 26 October 2016 at 08:15:44 UTC, Basile B. wrote:
> What would be possible is a "-fdmain" switch (force dummy main).

It should just be implied by -unittest!

The only cast I'd be worried about is an explicit version(unittest) main() {}... then maybe the user wanted something special. And even then, meh, 99% of those cases are just fixing the broken default anyway.

Otherwise, let's make the default sane.

On 10/26/2016 09:25 AM, Adam D. Ruppe wrote:
> On Wednesday, 26 October 2016 at 08:15:44 UTC, Basile B. wrote:
>> What would be possible is a "-fdmain" switch (force dummy main).
>
> It should just be implied by -unittest!
>
> The only cast I'd be worried about is an explicit version(unittest)
> main() {}... then maybe the user wanted something special. And even
> then, meh, 99% of those cases are just fixing the broken default anyway.
>
> Otherwise, let's make the default sane.

+1

Am 26.10.2016 um 15:25 schrieb Adam D. Ruppe:
> On Wednesday, 26 October 2016 at 08:15:44 UTC, Basile B. wrote:
>> What would be possible is a "-fdmain" switch (force dummy main).
>
> It should just be implied by -unittest!
>
> The only cast I'd be worried about is an explicit version(unittest)
> main() {}... then maybe the user wanted something special. And even
> then, meh, 99% of those cases are just fixing the broken default anyway.
>
> Otherwise, let's make the default sane.

How would a custom unit test runner such as "unit-threaded" or "tested" work in that case?