On Saturday 29 September 2012, Stephen Kelly wrote:
> Alexander Neundorf wrote:
> > To make it short, when upgrading CMake, and causing some pain by this,
> > I'd like to have the maximum outcome of it, i.e. the most recent version
> > possible.
> 
> To meet that goal, I would suggest bumping to CMake 2.8.11 instead when
> it's out and for the appropriate KDE 4 release.

This would mean KDE 4.11.
I want to upgrade now for 4.10, because we are already running now into 
problems.

> That version will have everything we'll need and want for KDE Frameworks
> hopefully:
> 
> http://community.kde.org/Frameworks/Epics/CMake_target_usage_requirements#T
> ODO
> 
> If we depend on that version we can make our buildsystem changes (in repos
> which are not kdelibs) orthogonally to our Qt changes. That is, we can port
> KDE 4 to a KDE-Frameworks-quality buildsystem:
> 
>  * We won't need to link to qtmain.lib on Windows. The need for that will
> be encoded in the Qt4::Core imported target.
>  * We won't need to use include_directories() for Qt or kdelibs includes
> anywhere. That information will be encoded in the Qt and kdelibs imported
> targets. For non-Qt non-KDE dependencies we can also look into adding
> IMPORTED targets to their find files too.
>  * We can use qt4_use_modules() extensively or exclusively, simplifying the
> port to KDE frameworks on the build system side to changing that to
> qt5_use_modules with a sed script. We can add a similar macro/function for
> kdelibs stuff with also a simple 4 -> 5 when porting.
> 
> In short - I'd like the KDE 4 CMake dependency to be the same as the
> minimum functional and featureful KDE Frameworks CMake dependency to
> orthogonalize ease the porting effort to modern 'target orientated' CMake
> and away from 'directory orientated' design which we currently have.
> 
> I would like that eventually. Not necessarily as soon as CMake 2.8.11 is
> out.
> 
> For kdelibs 4.10, I think it's a good idea to bump the CMake requirement to
> at least 2.8.7 so that we can port away from automoc4 already etc. That's
> also 'old' enough that recent releases of distros (current Ubuntu at least)
> already have it.

2.8.8 has a lot of work on find_package, config mode, and 
CMakePackageConfigHelpers.cmake, which I consider necessary for creating 
Config.cmake files, and also per-target include dirs.

I really want to have that once we upgrade cmake.

> So from the building kde stuff point of view it should be relatively
> painless, and we free ourselves from the silly restrictions we have by
> having CMake 2.8.6 as the minimum required version, 

We're at 2.6.4 ;-)

> such as not being able to use CMAKE_CURRENT_LIST_DIR etc.

Yes.

Alex
_______________________________________________
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem