Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change in FetchContent CMake API (v3.24) #21

Open
tpoignonec opened this issue Sep 17, 2024 · 1 comment
Open

Change in FetchContent CMake API (v3.24) #21

tpoignonec opened this issue Sep 17, 2024 · 1 comment
Assignees

Comments

@tpoignonec
Copy link
Member

A new DOWNLOAD_EXTRACT_TIMESTAMP option was added to the FetchContent CMake tool.

TODO: check doc and make code compliant.

--- stderr: fd_sdk_vendor                   
CMake Warning (dev) at /usr/share/cmake-3.28/Modules/FetchContent.cmake:1331 (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):
  CMakeLists.txt:34 (fetchcontent_declare)
This warning is for project developers.  Use -Wno-dev to suppress it.
@tpoignonec tpoignonec self-assigned this Sep 17, 2024
@tpoignonec tpoignonec changed the title Change in FetchContent CMake API Change in FetchContent CMake API (v3.24) Sep 17, 2024
@tpoignonec
Copy link
Member Author

From CMake documentation of policy CMP0135:

New in version 3.24.

When using the URL download method with the [ExternalProject_Add()](https://cmake.org/cmake/help/latest/module/ExternalProject.html#command:externalproject_add) or [FetchContent_Declare()](https://cmake.org/cmake/help/latest/module/FetchContent.html#command:fetchcontent_declare) commands, CMake 3.23 and below sets the timestamps of the extracted contents to the same as the timestamps in the archive. When the URL changes, the new archive is downloaded and extracted, but the timestamps of the extracted contents might not be newer than the previous contents. Anything that depends on the extracted contents might not be rebuilt, even though the contents may change.

CMake 3.24 and above prefers to set the timestamps of all extracted contents to the time of the extraction. This ensures that anything that depends on the extracted contents will be rebuilt whenever the URL changes.

The DOWNLOAD_EXTRACT_TIMESTAMP option to the [ExternalProject_Add()](https://cmake.org/cmake/help/latest/module/ExternalProject.html#command:externalproject_add) and [FetchContent_Declare()](https://cmake.org/cmake/help/latest/module/FetchContent.html#command:fetchcontent_declare) commands can be used to explicitly specify how timestamps should be handled. When DOWNLOAD_EXTRACT_TIMESTAMP is not given, this policy controls the default behavior. The OLD behavior for this policy is to restore the timestamps from the archive. The NEW behavior sets the timestamps of extracted contents to the time of extraction.

This policy was introduced in CMake version 3.24. It may be set by [cmake_policy()](https://cmake.org/cmake/help/latest/command/cmake_policy.html#command:cmake_policy) or [cmake_minimum_required()](https://cmake.org/cmake/help/latest/command/cmake_minimum_required.html#command:cmake_minimum_required). If it is not set, CMake warns, and uses OLD behavior.

Two easy options:

  1. fix policy to 3.23 for CMP0135 (legacy)
  2. always set parameter to TRUE. That seems to be better as there is no obvious downside...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant