Re: [cmake-developers] A policy for Policies
Stephen Kelly wrote: > Actually I re-discovered this today in KDE4 > > http://quickgit.kde.org/?p=kdelibs.git&a=blob&h=a9aecfd3&hb=dde411c1&f=cmake%2Fmodules%2FFindKDE4Internal.cmake#l349 KDE4 is 'done' from a development point of view. For several years there has been mainly only translation activity, so updating to new versions since then is not 'risky'. There are still enough people currently active and caring about KDE4 to fix the policy issues. Some of the fixing is done, but I think it's still ongoing. When it's finished KDE4 repos will use cmake_minimum_required(VERSION 2.8.9) without setting the ancient policies to OLD and without relying on OLD CMP0026 behavior. KDE4 repos may or may not trigger policies newer than 2.8.9. I don't know if there will be new releases from the KDE4 branches. Even if not, distributors can get the patches from the repos. So, for KDE4 the problem of CMake policies becoming errors is lessened. I'm not going to have time to design and implement end-of-life for CMake policies, so someone else can pick that task up if so inclined. 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
Re: [cmake-developers] A policy for Policies
Brad King wrote: > 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. Yes. The discussion died after my proposal. I've reverted the branch. 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
Re: [cmake-developers] A policy for Policies
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
Re: [cmake-developers] A policy for Policies
On Wed, Jul 08, 2015 at 14:11:44 -0400, David Cole wrote: > Interesting. So, sort of, but not really. At least not explicitly. Well, the docs state it, but there's no error for setting CMP0010 OLD and CMP0053 NEW at the same time other than the CMP0053 parser turning any code which would have required CMP0010 into a parse error (and it warns about the two parsers disagreeing if CMP0053 is the default). > I'm still interested in seeing an example commit (even if it's only > theoretical and will never actually be merged in) whose explicit > purpose is removing the OLD behavior of a single policy. (Is there > such a commit which removed the OLD behavior of CMP0010, or is it too > entwined in the parser improvement commits from the 3.1 release cycle > as to be easily identifiable as a concise diff?) My initial attempt at the new parser removed the parser entirely (5000+ lines removed :D ), but it has too many corner cases (allowed escape sequences, CMP0010, and others; look at the tests which came with CMP0053 for a taste). --Ben -- 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
Interesting. So, sort of, but not really. At least not explicitly. I'm still interested in seeing an example commit (even if it's only theoretical and will never actually be merged in) whose explicit purpose is removing the OLD behavior of a single policy. (Is there such a commit which removed the OLD behavior of CMP0010, or is it too entwined in the parser improvement commits from the 3.1 release cycle as to be easily identifiable as a concise diff?) Weird are the things interesting to geeks, right? Thx, David C. On Wed, Jul 8, 2015 at 10:34 AM, Ben Boeckel wrote: > On Tue, Jun 09, 2015 at 11:24:03 -0400, David Cole via cmake-developers wrote: >> Is there a single example of a policy wherein the OLD behavior has >> actually been removed? > > Technically, yes. CMP0053 as NEW ignores CMP0010's setting and treats it > as NEW (because the new parser doesn't implement the OLD behavior at > all). But CMP0010 is one of those "almost assuredly a bug" policies and > really easy to fix (just escape the '$' or add the closing '}'). > > --Ben -- 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 Tue, Jun 09, 2015 at 11:24:03 -0400, David Cole via cmake-developers wrote: > Is there a single example of a policy wherein the OLD behavior has > actually been removed? Technically, yes. CMP0053 as NEW ignores CMP0010's setting and treats it as NEW (because the new parser doesn't implement the OLD behavior at all). But CMP0010 is one of those "almost assuredly a bug" policies and really easy to fix (just escape the '$' or add the closing '}'). --Ben -- 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: > On 06/20/2015 05:29 AM, Stephen Kelly wrote: >> Even -Wno-dev should have no effect on the warning when the warning is >> unconditional. > > I think that makes sense. We would need to update the wording > accordingly. > >> I don't think more conditions with deprecation states is a good idea. > > I was brainstorming ways to make OLD behavior an error earlier than > the normal deprecation schedule for projects that are maintained. I see. > I don't think I called out the more important part of my previous > message well enough. We need to provide project authors with tools > to hunt down all OLD/unset behavior warnings before they become errors > by default. This includes warnings buried in script mode at build time > or in other cases that the output (which might have a warning) is never > visible. This means CMAKE_ERROR_DEPRECATED should turn policy warnings > into errors. We may need a way to activate such errors with an > environment variable. I see. > 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. We should also apply these tools > to our own test suite. Makes sense to me. >> CMake 3.4: >> >> * Policies <= CMP0011 >> -- emit unconditional warnings for each policy (no OLD anymore - 6 years >> old) > > Okay. IIUC the warnings should appear when: > > (1) the policy is explicit set to OLD, or > (2) the policy triggers without having been set to OLD or NEW > > For (2) we don't need to warn if the policy has been set to OLD > because (1) would have warned first. Therefore the logic in the > actual policy warning implementations does not have to change, > just the wording of the messages. Additionally, the cases cmPolicies::OLD and cmPolicies::WARN need to be reordered such that both issue a warning. 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. > >> * Policies CMP0051 -> CMP0054 >> -- emit unconditional warnings for each policy (no OLD anymore - 3 >> releases old) > > 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. We should do that in the next release by actually implementing it for the policies which match the criteria we decide which are at that part of the lifecycle. However, those policies will be three releases old for CMake 3.4. Maybe that is too old, and we should aim for allowing silencing the warning with cmake_policy for only one CMake release, and allow silencing it with the cmake option -Wno-dev for three releases. That should be easy enough to do by introducing a new MESSAGE_TYPE. Afaik, the only legitimate use designed for setting a policy to OLD is to relieve consumers of a project from the requirement of having to use the cmake option -Wno-dev while building the latest release of the project with the latest CMake. 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. Consumers whose cmake version in use progresses faster than the maintained project in use still get to use -Wno-dev to silence the warnings for a few CMake releases. 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
Re: [cmake-developers] A policy for Policies
On 06/20/2015 05:29 AM, Stephen Kelly wrote: > Even -Wno-dev should have no effect on the warning when the warning is > unconditional. I think that makes sense. We would need to update the wording accordingly. > I don't think more conditions with deprecation states is a good idea. I was brainstorming ways to make OLD behavior an error earlier than the normal deprecation schedule for projects that are maintained. I don't think I called out the more important part of my previous message well enough. We need to provide project authors with tools to hunt down all OLD/unset behavior warnings before they become errors by default. This includes warnings buried in script mode at build time or in other cases that the output (which might have a warning) is never visible. This means CMAKE_ERROR_DEPRECATED should turn policy warnings into errors. We may need a way to activate such errors with an environment variable. 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. We should also apply these tools to our own test suite. > CMake 3.4: > > * Policies <= CMP0011 > -- emit unconditional warnings for each policy (no OLD anymore - 6 years old) Okay. IIUC the warnings should appear when: (1) the policy is explicit set to OLD, or (2) the policy triggers without having been set to OLD or NEW For (2) we don't need to warn if the policy has been set to OLD because (1) would have warned first. Therefore the logic in the actual policy warning implementations does not have to change, just the wording of the messages. > * Policies CMP0051 -> CMP0054 > -- emit unconditional warnings for each policy (no OLD anymore - 3 releases > old) Let's skip these for 3.4 and see how the warnings for the 14 policies in the above and below groups work out. > * Policies CMP0026, CMP0024 > -- emit unconditional warning (CMP0026 warning will be in place for longer > as many are affected, so start unconditional warning now). These are high > priority because they make a better CMake implementation possible. Yes. Neither of these affect script mode and both have documentation that explains what to do instead, so it should be easy for projects to eliminate them. > Of course all of this needs to be malleable. Let's see what the response is > to the warning behavior in 3.4 if you apply it. Right, let's see how things go with 3.4's unconditional warnings before we decide on future releases. 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
On 06/22/2015 02:32 PM, Alexander Neundorf wrote:
> "Users who don't want to spend time babysitting their buildsystem, ".
So instead of incremental updates to the buildsystem occasionally as
KDE devs update their CMake, you're hiding the policies from them
until they become errors. Suddenly they will be faced with a bunch
of errors on behavior that should have been updated years ago. And
it will look like CMake's fault even though we provided years of
of compatibility.
> Once a newer version of cmake is required, those policy settings may be
> changed. But even doing this means that developers may have to relearn some
> of
> their cmake skills, which is a cost, and shouldn't be forced without good
> reason.
Porting a project to new policies does not mean forcing users to update
their CMake version.
For most policies it is possible to modify the source to work with CMake
versions from before the policy was introduced and also set the policy
to NEW for CMake versions that do have it. Often the policy warnings
are about cases that might not work with the new behavior but often
do. Then the change is just
if(POLICY ${policy})
cmake_policy(SET ${policy} NEW)
endif()
plus testing that it works. When the project later decides to require
a newer CMake then these explicit settings can go away.
> If there is a fixed date when the policy will result in an error, I'd
> consider
> it useful to have that date printed as part of the warning message.
We cannot predict such dates in general. Even if we could, they would
typically be so far in the future at the time the warning first appears
that no one would consider it a priority just for that reason.
The time to update a project to work with the NEW behavior of a policy
is as soon as possible after the maintainer of the project sees the
warning produced by the first version of CMake to introduce the policy.
We provide a grace period of *years* to fit such updates into the
maintainer's schedule.
-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
On Saturday, June 20, 2015 11:29:46 Stephen Kelly wrote: > Brad King wrote: > > > > I recommend the following guidelines: > > 1) Policies need to result in errors in a short timeframe. They are not > something to ignore for years, because allowing that makes them feature > toggles. Alex won't be happy with this one obviously, but that's what I > recommend. Just replace "Alex" with "Users who don't want to spend time babysitting their buildsystem, ". > 2) Policies need to result in unconditional warnings in a short timeframe. > Even -Wno-dev should have no effect on the warning when the warning is > unconditional. If third parties are using -Wno-dev to silence output they > need to know that will no longer work. It only works while there is an OLD > state for the policy. > > I don't think more conditions with deprecation states is a good idea. Policy > lifecycle should be simple to understand. It should be a loud notification > to people who see it that they have an action item on their hands. > > Here's my recommendation for a way forward: > > CMake 3.4: > > * Policies <= CMP0011 > -- emit unconditional warnings for each policy (no OLD anymore - 6 years > old) > > * Policies CMP0051 -> CMP0054 > -- emit unconditional warnings for each policy (no OLD anymore - 3 releases > old) > > * Policies CMP0026, CMP0024 > -- emit unconditional warning (CMP0026 warning will be in place for longer > as many are affected, so start unconditional warning now). These are high > priority because they make a better CMake implementation possible. > > CMake 3.5: > > * Policies CMP0001, CMP0003, CMP0004, CMP0006 -> CMP0010 > -- emit unconditional errors for each policy (the ancient ones except 'the > KDE4 policies') Just so it doesn't sound only stupid: when I was still maintaining the KDE4 buildsystem, I tried to avoid forcing users to have to update CMake (I always hate it if I try to do something on KDE, but instead of being able to start to do something, first I have to spend a day or two updating various stuff). Ok, I wanted to avoid that for the cmake part. So, let's say some version of KDE was released requiring CMake 2.4.5 (yeah, that old). As long as there was no strong reason to require a newer version of CMake, I kept it at 2.4.5. Which implied, that the source should still be compilable with 2.4.5. Which, (at least to be on the safe side), also means, if there is a policy which results in a warning e.g. in 2.6.0, developers should not fix that warning with 2.6.0, since this might mean it does not work anymore with 2.4.5. Once a newer version of cmake is required, those policy settings may be changed. But even doing this means that developers may have to relearn some of their cmake skills, which is a cost, and shouldn't be forced without good reason. Also, given the KDE4 source compatibility guarantees, kdebase 4.12 should still compile with kdelibs 4.3, and changing the cmake environments kde4libs is setting up influences this (and I had the impression that the uptake of more advanced cmake features in the wider KDE community was quite slow, e.g. learning about the subtleties of cmake policies). So to me this still sounds reasonable. ... > Of course all of this needs to be malleable. Let's see what the response is > to the warning behavior in 3.4 if you apply it. If there is a fixed date when the policy will result in an error, I'd consider it useful to have that date printed as part of the warning message. Alex -- 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: > I recommend the following guidelines: 1) Policies need to result in errors in a short timeframe. They are not something to ignore for years, because allowing that makes them feature toggles. Alex won't be happy with this one obviously, but that's what I recommend. 2) Policies need to result in unconditional warnings in a short timeframe. Even -Wno-dev should have no effect on the warning when the warning is unconditional. If third parties are using -Wno-dev to silence output they need to know that will no longer work. It only works while there is an OLD state for the policy. I don't think more conditions with deprecation states is a good idea. Policy lifecycle should be simple to understand. It should be a loud notification to people who see it that they have an action item on their hands. Here's my recommendation for a way forward: CMake 3.4: * Policies <= CMP0011 -- emit unconditional warnings for each policy (no OLD anymore - 6 years old) * Policies CMP0051 -> CMP0054 -- emit unconditional warnings for each policy (no OLD anymore - 3 releases old) * Policies CMP0026, CMP0024 -- emit unconditional warning (CMP0026 warning will be in place for longer as many are affected, so start unconditional warning now). These are high priority because they make a better CMake implementation possible. CMake 3.5: * Policies CMP0001, CMP0003, CMP0004, CMP0006 -> CMP0010 -- emit unconditional errors for each policy (the ancient ones except 'the KDE4 policies') * Policies CMP0055, CMP0056 -- emit unconditional warnings for each policy (no OLD anymore - 3 releases old) * Policies selection -- Select some other high-value policies to warn unconditionally on, eg CMP0031. CMake 3.6: * Policies CMP0051 -> CMP0054 -- emit unconditional errors for each policy (unconditional warning for two releases already) * Policies CMP0058, CMP0063 -- emit unconditional warnings for each policy (no OLD anymore - 3 releases old) CMake 3.7: * Policies CMP, CMP0002, CMP0003, CMP0005, , CMP0011 -- Make 'the KDE4 policies' unconditional errors. Of course all of this needs to be malleable. Let's see what the response is to the warning behavior in 3.4 if you apply it. 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
Re: [cmake-developers] A policy for Policies
On 06/11/2015 02:20 PM, Stephen Kelly wrote: > So, KDE4 as a platform breaks the cmake compatibility design for its > downstreams. At least ECM, used by KDE Frameworks 5, doesn't do that. That is unfortunate :( > I still think they should be unconditional warnings. Yes, see below. > I also think we should make them REQUIRED_* eventually, but I expect > you now never will. Either way we clearly need to do a better job at convincing projects to port away from OLD behaviors. One idea is that if a project does cmake_minimum_required(VERSION X.Y) # or cmake_policy(VERSION X.Y) then we can make it an error to set to OLD any policy introduced in version X.Y or earlier. (For pre-3.4 policies this may have to be an unconditional warning instead.) Then N(=6?) releases later we make it an unconditional warning regardless of cmake_minimum_required. We could also make setting a policy to OLD a deprecation warning for use with CMAKE_ERROR_DEPRECATED and CMAKE_WARN_DEPRECATED. We should also have a way to optionally turn policy-no-set warnings into errors to make them easy to find even in scripts whose output no one ever reads. 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: > We designed > policies to give projects smooth transitions from old to new behavior. > If we suddenly make an error occur in code that currently works > warning-free it will give policies and CMake a bad name. Ok. Actually I re-discovered this today in KDE4 http://quickgit.kde.org/?p=kdelibs.git&a=blob&h=a9aecfd3&hb=dde411c1&f=cmake%2Fmodules%2FFindKDE4Internal.cmake#l349 So, KDE4 as a platform breaks the cmake compatibility design for its downstreams. At least ECM, used by KDE Frameworks 5, doesn't do that. I still think they should be unconditional warnings. I also think we should make them REQUIRED_* eventually, but I expect you now never will. 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
Re: [cmake-developers] A policy for Policies
On 06/10/2015 03:52 PM, Domen Vrankar wrote: > I've read it in Mastering CMake and had to search for it today... On > page 42 it says that by default if cmake_minimu_required is missing it > sets policy version of 2.4. That's because version 2.6 was the first to introduce policies so using 2.4 leaves them all unset. Prior to that we had another mechanism called CMAKE_BACKWARDS_COMPATIBILITY which is now ignored when the version requested is 2.6 or higher. We cannot change the default value without possibly breaking existing scripts. -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
On 06/10/2015 05:41 PM, Stephen Kelly wrote: >> The presence of the warning from step (1) will mean projects should have >> long ported away from encountering the error. > > I think the same is true of the existing design of policies. The WARN > behavior of <= CMP0011 for the last six years is enough and we can error on > them. As you keep pointing out people *have* been setting policies to OLD like feature toggles. We cannot suddenly break them without warnings. The very plan that we've agreed on to use in the future acknowledges this. It will take a few releases to apply retroactively. I understand that you're doing a bunch of refactoring and supporting some of the policy OLD behaviors makes it harder, but we have to live with what has been done up to this point and deal with it. We designed policies to give projects smooth transitions from old to new behavior. If we suddenly make an error occur in code that currently works warning-free it will give policies and CMake a bad name. >> Projects that have been maintained but set policies to OLD will also be >> affected. Such projects need to be able to see warnings for a few >> releases first. > > What scenarios get the new CMake version into the hands of users who can do > anything about them? The projects that are maintained but set policies to OLD will see the new warnings and their maintainers will fix them. Our own test suite sits in this category as demonstrated by the fixes needed with your topic to get rid of errors caused by dropping support for OLD behavior. > They are warnings. By default. The warnings say "policy not set at all" and can be turned off and forgotten about for years by setting to OLD. We need to show them the new "policy not set to NEW" warnings that cannot be turned off except by fixing the code. -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: >> 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. > > Yes, we should consider enforcing CMP in script mode too > or perhaps add a separate policy for it. Yes. The good news is that 1) Most policies affect things related to the buildsystem/targets etc which are not in scope of scripts. So scripts affected by policies are rare (which is why this hasn't come up before). 2) Scripts which are affected by policies (such as CMP0010, CMP0054) can almost always be changed such that they also work with ancient cmake. 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
Re: [cmake-developers] A policy for Policies
Brad King wrote: > I think Fraser's point about the docs of each policy not explicitly > mentioning "deprecated" is a major culprit there. I disagree. It is obvious that NEW is better than OLD. If it 'works' people will use it until they are forced not to, as Alex said. I expect most people doing that are doing so in a well-informed way. The people getting help on SO and setting policies to OLD are in their first days/weeks of using cmake and probably seeing cmake documentation for the first time. It is not a good idea to use that as a reference scenario for us to make decisions. Even warnings won't prevent people relying on OLD behavior. They can still add -Wno-dev to a build script or alias (as is appropriate to do when building third party software). >> 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. > > Yes. We could also look at making this automatic in the implementation > of each policy by checking the version number or some internal release > counter. That way we don't have to remember to update old policies. It should be a simple pre-processor trick :). >> 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. > > If OLD behavior is an unconditional error then there is no reason not > to remove its implementation immediately in the same step. The old > code could not possibly be covered by the test suite anyway. > The > presence of the warning from step (1) will mean projects should have > long ported away from encountering the error. I think the same is true of the existing design of policies. The WARN behavior of <= CMP0011 for the last six years is enough and we can error on them. > Projects that have been maintained but set policies to OLD will also be > affected. Such projects need to be able to see warnings for a few > releases first. Why? What kind of scenario are you thinking of that warnings are a benefit? What scenarios get the new CMake version into the hands of users who can do anything about them? I think making policies <= CMP0011 errors in CMake 3.4 is a benefit to all parties (maintainers of cmake, third party buildsystem maintainers, users of third party software, people doing user support). Those policy warnings are six years old. > We need a transition plan that does not jump straight > to making things errors in 3.4 even for the oldest policies because > they are not even warnings right now. They are warnings. By default. What is the transition plan and what categories of third parties will and won't benefit from it? 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
Re: [cmake-developers] A policy for Policies
So, when you're saying:
"...but still supporting the OLD stuff with a warning if no one tried
explicitly to set things to use OLD, they just had a working build
system."
You're effectively saying we will never remove the OLD behavior for
any policies, ever?
If that's the case, then why bother even having policies?
On Wed, Jun 10, 2015 at 5:17 PM, Bill Hoffman wrote:
> On 6/10/2015 4:57 PM, Alexander Neundorf wrote:
>>
>> If the conclusion would be a policy is removed after 5 years, it's
>> deadline
>> could even be part of the error/warning message right from the point when
>> it
>> is introduced ("you are relying on CMP1234 OLD behaviour. This will be
>> removed
>> June 2020.").
>>
>> Then I could (at work) ignore this maybe until 2017 or 2018, and then it
>> would
>> slowly rise in my priority, and at some point I would fix it in some spare
>> time.
>
> I guess what we want to do is to come up with a system where the "fix" is
> not to just add OLD. We want to be able to build old releases of projects
> and not break them. However, if we change something that requires changes
> in the CMakeLists.txt we don't want the developers to just set to OLD, we
> want them to fix it. If someone goes to the trouble of editing the
> CMakeLists.txt, they should just do the fix not set to OLD to shut up the
> warning.
>
> There is also a whole bunch of users of CMake that have never written a
> single line of CMake code. They just build software and follow
> instructions. We want to try real hard to make things work for them and not
> to have a version of CMake nightmare for them.
>
> So, erroring on OLD earlier might work, but still supporting the OLD stuff
> with a warning if no one tried explicitly to set things to use OLD, they
> just had a working build system.
>
> -Bill
>
>
> --
>
> 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] A policy for Policies
On 6/10/2015 4:57 PM, Alexander Neundorf wrote:
If the conclusion would be a policy is removed after 5 years, it's deadline
could even be part of the error/warning message right from the point when it
is introduced ("you are relying on CMP1234 OLD behaviour. This will be removed
June 2020.").
Then I could (at work) ignore this maybe until 2017 or 2018, and then it would
slowly rise in my priority, and at some point I would fix it in some spare
time.
I guess what we want to do is to come up with a system where the "fix"
is not to just add OLD. We want to be able to build old releases of
projects and not break them. However, if we change something that
requires changes in the CMakeLists.txt we don't want the developers to
just set to OLD, we want them to fix it. If someone goes to the trouble
of editing the CMakeLists.txt, they should just do the fix not set to
OLD to shut up the warning.
There is also a whole bunch of users of CMake that have never written a
single line of CMake code. They just build software and follow
instructions. We want to try real hard to make things work for them and
not to have a version of CMake nightmare for them.
So, erroring on OLD earlier might work, but still supporting the OLD
stuff with a warning if no one tried explicitly to set things to use
OLD, they just had a working build system.
-Bill
--
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 Monday, June 08, 2015 09:57:14 Brad King wrote:
...
> This may be okay for CMP0011, but CMP0024 and CMP0026 were much
> more recent (3.0). I think 5 years is a more reasonable cut-off
> than 2 years, especially given the time it takes CMake versions
> included in older distro releases to fall out of common use.
Yes, I fully agree, 2 years would be quite quite short.
The buildsystem should do its job, and not get in the way and create
additional work.
I love that cmake still works on old projects, and doesn't fail when updating.
I can remember all the hassle with autotools if some versions did not match,
and I'm so happy that this is just not the case with cmake.
We have a lot of feature and time pressure at work (I guess most people around
have that), and not having to babysit the cmake code for a long time is great.
If the conclusion would be a policy is removed after 5 years, it's deadline
could even be part of the error/warning message right from the point when it
is introduced ("you are relying on CMP1234 OLD behaviour. This will be removed
June 2020.").
Then I could (at work) ignore this maybe until 2017 or 2018, and then it would
slowly rise in my priority, and at some point I would fix it in some spare
time.
Alex
--
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
>> 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)? > > To which default do you refer? Where in our code is it set? > Likely we cannot update it because it could change behavior > of existing scripts with no transition warning ever given. I've read it in Mastering CMake and had to search for it today... On page 42 it says that by default if cmake_minimu_required is missing it sets policy version of 2.4. It's probably a technical back compatibility reason (cmake_minimum_required wasn't present back then?) and those scripts don't necessarily use any of the policies that will change but I was wondering if changing this to a newer version (2.6.8?) would be appropriate now that older policies will no longer support current OLD setting. Since the main reason I proposed that was fall back of CMake scripts that are missing cmake_minimu_required I guess that printing out a warning for scripts as well would also be fine. 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/10/2015 01:41 AM, Domen Vrankar wrote: > 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? See my response to the GP for a side note about policies in tests. > Should cmake_minimum_required also be used in CMake scripts (added > with -P argument to CMake command) not just CMakeLists.txt? Yes. > 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)? To which default do you refer? Where in our code is it set? Likely we cannot update it because it could change behavior of existing scripts with no transition warning ever given. > 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. Yes, we should consider enforcing CMP in script mode too or perhaps add a separate policy for it. -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
On 06/09/2015 07:06 PM, Stephen Kelly wrote: > The problems are that we have no defined lifecycle for a Policy Agreed, and that's what this thread is about. > even greenfield projects starting their project with CMake 3.2 - see the > policies as feature toggles. I think Fraser's point about the docs of each policy not explicitly mentioning "deprecated" is a major culprit there. Even those that did read the policy documentation referenced by warnings were not told before that OLD means deprecated. The documentation update I made for that may help with future perception. > Policies should issue 'unconditional' warnings in time frames of > less than 6 years. Yes. > 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. Yes. We could also look at making this automatic in the implementation of each policy by checking the version number or some internal release counter. That way we don't have to remember to update old policies. > 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. If OLD behavior is an unconditional error then there is no reason not to remove its implementation immediately in the same step. The old code could not possibly be covered by the test suite anyway. The presence of the warning from step (1) will mean projects should have long ported away from encountering the error. > 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. Yes, I like that better. > 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. Good. > We should also apply this retroactively and make CMake 3.4 issue warnings > for policies introduced in 3.1 and earlier. Yes, though see below for an alternative schedule for transition to this policy sunset approach. > 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. > > The projects this will potentially affect negatively are the projects > which have been unmaintained for 6 years. Projects that have been maintained but set policies to OLD will also be affected. Such projects need to be able to see warnings for a few releases first. We need a transition plan that does not jump straight to making things errors in 3.4 even for the oldest policies because they are not even warnings right now. Side note: We also need infrastructure to catch policy warnings within our own test cases. Several tests have policy warnings right now that go unnoticed because no one reads the output of passing tests. - In order to test the waters of this approach I think we should start by placing policies <= CMP0011 into step 1 by adding warnings for use of OLD behavior in 3.4. Then in each following release play catch-up by adding warnings for policies introduced in the next two or three oldest releases. This will soften the blow by not adding dozens of new warnings in a single release. Depending on the reaction to such warnings in 3.4 we can decide on a schedule to remove the ancient policy OLD behavior altogether. -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
> 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
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
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 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] 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
Re: [cmake-developers] A policy for Policies
Hi there, I suspect I'm the culprit in this case. To give a bit of context, I think the original recommendation was to the CMake ML (http://cmake.3232098.n2.nabble.com/Help-with-Policy-CMP0026-disallow-LOCATION-target-property-td7589336.html) and the other instance was a recent StackOverflow answer (http://stackoverflow.com/a/30669105/2556117). I'd hardly class the SO answer as a recommendation... but that's by the by :-) As a CMake user, I have a couple of observations here. I don't think any amount of documentation will entirely solve this. Compare the docs for policies (http://www.cmake.org/cmake/help/v3.3/manual/cmake-policies.7.html) with those for file(GLOB ...) (http://www.cmake.org/cmake/help/v3.3/command/file.html) and link_directories (http://www.cmake.org/cmake/help/v3.3/command/link_directories.html) All of these discourage the use of these features in some way (probably most noticeable for file(GLOB ...) due to the highlighting), but there are often answers on SO which recommend them. Having said that, I think the docs for policies is the least likely to be read of the three. I'm only guessing, but I expect 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 command (http://www.cmake.org/cmake/help/v3.3/command/cmake_policy.html). None of these pages gives even a hint that setting a policy to OLD is discouraged. 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. Again as an outsider, if setting CMP0002 to OLD to allow duplicate target names is a guaranteed bug regardless of OS or compiler, I can't see a reason to continue supporting it. Cheers, Fraser. On 08/06/2015 21:52, Brad King wrote: On 06/08/2015 04:43 PM, Stephen Kelly wrote: In fact, I added that in response to someone on SO recommending setting policies to OLD and pointed them to the commit and the generated docs, and they're still recommending the same thing as SO answers. Policies are alive too long to be credible pending error-conditions. They look like - and are treated as - feature toggles. Given the existing docs you quoted I don't think any further docs such as release notes will help. We would need to add a runtime warning to draw attention to pending removal. It would be different than the current "not set" warning and instead be "not set to NEW". -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
On 06/08/2015 04:43 PM, Stephen Kelly wrote: > In fact, I added that in response to someone on SO recommending setting > policies to OLD and pointed them to the commit and the generated docs, and > they're still recommending the same thing as SO answers. Policies are alive > too long to be credible pending error-conditions. They look like - and are > treated as - feature toggles. Given the existing docs you quoted I don't think any further docs such as release notes will help. We would need to add a runtime warning to draw attention to pending removal. It would be different than the current "not set" warning and instead be "not set to NEW". -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: > On 06/08/2015 04:15 PM, Stephen Kelly wrote: >> This isn't a 3.3 feature but a change to the documentation/release notes >> which is supposed to be ok? > > Yes, if the wording does not commit us to a specific future release. Even if the docs say 'the next release', we are not obligated to remove them in the next release. >> I've changed the release notes to say 'some future release' instead. So, >> we can figure that out on a per-Policy basis. > > Okay. Actually shouldn't the documentation of every policy say it may > be removed in a future release? Yes. This documentation note is not necessary at all. The fact that they are Policies is already enough as you said. I just added it for notification anyway because it's possible. > That is their general purpose. Perhaps > that may help discourage projects from setting them to OLD. http://www.cmake.org/cmake/help/v3.2/manual/cmake-policies.7.html "The ``OLD`` behavior of each policy is undesirable and will be replaced with an error condition in a future release." Given what we see on mailing lists and SO, that doesn't help. In fact, I added that in response to someone on SO recommending setting policies to OLD and pointed them to the commit and the generated docs, and they're still recommending the same thing as SO answers. Policies are alive too long to be credible pending error-conditions. They look like - and are treated as - feature toggles. 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
Re: [cmake-developers] A policy for Policies
On 06/08/2015 04:25 PM, Brad King wrote: >> I've changed the release notes to say 'some future release' instead. So, we >> can figure that out on a per-Policy basis. > > Okay. Actually shouldn't the documentation of every policy say it may > be removed in a future release? That is their general purpose. Perhaps > that may help discourage projects from setting them to OLD. >From the change: > + are now deprecated. In a future release of CMake, it will not be possible > + to set them to ``OLD``. See also :manual:`cmake-policies(7)` Actually it will not be possible to build a project that does not set them to NEW explicitly or implicitly through cmake_minimum_required. This is a much stronger restriction. -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
On 06/08/2015 04:15 PM, Stephen Kelly wrote: > This isn't a 3.3 feature but a change to the documentation/release notes > which is supposed to be ok? Yes, if the wording does not commit us to a specific future release. > I've changed the release notes to say 'some future release' instead. So, we > can figure that out on a per-Policy basis. Okay. Actually shouldn't the documentation of every policy say it may be removed in a future release? That is their general purpose. Perhaps that may help discourage projects from setting them to OLD. >> There could still be code paths that never set the >> minimum required version of CMake and therefore never set the policy >> to NEW. > > Will that ever not be the case? Of course project code may need to be fixed for this but I'm concerned about code paths within CMake itself. I'm pretty sure ctest and cpack both create cmake language contexts and may not always set the policy version. Things like that will come out of the woodwork when a change like this is made, and may not be noticed until project code activates them. >> Any refactoring that depends on removing support for OLD behavior >> needs to wait until after a release or two have removed it. We need >> to retain the possibility to revert the removal if major problems >> arise. I don't want the fallback to be "re-implement post-refactoring" >> because typically this may be revealed during a release candidate >> cycle. > > I think that's overkill for something like CMP0044 as I described in my > other mail. It would be easily re-added. This seems like something to apply > on a case-by-case basis. If for a specific case it is very easy to re-add post-refactoring then it could instead just be subsumed in the refactoring instead of removed. I'm saying that refactoring that is made possible only by removing a policy should not be done until after the policy removal is well- established as acceptable. Otherwise refactoring should preserve policies even if it is harder. -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: > Also, no mention of this decision can be made in 3.3 because we are > already past the deadline for that release. This isn't a 3.3 feature but a change to the documentation/release notes which is supposed to be ok? > On 06/08/2015 03:52 PM, Stephen Kelly wrote: >> Given what you wrote about the impact of making CMP0011 required, I've >> instead documented all policies <= CMP0011 as deprecated for 3.3, making >> them fair-game for 3.4. > > Sorry, but that schedule is way too aggressive since we've never removed > policies before. There may be unforeseen problems with enforcing these > policy settings. I've changed the release notes to say 'some future release' instead. So, we can figure that out on a per-Policy basis. > There could still be code paths that never set the > minimum required version of CMake and therefore never set the policy > to NEW. Will that ever not be the case? > Any refactoring that depends on removing support for OLD behavior > needs to wait until after a release or two have removed it. We need > to retain the possibility to revert the removal if major problems > arise. I don't want the fallback to be "re-implement post-refactoring" > because typically this may be revealed during a release candidate > cycle. I think that's overkill for something like CMP0044 as I described in my other mail. It would be easily re-added. This seems like something to apply on a case-by-case basis. 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
Re: [cmake-developers] A policy for Policies
On 06/08/2015 03:52 PM, Stephen Kelly wrote: > Given what you wrote about the impact of making CMP0011 required, I've > instead documented all policies <= CMP0011 as deprecated for 3.3, making > them fair-game for 3.4. Sorry, but that schedule is way too aggressive since we've never removed policies before. There may be unforeseen problems with enforcing these policy settings. There could still be code paths that never set the minimum required version of CMake and therefore never set the policy to NEW. Any refactoring that depends on removing support for OLD behavior needs to wait until after a release or two have removed it. We need to retain the possibility to revert the removal if major problems arise. I don't want the fallback to be "re-implement post-refactoring" because typically this may be revealed during a release candidate cycle. Also, no mention of this decision can be made in 3.3 because we are already past the deadline for that release. -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
Stephen Kelly wrote: > Thanks for the clarification. I've added an entry to the release notes > that CMP0011 is deprecated, and I can add something similar for CMP0003. Given what you wrote about the impact of making CMP0011 required, I've instead documented all policies <= CMP0011 as deprecated for 3.3, making them fair-game for 3.4. 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
Re: [cmake-developers] A policy for Policies
Brad King wrote: > On 06/06/2015 06:36 AM, Stephen Kelly wrote: >> The documentation notes that Policies are not feature toggles: >> >> http://www.cmake.org/cmake/help/git-master/manual/cmake-policies.7.html >> >> However, the reality is that Policies *are* feature toggles because they >> are so long-lived. Users have no expectation that Policies will 'stop >> working', and happily set them to OLD and encourage others to do the >> same. I see this on StackOverflow all the time, and on the users mailing >> list. > > Yes. Documentation is never enough to discourage such decisions. When > faced with the choice of "add this line" or "read and understand the > policy and port your code to the new behavior while possibly maintaining > compatibility with versions of cmake that do not have the policy", which > one will many users pick? For most software out there, users get no choice. They upgrade, get an error with NEW behavior, and apply a workaround or search the internet for a workaround, and they're done. I like that the cmake Policy system allows something better, but I think it is not well-understood because it is unique. I know nothing else like it. For most Policies, the only question is whether a) a good workaround will be chosen, or b) the policy will be set to OLD. For example, on hitting CMP0002 the right approach would be to use unique target names. That policy was easy to overcome because it indicates a pure error in user code which can be fixed without affecting behavior of any cmake version on the code. CMP0020 is a little harder to deal with. Instead of setting it to OLD, users would have to change their code to contain an if() for the CMAKE_VERSION, and it doesn't indicate an error in the user code, but just a new behavior of CMake. But it is low-impact. CMP0024 also falls into this category. CMP0022 is higher impact, and also indicates only a new behavior but not an error in user code. It is quite easy to deal with though as user code can choose some lowest common denominator or use if() on the CMake version. CMP0026 is high impact and hard to deal with for users. Most Policies which are only about new CMake behavior are introduced several releases after new preferred features, such as CMP0043. I think it should be ok to deprecate/remove OLD behavior of Policies falling into the category with CMP0002 without waiting 5 years. For most of the other categories, I think 5 years is too long because the user code can gain a if() on the CMAKE_VERSION. We should consider the impact of the Policy on users, the difficulty of doing the right thing, and the impact on the cmake implementation, not just time. I don't see any reason to wait 5 years for CMP0044 for example. 2 years is also "long" for that one, but it doesn't have a very bad impact on the cmake implementation anyway either, so making it REQUIRED_ALWAYS would be a very small cleanup. Making CMP0003 REQUIRED_ALWAYS would be a big cleanup, and actually is also something I think we should do for CMake 3.4 as it would help my refactoring. It is now 7 years old. Making it REQUIRED_IF_USED would make it easier to implement saner CMP0024 and CMP0026 OLD behavior I think. >> will then result in an error if code attempts to set it to OLD, and >> recommend the user to use an older release or fix the code instead. > > It is not just explicit attempts to set the policy to OLD that will > give an error. It is any time CMake needs to know the policy setting > and it has not been set to NEW either explicitly or by use of > cmake_minimum_required with a sufficiently recent version. Right. Implementations of policies typically determine whether checking the policy is needed before actually checking it. So it will only try to determine the CMP0044 behavior at all if a case insensitive match is found. For most projects, that will not ever have been the case. The same scenario is true for many policies. > In the case of CMP0011, the include() command will be used all over > even within CMake's own modules and trigger query of the policy. > This makes REQUIRED_IF_USED effectively REQUIRED_ALWAYS. This > means any project that does not call cmake_minimum_required > with version 2.6.3 will not be able to build with newer CMake > versions. The only recourse a user will have to get such a project > building will be to edit the source or try setting the policy to > NEW using CMAKE_POLICY_DEFAULT_CMP: Thanks for the clarification. I've added an entry to the release notes that CMP0011 is deprecated, and I can add something similar for CMP0003. > This may be okay for CMP0011, but CMP0024 and CMP0026 were much > more recent (3.0). I think 5 years is a more reasonable cut-off > than 2 years, especially given the time it takes CMake versions > included in older distro releases to fall out of common use. I think 5 years is too long for most policies, at least those which are easy for third party maintainers to deal w
Re: [cmake-developers] A policy for Policies
On 06/06/2015 06:36 AM, Stephen Kelly wrote: > The documentation notes that Policies are not feature toggles: > > http://www.cmake.org/cmake/help/git-master/manual/cmake-policies.7.html > > However, the reality is that Policies *are* feature toggles because they are > so long-lived. Users have no expectation that Policies will 'stop working', > and happily set them to OLD and encourage others to do the same. I see this > on StackOverflow all the time, and on the users mailing list. Yes. Documentation is never enough to discourage such decisions. When faced with the choice of "add this line" or "read and understand the policy and port your code to the new behavior while possibly maintaining compatibility with versions of cmake that do not have the policy", which one will many users pick? > I propose a policy that a Policy may be changed to REQUIRED_IF_USED in a > release two years following the release which introduced it. We designed policies with the idea of switching to REQUIRED_IF_USED eventually. We just never had cause to actually do it before. > will then result in an error if code attempts to set it to OLD, and > recommend the user to use an older release or fix the code instead. It is not just explicit attempts to set the policy to OLD that will give an error. It is any time CMake needs to know the policy setting and it has not been set to NEW either explicitly or by use of cmake_minimum_required with a sufficiently recent version. In the case of CMP0011, the include() command will be used all over even within CMake's own modules and trigger query of the policy. This makes REQUIRED_IF_USED effectively REQUIRED_ALWAYS. This means any project that does not call cmake_minimum_required with version 2.6.3 will not be able to build with newer CMake versions. The only recourse a user will have to get such a project building will be to edit the source or try setting the policy to NEW using CMAKE_POLICY_DEFAULT_CMP: http://www.cmake.org/cmake/help/v3.3/variable/CMAKE_POLICY_DEFAULT_CMP.html (Side note: the error message could be updated to mention this.) This may be okay for CMP0011, but CMP0024 and CMP0026 were much more recent (3.0). I think 5 years is a more reasonable cut-off than 2 years, especially given the time it takes CMake versions included in older distro releases to fall out of common use. -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
On Sun, Jun 7, 2015 at 7:09 PM, Mike Gelfand wrote: > On Sat, June 6, 2015 13:36, Stephen Kelly wrote: >> Code for Policies is also often complex. I often encounter Policies which >> are ancient and which get in the way of code clean up generally. > > Exactly the reason I don't understand why you'd want to add another policy > to affect policies. If you carefully re-read Steve's proposal, you'll notice the distinction between policy and Policy. Policies (upper case P) are represented in code; policies aren't. -- 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 Sat, June 6, 2015 13:36, Stephen Kelly wrote: > Code for Policies is also often complex. I often encounter Policies which > are ancient and which get in the way of code clean up generally. Exactly the reason I don't understand why you'd want to add another policy to affect policies. Won't this complicate things even further? If you want so much to remove some ancient code, just do that instead. After all, you want this new policy to recommend using older cmake release anyway, so what's the difference (except that removing old policy will not _recommend_, but _force_ someone to use older release, which is normal practice in most/all the other programs I'm using)? As a side note, removing the policies will result in CMP (where > 1) to become the first policy, which one may find odd. You might also think of starting to give policies symbolic names instead of sequential numbers. Regards, Mike -- 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
Stephen Kelly wrote: > Setting a policy to REQUIRED_IF_USED in the cmake source means that if > someone tries > > cmake_policy(SET CMP0011 OLD) > > they will get an informative error instead of no warning. Actually, that's not correct, sorry I wrote the explanation too quickly. What I described is actually REQUIRED_ALWAYS. REQUIRED_IF_USED means that if the policy behavior is hit (ie, relying on old CMP0011 behavior), *and* the code has cmake_policy(SET CMP0011 OLD) *then* they get an informative error. If they set the policy (with cmake_policy or with cmake_minimum_required), but already don't rely on OLD behavior, then there is no new error. 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
Re: [cmake-developers] A policy for Policies
Stephen Kelly wrote: > Setting a policy to REQUIRED_IF_USED in the cmake source means that if > someone tries > > cmake_policy(SET CMP0011 OLD) > > they will get an informative error instead of no warning. Actually, that's not correct, sorry I wrote the explanation too quickly. What I described is actually REQUIRED_ALWAYS. REQUIRED_IF_USED means that if the policy behavior is hit (ie, relying on old CMP0011 behavior), *and* the code has cmake_policy(SET CMP0011 OLD) *then* they get an informative error. If they set the policy (with cmake_policy or with cmake_minimum_required), but already don't rely on OLD behavior, then there is no new error. 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
Re: [cmake-developers] A policy for Policies
Alex Merry wrote: > I'm not sure the term REQUIRED_IF_USED is clear enough - I'm certainly > confused by quite what you mean by it. You'll find it if you grep for it in cmake.git. > The main reason for keeping policies around, as I see it, is to allow old > projects to keep building with newer versions of CMake. Actually the reason is to give projects notification and time to port to the NEW behavior, while also making it possible for them to get OLD behavior if they are close to their own release and can't port at that time. Setting a policy to REQUIRED_IF_USED in the cmake source means that if someone tries cmake_policy(SET CMP0011 OLD) they will get an informative error instead of no warning. 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
Re: [cmake-developers] A policy for Policies
On Saturday 06 June 2015 12:36:53 Stephen Kelly wrote: > Hi, > > The documentation notes that Policies are not feature toggles: > > http://www.cmake.org/cmake/help/git-master/manual/cmake-policies.7.html > > However, the reality is that Policies *are* feature toggles because they are > so long-lived. Users have no expectation that Policies will 'stop working', > and happily set them to OLD and encourage others to do the same. I see this > on StackOverflow all the time, and on the users mailing list. > > Code for Policies is also often complex. I often encounter Policies which > are ancient and which get in the way of code clean up generally. > > We also encountered this with CMP0024 and CMP0026 getting in the way in > 2013. The refactoring I'm doing now will encounter those two again. I'd also > prefer to drop CMP0011 rather than deal with its complexity in my current > refactoring. CMP0011 was introduced in 2009. > > > I propose a policy that a Policy may be changed to REQUIRED_IF_USED in a > release two years following the release which introduced it. Such a change > will then result in an error if code attempts to set it to OLD, and > recommend the user to use an older release or fix the code instead. I'm not sure the term REQUIRED_IF_USED is clear enough - I'm certainly confused by quite what you mean by it. The main reason for keeping policies around, as I see it, is to allow old projects to keep building with newer versions of CMake. The main questions are: how far back do we want this compatibility to go? and how selective do we want to allow developers to be about policies? However much we care about backwards compatilibity, I think it's reasonable to have a cut-off point for allowing setting individual policies back (as opposed to having them set back by cmake_minimum_required). That would hopefully encourage developers to clean up code that depends on old behaviour in order to use a useful new feature, which would in turn allow support for old policies to be dropped sooner. Alex -- 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
