Justin Bassett

The upstream CMake issue has been merged into CMake 3.18. As such, we can go ahead and pull this feature back online after verifying the CMake version. As I mentioned...

There may be some mishandled quoting going on there. Check the generated `_tests-.cmake` file and see what the `set_property(...)` calls look like. If they look like this: ```cmake set_property(TEST utils:Binary...

[`set_tests_properties`](https://cmake.org/cmake/help/latest/command/set_tests_properties.html) will only let each test have a single label, unless you change the label computation to calculate every label for a test and add them all at once. That's...

It may have worked, but it was breaking the documented rules. To quote the [CMake upstream issue](https://gitlab.kitware.com/cmake/cmake/-/issues/19391): > The documentation for `add_test(NAME ...)` states, "The test name may not contain...

> Is there any backwards-compatibility logic that will need to be added for pre-3.18 CMake versions? I would probably include a CMake version check that skips the label management if...

Except the user could decide to set properties of their own, e.g. their own labels: ```cmake catch_discover_tests(target PROPERTIES LABEL CustomLabel ) ```

> I tried to apply your patch, but didn't find commit 3047ee8 It's in my fork: https://github.com/Quincunx271/Catch2/tree/fix-catch-discover-tests-with-labels-from-tags https://github.com/Quincunx271/Catch2/commit/3047ee81052b35f9867b61c15a81c9df2b539621

First off, I am not really *that* experienced with CMake, but I do have an idea of what the best practices are. It's totally possible that there are better practices...

I would recommend a `dds build` flag to force rerun tests. Sometimes it's nice to rerun the tests to gain a little more confidence. Theoretically, it wouldn't make a difference,...

I'm becoming quite convinced that having a test support library and not just test support headers is useful. ---- Here's a horrifying proof of concept using the current tip of...