cmake-init-fetchcontent VS cmake-init-use-pkg-config

You can see that in action here: https://github.com/friendlyanon/cmake-init-fetchcontent This example has the idiomatic find_package(headeronly REQUIRED) call in the CMakeLists.txt, but when configuring ${sourceDir}/cmake/find is added to CMAKE_MODULE_PATH, so the FetchContent code is run to "find" the dependency. There are comments to further explain this.

Please consider using https://github.com/friendlyanon/cmake-init before this has any significant amount of users. There is an example that shows you how to still rely on FetchContent as an opt-in.

Are they only on git(hub)? You can write a vcpkg overlay port (example) or use FetchContent if the projects are FetchContent ready in a way that doesn't force FetchContent on people trying to build the project (example).

This came up somewhere else, but I created an example repo that idiomatically uses find_package and an opt-in find module to FetchContent a dependency from GitHub: https://github.com/friendlyanon/cmake-init-fetchcontent

You have to realize that the point of using CMake is not entirely about your project, but about downstream users who wish to use CMake as well. If you do not support clients using CMake (i.e. install a CMake package) you are forcing every downstream user to figure your requirements out by themselves, which even for a project with no dependencies is non-trivial: https://github.com/friendlyanon/cmake-init-use-pkg-config

See this example from the wiki. This one tries to use unofficial vcpkg package nd targets, then falls back to pkg config, then falls back to find_* commands. This is probably more than what you are asking, but you can put anything in the find module, even code that vendors projects, although I highly recommend against any form of vendoring (manual, git, FetchContent, etc). Vendoring only causes problems for packagers.