The CMake situation in frameworks
Alexander Neundorf
neundorf at kde.org
Fri Nov 25 15:47:34 UTC 2011
On Friday 25 November 2011, Stephen Kelly wrote:
> 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:
...
> === 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}
> )
Are you sure ?
The old behaviour, i.e. without LINK_PUBLIC or LINK_PRIVATE resulted in all
libraries being exposed in the link interface, i.e. LINK_PUBLIC would be
default if no keyword is given.
Don't you mean
target_link_libraries(foo
${QT_QTCORE_LIBRARIES}
LINK_PRIVATE
${QT_QTSCRIPT_LIBRARIES}
)
or (which should be the same):
target_link_libraries(foo
LINK_PUBLIC
${QT_QTCORE_LIBRARIES}
LINK_PRIVATE
${QT_QTSCRIPT_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
Doesn't the export header stuff still have to be called explicitely ?
> 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.
Yes, enable-final is gone until somebody finds the time to add it to cmake
directly.
> 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
I think some of this is too specific to be anywhere else than in KDE (whatever
that means).
> == 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?
Yes, probably.
But maybe I could be also convinced to install them all at once e.g. with
kcore if somebody argues hard enough.
> == 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).
Input wanted please ! :-)
Sune, Michael, Thiago, David, etc., everybody who has an opinion on this.
Alex
More information about the Kde-frameworks-devel
mailing list