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

[Allen Winter]

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?