Fix build with telepathy-qt 0.9.8
ClosedPublic

Authored by arojas on Nov 12 2019, 8:43 AM.

Details

Summary

Qt5::Xml is no longer in the exported linked libraries for the telepathy-qt target, so it needs to be added explicitely

Test Plan

Builds with telepathy-qt 0.9.8

Diff Detail

Repository
R145 KDE Telepathy Common Internals
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.
arojas requested review of this revision.Nov 12 2019, 8:43 AM
arojas created this revision.

Wait a sec... where we link against "telepathy-qt target"? I see only ${TELEPATHY_QT5_LIBRARIES} and IMO it was just wrong to treat LIBRARIES variable as targets.

Starting from 0.9.8 we have TelepathyQt5::Core target that exports linked libraries (thought as Qt5::Xml is not a part of the public API, it is not added to the link list to prevent "overlinking".
I admit I could mess it up, but the new targets worked well for me: https://github.com/TelepathyIM/telepathy-morse/commit/997100a07e6464d85c2cbd3ce56049eebae310c6

That would require bumping the telepathy-qt dependency, no? I think we're past the dependency freeze for 19.12

akulichalexandr added a comment.EditedNov 12 2019, 9:58 AM

Yes, probably it would be better to land this patch for now.
Long story short — I rewrote targets for TelepathyQt, because we exported them under the same name as the library files. CMake doesn't allow to export a target under multiple names, nor add_library(telepathy-qt5 ALIAS TelepathyQt5::Core). It is sad that we relied on ${TELEPATHY_QT5_LIBRARIES} that had not the recommended full path (like /usr/lib/libtelepathy-qt5.so.0.9.7) or the lookup path and linking flag (such as -L/usr/lib -ltelepathy-qt5), but just the "telepathy-qt5" name that happened to match the odd target name.

I considered addition of "add_library(telepathy-qt5 UNKNOWN IMPORTED)" with manual iteration and coping of the target properties from TelepathyQt5::Core to telepathy-qt5 but it seemed like too big workaround for the use that I consider as invalid.

I would suggest to make it clear that there is new version that works:

if(TELEPATHY_QT5_VERSION VERSION_LESS "0.9.8")
    target_link_libraries (KTpCommonInternals
        PUBLIC
            Qt5::DBus
            Qt5::Xml
            # ${TELEPATHY_QT5_LIB_DIR}/lib${TELEPATHY_QT5_LIBRARIES}.so.0.${TELEPATHY_QT5_VERSION}
            ${TELEPATHY_QT5_LIBRARIES}
    )
else()
    target_link_libraries (KTpCommonInternals
        PUBLIC
            TelepathyQt5::Core
    )
endif()

What about pushing this as-is for 19.12 and bumping the dependency and using the new target on master (19.12 is already branched)

akulichalexandr added a comment.EditedNov 12 2019, 11:40 AM

What about pushing this as-is for 19.12 and bumping the dependency and using the new target on master (19.12 is already branched)

Meh :-(. I realized that a distribution can't update to telepathy-qt-0.9.8 because it'll break KTp. That said, I actually need your patch to land in 19.12 at the very least. Or maybe I have to release a hotfix for TpQt, but there is no nice solution to copy an imported target. I actually checked if KTp use the target, but didn't found that weird-named "telepathy-qt5" target in the link list and thought that we use the legacy variable-based approach (TELEPATHY_QT5_LIBRARIES, etc).

akulichalexandr added a comment.EditedNov 12 2019, 11:57 AM

Hey-ho! One-line fix 😄 :facepalm: :

if(NOT TELEPATHY_QT5_VERSION VERSION_LESS "0.9.8") # Use NOT VERSION_LESS because VERSION_GREATER_EQUAL is not available until CMake-3.7
    set(TELEPATHY_QT5_LIBRARIES TelepathyQt5::Core)
endif()
akulichalexandr accepted this revision as: akulichalexandr.EditedNov 14 2019, 4:22 PM

I thought more about this and now I agree with this patch. I focused on the thought "how to make it work as it worked before" instead of thinking about "what's right or wrong with the proposed changes".

We should explicitly list all libraries used by the target. It is wrong to say that "we rely on library A and B, and the B needs A too, so just list B here".

TelepathyQt uses Qt5::Xml for Tp::Account implementation, but it doesn't reference Xml in the exported API.
KDE Telepathy directly uses Xml (KTp/logs-importer-private.h includes QDomDocument) and thus it should not rely on Xml module in the TpQt target properties.

Properly speaking, we should list everything, including Qt5::Core.


With or without Core component, consider this as
Reviewed-by: @akulichalexandr

This revision is now accepted and ready to land.Nov 14 2019, 4:22 PM
This revision was automatically updated to reflect the committed changes.