Propagating DOWNLOAD_EXTRACT_TIMESTAMP or CMP0135 settings to dependencies?

Usage
1

I’m running into a bit of an issue with the new DOWNLOAD_EXTRACT_TIMESTAMP option for ExternalProject. I’ve set

if(POLICY CMP0135)
	cmake_policy(SET CMP0135 NEW)
	set(CMAKE_POLICY_DEFAULT_CMP0135 NEW)
endif()

in our top-level CMakeLists.txt and that works fine for all our immediate dependencies that are fetched with CPM 's usage of FetchContent but the problem is that those dependencies then themselves use ExternalContent to fetch their own deps, and then some of those further do another level of ExternalContent. It seems that the policy is not able to propagate down the chain to those dependencies, presumably since they’re launching their own CMake builds and so we still get a whole bunch of CMake warnings during our builds. What’s the best way to deal with this and silence these? I don’t think we’ll be able to update all our external dependencies very easily.

2

You’d need to pass in -DCMAKE_POLICY_DEFAULT_…=NEW to these builds in some way.

3

Right, so my question is how can I do that if those builds are being triggered by ExternalProject in my dependencies (and sometimes in the dependencies of those dependencies)? It’s my understanding that a new instance of CMake is invoked for each of those sub-builds. I can’t really go up the chain and modify all the projects involved.

4

I don’t see a mechanism to do that, sorry. Maybe an envvar could be used as an additional mechanism? That would be a new feature request though.

5

It would be good if there was a way to do it. We try to have clean builds and so this new warning introduced by this new policy is causing some confusion in our organization. For now I can tell affected users to ignore it but that’s not a great long-term solution. I don’t know when, or if ever, the upstream dependencies will be updated to silence the warning.

6

You could maybe use a toolchain file to set those and request its use via environment variable…

7

Unfortunately that does not work either.

I put the code from my first post into the toolchain file and then used it for my build, here’s a portion of the log:

-- CMP0135: NEW
-- The ASM compiler identification is Clang with GNU-like command-line
-- Found assembler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc
-- Downloading clog to /Users/kamil/CLionProjects/pinpoint-noisefilter/cmake-build-test/clog-source (define CLOG_SOURCE_DIR to avoid it)
-- CMP0135: 
CMake Warning (dev) at /opt/homebrew/Cellar/cmake/3.24.1/share/cmake/Modules/ExternalProject.cmake:3071 (message):
  The DOWNLOAD_EXTRACT_TIMESTAMP option was not given and policy CMP0135 is
  not set.  The policy's OLD behavior will be used.  When using a URL
  download, the timestamps of extracted files should preferably be that of
  the time of extraction, otherwise code that depends on the extracted
  contents might not be rebuilt if the URL changes.  The OLD behavior
  preserves the timestamps from the archive instead, but this is usually not
  what you want.  Update your project to the NEW behavior or specify the
  DOWNLOAD_EXTRACT_TIMESTAMP option with a value of true to avoid this
  robustness issue.
Call Stack (most recent call first):
  /opt/homebrew/Cellar/cmake/3.24.1/share/cmake/Modules/ExternalProject.cmake:4168 (_ep_add_download_command)
  CMakeLists.txt:14 (ExternalProject_Add)
This warning is for project developers.  Use -Wno-dev to suppress it.

The lines beginning with CMP0135: are a modification I did to my local copy of ExternalProject.cmake to show me what the variable is, and it seems even with the policy set in a toolchain file when one of the dependencies triggers a download the value is once again clear…