CMake policy settings with CMake 2.8.8

[Alexander Neundorf]

On Monday 29 October 2012, Stephen Kelly wrote:
> David Faure wrote:
> > On Saturday 27 October 2012 16:14:47 Alexander Neundorf wrote:
> >> Hi,
> >> 
> >> I was just looking through the cmake policies which were added after
> >> 2.6.4, and what to do with them.
> >> 
> >> These are the following:
> >> CMP0010: Bad variable reference syntax is an error (already in 2.6.3)
> >> CMP0012: if() recognizes numbers and boolean constants
> >> CMP0013: Duplicate binary directories are not allowed
> >> CMP0014: Input directories must have CMakeLists.txt.
> >> CMP0015: link_directories() treats paths relative to the source dir.
> >> CMP0016: target_link_libraries() reports error if only argument is not a
> >> target.
> >> CMP0017: Prefer files from the CMake module directory when including
> >> from there.
> >> 
> >> Actually, all of them sound reasonable, but in kdelibs we have to
> >> guarantee source compatiblity, so we cannot simply enable (set them to
> >> NEW) them, because this might break the build of existing projects.
> >> 
> >> CMP0017 is already set to NEW, mostly because of us (and our version of
> >> FindPackageHandleStandardArgs.cmake in kdelibs/cmake/modules/).
> >> 
> >> 
> >> Beside this one, I'm thinking about setting the following to NEW:
> >> 
> >> CMP0010: this makes cmake abort if it finds a cmake syntax error. This
> >> is a good thing. I don't think there can be projects out there which
> >> have this problem and which nevertheless build.
> >> 
> >> 
> >> CMP0013: According to the docs, in 2.6.4 duplicate binary directories
> >> were an error, but since 2.8.0 it's a warning by default. I think this
> >> should be an error.
> >> 
> >> 
> >> All others I think we should keep at OLD.
> >> 
> >> While CMP0016 is good candidate, this problem may exist in some
> >> projects, but it doesn't actually cause any errors. So probably better
> >> keep it silent instead of breaking the build.
> >> 
> >> CMP0012 is dangerous, since it could break builds, and if a developer
> >> then makes his application build again, it may not build with an older
> >> kdelibs anymore.
> >> 
> >> 
> >> Comments ?
> > 
> > That's about "global defaults", set in kdelibs/cmake/modules and used by
> > all software that uses these modules, right?
> > 
> > Then I agree -- but we could *also* set additional restrictions in
> > selected projects, where we can simply check that they compile with all
> > these restrictions enabled.
> > 
> > Is there an easy way to say "set all policies known by 2.8.8 to NEW", for
> > instance in KDE Frameworks 5? Assuming NEW is always better than OLD, but
> > if it wasn't, then surely the change wouldn't have been made :-)
> 
> Yep, that's what
> 
>  cmake_minimum_required(VERSION 2.8.8)
> 
> does.
> 
> I think we should reset all our policies to the CMake defaults too for
> Frameworks, but I think Alex might be talking about KDE 4 here.

Yes, indeed I didn't mention this explicitely.
This is about kdelibs 4.10.

Alex