# FetchContent path handling changed?

**URL:** https://discourse.cmake.org/t/fetchcontent-path-handling-changed/2400
**Category:** Usage
**Created:** [December 20, 2020, 5:30pm UTC](https://discourse.cmake.org/t/fetchcontent-path-handling-changed/2400 "2020-12-20T17:30:21Z")
**Posts on this page:** 9
**Page:** 1

<div class="post-metadata">

### Author: ![fry](https://discourse.cmake.org/user_avatar/discourse.cmake.org/fry/32/613_2.png) [@fry](https://discourse.cmake.org/u/fry)
#### Post date: [December 20, 2020, 5:30pm UTC](https://discourse.cmake.org/t/fetchcontent-path-handling-changed/2400/1 "2020-12-20T17:30:21Z")

</div>

I have a project that does this:

```nohighlight
set(JAMBA_ROOT_DIR "../../pongasoft/jamba")
...
include(FetchContent)

if(JAMBA_ROOT_DIR)
  # instructs FetchContent to not download or update but use the location instead
  set(FETCHCONTENT_SOURCE_DIR_JAMBA ${JAMBA_ROOT_DIR})
else()
  set(FETCHCONTENT_SOURCE_DIR_JAMBA "")
endif()

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)

FetchContent_Declare(jamba
      GIT_REPOSITORY ${JAMBA_GIT_REPO}
      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"
      CONFIGURE_COMMAND ""
      BUILD_COMMAND ""
      INSTALL_COMMAND ""
      TEST_COMMAND ""
      )

FetchContent_GetProperties(jamba)

if(NOT jamba_POPULATED)
  FetchContent_Populate(jamba)
endif()

```

And I am getting this error:

```nohighlight
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:

```nohighlight
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?

Thanks  
Yan

---

<div class="post-metadata">

### Author: ![craig.scott](https://discourse.cmake.org/user_avatar/discourse.cmake.org/craig.scott/32/20_2.png) [@craig.scott](https://discourse.cmake.org/u/craig.scott)
#### Post date: [December 21, 2020, 10:37am UTC](https://discourse.cmake.org/t/fetchcontent-path-handling-changed/2400/2 "2020-12-21T10:37:02Z")

</div>

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](https://gitlab.kitware.com/cmake/cmake/-/issues/21208). 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.

---

<div class="post-metadata">

### Author: ![fry](https://discourse.cmake.org/user_avatar/discourse.cmake.org/fry/32/613_2.png) [@fry](https://discourse.cmake.org/u/fry)
#### Post date: [December 21, 2020, 2:03pm UTC](https://discourse.cmake.org/t/fetchcontent-path-handling-changed/2400/3 "2020-12-21T14:03:08Z")

</div>

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:

```nohighlight
pongasoft/jamba/CMakeLists.txt
pongasoft/vst-sam-spl-64/CMakeLists.txt

```

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…

---

<div class="post-metadata">

### Author: ![craig.scott](https://discourse.cmake.org/user_avatar/discourse.cmake.org/craig.scott/32/20_2.png) [@craig.scott](https://discourse.cmake.org/u/craig.scott)
#### Post date: [December 21, 2020, 8:39pm UTC](https://discourse.cmake.org/t/fetchcontent-path-handling-changed/2400/4 "2020-12-21T20:39:53Z")

</div>

Where do you put your build directory?

---

<div class="post-metadata">

### Author: ![fry](https://discourse.cmake.org/user_avatar/discourse.cmake.org/fry/32/613_2.png) [@fry](https://discourse.cmake.org/u/fry)
#### Post date: [December 21, 2020, 8:43pm UTC](https://discourse.cmake.org/t/fetchcontent-path-handling-changed/2400/5 "2020-12-21T20:43:40Z")

</div>

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))

---

<div class="post-metadata">

### Author: ![craig.scott](https://discourse.cmake.org/user_avatar/discourse.cmake.org/craig.scott/32/20_2.png) [@craig.scott](https://discourse.cmake.org/u/craig.scott)
#### Post date: [December 21, 2020, 8:54pm UTC](https://discourse.cmake.org/t/fetchcontent-path-handling-changed/2400/6 "2020-12-21T20:54:25Z")

</div>

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

---

<div class="post-metadata">

### Author: ![fry](https://discourse.cmake.org/user_avatar/discourse.cmake.org/fry/32/613_2.png) [@fry](https://discourse.cmake.org/u/fry)
#### Post date: [December 21, 2020, 9:06pm UTC](https://discourse.cmake.org/t/fetchcontent-path-handling-changed/2400/7 "2020-12-21T21:06:32Z")

</div>

My source directory is

```nohighlight
/Volumes/Development/github/pongasoft/vst-sam-spl-64

```

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

```nohighlight
/Volumes/Vault/tmp/vst-sam-spl-64/build

```

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

```nohighlight
/Volumes/Vault/deployment/build/vst-sam-spl-64/Debug

```

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…

---

<div class="post-metadata">

### Author: ![craig.scott](https://discourse.cmake.org/user_avatar/discourse.cmake.org/craig.scott/32/20_2.png) [@craig.scott](https://discourse.cmake.org/u/craig.scott)
#### Post date: [December 21, 2020, 11:51pm UTC](https://discourse.cmake.org/t/fetchcontent-path-handling-changed/2400/8 "2020-12-21T23:51:34Z")

</div>

Reported as [issue 21624](https://gitlab.kitware.com/cmake/cmake/-/issues/21624) and fix for the 3.19 release branch in [MR 5641](https://gitlab.kitware.com/cmake/cmake/-/merge_requests/5641). This will make it a warning instead of a hard error.

---

<div class="post-metadata">

### Author: ![fry](https://discourse.cmake.org/user_avatar/discourse.cmake.org/fry/32/613_2.png) [@fry](https://discourse.cmake.org/u/fry)
#### Post date: [December 22, 2020, 2:07pm UTC](https://discourse.cmake.org/t/fetchcontent-path-handling-changed/2400/9 "2020-12-22T14:07:11Z")

</div>

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.