Timestamps for URL downloads match the download time

[robertmaynard]

By enabling CMake policy 135 we ensure that extracted files timestamp match that of the download time, instead of when the archive is created. This makes sure that if the URL changes to an older version we still rebuild everything as the timestamp
stays newer.

[TheLartians]

Hey, thanks for the PR! That policy change definitely sounds like a good idea. However, I feel a bit uneasy with changing global CMake policies from a utility script like CPM, as it can be unexpected for users. E.g. this lead to different behaviour of the same scripts based on the current CMake version.

Alternatively, how about adding a note to the Readme explaining the issue and suggesting using cmake_minimum_required(VERSION <min>...3.24) (which will auto-set the new policies) in projects, if possible?

[robertmaynard]

Hey, thanks for the PR! That policy change definitely sounds like a good idea. However, I feel a bit uneasy with changing global CMake policies from a utility script like CPM, as it can be unexpected for users. E.g. this lead to different behaviour of the same scripts based on the current CMake version.

Alternatively, how about adding a note to the Readme explaining the issue and suggesting using cmake_minimum_required(VERSION <min>...3.24) (which will auto-set the new policies) in projects, if possible?

I think we would need to suggest that the projects set CMAKE_POLICY_DEFAULT_CMP0135 value instead cmake_minimum_version. That way when a nested project calls CPM it uses the correct behavior instead of the behavior being reset by the nested projects cmake_minimum_version call.

[robertmaynard]

How about if we do this as a global CPM option? That would be an opt-in behavior change and we would document the flag as only working with CMake 3.24+

[TheLartians]

I think we would need to suggest that the projects set CMAKE_POLICY_DEFAULT_CMP0135 value instead cmake_minimum_version. That way when a nested project calls CPM it uses the correct behavior instead of the behavior being reset by the nested projects cmake_minimum_version call.

I see, that's a good point. Maybe having an option like CPM_SET_RECOMMENDED_CMAKE_POLICIES, that sets the policies and defaults (as available for the current CMake version) on launch, would be a good idea.

[robertmaynard]

I think we would need to suggest that the projects set CMAKE_POLICY_DEFAULT_CMP0135 value instead cmake_minimum_version. That way when a nested project calls CPM it uses the correct behavior instead of the behavior being reset by the nested projects cmake_minimum_version call.

I see, that's a good point. Maybe having an option like CPM_SET_RECOMMENDED_CMAKE_POLICIES, that sets the policies and defaults (as available for the current CMake version) on launch, would be a good idea.

I have updated this PR with the introduction of CPM_SET_RECOMMENDED_CMAKE_POLICIES

[TheLartians]

Thanks for updating the PR to add the recommended policy updates!

[TheLartians]

I also wonder if it would make sense to default CPM_SET_RECOMMENDED_CMAKE_POLICIES to YES, as I can imagine this being much more common than opting out. It's hard to imagine the policy changes in question to introduce bugs. But then again I'm not completely sure about all possible implications and edge-cases.

@iboB do you have any thoughts on this?

[iboB]

I agree with @TheLartians that setting the policies to new by default is desirable. This is the future, right? :)

I also think that we should set them when CPM.cmake is included.

It should be the responsibility of the users to manually handle policies if they want to depend on the old behavor

IMO the tougher question is what to do with the policies set in cmp_add_subdirectory. We can just delete the code there and assume they're being handled from above (and I favor this), but it should be noted that if we allow opting out of setting the default CPM policies, old working code with options will break. If we do keep the code there, there is no point in setting them to NEW at the point of inclusion. Also in such case CPMAddPackage will set them to NEW in packages added with OPTIONS anyway regardless of the opt-out. We could also do a cmake_policy(PUSH/POP) there to try to save the policy configuration from the scope above, but they will be set to NEW in the package's CMakeLists anyway.

Thinking about it, I find it unpleasant that adding the exact same package with and without OPTIONS will lead to potentially different policy configurations in the package itself.

So... in short I would:

• set all three policies to NEW when including CPM.cmake without the possibility to opt-out
• document that these policies are set to NEW and advise authors who want to depend on the old behavior that they should manually take care of it in the appropriate places.

[robertmaynard]

Based on the feedback it looks like everyone agrees that the policies should be set on inclusion of CPM.cmake. So I have updated the PR to do exactly that.

The policies are still guarded by CPM_SET_RECOMMENDED_CMAKE_POLICIES, but by default the value is set to ON. Once we have agreed on default behavior I will update this PR.

[TheLartians]

Thanks @iboB for the feedback and @robertmaynard for the changes!

After thinking about it I'm now also convinced that setting the policies initially without option to opt-out is the way to go. Besides the points mentioned above, providing no opt-out also means less options to handle and maintain for us. If setting the policies do lead to an increase in issues, we can still add an opt-out in a future version if deemed necessary.

[robertmaynard]

After thinking about it I'm now also convinced that setting the policies initially without option to opt-out is the way to go. Besides the points mentioned above, providing no opt-out also means less options to handle and maintain for us. If setting the policies do lead to an increase in issues, we can still add an opt-out in a future version if deemed necessary.

I have updated the PR to always enable the policies, and dropped the CPM_SET_RECOMMENDED_CMAKE_POLICIES option ( and docs ).

[TheLartians]

Looks good, thanks! Perhaps we can still add a quick note in the readme about the policies , but IMO it's also good as is.