On Thursday, 2 September 2021 at 20:46:57 UTC, deadalnix wrote:

Case in point: https://issues.dlang.org/show_bug.cgi?id=22268

On 9/2/21 1:26 PM, deadalnix wrote:

$ dmd -m64 -Isrc -w -debug -g -main -unittest -i -run src/somemodule.d
3 modules passed unittests

The -i flag finds all dependencies and builds them all at once as if you weren't linking in the object code that is in a library. That's not what I was saying.

What I was saying is, you have a library, you built it without -unittest (on its own build line, or just use dub because it does the right thing), and then you build your main application with -unittest, linking in the already-built library (or its object files). The runtime runs all unittests it finds, and so it's running just the modules that were built with the -unittest flag.

When you use -i, it means ALL MODULES AND IMPORTS are built with the -unittest flag, and so they all run.

-i is going to run all unittests. How else would it interpret the command line? If you want to build some modules differently than others
(i.e. some with unittests and some without), you can't use -i.

What is the "right thing"? Reading what you expect in your mind is not what a compiler can do. Define how it will work. I think unittests work acceptably the way they are now, but I'm sure others would be keen to have some more bells and whistles. Just make a proposal and get it merged in.

Start by saying "when I type dmd -m64 -Isrc -w -debug -g -main -unittest -i -run src/somemodule.d, here is what I expect to happen: ...", and then define rules that will make that happen.

-Steve

On Thursday, 2 September 2021 at 23:00:06 UTC, Steven Schveighoffer wrote:

I know. That's dumb.

Is this groundhog day? There are no combination of flags that do the sensible thing. I can't use -i, no problem. I can't use anything else either, big problem.

The proof is in the pudding, you just told me that I need a full build infra to run unittests for something that use anything else than phobos.

The right thing is being able to run the unitests of a god damn module easily. not the unit tests of that module and all of its dependencies. Not using a complex test framework. Just running the unit tests of a module.

This is the sensible thing. This is the simplest thing. This is the "right thing".

It doesn't matter if the module has a main or not. It doesn't matter if the module depends on phobos or half the solar system.

Here is what I expect.

$ dmd --run-the-god-damn-unittest mymodule.d

And it run the unit tests of mymodule.d . Replace --run-the-god-damn-unittest by any set of flags that pleases you, for as long as there is one.

The -unittest flag should just accept a pattern, same as -i, so you can explicitly add or remove things that get the unittest build.

Then you can be like dmd -unittest=foo.bar -i main.d and it will build foo.bar with unitest and skip the rest while still auto-following imports.

On Thursday, 2 September 2021 at 23:22:57 UTC, deadalnix wrote:

A patch for silly.d that boils down to

string targetmodule;
// add "test a single module" to existing getopt flags
if (targetmodule && moduleName!module_ != targetmodule) continue;

permits this usage:

$ time dub -q test -- --module=testme
 ✓ testme __unittest_L1_C1

Summary: 1 passed, 0 failed in 0 ms

real    0m0.190s
user    0m0.129s
sys     0m0.059s

Which tests that single module and ignores the others. This still compiles in all the other modules of your project, still compiles in their unittest blocks, still runs their module initialization, still might rebuild a dub dependency, but in the end it runs only the unittest blocks of the chosen module.

Anything short of that is going to be a hacky once-off solution that relies on package-specific knowledge that a module's unittests don't really depend on that other stuff happening. At that level you may as well run 'dmd -main -unittest -run module'.

I think this is the best you're going to get. You can try this now by cloning the silly repo, patching it, running dub add-override silly 1.1.1 . in the repo, and trying out the usage above in your dub package that's already set up to use silly.
There's really nothing to the patch but it's here: https://run.dlang.io/is/smXgof

Well, there's someone in the thread who keeps complaining about random dmd flags, which both draws defenses of those flags and proposals to change them that won't actually give you the workflow you want (like the -unittest= proposal, that still requires you to tell dmd about where all your modules are, which would still be irritating for dub dependencies).

On Friday, 3 September 2021 at 00:34:01 UTC, jfondren wrote:

I'll be blunt, but this is needed because this whole thread is retarded.

The current flag's behavior make no sense. They are not useful. They don't so something sensible. They don't serve typical use cases. The whole thing is completely retarded.

Yes, improving unittest as some suggest would be an improvement. But it doesn't address the core problem. The -main situation remains retarded. It is still not possible to run the unittest of several modules this way, etc...

And here is the root problem: something is complete trash and yet, not only I'm told this is normal and expected, but I'm supposed to be happy with it. By yourself, by Walter, by Steven. You guys are obviously smart, but you aren't looking at this straight or even at all. Or you are drowning in so much trash you don't even see it anymore, like a fish in water. In don't know. But this is alarming.

In fact, people went through the length of migrating the whole standard library to use the StdUnittest version to work around the problem I'm pointing. Think about it. people would rather change how all the tests of the standard lib work rather than fix this shit. This is insane. Literally.

WAKE UP!

This is bad. This is really bad. Stop making excuses. It's time to ask, how did this get this way and what can be done so that this never ever happens again.

Consider the following. You work in a car company. The eng team just came up with this new design with the engine bolted on the roof of the car. You tell them "Guys, this does not make sense, nobody is going to want a car with the engine on the roof." and they respond to you "Well, this is how it is, you can get better cooling this way and yada yada yada...", what would you think? That these people need a technical solution? No, these people need an intervention. They are building a car for people to use, right?

Well, jfondren, you need an intervention. Stop. Take a break and think. You need to look at this with a fresh eye. You have been in this crap for too long and can't see straight anymore.

The set of flags the compiler propose is complete nonsense that do not serve users, it has cause major rewrite in the standard library, and motivated the creating of a new test framework per large project. This needs to stop.

On Friday, 3 September 2021 at 01:08:25 UTC, deadalnix wrote:

Nah.