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