# How to vend dependency information/configuration

**URL:** https://discourse.cmake.org/t/how-to-vend-dependency-information-configuration/10319
**Category:** Usage
**Created:** [March 7, 2024, 7:35pm UTC](https://discourse.cmake.org/t/how-to-vend-dependency-information-configuration/10319 "2024-03-07T19:35:42Z")
**Posts on this page:** 1
**Showing post:** 3

<div class="post-metadata">

### Author: ![dabrahams](https://discourse.cmake.org/user_avatar/discourse.cmake.org/dabrahams/32/4265_2.png) [@dabrahams](https://discourse.cmake.org/u/dabrahams)
#### Post date: [March 10, 2024, 8:31pm UTC](https://discourse.cmake.org/t/how-to-vend-dependency-information-configuration/10319/3 "2024-03-10T20:31:50Z")

</div>

Thanks for your reply, (which I’m intentionally answering in reverse order); I wanted to make sure I really knew what I was talking about before posting again.

> [@craig.scott](#):
>
> > [@dabrahams](#):
> >
> > Also it violates the convention that there should be only one call to `FetchContent_make_available`.
> 
> I’m not aware of that convention, nor would I want to try to enforce it. One of the behaviours of `FetchContent_MakeAvailable()` is that you can call it multiple times for the same dependency, and only the first call will try to do the population.

A friend of mine told me this is the way, and I could swear I found definitive confirmation of that in the official documentation, but I’m not seeing it now. The closest thing I see is this passage in the [FetchContent documentation](https://cmake.org/cmake/help/latest/module/FetchContent.html):

> Content population details should be defined separately from the command that performs the actual population. This separation ensures that all the dependency details are defined before anything might try to use them to populate content. This is particularly important in more complex project hierarchies where dependencies may be shared between multiple projects.

And I do think this discipline is very hard to maintain with an arrangement like the one I’m describing.

> [@craig.scott](#):
>
> In what way does that not work?

I think it will help to look at [an example](https://github.com/hylo-lang/Swifty-LLVM/blob/4faa0945c43c232c1d08575f63cd33d71f2be31f/CMakeLists.txt#L73-L117). Please ignore the somewhat questionable way this file does everything at the top level, and the fact that I used `NEVER` instead of `OPT_IN` for `FETCHCONTENT_TRY_FIND_PACKAGE_MODE`; those are temporary. Here are the problems I see:

1. If I want to get the transitive dependency fetching stuff from my dependency before I actually add the subdirectories of any dependencies, there’s [this little boilerplate dance](https://github.com/hylo-lang/Swifty-LLVM/blob/4faa0945c43c232c1d08575f63cd33d71f2be31f/CMakeLists.txt#L89-L91) I need to do.
2. I might be able to encapsulate that in a function, but I have to break up that dance [here](https://github.com/hylo-lang/Swifty-LLVM/blob/4faa0945c43c232c1d08575f63cd33d71f2be31f/CMakeLists.txt#L98-L99), because I can’t just call `FetchContent_Populate` unconditionally. Unlike `FetchContent_MakeAvailable` it _isn’t_ resilient to being called multiple times.
3. To know that I need to populate `SwiftCMakeXCTesting` [in this `else()` clause](https://github.com/hylo-lang/Swifty-LLVM/blob/4faa0945c43c232c1d08575f63cd33d71f2be31f/CMakeLists.txt#L93) I have to know that my conditional dependency, `GenerateSwiftXCTestMain` will populate it when I fetch _its_ dependencies. That information should be encapsulated.
4. If I’ve called `FetchContent_Populate` on a dependency, the subsequent call to `FetchContent_MakeAvailable` doesn’t actually make it available and I have to [explicitly `add_subdirectory`](https://github.com/hylo-lang/Swifty-LLVM/blob/4faa0945c43c232c1d08575f63cd33d71f2be31f/CMakeLists.txt#L110-L111) on it. And when `FetchContent_MakeAvailable` bypasses `add_subdirectory` it also bypasses a bunch of other logic I haven’t analyzed, so who knows what important things I may be missing here?
5. If any of these dependencies themselves do what I’m doing here in their `XXX_FetchDependencies.cmake` file, they may fetch a shared dependency before all the other dependencies I use have a chance to declare version requirements in their `FIND_PACKAGE_ARGS`. And AFAICT there’s no established way to string together a set of dependency declarations with their version requirements so that the top level can sort them out and decide what to actually fetch.

---

_[View the full topic](https://discourse.cmake.org/t/how-to-vend-dependency-information-configuration/10319)._