FetchContent_Declare issues misleading error message

This was observed while using: CMake version 4.4.3 on windows

To me, this looks like a clear bug in CMake. While I was switching from Boost 1.86.0 to 1.90.0, I forgot to update to the correct URL_HASH. Instead of telling me that the hash was wrong, I observed that it was downloading six times in a row and ended with this message:

CMake Error at C:/builds/xxx/CMakeFiles/fc-stamp/boost/download-boost.cmake:163 (message):
[cmake] Each download failed!

This sent me down the wrong rabbit hole checking my ethernet connection. :face_with_bags_under_eyes:

Expected behavior

When a hash does not match, it should print an error message saying something like “Hey, the hash you supplied does not match!”

Observed behavior

Unnecessarily downloading six times and printing a wrong message at the end: “Each download failed!”. It is a) the wrong message and b) not true: all downloads succeeded perfectly.

my finally working code here:

FetchContent_Declare(
  Boost
  URL
      # https://artifactory/3rd-party/boost/releases/download/boost-1.86.0/boost-1.86.0-cmake.tar.xz
      https://artifactory/3rd-party/boost/releases/download/boost-1.90.0/boost-1.90.0-cmake.tar.xz
  URL_HASH
      # SHA256=2c5ec5edcdff47ff55e27ed9560b0a0b94b07bd07ed9928b476150e16b0efc57
      SHA256=aca59f889f0f32028ad88ba6764582b63c916ce5f77b31289ad19421a96c555f
  DOWNLOAD_EXTRACT_TIMESTAMP OFF
  EXCLUDE_FROM_ALL
)
FetchContent_MakeAvailable(Boost)

I can understand that the message differs from what you were expecting. Part of the problem is that sometimes a download does fail and instead of getting the file you asked for, you get some sort of error page. But the HTTP return code might still indicate success, so the only reliable indicator we have that the download failed is that it doesn’t match the expected hash.

Downloading six times also seems unexpected. From what I recall, the default retry count is only three. If you have two separate FetchContent_MakeAvailable(Boost) calls in your project, that might explain it though.

I acknowledge that simply saying “download failed” is a bit terse when we know the hash didn’t match. I recommend you open a new issue for this in CMake’s bug tracker with the information you’ve provided here. You can add a link back to this forum thread in the issue description. Not sure what’s possible for improving the error message, but having it in the issue tracker will keep it on my radar (I am the primary owner of that part of CMake).