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. _______________________________________________ SyncEvolution mailing list [email protected] https://lists.syncevolution.org/mailman/listinfo/syncevolution
