cmake fails on catch2

[JeffGarland]

cmake .. -DCMAKE_CXX_COMPILER=g++-15 -DCMAKE_CXX_STANDARD=20 -G=Ninja

- Performing Test HAS_MSVC_OVERFLOW - Failed
CMake Error at tests/beman/bounds_test/CMakeLists.txt:3 (find_package):
  Could not find a package configuration file provided by "Catch2" (requested
  version 3) with any of the following names:

    Catch2Config.cmake
    catch2-config.cmake

  Add the installation prefix of "Catch2" to CMAKE_PREFIX_PATH or set
  "Catch2_DIR" to a directory containing one of the above files.  If "Catch2"
  provides a separate development package or SDK, be sure it has been
  installed.

[JeffGarland]

So this is I guess the intended behavior here of find_package since I don't have it installed. In other repos here we're doing fetch_content which I suppose is why this took me off guard.

of course optional does this:

if(OPTIONAL_ENABLE_TESTING)
    find_package(GTest QUIET)
    if(GTest_FOUND)
   ...stuff...
    else
        message(
            WARNING
            "
No provider for GTest. Unable to build tests.
Consider using CMAKE_PROJECT_TOP_LEVEL_INCLUDES=./cmake/use-fetch-content.cmake as documented in the README.md
"
        )

is this not the best practice?

[nickelpro]

The problem here is we're assuming the user has either provided Catch2 via their own mechanisms, or asked us to provide it by bootstrapping package management.

Exemplar does the same thing, Exemplar will fail to build by default if it is the top level and the user hasn't done anything to provide GoogleTest when it calls find_package(GTest REQUIRED).

In Exemplar you turn on the built-in package management with:

cmake \
  -DCMAKE_PROJECT_TOP_LEVEL_INCLUDES=infra/cmake/use-fetch-content.cmake

In bounds_test you turn on the built-in package management with:

cmake \
  -DBEMAN_BOUNDS_TEST_BOOTSTRAP_VCPKG=ON

We do this because our usage of Catch2 doesn't work with the FetchContent mechanism provided in the use-fetch-content.cmake script, so we use a "real" package manager instead that actually does an install of Catch2 instead of relying on add_subdirectory.

Maybe bounds_test should not fail on a top-level build without providing the test framework, but in that case neither should Exemplar. This is a pretty straight-forward fix, but I think the general question should be resolved prior to resolving it here.

[nickelpro]

I will briefly note that the blessed Beman solution to this is to use presets. That the presets should always work so long as the user has the given compiler available in PATH. Like Exemplar, bounds_test works without further intervention when built via preset.

[JeffGarland]

Maybe bounds_test should not fail on a top-level build without providing the test framework, but in that case neither should Exemplar. This is a pretty straight-forward fix, but I think the general question should be resolved prior to resolving it here.

You mean be simply turning off testing? That seems like a nice solution actually -- especially if paired with a message that describes how to install the test framework. And yeah, examplar needs to work...

I will briefly note that the blessed Beman solution to this is to use presets.

Of course I'm using a compiler that isn't in the presets so that doesn't work. I'm unconvinced that presets will be a long term solution here -- I think you've already expounded on the limitations.

[JeffGarland]

btw -- let me add that I'm clearly capable of solving the issue in this case, but I'm looking at all the Beman libraries and despite all our efforts to date we aren't solving issues like this.

As another note, I was going to recommend we switch to catch2 in examplar since many libraries are adopting and gtest didn't make releases (but lol they finally made one in april)

[nickelpro]

I'm all about getting everyone on the same page on things we think are worth standardizing.

It's a valid bug, but right now we're at N solutions to this problem and if I solve it only here in bounds_test we'll be at N + 1 solutions.

I don't really have strong feelings about it. From a packager's point of view the question is irrelevant, packagers are "expert" users and thus know to turn off building tests in any case and have their own dependency provisioning solutions. So whatever people think is the right answer for the non-packager audience I'm here to support.