On Wednesday 29 June 2011, Michael Jansen wrote: > On Wednesday 29 June 2011 20:17:53 Alexander Neundorf wrote: > > Hi, > > > > I guess I should explain a bit more what's behind the idea of > > extra-cmake- modules. > > > > There were two big topics at the Platform sprint in Randa: Qt5, and how > > to make KDE libraries better available for Qt-only software. > > > > Qt5 will break binary compatibility, and will try to stay 100% source > > compatible (so it will be mostly source compatible). > > > > We (KDE) can use this chance to also break binary compatibility. > > The plan is to restructure the KDE libraries so that the libraries become > > more focussed, with less dependencies for each individual library. > > This will be binary incompatible, and we will also try to stay as source > > compatible as possible (but it won't be 100%). > > > > > > For the buildsystem we can use this chance to also break source > > compatibility once. I think we should use this opportunity, break cmake > > source compatibility and clean up our cmake stuff. > > > > This includes upstreaming some things into cmake. CMake 2.8.5 will be > > released really soon now, and 2.8.6 will be out in 3 to 4 months. > > It would be nice if we could get into 2.8.6 what we want to get > > upstreamed into cmake. This means we have to do this in the next three > > months. > > > > Once we succeeded with this, and once cmake 2.8.6 has been released, we > > can start requiring cmake 2.8.6 (i.e. in October or so). > > > > > > So, what do we do with the cmake stuff we have in kdelibs ? > > > > -some things will not be necessary anymore (e.g. > > MacroOptionalFindPackage) -with Qt5 we will not use FindQt4.cmake > > anymore > > -some stuff should be merged into cmake > > -some things may simply not make it into extra-cmake-modules (e.g. > > MacroAddLinkFlags, MacroEnsureVersion, others) > > -all macros which will end up in extra-cmake-modules will not have the > > "macro_" prefix anymore, but will get the prefix "ecm_" > > > > > > So, this means e.g. that kdelibs/cmake/modules/ must not be synced with > > extra- cmake-modules, since they will contain different stuff. > > > > > > Once we require cmake 2.8.6, we can do an initial release of e-c-m. Then > > stuff which is 100% source compatible with what we have right now in > > kdelibs can be removed from kdelibs. > > > > Then, when the switch to Qt5 comes, there will be a cmake source > > incompatible break, since from then on the modules from e-c-m have to be > > used. > > > > As plan I would > > - go through the list from Raphael again and insert some more details > > - then slowly add one file after the other, no mass commits or simply > > adding new stuff > > Then we should reset the module. It is populated currently.
Yes. Is there a special "reset" or simply git rm all files ? > That means in the transition phase we(you) move stuff from kdelibs up to > ecm. If it is behaviour and source compatible we remove it from kdelibs. > If it is not it can happen that we fork it and keep both the kdelibs and > ecm version with the intention on wiping out everything (or nearly > everything) from kdelibs when we start to require qt5 (whichever kde > whatever version that is). > > from kde sc 4.8 (if we rely on cmake 2.8.6 then) it is a requirement to > compile kde. > > right? Yes. Alex _______________________________________________ Kde-buildsystem mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-buildsystem
