cmake-init-fetchcontent VS SimpleBluez

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

Internally, SimpleBLE is using CoreBluetooth on MacOS, WinRT on Windows and SimpleBluez/SimpleDBus (two other components that I wrote providing low-level access to DBus as well as Bluez abstractions). The library is extensively tested in terms of functionality as well as memory/thread sanity and I do feel confident about it being production ready. Tiny caveat: Most tests I run are manual, although I have plans for a proper hardware-in-the-loop CI pipeline if I get enough people interested / funding.