Adding Criterion to the Meson wrapsdb repository

[0x5a17ed]

Hey y'all,

it would be nice to add criterion to meson's wrapsdb repository for several reasons. From the top of my head I can name:

• increase exposure of criterion to a wider audience. Maybe more developers will come across criterion and consider it to be useful for their work.
• simplify the installation of criterion by including it directly into the host project through the invocation of meson wrap install criterion instead of requiring criterion to be available in the host system package manager.

For that reason I tried to integrate criterion into the wrapsdb repository myself by following their guidelines, but had to come to a halt due to numerous test failures. It seems that while it is fundamentally possible to integrate criterion as a wrap file into meson and use it that way instead of installing criterion directly to the system, the meson.build files in criterion directly at least do not play nicely together when imported as a subproject to a meson host project.

I would be willing to take on the task myself since I prefer criterion over other testing frameworks and making criterion easier to use in other projects also makes my own life a bit easier. Before submitting the files necessary to the wrapsdb to integrate criterion, I would like to fix the outstanding tests first though. But there are numerous things that require fixing and I'm not exactly sure what the desired way of fixing them would be. One big issue is the automated version number generation when a git repository is detected. The detection automatically assumes that the discovered git repository is the repository containing the respective component itself. Boxfort as one of criterion's dependencies has the same logic as well. How is this is not a problem for Boxfort to detect its version number when it's compiled during the testing of criterion code changes though? The Boxfort meson.build must also be detecting the .git directory of the criterion repository and then mess up its own version detection, no? I really would love to know what the desired behavior is, it would be enough for me if it was documented in the issue here. That would allow me to provide a patch to fix this and maybe the other problems as well.

[0x5a17ed]

Sometimes writing random thoughts down into an incoherent description helps to figure out what actually the problem is and how to fix it. Or so I want to believe. Afterwards, at least, I had a clearer idea of what the desired behavior could be and tried to provide an implementation in the provided pull request. If that is an acceptable change, I would love to see that added to the other sub projects as well that do a similar dynamic generation of the version string.