RFC: Deprecating direct calls to FetchContent_Populate()

In the early days of FetchContent (CMake 3.11 – 3.13), projects were required to implement the following pattern to populate a dependency:

FetchContent_GetProperties(depname)
if(NOT depname_POPULATED)
  FetchContent_Populate(depname)
  # ...maybe set some variables here...
  add_subdirectory(${depname_SOURCE_DIR} ${depname_BINARY_DIR})
endif()

Since CMake 3.14, FetchContent_MakeAvailable() became available and is the preferred way to populate instead. In recent CMake versions, FetchContent_MakeAvailable() has gained quite a bit more functionality, specifically all the integration with find_package() and the dependency providers features. It is therefore highly desirable for projects to use it instead of the old manual population pattern.

To that end, I propose deprecating direct calls to FetchContent_Populate() in project code. We can still allow it in script mode (cmake -P), since FetchContent_MakeAvailable() doesn’t apply to that use case. The deprecation message will highlight to projects that they should be updated to use FetchContent_MakeAvailable() instead, while not actually causing an error for now. I don’t expect to turn the deprecation into an error for quite a while (likely at least 2 years’ worth of CMake releases, or any other point where CMake drops other already deprecated features as a batch).

If there’s no objection, I propose to add this deprecation for the CMake 3.28 release toward the end of this year (I don’t want to add it for the upcoming 3.27 release, that’s a bit too close for me to get done without bumping other tasks).

1 Like

Looking at GitHub - cpm-cmake/CPM.cmake: 📦 CMake's missing package manager. A small CMake script for setup-free, cross-platform, reproducible dependency management. the move to FetchContent_MakeAvailable wouldn’t be possible intill we can mark a project with EXCLUDE_FROM_ALL

Thanks for pointing that out. Adding support for EXCLUDE_FROM_ALL to FetchContent_Declare() has been actively discussed recently and hopefully it will be implemented for CMake 3.27 3.28. You can find that discussion thread here: https://gitlab.kitware.com/cmake/cmake/-/issues/20167#note_1363010

1 Like

Why “just” a warning and not a policy?