This is the strategy I’m currently pursuing.
Now I’d like to ask about the true meaning of the passage I quoted from the FetchContent documentation that begins:
Content population details should be defined separately from the command that performs the actual population.
I assumed that this idea explains why FetchContent usage is always two-phase: first a _Declare call and then (normally) a _MakeAvailable call. But if I pursue the strategy above, I’m going to end up creating and calling a single function that does both parts. And I don’t really understand why that would be a problem.
The doc goes on to give this rationale:
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.
But it seems to me that if top-level projects always determine all the dependencies, as @ben.boeckel confirmed is the way to do things, that separation becomes irrelevant.
Lastly, it seems as though, even if I don’t follow the top-level-owns-dependency-resolution pattern, there’s no obvious pattern of usage that would let me take advantage of the separation that the FetchContent docs are advocating.
This is so confusing. Am I misunderstanding what the doc means by “separation?”