FetchContent_Declare: should it re-fetch when the GIT_SUBMODULES param changes?

I am modifying slightly a project called boost-cmake that I found on Github. In his project he grabs the boost tarball from jfrog.io, but I am instead using git to pull the overall project and selected submodules. Here’s the gist of what I do:

set(BOOST_URL "https://github.com/boostorg/boost.git")
set(BOOST_REQD_SUBMODULES
    "libs/multiprecision;libs/config"   # leave value empty if all submodules wanted
    "libs/mpl;libs/preprocessor;libs/type_traits"
)

include(FetchContent)
FetchContent_Declare(
    Boost
    GIT_REPOSITORY ${BOOST_URL}
    GIT_TAG boost-1.75.0                        # v1.75.0
    GIT_SUBMODULES ${BOOST_REQD_SUBMODULES}
    GIT_PROGRESS TRUE
    CONFIGURE_COMMAND ""                        # tell CMake it's not a cmake project
)
FetchContent_GetProperties(Boost)

if(NOT Boost_POPULATED)
  message(STATUS "Fetching Boost")
  FetchContent_Populate(Boost)
  message(STATUS "Fetching Boost - done")
  set(BOOST_SOURCE ${boost_SOURCE_DIR})
endif()

As I add submodules to my variable ${BOOST_REQD_SUBMODULES} the Fetch is not re-executed. Actually, to clarify: The message “Fetching Boost” always appears, but when the GIT_SUBMODULES value changes it does not add to _deps the additional Boost submodule. I have to manually clear the _deps folder in the build folder and then it will get the added submodule when I run CMake again. I’m wondering if this is a FetchContent flaw or the way it is designed. I’m designing this to only download modules we depend on now but want the flexibility to add boost modules down the road. I’d like to make this as seamless as possible for users so if I could avoid having to instruct them they need to manually remove the _deps folder when a new submodule gets added that would be ideal.

Any suggestions? I ask about the GIT_SUBMODULES param because I thought I saw somewhere else that modifying the GIT_TAG would force a re-fetch.

Sounds like the “is the source out-of-date” detection needs to take the submodule list into account. FYI @craig.scott

1 Like

Wow that was fast. I have to say this is one of the best forums I’ve encountered. You guys are awesome.

Which CMake version was this with? Please try the latest release. There were changes that went in to 3.23.0 (notable MR 6926) which I think will have already fixed the problem you’re seeing.

My bad - I spaced out on reporting what version I was using. The problem occurred with 3.21. It’s gone in 3.23.1.