2:49 p.m.
Well, I'm trying to build a GUI for Sailfish, which is Qt5-based. But
Qt5 is not really supported by SyncEvolution. Although I've added some
workarounds in the backends, it would probably be nice if Qt5 was more
directly supported by the build system.
Most importantly, perhaps, is that I'm not sure how to cleanly build the
Qt D-Bus bindings. For example, syncevolution-qt-dbus.pc should contain
"Requires: Qt5DBus" instead of "QtDBus". What's the least hackish
way to
achieve that?
The build patches I've had to make so far include, with comments:
--- a/src/backends/kcalextended/configure-sub.in
+++ b/src/backends/kcalextended/configure-sub.in
@@ -13,5 +13,6 @@ SE_ARG_ENABLE_BACKEND(kcalextended,
if test "$enable_kcalextended" = "yes"; then
AC_DEFINE(ENABLE_KCALEXTENDED, 1, [KCalExtended available])
- PKG_CHECK_MODULES(KCALEXTENDED, libmkcal libkcalcoren)
+ PKG_CHECK_MODULES(KCALEXTENDED, libmkcal-qt5 libkcalcoren-qt5 Qt5Core,,
+ [PKG_CHECK_MODULES(KCALEXTENDED, libmkcal libkcalcoren)])
fi
(Fairly straightforward, but the Qt5Core part would probably not be
needed if the build system supported Qt5)
--- a/src/backends/qtcontacts/configure-sub.in
+++ b/src/backends/qtcontacts/configure-sub.in
@@ -13,11 +13,11 @@ SE_ARG_ENABLE_BACKEND(qtcontacts,
if test "$enable_qtcontacts" = "yes"; then
AC_DEFINE(ENABLE_QTCONTACTS, 1, [QtContacts available])
- # AC_WITH_QT() will be called in configure-post if need_qt_modules is not
empty,
- # setting QT_* flags.
- need_qt_modules="$need_qt_modules +gui" # GUI needed for QVersit
- qt_config="$qt_config +mobility"
- qt_misc="$qt_misc
-MOBILITY += contacts versit"
+ PKG_CHECK_MODULES(QT_CONTACTS, Qt5Contacts Qt5Versit,,[
+ # AC_WITH_QT() will be called in configure-post if need_qt_modules is not
empty,
+ # setting QT_* flags.
+ need_qt_modules="$need_qt_modules +gui" # GUI needed for QVersit
+ qt_config="$qt_config +mobility"
+ qt_misc="$qt_misc
+MOBILITY += contacts versit"])
fi
-AC_SUBST(QT_CONTACTS_LIBS)
--- a/src/backends/qtcontacts/qtcontacts.am
+++ b/src/backends/qtcontacts/qtcontacts.am
@@ -19,4 +19,4 @@ src_backends_qtcontacts_syncqtcontacts_la_DEPENDENCIES =
src/syncevo/libsyncevol
# Allow Qt to set some compile flags, but not the ones normally set via configure.
# In particular -W is not compatible with the SyncEvolution header files (we have
# unused parameters in some inline functions).
-src_backends_qtcontacts_syncqtcontacts_la_CXXFLAGS = $(SYNCEVOLUTION_CXXFLAGS)
$(filter-out -O2 -g -W -Wall, $(QT_CXXFLAGS)) $(SYNCEVO_WFLAGS)
+src_backends_qtcontacts_syncqtcontacts_la_CXXFLAGS = $(SYNCEVOLUTION_CXXFLAGS)
$(QT_CONTACTS_CFLAGS) $(filter-out -O2 -g -W -Wall, $(QT_CXXFLAGS)) $(SYNCEVO_WFLAGS)
(The AC_SUBST is removed because presumably the new PKG_CHECK_MODULES
already does that)
And some bugfixes for the Qt bindings:
--- a/src/dbus/qt/qt.am
+++ b/src/dbus/qt/qt.am
@@ -69,7 +69,7 @@ src/dbus/qt/syncevo-%-full.cpp src/dbus/qt/syncevo-%-full.h:
src/dbus/qt/stamp-%
# work around #ifndef SYNCEVO-SERVER-FULL_H_1305547804 bug
src/dbus/qt/stamp-%: $(top_srcdir)/src/dbus/interfaces/syncevo-%-full.xml
- $(AM_V_at)@QDBUSXML_TO_CPP@ -p src/dbus/qt/syncevo-$*-full -i
src/dbus/qt/dbustypes.h $< \
+ $(AM_V_at)@QDBUSXML_TO_CPP@ -p src/dbus/qt/syncevo-$*-full -i dbustypes.h $<
\
&& perl -pi -e 's/SYNCEVO-(\w*)-FULL_H/SYNCEVO_$$1_FULL_H/'
src/dbus/qt/syncevo-$*-full.* \
&& echo 'timestamp' >$@
(The -i is for generating the #include, and using the source path
doesn't work for installed files)
--- a/src/dbus/interfaces/syncevo-connection-full.xml
+++ b/src/dbus/interfaces/syncevo-connection-full.xml
@@ -102,8 +102,8 @@
"URL" - the URL for an HTTP POST.
</doc:summary>
</doc:doc>
- <annotation name="com.trolltech.QtDBus.QtTypeName.In2"
value="QStringMap"/>
</arg>
+ <annotation name="com.trolltech.QtDBus.QtTypeName.In2"
value="QStringMap"/>
<arg type="b" name="final">
<doc:doc>
--- a/src/dbus/interfaces/syncevo-server-full.xml
+++ b/src/dbus/interfaces/syncevo-server-full.xml
@@ -129,8 +129,8 @@
"system" - some plain text information about system libraries,
"backends" - available backend libraries
</doc:summary></doc:doc>
- <annotation name="com.trolltech.QtDBus.QtTypeName.Out0"
value="QStringMap"/>
</arg>
+ <annotation name="com.trolltech.QtDBus.QtTypeName.Out0"
value="QStringMap"/>
</method>
<method name="Attach">
@@ -585,8 +585,8 @@
version of the transport entity.
</doc:summary>
</doc:doc>
- <annotation name="com.trolltech.QtDBus.QtTypeName.In0"
value="QStringMap"/>
</arg>
+ <annotation name="com.trolltech.QtDBus.QtTypeName.In0"
value="QStringMap"/>
<arg type="b" name="must_authenticate"
direction="in">
<doc:doc>
<doc:summary>
--- a/src/dbus/interfaces/syncevo-session-full.xml
+++ b/src/dbus/interfaces/syncevo-session-full.xml
@@ -345,8 +345,8 @@
</arg>
<arg type="a{ss}" name="vars" direction="in">
<doc:doc><doc:summary>Environment variables in
clients</doc:summary></doc:doc>
- <annotation name="com.trolltech.QtDBus.QtTypeName.In1"
value="QStringMap"/>
</arg>
+ <annotation name="com.trolltech.QtDBus.QtTypeName.In1"
value="QStringMap"/>
</method>
<signal name="StatusChanged">
(The annotations can't be inside the args, the xml-to-c++ tool doesn't
recognize them there.)
3:56 p.m.
On Mon, 2014-01-13 at 14:49 +0100, Ove Kåven wrote:
Well, I'm trying to build a GUI for Sailfish, which is Qt5-based.
But
Qt5 is not really supported by SyncEvolution. Although I've added some
workarounds in the backends, it would probably be nice if Qt5 was more
directly supported by the build system.
I don't know what the best way to handle Qt5 with autoconf/automake is
these days. I'm open for suggestions.
The existing Qt[5] D-Bus bindings are not used by anything at the
moment. Feel free to make whatever changes you need.
> --- a/src/backends/kcalextended/configure-sub.in
> +++ b/src/backends/kcalextended/configure-sub.in
> @@ -13,5 +13,6 @@ SE_ARG_ENABLE_BACKEND(kcalextended,
>
> if test "$enable_kcalextended" = "yes"; then
> AC_DEFINE(ENABLE_KCALEXTENDED, 1, [KCalExtended available])
> - PKG_CHECK_MODULES(KCALEXTENDED, libmkcal libkcalcoren)
> + PKG_CHECK_MODULES(KCALEXTENDED, libmkcal-qt5 libkcalcoren-qt5 Qt5Core,,
> + [PKG_CHECK_MODULES(KCALEXTENDED, libmkcal libkcalcoren)])
> fi
(Fairly straightforward, but the Qt5Core part would probably not be
needed if the build system supported Qt5)
Would you prefer something like a --enable-qt5 switch? Something
explicit instead of this implicit "pick the most recent version that we
can find"? It might be a bit clearer, but other than that, such an
automatic fallback isn't that bad, is it?
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
12:46 a.m.
Den 13. jan. 2014 15:56, skrev Patrick Ohly:
Would you prefer something like a --enable-qt5 switch? Something
explicit instead of this implicit "pick the most recent version that we
can find"?
Well, it seems a bit ugly too.
I've tried to look into things a bit more, and perhaps the existing
autotroll.m4 thing (which seems to call qmake) might still do the job
for QtContacts, at least. The main problem in that regard is that
SyncEvolution doesn't have any way to check whether any given Qt module
is available and fall back to another module if not.
With Qt5, there's no longer a "QtMobility", but a "QtPim" or
something.
So, to import QtContacts with autotroll, you should now just add
"+contacts +versit" to the main "need_qt_modules" thing, I think,
instead of having special imports for mobility. There's just no way to
know that beforehand with the current approach.
But given that knowledge of the Qt version is needed for
--enable-qt-dbus (where the syncevolution-qt-dbus.pc file needs to know
that it's now Qt5DBus, not QtDBus), and for --enable-kcalextended (where
the kcalextended modules aren't known to qmake at all, only to
pkg-config), perhaps it really is best to migrate to a completely
pkg-config-based approach, instead of using autotroll.
But, of course, a pkg-config-based approach would work for Qt4 too,
since Qt4 also has full pkg-config support. Perhaps it's best to just
use pkg-config all the way, and completely remove all uses of autotroll.m4?
4:57 p.m.
On Thu, 2014-01-23 at 00:46 +0100, Ove Kåven wrote:
But, of course, a pkg-config-based approach would work for Qt4 too,
since Qt4 also has full pkg-config support. Perhaps it's best to just
use pkg-config all the way, and completely remove all uses of autotroll.m4?
I would be fine with that. Feel free to implement what works for you. I
don't think anyone else currently uses the QtContacts backend or the Qt
D-Bus binding library.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
3035
days inactive
3051
days old
syncevolution@synevolution.org
3 comments
2 participants
participants (2)
-
Ove Kåven -
Patrick Ohly