@craig.scott thank you for your wonderful work on FetchContent, the find_package integrations are an amazing feature!
Unless the docs are out of date, it looks like find_dependency only wraps a find_package call, there seems to be no “official” way to use FetchContent from a package-config.cmake file.
I have several ideas about this:
- Extend the functionality of find_dependency, perhaps to something like:
find_dependency (FETCH_CONTENT_ARGS <args...>
FIND_PACKAGE_ARGS <args...>)
- For any dependencies that I fetch via FetchContent, I could write a minimal Find module that simply contains the FetchContent call, and install this find module with my project. This works, and was my strategy before the FetchContent/find_package integrations, but it seems to defeat the purpose of these new features.
I would also love to know if there is anything on the roadmap or in discussions for unifying the process of declaring dependencies between the project’s CMakeLists.txt and its package-config.cmake script – as it stands today, there is either code repetition, or projects define some kind of custom add_dependency macro and then generate their config script programatically…
1 Like
find_dependency() is really just a thin wrapper around find_package(). It’s sole reason for existence is to make respecting REQUIRED and QUIET flags easier when finding transitive dependencies. It shouldn’t be expected to do anything more than that.
If you need to use FetchContent to bring a transitive dependency in, then use FetchContent, but I would discourage doing that in a config package file. If you can use find_dependency() instead, consumers can still override it to use FetchContent if they want thanks to the new integration added in CMake 3.24. More importantly though, if the consumers are using an older CMake version that doesn’t support FetchContent, then you would be locking them out of your project if you used FetchContent in your project’s config package file. Package managers might also not take too kindly to any use of FetchContent inside config package files.
In general, I’d say use find_dependency() in config package files, even if that dependency was obtained using FetchContent when you built your project to produce a package for it. Consumers then have the choice of how to provide that dependency. If you rely on some aspect of pulling in that dependency via FetchContent though, then I guess this path isn’t open to you. CMake 3.24 provides you with more alternatives to your existing approach of writing a minimal Find module, but it will likely be quite a while before you can reasonably require consumers to be using CMake 3.24 or later, so those techniques probably aren’t viable for now.
This comes up in various forms in the issue tracker reasonably often. If I’m understanding you correctly, I think the main umbrella issue you may be interested in is 22686. That issue went off into the weeds and never really recovered. Last private feedback I had from some mainstream package managers were pretty pessimistic about its prospects, but I don’t know if that view has changed. Either way, I don’t have the time or energy to drive that one. I think it would need someone with more dedicated resources to take ownership of it to have any success. Even the features I added to CMake 3.24 came at a high personal cost, and I’m in no hurry to put myself through that again any time soon.
1 Like