On 07/01/2015 02:17 PM, Stephen Kelly wrote: > Brad King wrote: >> We need to provide such capabilities so authors that do maintain >> their projects can be confident they've ported away from behavior >> that will later become an error. > > Makes sense to me.
I see topic end-Policy-lifetime with commit range e7fbd489..c7512801 currently in 'next', but it doesn't have anything about making things into errors early. I thought we agreed to build that infrastructure first. I guess POLICY_WARNING and POLICY_OPTIONAL_WARNING are a step in that direction but I'd like to see the actual error options be available before we start showing the warnings unconditionally. > I think the warning should indicate which version of CMake introduced the > policy (already the case) and the date that was released. This might provide > the information needed to prioritize that Alex was looking for by instead > asking for the date it would become an error. The problem with such dates is when the policy is introduced we don't know the date of the next release. Even if we had some kind of lookup table maintained as releases are made, the wording of policy messages would then change as a release is made, which is not great for testing. >> Let's skip these for 3.4 and see how the warnings for the 14 policies >> in the above and below groups work out. > > The reason I suggested emitting these unconditional warnings is that we > should establish what the lifecycle of policies actually is. No. My view throughout the conversation in this thread is that we don't know an appropriate length for the lifecycle. We should start by assuming it is longer than some of the oldest policies (e.g. CMP0011) and working our way forward through time. That will let us see how projects handle steps of the lifecycle without aggressively warning even on recently valid code. The lifecycle proposed in commit d5b1839a is way too aggressive. The end-Policy-lifetime topic looks nothing like the schedule or selection of policies discussed in the last few messages of this thread. > Setting a policy to OLD is not designed to be a convenience for the > maintainer of the project, who can schedule appropriate handling of > the policy. Originally it was intended to be exactly that. Not all projects are maintained on the same release schedule that CMake has. If they release only once per year then CMake could be deep into a policy lifecycle as proposed in d5b1839a. Many people skip a few CMake releases at a time and may jump over some of the steps. I think step 2 of that schedule should be at least 3 releases after step 1, but we don't really know yet what the schedule should be as mentioned above. All we've agreed upon in this thread is that 3.4 can emit unconditional warnings for CMP0011 and below and also CMP0024 and CMP0026 (since those are the ones we really want to get rid of and may be frequently set to OLD). Also it should come with options to make the warnings into errors so they are easier to find. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers