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