Installation of both v2 and v3

[dimztimz]

A problem arises when the users that depend on Catch2 v2 via package manager and the package manager upgrades Catch2 to v3 which is API incompatible. The solution usually is to package both versions under different name. See the following guidelines how to do this https://developer.gnome.org/GSettings/documentation/guidelines/maintainer/parallel-installability.html . Various libraries from the GNOME ecosystem like GTK+ or Glib do these tricks.

I think only few tweaks on the Cmake and pkg-config are needed.

1. Bellow is OK, but can be changed. Downstream packagers can set CMAKE_INSTALL_INCLUDEDIR to something like include/v3 so headers will end up like /usr/include/v3/catch2/catch_all.hpp. What you can change is hardcode the v3 so downstream packagers don't have to. https://github.com/catchorg/Catch2/blob/605a34765aa5d5ecbf476b4598a862ada971b0cc/src/CMakeLists.txt#L354-L363

2. Bellow is OK, $<INSTALL_INTERFACE:${CMAKE_INSTALL_INCLUDEDIR}> is the right thing to do. You will need to change that line only if you change above and hardcode the v3. https://github.com/catchorg/Catch2/blob/605a34765aa5d5ecbf476b4598a862ada971b0cc/src/CMakeLists.txt#L379-L384

3. The pkg-config is most likely already good. See point 2. https://github.com/catchorg/Catch2/blob/605a34765aa5d5ecbf476b4598a862ada971b0cc/CMake/catch2.pc.in#L3

4. This line bellow should probably be changed, you should add something like "-v3" at the end of that string. find_package(Catch2) should still work. See Config Mode Search Procedure. https://github.com/catchorg/Catch2/blob/605a34765aa5d5ecbf476b4598a862ada971b0cc/CMakeLists.txt#L66 What I am not sure is what will happen when CMake sees both /usr/lib/cmake/Catch2/Catch2Config.cmake and /usr/lib/cmake/Catch2-v3/Catch2Config.cmake. Will it select according to the call to find_package() or will it show error?

5. The OUTPUT_NAME of the static library Catch2WithMain might need changing only if package managers previously packaged the experimental from v2, which they should not because it was experimental. Still the Debian/Ubuntu package shipped this.

[horenmar]

No.

[gahr]

This is making the work of downstream packagers very difficult. In the release notes you mention

Why the big breaking change caused by replacing catch.hpp with catch_all.hpp? The convenience header catch_all.hpp exists for two reasons. One of them is to provide a way for quick migration from Catch2

but this is only true for end users who control the including source code. I, as a downstream maintainer of a catch package, have no control on all packages that depend on catch. At this point I have a couple of ways forwards, none of which looks very compelling:

• I provide my own catch.hpp -> catch_all.hpp as a fallback
• I provide two versions of the package, catch2 and catch3, thus diverging from upstream's naming etc
• go after all packages that depend on catch and upgrade them to catch3 at the same time

What's your suggestion upgrade path for downstream maintainers?

[gahr]

• I provide my own catch.hpp -> catch_all.hpp as a fallback

Which won't work, as catch_all.hpp doesn't provide everything the old catch.hpp did. E.g., it doesn't include iostream and doesn't provide Approx, which is now Catch::Approx in catch_approx.hpp.

[StefanBruens]

Catch2 v3 should have been called Catch3, this would have avoided these problems ...

One of the main reasons for switching to a compiled static library is compile time. On the other hand, the current scheme encourages usage of a bundled version in each package, negating any possible gains due to recompilation.

[bkmgit]

It would be helpful to have Catch3. The best option for packaging seems to be to use Catch3, and use catch3 in include paths. This would allow coexistence of both packages as it seems they will be maintained for some time.

[ChrisThrasher]

https://github.com/ChrisThrasher/argon/blob/dcef4fc2d888bf2fd7da099d5ee4c6f806449543/CMakeLists.txt#L31-L32

I like to include ${PROJECT_NAME}-${PROJECT_VERSION} in the path to installed artifacts. This makes it harder to accidentally use a library you didn't request (this has been a real problem for me in the past) and has the added benefit of letting you install multiple versions simultaneously. I'd support such a change.