Re: [cmake-developers] A policy for Policies
On 06/09/2015 11:24 AM, David Cole wrote: Is there a single example of a policy wherein the OLD behavior has actually been removed? No. This thread is about starting plans to actually remove some. It would good for all of us to understand exactly what it looks like to remove an OLD behavior. From the user perspective it means that it is an error for a project to not set the policy to NEW before hitting a relevant case. Typically cmake_minimum_required sets old policies to NEW implicitly. Older projects that do not have a sufficiently high requirement may no longer build. Perhaps instead we should make it an error only to explicitly set the policy to OLD and leave it as a warning to not set it to NEW. Either way the implementation of the OLD behavior will be removed and the NEW behavior will always be used. -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
Re: [cmake-developers] A policy for Policies
Is there a single example of a policy wherein the OLD behavior has actually been removed? Contributing to the problem is this: despite the policy mechanism, OLD behavior is never actually removed. Therefore, people know they can just set OLD and move on. The first policy was introduced in CMake v2.6.0, which is now just over 7 years old. The first 11 policies were introduced in v2.6.x, all more than 6 years old now. Would any of them be candidates for actually removing the OLD behavior now? It would good for all of us to understand exactly what it looks like to remove an OLD behavior. Is there an example series of commits anywhere (even on a side-branch or in patch-file form) which show removing an OLD behavior and updating the associated policy code to deal with it? Good discussion in this thread, by the way. Very informative. David C. On Tue, Jun 9, 2015 at 9:42 AM, Brad King brad.k...@kitware.com wrote: On 06/08/2015 08:43 PM, Fraser Hutchison wrote: As a CMake user, I have a couple of observations here. Thanks for coming forward to discuss this! users will be more likely to hit the page for the specific policy they're interested in, along with the page for the cmake_policy. None of these pages gives even a hint that setting a policy to OLD is discouraged. Good point. This should take care of that: Help: Document explicitly that policy OLD behavior is deprecated http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=482a3bf3 From my own perspective, runtime warnings would be the best way to encourage me to use a different option other than setting a policy to OLD. Yes. 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. I think this discussion has led us to understand that we need a second warning about setting the policy to OLD, 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. Thanks, -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 -- 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
Re: [cmake-developers] [PATCH] DEFINES_FILE feature for FindBISON module
On 06/08/2015 11:09 PM, 정언 wrote: New patches for FindBISON changes. Thanks. I revised the original module's documentation formatting and then rebased your changes on that. Applied here: FindBISON: Improve documentation formatting http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=801b799f FindBISON: Use BISON_TARGET macro argument names internally http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=29985ad8 FindBISON: Use CMAKE_PARSE_ARGUMENTS to parse arguments http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=eb859263 FindBISON: Add DEFINES_FILE option to pass --defines=FILE http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=12e534c2 Please test that version because I made some minor tweaks. Thanks, -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
Re: [cmake-developers] A policy for Policies
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
[cmake-developers] [CMake 0015606]: Having problem with building a C++ file using Cmake from linux to windows
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15606 == Reported By:Arunava Nag Assigned To: == Project:CMake Issue ID: 15606 Category: CMake Reproducibility:always Severity: minor Priority: urgent Status: new == Date Submitted: 2015-06-09 22:05 EDT Last Modified: 2015-06-09 22:05 EDT == Summary:Having problem with building a C++ file using Cmake from linux to windows Description: CMake Warning (dev) at CMakeLists.txt:6 (if): Policy CMP0054 is not set: Only interpret if() arguments as variables or keywords when unquoted. Run cmake --help-policy CMP0054 for policy details. Use the cmake_policy command to set the policy and suppress this warning. Quoted variables like MSVC will no longer be dereferenced when the policy is set to NEW. Since the policy is not set the OLD behavior will be used. This warning is for project developers. Use -Wno-dev to suppress it. CMake Warning (dev) at CMakeLists.txt:11 (elseif): Policy CMP0054 is not set: Only interpret if() arguments as variables or keywords when unquoted. Run cmake --help-policy CMP0054 for policy details. Use the cmake_policy command to set the policy and suppress this warning. Quoted variables like MSVC will no longer be dereferenced when the policy is set to NEW. Since the policy is not set the OLD behavior will be used. This warning is for project developers. Use -Wno-dev to suppress it. Configuring done == Issue History Date ModifiedUsername FieldChange == 2015-06-09 22:05 Arunava NagNew Issue == -- 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
Re: [cmake-developers] A policy for Policies
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. +1 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 personally never seen them as feature switches but I agree that they can be too quickly seen as such. 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. So that's why my newly added test broke with CMP0011 error :) I didn't even know that I was using this policy with old functionality... Can I somehow force treating of all policies as errors to spot such cases for e.g. in tests? Side question: Should cmake_minimum_required also be used in CMake scripts (added with -P argument to CMake command) not just CMakeLists.txt? And do we really still need version 2.6 as default (we could bump this version to where current policies are still treated as warnings not errors)? I'd also be glad if missing cmake_minimum_required in root CMake list/script would be treated as error and not as warning since you can get old policies in by accident. Regards, Domen -- 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
Re: [cmake-developers] A policy for Policies
On 06/08/2015 08:43 PM, Fraser Hutchison wrote: As a CMake user, I have a couple of observations here. Thanks for coming forward to discuss this! users will be more likely to hit the page for the specific policy they're interested in, along with the page for the cmake_policy. None of these pages gives even a hint that setting a policy to OLD is discouraged. Good point. This should take care of that: Help: Document explicitly that policy OLD behavior is deprecated http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=482a3bf3 From my own perspective, runtime warnings would be the best way to encourage me to use a different option other than setting a policy to OLD. Yes. 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. I think this discussion has led us to understand that we need a second warning about setting the policy to OLD, 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. Thanks, -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
