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