The CMake situation in frameworks

[Stephen Kelly]

Alexander Neundorf wrote:

> 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.

Yes, unless CMAKE_LINK_INTERFACE_LIBRARIES is set to empty.

The fragment I posted would not work.

> Don't you mean
> 
> target_link_libraries(foo
>    ${QT_QTCORE_LIBRARIES}
>    LINK_PRIVATE
>    ${QT_QTSCRIPT_LIBRARIES}
> )

Actually this wouldn't work either.

> 
> or (which should be the same):
> 
> target_link_libraries(foo
>    LINK_PUBLIC
>    ${QT_QTCORE_LIBRARIES}
>    LINK_PRIVATE
>    ${QT_QTSCRIPT_LIBRARIES}
> )

Only this or 

target_link_libraries(foo
   LINK_PRIVATE
   ${QT_QTSCRIPT_LIBRARIES}
   LINK_PUBLIC
   ${QT_QTCORE_LIBRARIES}
)

would work. I don't remember why. It might make sense to allow specifying 
only one of them, so that the below would be equivalent to the above.

target_link_libraries(foo
   ${QT_QTSCRIPT_LIBRARIES}
   LINK_PUBLIC
   ${QT_QTCORE_LIBRARIES}
)

target_link_libraries(foo
   ${QT_QTCORE_LIBRARIES}
   LINK_PRIVATE
   ${QT_QTSCRIPT_LIBRARIES}
)

But I guess the cmake devs would have to agree to it.

> 
>> == 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.

That doesn't necessarily make any sense. kcore is not something that 
everything else depends on. If kauth (which does not depend on kcore) 
provides a macro, does it make sense to put that macro into kcore and force 
dependence on kcore for that?

Thanks,

Steve.