[cmake-developers] A policy for Policies

[Alexander Neundorf]

On Saturday, June 20, 2015 11:29:46 Stephen Kelly wrote:
> Brad King wrote:
> > <snip>
> 
> 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