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

[Michael Jansen]

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.

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?

Mike