# FetchContent and find\_dependency

**URL:** https://discourse.cmake.org/t/fetchcontent-and-find-dependency/6591
**Category:** Development
**Created:** [October 4, 2022, 3:32am UTC](https://discourse.cmake.org/t/fetchcontent-and-find-dependency/6591 "2022-10-04T03:32:52Z")
**Posts on this page:** 2
**Page:** 1

<div class="post-metadata">

### Author: ![benthevining](https://discourse.cmake.org/user_avatar/discourse.cmake.org/benthevining/32/1924_2.png) [@benthevining](https://discourse.cmake.org/u/benthevining)
#### Post date: [October 4, 2022, 3:32am UTC](https://discourse.cmake.org/t/fetchcontent-and-find-dependency/6591/1 "2022-10-04T03:32:52Z")

</div>

@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:

1. Extend the functionality of find\_dependency, perhaps to something like:

```cmake
find_dependency (FETCH_CONTENT_ARGS <args...>
                 FIND_PACKAGE_ARGS <args...>)

```

1. 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…

---

<div class="post-metadata">

### Author: ![craig.scott](https://discourse.cmake.org/user_avatar/discourse.cmake.org/craig.scott/32/20_2.png) [@craig.scott](https://discourse.cmake.org/u/craig.scott)
#### Post date: [October 7, 2022, 6:13am UTC](https://discourse.cmake.org/t/fetchcontent-and-find-dependency/6591/2 "2022-10-07T06:13:06Z")

</div>

`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.

> [@benthevining](#):
>
> 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

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](https://gitlab.kitware.com/cmake/cmake/-/issues/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.
