Rough plan for extra-cmake-modules Was: extra-cmake-modules populated

[Alexander Neundorf]

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