FetchContent path handling changed?

I have a project that does this:

set(JAMBA_ROOT_DIR "../../pongasoft/jamba")

  # instructs FetchContent to not download or update but use the location instead

set(JAMBA_GIT_REPO "https://github.com/pongasoft/jamba" CACHE STRING "Jamba git repository url" FORCE)
set(JAMBA_GIT_TAG v5.1.1 CACHE STRING "Jamba git tag" FORCE)

      GIT_TAG           ${JAMBA_GIT_TAG}
      GIT_CONFIG        advice.detachedHead=false
      GIT_SHALLOW       true
      SOURCE_DIR        "${CMAKE_BINARY_DIR}/jamba"
      BINARY_DIR        "${CMAKE_BINARY_DIR}/jamba-build"
      BUILD_COMMAND     ""
      TEST_COMMAND      ""



And I am getting this error:

CMake Error at /Applications/CMake.app/Contents/share/cmake-3.19/Modules/FetchContent.cmake:1057 (message):
  Manually specified source directory is missing:

    FETCHCONTENT_SOURCE_DIR_JAMBA --> ../../pongasoft/jamba
Call Stack (most recent call first):
  jamba.cmake:38 (FetchContent_Populate)
  CMakeLists.txt:38 (include)

This is failing using cmake 3.19.2 but is working fine with 3.17.3!!

If I use:

set(JAMBA_ROOT_DIR "${CMAKE_CURRENT_LIST_DIR}/../../pongasoft/jamba")

then it works fine.

Is this a behavior that was changed on purpose or is it a bug that was introduced?


You should never use a relative path for FETCHCONTENT_SOURCE_DIR_<depName>. It will be provided back to the project in a <depName>_SOURCE_DIR variable unchanged, i.e. as a relative path. When projects use that, the actual effective path they then get will be different depending on what directory scope the project calls FetchContent_Populate() from.

You probably never noticed with previous CMake versions because you just happened to have the path in the right place and always called FetchContent_Populate() from the same directory scope.

CMake 3.19 added an explicit check that the source directory exists to catch the situation where you gave it a path that doesn’t actually exist. The issue that led to the change can be found here. The fact that this check is now triggering an error for you indicates that the directory doesn’t actually exist at the relative location you think it does. When I use your test project locally on my machine, I ensure that directory exists and CMake does not give me an error.

I understand that I am not supposed to do it (although I don’t remember reading it in the documentation).

But your statement:

The fact that this check is now triggering an error for you indicates that the directory doesn’t actually exist at the relative location you think it does

is actually wrong. It is working fine and as expected with 3.17.3 but not with 3.19.2.

My directory structure is the following:


The code that defines the JAMBA_ROOT_DIR (the source code in my previous post) comes from pongasoft/vst-sam-spl-64/CMakeLists.txt so ../../pongasoft/jamba does exist.

Since it was working fine with 3.17.3 also shows that the directory exists otherwise my code would simply not compile…

Where do you put your build directory?

In some temp folder outside the source tree. But I do the same with 3.7.13 (and I have been building with this setup for several years on 2 different platforms (mac and PC))

Can you please give the exact path of your build directory relative to your source directory.

My source directory is


My build directory is (when building from the command line)


or (when opening the project in CLion which works with CMake natively)


They obviously both work with ../../pongasoft/jamba and cmake 3.17.3 since this is what I have been using for years…

/Volumes/Vault and /Volumes/Development are 2 distinct drives and there is no link between them…

Reported as issue 21624 and fix for the 3.19 release branch in MR 5641. This will make it a warning instead of a hard error.

Looks like the right thing to do as this change essentially made CMake not backward compatible. I will update my code on my end too and probably revert to a previous version of CMake in the meantime.