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 _______________________________________________ Kde-buildsystem mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-buildsystem
