CMake policy settings with CMake 2.8.8

[David Faure]

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 :-)

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5