snitch v1.2.0 released

[cschreib]

The main point of this release is to make snitch easier to use. The focus was therefore on:

• Enabling IDE integrations.
• Better packaging support (i.e., we should be soon in ConanCenter!)

Main changes:

• [API] Added REQUIRE_NOTHROW(EXPR) and CHECK_NOTHROW(EXPR).
• [API] Added SUCCEED(MESSAGE).
• [API] Added REGISTER_REPORTER(...) (from Catch2) for registering multiple reporters that can be selected from the command line.
• [CLI] Added support for --out to save test report to a file.
• [CLI] Added support for filtering the output of --list-tests (Apply CLI test filtering to the output of --list-tests #114).
• [Reporter] Added the Catch2 XML reporter (Add native support for Catch2 XML output #100).
• [Reporter] Added file/line information for test cases and sections.
• [Reporter] Added fixture class name information for test cases ("method" test cases only).
• [Reporter] Added test filtering criteria to the test_run_started event.
• [Reporter] Expression data is no longer concatenated into a single message when sent to the reporter.
• [Reporter] Added events for listing tests (listing started, ended, and test case listed).

As a result, the following Catch2 IDE integrations now work with snitch:

• Visual Studio Code & C++ TestMate
• Visual Studio 2022 & Catch2 Test Adapter
• CLion Catch2 configuration

Small changes and bug fixes:

• [API] Fixed small_function is not copy-constructible from another non-const object #105: small_function copy construction from a non-const object was ambiguous.
• [API] Fixed Failure on nullptr char* #107: crash when evaluating a check containing a const char* equal to nullptr.
• [Reporter] Fixed: the Teamcity reporter was reporting failures in [!mayfail] and [!shouldfail] as actual failures.
• [Reporter] Fixed: long outputs in registry::print and all reporters was too easily truncated; the risk of this is now largely reduced.
• [CLI] Fixed: unsupported Catch2 command line parameters were not parsed correctly.
• [CLI] Fixed CTest integration using Catch2 scripts does not work #110: the output of --list-tests did not contain the full test name.
• [CLI] Fixed Implement exact same CLI test filtering as in Catch2 #113: the test filtering algorithm did not match Catch2 v3.
• [Build] snitch can now build as a shared library.
• [Build] The CMake scripts will now build either a compiled library or a header-only library, but not both.
• [Docs] Fixed Can't provide serialization for vector<int> #108: clarify how to write your own append() function for serialisation
• [Internal] Fixed: small_vector_span<const T> was unsafe when not initialized with a valid backing small_vector.
• [Internal] Fixed: small_function compilation error when assigning a member function (or stateful lambda) when the function parameters contain l-value references.
• [Internal] Added file_writer.
• [Tests] Added approval tests for all reporters.
• [Tests] Reduced memory usage of mock_framework in tests by ~x3.
• [Tests] Reduced stack usage in tests by allocating large data on the heap (reduce risk of stack overflow).
• [Tests] Fixed stack size for tests not set correctly on Windows.

[tocic]

Congrats, thank you for this release! I have a question though: why did you change the snitch-header-only target to just snitch? In the previous release, I was able to package both a compiled version of the library and the header-only one, so the users could use the one they want via linking to either snitch::snitch or snitch::snitch-header-only. Now it seems ambigious to link to snitch::snitch this way.

[cschreib]

Thanks for the feedback. I'm not wedded to the idea, so we can change it back (or make it configurable).

The main reason behind the change was that having both the regular and header-only library build simultaneously in the same CMake script was proving hard to maintain. With the addition of shared library support, the snitch_config.hpp gets generated differently between the compiled and header-only target, so I was having to do everything twice. At that point, I thought it was better to bite the bullet, and just have one or the other, but not both. My thinking was that no one would need both at the same time. I didn't think about you :)

Still, you should be able to run CMake twice to generate the files you need. The issue then is that both builds are generated with the same target name snitch::snitch. Presumably, if the header-only target was still named snitch::snitch-header-only, or if I gave you an option to rename the target (using a CMake option like SNITCH_TARGET_NAME), then that would be fine?

I don't know where to draw the line though. Should I change the target name for each combination of build option? Static/shared/header-only, with/without main, with/without exceptions, etc... That won't scale.

Alternatively, could you package the library in two different packages?

[tocic]

Still, you should be able to run CMake twice to generate the files you need. The issue then is that both builds are generated with the same target name snitch::snitch.

That's right.

Presumably, if the header-only target was still named snitch::snitch-header-only [...] then that would be fine?

Yes, I think that's the option I like the most.

[...] or if I gave you an option to rename the target [...]

I don't think it's a good idea to give packagers the freedom to choose the names. Users should refer to the official documentation for the usage instructions, and every package should have the same targets specified there.

Should I change the target name for each combination of build option? [...] Alternatively, could you package the library in two different packages?

There's no clear answer to that. In my experience, the combination of shared + header-only covers most of the use cases and usually goes into one package shared to the community, a static version goes into a separate shared package (but only if someone actually needs it, i.e. when the upstream is extremely popular), other versions don't have a shared package - the seekers utilize add_subdirectory or FetchContent. So I put a header-only version into the same package as long as the upstream provides it and the headers don't clash. If there's additional support from the CMake side, nice!

[cschreib]

Ok, here's where I will draw the line from now on. There is a significant difference in how one uses the library depending on whether it is header-only or not: the #include <...> is different. All of the other build options (including e.g., shared vs static) will yield the same interface, so they will have the same target name. But indeed, because the header-only build uses its own header, it can cohabit with a non-header-only build, hence deserve its own target name.

I have revert the target name change in v1.2.1, which is just published. I tested the use case you have, i.e., run CMake twice to generate two targets that can cohabit; and that works (I had to jump through a few hoops to avoid one target overwriting another, it should be future-proof in this regard now, in case we add more targets going forward).