CMake policy settings with CMake 2.8.8

[Stephen Kelly]

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.

Thanks,

Steve