Hi, Alex and I had a discussion this evening on some issues around CMake features in upcoming CMake versions that we want to use in frameworks, and some of the remaining issues around CMake and frameworks in general.
To bring people up to speed on some other relevant stuff and what we discussed: == Qt5 will install CMake Config files == Instead of creating a FindQt5.cmake in CMake and maintaining a fork of it in KDE for quick access to new features, Qt5 will install CMake config files and macros. They will be maintained there by myself (via KDAB) and possibly Clinton Stimpson, who maintained FindQt4.cmake in CMake. The Qt5 plan is modularity, so some variables like QT_VERSION_MINOR may not have any meaning anymore, replaced by Qt5Core_VERSION_MINOR and Qt5Declarative_VERSION_MINOR, which may be different. The impact of this will have to be found out later. Even though Qt5 Config files will exist KDE can still not use them by providing a FindQt5.cmake, or it can provide a FindQt5.cmake which internally does use the config file (by doing something like find_package(Qt5 NOMODULE)) and add 'KDE stuff' on top, whatever that might be. For more see: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/2090 I hope to get the patch merged into Qt soon so that remaining issues can be fixed. == New CMake features making parts of KDE macros obsolete == === Automoc === Alex's work on getting automoc features into CMake and bugfixed continues. The automoc features in CMake make the automoc4 tool obsolete, so there will be no need for an automoc5 tool. The preferred way to use the CMake automoc integration will be to not include a moc file at all. That is, don't use: #include "foo.moc" or #include "moc_foo.cpp" CMake will create the moc files anyway for those based on the existence of the Q_OBJECT macro. You don't need to worry about compilation being slow because of compiling each moc file separately either. The moc files which are created without being included will be compiled into one compilation unit per target. There are still reasons to include moc files, such as for example including the result of moc'ing a private header. In that case #include "moc_foo_p.cpp" should be used instead of #include "foo_p.moc" The difference is that from the point of view of qmake, moc_*.cpp files are supposed to be the result of moc'ing .h files, and *.moc files are supposed to be the result of moc'ing .cpp files. Although the automoc4 tool allowed either, The CMake automoc feature will prefer the Qt/QMake convention. === Link interface libraries === In some places in KDE you might see code like: target_link_libraries(foo ${QT_QTCORE_LIBRARIES} ${QT_QTGUI_LIBRARIES} ${QT_QTSCRIPT_LIBRARIES} ${QT_QTSQL_LIBRARIES} ) target_link_libraries(foo LINK_INTERFACE_LIBRARIES ${QT_QTCORE_LIBRARIES} ${QT_QTGUI_LIBRARIES} ) The LINK_INTERFACE_LIBRARIES version is special in CMake, and together the two calls communicate that anything that links to foo must also link to QtCore and QtGui, and foo itself links to QtScript and QtSql, but things linking to foo don't need to link to QtScript or QtSql as a result of linking to foo (because no symbols from QtScript appear in the ABI of foo). In CMake 2.8.7, the more compact version can be used and will be preferred: target_link_libraries(foo ${QT_QTSCRIPT_LIBRARIES} LINK_PUBLIC ${QT_QTCORE_LIBRARIES} ) == Library, executable, plugin and test wrapper macros == The kde4_add_library macro wraps the CMake add_library function with the features of automoc, enable_final, defining symbols for export headers, and setting the LINK_INTERFACE_LIBRARIES to empty. CMake 2.8.7 will provide built in features to provide all of those features obsolete with the exception of enable_final, which may not work properly anymore (when using CMake built in automoc support), and was not considered very important during the last few kde-buildsystem meetings. kde4_add_executable also does automoc, adding WIN32 or MACOSX_BUNDLE flags to the add_executable, enable_final, tests handling, linking to QtMain and adding uac manifest files on windows. It will probably not be possible to add upstream (or otherwise external) equivalents of all of the features of this macro. The automoc is already upstream and enable_final will go from the macro and only be able to exist as a CMake builtin if anywhere. The linking to QtMain can I suspect be done in the Qt CMake config files. I suspect that the WIN32 and MACOSX_BUNDLE flags can be added there too. I don't know about the manifest and tests stuff. Perhaps we can put that stuff into ECM. There are several other kde wrappers such as kde4_add_unit_test kde4_add_kdeinit_executable etc. I have not evaluated what parts of any other macros are obsolete, or can be upstreamed. If anyone else wants to look into that with goals of modularity in mind, feel free == Module specific macros == There are other macros such as kde4_create_handbook(), kde4_install_icons(), kde4_create_manpage() (and others) which KDE needs and which need to be installed from somewhere. One option is to install kde4_install_icons from the same place that KIconEngine is installed from (KGuiSomething?), kde4_create_manpage from the place where the doctools are, etc. That is, keep the macros together with the modules they relate to. I support that idea, and I *think* Alex does too. What do others think? == Multiarch == The way libraries get installed and found is changing. Instead of just lib/ or lib64/ they might be in lib/i386-linux-gnu/ or lib/arm-linux-gnueabi/. We need to evaluate how that impacts KDE and KDE developers (who just want to use ${KDE_LIB_INSTALL_DIR} or so and not care about it). == Communicating build parameters between modules == Some people don't want to set custom parameters for certain install directories and have those locations picked up by other depending modules. Eg, if a custom value is set for LIB_INSTALL_DIR in kdelibs and KDEPIM is built against that version of kdelibs, KDEPIM should use the same value for LIB_INSTALL_DIR. This is provided by the _set_fancy macro currently. There may be better ways to do this, such as specifying the values in the config files for frameworks, or installing a CMakeCache.txt. Needs more investigation. Thanks, Steve. _______________________________________________ Kde-buildsystem mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-buildsystem
