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

[Alexander Neundorf]

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


Alex