On Wednesday 29 June 2011 3:10:56 PM Alexander Neundorf wrote: > 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 ? > Aww .. gee... I actually spent quite some time figuring out how to copy these over without losing history. How about we move all the kdelibs stuff I copied over into a "kdelibs-cmake" subdir, at least for reference?
_______________________________________________ Kde-buildsystem mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-buildsystem
