# Propagating DOWNLOAD\_EXTRACT\_TIMESTAMP or CMP0135 settings to dependencies?
**URL:** https://discourse.cmake.org/t/propagating-download-extract-timestamp-or-cmp0135-settings-to-dependencies/6464
**Category:** Usage
**Created:** [September 12, 2022, 11:17pm UTC](https://discourse.cmake.org/t/propagating-download-extract-timestamp-or-cmp0135-settings-to-dependencies/6464 "2022-09-12T23:17:41Z")
**Posts on this page:** 7
**Page:** 1
### Author:  [@kisielk](https://discourse.cmake.org/u/kisielk)
#### Post date: [September 12, 2022, 11:17pm UTC](https://discourse.cmake.org/t/propagating-download-extract-timestamp-or-cmp0135-settings-to-dependencies/6464/1 "2022-09-12T23:17:41Z")
I’m running into a bit of an issue with the new `DOWNLOAD_EXTRACT_TIMESTAMP` option for `ExternalProject`. I’ve set
```auto
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.
---
### Author:  [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [September 14, 2022, 8:53pm UTC](https://discourse.cmake.org/t/propagating-download-extract-timestamp-or-cmp0135-settings-to-dependencies/6464/2 "2022-09-14T20:53:40Z")
You’d need to pass in `-DCMAKE_POLICY_DEFAULT_…=NEW` to these builds in some way.
---
### Author:  [@kisielk](https://discourse.cmake.org/u/kisielk)
#### Post date: [September 14, 2022, 9:01pm UTC](https://discourse.cmake.org/t/propagating-download-extract-timestamp-or-cmp0135-settings-to-dependencies/6464/3 "2022-09-14T21:01:16Z")
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.
---
### Author:  [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [September 14, 2022, 9:06pm UTC](https://discourse.cmake.org/t/propagating-download-extract-timestamp-or-cmp0135-settings-to-dependencies/6464/4 "2022-09-14T21:06:08Z")
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.
---
### Author:  [@kisielk](https://discourse.cmake.org/u/kisielk)
#### Post date: [September 14, 2022, 9:10pm UTC](https://discourse.cmake.org/t/propagating-download-extract-timestamp-or-cmp0135-settings-to-dependencies/6464/5 "2022-09-14T21:10:57Z")
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.
---
### Author:  [@hsattler](https://discourse.cmake.org/u/hsattler)
#### Post date: [September 15, 2022, 6:29am UTC](https://discourse.cmake.org/t/propagating-download-extract-timestamp-or-cmp0135-settings-to-dependencies/6464/6 "2022-09-15T06:29:37Z")
You could maybe use a toolchain file to set those and request its use via environment variable…
---
### Author:  [@kisielk](https://discourse.cmake.org/u/kisielk)
#### Post date: [September 16, 2022, 9:32pm UTC](https://discourse.cmake.org/t/propagating-download-extract-timestamp-or-cmp0135-settings-to-dependencies/6464/7 "2022-09-16T21:32:08Z")
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:
```auto
-- 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…