> > Apart from that, how do you think, is it worth trying to still detach > > the library as an external dependency or we're better off sticking > > with current internal one? That's just in order to take a moment and > > make most major changes during this transfer now and not soon after > > the port is stabilized. > > Reason why kopete repository contains copy of libiris is historic. First > is that kopete had own patches to libiris (now all are upstreamed) and > second because libiris upstream project itself does not have stable > API/ABI and does not provide system/shared library. So projects copy its > own copy (either via git submodule or as kopete, full subtree copy). > > So if we need some modification to libiris, we can do that in kopete > tree, no problem... But I would like to have master branch synced. In > working branches, feel free what you need/want.
Thank you so much for detailed clarification, Pali! Yes, I see the reasons for that now. I also checked out vanilla libiris from its repository and it also failed to compile against Qt5 out of the box. So, the one way is to fix it, send changes upstream and then check out the updated version to internal copy. But I also would like to come up with an idea that crossed my mind yesterday after I failed to compile libiris. Would it be bad or undesired to switch to another backend for Jabber connectivity? Please don't consider it as "I'm here, let's now change everything" newcomer's suggestion, just want to discuss all the approaches before using one. I've looked at Qxmpp project (https://github.com/qxmpp-project/qxmpp). At first glance, it's being actively developed, supports a bunch of features, even has Jingle support, contains documentation, is included into distros and already Qt5-friendly, compiled for me with no issues. The key important feature is that we could just use it as external dependency and don't care too much about supporting its tree internally. If you wouldn't be against this idea, I could play with this change in separate branch and return with some results on that. But anyway, I think, after all the remaining parts are ported to not postpone or delay this. _______________________________________________ kopete-devel mailing list kopete-devel@kde.org https://mail.kde.org/mailman/listinfo/kopete-devel