CMake policy settings with CMake 2.8.8

[David Faure]

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?

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.

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