Brad King wrote: > The intention originally was that the warning about the policy not > being set would prompt project authors to port to the NEW behavior > and set the policy. The only reason for the OLD setting is to > disable the warning in stable release branches and such.
It is also easy to throw a stone and hit projects doing the right thing. Eg https://github.com/knopkem/yaps/blob/master/CMakeLists.txt The problems are that we have no defined lifecycle for a Policy except "It can be set to OLD after it is introduced" (no end point), and that others - even greenfield projects starting their project with CMake 3.2 - see the policies as feature toggles. > I think this discussion has led us to understand that we need a > second warning about setting the policy to OLD That's certainly not where this discussion leads me :). A second warning would be 'throwing good money after bad'. Policies should issue 'unconditional' warnings in time frames of less than 6 years. > , but not immediately. > A few releases before policy OLD behavior is to actually be removed > we could add a runtime warning for code that does not set it to > NEW implicitly or explicitly. The only way to turn off this second > warning (aside from -Wno-dev) would be to set the policy to NEW. > This would give straggling projects another chance to port. It is clear from this discussion that the current design of Policies is not good enough. It's good that that's recognized, but adding different warnings and more complexity to Policy implementations is not the right response. The right response is to make a Policy something credibly not a feature toggle. Even Alex thinks the only right time to fix code is when an actual error is issued: http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/51705/focus=51835 We only need one warning, not two. Making Policies even more complex is a bad direction and not a valuable one. A better Policy lifecycle would be 1) Three releases after introducing a Policy, we make OLD the same as WARN for it. That is, the only way to not get the warning will be to fix the code or use -Wno-dev. 2) After some time in years (depending on the impact of the Policy), we change it to an unconditional error. 3) Remove the code implementing the OLD behavior in a following release. My suggestion is similar to yours except that mine introduces the no-OLD implementation closer to the introduction of the Policy rather than close to the removal of it. That will achieve the goal of allowing projects to silence the warning when they're close to their own release, and the goal of encouraging fixing code away from OLD behavior in a timely manner. We should also apply this retroactively and make CMake 3.4 issue warnings for policies introduced in 3.1 and earlier. There is contemporary greenfield code using Policy OLD as feature switches: http://stackoverflow.com/questions/14822794 "It seems that policy CMP0003 may be what you need." "I think CMP0003 is used to switch on/off the function of adding searching path automatically as described in the official document" That is because currently Policies *are* feature switches. The answer to that is not more warnings, as Alex told us, but error conditions. There needs to be credibility to any documentation claiming that setting a Policy to OLD will result in an error some day. Such documentatation will be ignored. I've pushed a branch for testing which updates the policies <= CMP0011 to REQUIRED_IF_USED. Those have resulted in warnings by default for 6 years. That is a long time to ignore warnings. I can push a follow up changing the implementation of policies <= CMP0054 to issue a warning in the case of OLD behavior. The projects this will potentially affect negatively are the projects which have been unmaintained for 6 years. It makes sense to use a CMake version from the same era if you want to use something that was maintained at the time. Thanks, Steve. -- 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
