This is an alternative and mutually exclusive approach to #92.

Note that it uses yet another approach to letting the same repo use either FetchContent or find_package without hardcoding anything special in CMakeLists.txt. See https://cmake.org/cmake/help/latest/guide/using-dependencies/index.html#id11 and the documents it links for more on how "Dependency Providers" work.

This approach is more code compared to #92, but I would expect if we liked this approach, the entirety of the use-fetch-content.cmake file could spun off to a standalong utility project, perhaps inside https://github.com/bemanproject/infra. This seems to be an ergonomic gap in CMake, so analogous features could be proposed upstream to CMake itself assuming we get a usage experience we're happy with.

Another merit of this approach compared to #92 is that pinned dependency information is in legible JSON format, so automation (like a make update target) to update the pinned version of GoogleTest would be very possible compared to hardcoding that information in a CMakeLists.txt. Similarly, documentation would be relatively simpler and require no special CMake knowledge.

On the failing CI checks, they are due to a missing googletest dependency, which isn't a large concern. It's not too difficult to have presets that prefer FetchContent on MacOS and Windows, pending selection of package management solutions on those architectures. Same for installing libgtest-dev on Ubuntu.

First, I'd like to hear whether this is a design we would like to pursue before investing time in troubleshooting CI failures.

@wusatosi Using FetchContent is implementing dependency management in-repo, yes.

Using it explicitly is an incomplete approach to dependency management since it doesn't have the features (sandbox-friendliness, portability to existing packaging systems, trivial version bumping) that I'm looking for with this PR.

This PR demonstrates how find_package might be redirected to FetchContent calls. I don't expect this is a good long-term approach. As I state in the Discourse on this change, if we take this direction as a medium-term strategy, I expect the interesting CMake logic would be pulled out into another repo like https://github.com/bemanproject/infra.

Another approach to consider would be to use find_package explicitly but lean harder into package managers by supporting Conan with a conanfile.txt and/or supporting vcpkg with a vcpkg.json directly in this repo. One or both of those approaches could be used in CI, assumed in presets, etc.

FetchContent would still be possible for consumers of this project, but it would be an exercise for them to wire that up if they desired, perhaps with the same CMAKE_PROJECT_TOP_LEVEL_INCLUDES and dependency provider approach in the current revision of this PR.

This latest commit fixes the linting checks, especially CMake formatting issues.

The remaining CI failures revolve around actually installing GTest. Those are going to require a consensus decision on how to resolve. Look out for another draft PR by me to demonstrate how to resolve that issue with a conanfile.txt.

I made a PR against the Beman Standard to land alongside this change that recommends find_package instead of FetchContent:
bemanproject/beman#98

Forgive the CI-driven-development, but the HEAD commit on this PR now works.

This is ready for review, and if acceptable, merging.

Do we really want searching for local libgtest to be the default behavior?

We want find_package(GTest) to be the way we declare an external dependency, yes. This is the recommended and portable practice as discussed. FetchContent does not provide the portability or ergonomics we'd want to replicate across the other Beman libraries and the C++ ecosystem more broadly.

I would prefer if we can switch this behavior with something like: BEMAN_DEPENDENCY_FETCH=LOCAL (as enum option with local, fetch. so we can add maybe vcpkg in the future).

I'm opposed to implementing bits and pieces of a dependency management system in every Beman library. It makes more sense to move the whole community to supported and widely adopted technologies like Conan, vcpkg, and/or a number of other systems that already support fetching dependencies from the internet (or not) in all sorts of configurations.

I'll be clear about this. Downloading dependencies from github.com is supported by both Conan and vcpkg (and all the other options too!). It's really easy and covered by the introductory tutorials of both options. They both support building against a local cloned and modified of the googletest repo as well. We wouldn't have to develop and maintain tools and paragraphs of docs, just point our users at the most relevant sections, if that's required.

I would prefer if we can switch this behavior with something like: BEMAN_DEPENDENCY_FETCH=LOCAL (as enum option with local, fetch. so we can add maybe vcpkg in the future).

A BEMAN_DEPENDENCY_FETCH=conan or vcpkg wouldn't really work. Conan is already running a command like conan install before it invokes cmake. vpkg is incorporated via a CMake toolchain file named vcpkg.cmake.

One of the biggest problems with FetchContent is that it encourages conflation of build systems and dependency management systems. This wouldn't be too bad except for the fact that the dependency management features it realistically provides does not stack up well at all compared to alternatives (see the discussion below about lockfiles).

I also don't want users to type use-fetch-content.cmake long term. This is an intermediate technology until we come up with something better. The main goal of adding it in this PR is to provide some sort of stopgap and to demonstrate that we can make find_package(GTest) resolve to... well, whatever we want.

The internals of lockfile.json is not documented...

That's fair, and I can update the PR quickly to add some docs, though they are more developer documentation for maintainers of Exemplar than something I expect users will need to interact with. Meaning I'm not sure if I'll put them in a user-facing README.md or not.

I'm fairly flexible on the name, for what it's worth. If we can get consensus but only if the file is named examplar.lock.json or fetchcontent.dependencies.json or something, I can live with that.

To explain my reasoning, I chose the name "lockfile" because that's one term of art for files like these. If you ask your search engine or your favorite programmer-oriented LLM tool will turn up full explanations, I expect, but here's the Conan Lockfile documentation for a quick and relevant example

PS. By linking the Conan docs on the subject of dependency pinning, I'm throwing shade at FetchContent because Conan supports (and documents!) all sorts of dependency manipulation workflows and features that FetchContent really doesn't. And Conan is actually not exceptional in supporting this. On the contrary, FetchContent is notable for its limited built-in feature set.

Cool! I don't and can't claim to know enough about CMake or package managers to provide more judgement, but as long as my concerns are seen I am happy to sit aside and learn by observation.

My only concern would be loss of one-click setup, I think a cheaty way would be to do this would be adding CMAKE_PROJECT_TOP_LEVEL_INCLUDES=./cmake/use-fetch-content.cmake to current CMake presets, and having presets that deal specificity with package management. Agh, only if you can pass arguments when using preset, how much do we need to pay kitware to have this implemented?

This PR is updated and ready for final review. If it's basically OK, I would like to merge so I can push up pull requests to initially support Conan and vcpkg. I'm happy to collaborate on followon PRs to provide more polish, iterate on how we inject FetchContent, etc.

@wusatosi I added some documentation for lockfile.json as requested.

Can you add this patch so the devcontainer still work?

diff --git a/.devcontainer/postcreate.sh b/.devcontainer/postcreate.sh
index bddba03..81d2420 100644
--- a/.devcontainer/postcreate.sh
+++ b/.devcontainer/postcreate.sh
@@ -1,3 +1,6 @@
 # Setup pre-commit
 pre-commit
 pre-commit install
+
+# Install GoogleTest
+sudo apt-get -y install libgtest-dev

@wusatosi I added more docs walking through how to add a Catch2 dependency. Does that help?

I also added libgtest-dev to the devcontainer JSON. I did a little tidying up in there as well. Hopefully that's OK.

I'm merging this change given the approving reviews. @wusatosi, I'm happy to team up on follow up on issues and PRs addressing ergonomic concerns.