The CMake situation in frameworks

[Alexander Neundorf]

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