CMake policy settings with CMake 2.8.8

[Alexander Neundorf]

On Tuesday 30 October 2012, David Faure wrote:
> On Monday 29 October 2012 19:06:53 Alexander Neundorf wrote:
> > 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.
> 
> So changing the cmake_minimum_required line in FindKDE4Internal.cmake
> creates source incompatibilities, unless you explicitely set the relevant
> policies to OLD?

Yes, but we do that:

cmake_minimum_required(VERSION 2.8.8 FATAL_ERROR)
...
cmake_policy(VERSION 2.4.5)

This sets all newer policies to WARN, i.e. use the old behaviour, but warn 
about it.

The following lines which set some policies to OLD, silence those warnings.

> OK, then we could still do that in FindKDE4Internal (i.e. globally), and
> still set some of them back to NEW inside individual modules if we feel it
> leads to better cmake lists.

Yes.

Alex