tp-qt-service is a library that started out as static, because we weren't sure if we wanted to break the API/ABI while we were experimenting with its first code. Later on, due to distribution demand, it became a shared library, with soname management. However, the initial plan was to keep this inside the same library as the client-side API, which is why all the export macros are TP_QT_EXPORT. This macro is wrong to be used in two different shared libraries, as that wouldn't link on certain systems (basically, Windows). The solution is to add a new export macro, though question remains if we want to keep this as a separate library instead of merging it into tp-qt. I think I would prefer merging it.
I agree that current "position" of the service library is wrong, but in fact, the service library API is not stable yet and experience shows that there would be more API/ABI incompatible changes. If the libraries would be merged, we probably would force clients to rebuild on every service API change. I even thought about the opposite solution: split the service library into its own project and repository with a different release cycle. Detached library can easily depend on, say, TpQt-0.9.5, so we would be able to distribute a CM with statically or dynamically linked TpQt-service across all distribution, regardless of their TpQt version. This was been an issue, because TpQt-0.9.5 works pretty well, while "services" was not been really useful until at least 0.9.6. Release 0.9.7 is useful enough to let users just live with it and wait for the next release instead of compiling code from git. We have three logical components of TpQt: 1) client - local client dbus interface - AbstractClient - ClientRegistrar - ... - client side bindings to remote dbus interfaces with generated code - ConnectionManager - Protocol - Connection - Channel - ... 2) service - service side bindings to local dbus interfaces with generated code - BaseConnectionManager - BaseProtocol - BaseConnection - BaseChannel - ... 3) shared (common). - Generated types and constants - TelepathyQt/_gen/types.h - TelepathyQt/_gen/constants.h - Hand-written types and constants - TelepathyQt/types.h - TelepathyQt/constants.h - AvatarSpec - LocationInfo - Presence - ... - Utilities - DBusProxy - ReadyObject - Callback classes - TelepathyQt/utils.h - ... I also would place BaseDebug into shared, because in fact it can be used by any Telepathy application. The only purpose of having all three components together is testing. It's convenient to test BaseChannelFileTransferType via FileTransferChannel and vice versa. I don't think we would end up with splitting the project, because it would require even more efforts. Let's go with unified library since TpQt-0.10.0, but before that make 0.9.8 release with Qt4 support and two libraries. For the 0.10.0 release we also can rework the build process. Thank you for the bugreport — I just realised that probably this is why I could not link the service library in windows: TP_QT_EXPORT macro in the main library should expand into import declaration on include from the service library.
Hmm, splitting the service library would help with the API/ABI management, but I personally think it's a bad idea because of testing, as you say. I would personally like it if we gradually remove the tp-glib parts from our unit tests and replace them with equivalent tp-qt code. The only reason that we have the tp-glib dependency is because we need the service-side bindings there. I am fine with keeping the situation as it is now until the API of the service-side bindings is considered stable. Afterwards, we can merge it into the main library. I mainly filed the bug report as a reminder. Regarding the other stuff in tp-qt, there was once an idea (which still sounds tempting today) to move the generated stuff of tp-glib and tp-qt both into the tp-spec repository. This would avoid copying the spec into the tp-glib and tp-qt repositories and would also remove all the build cruft that we now have around.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/telepathy/telepathy-qt/issues/51.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.