On Mi, 2012-01-25 at 10:22 +0100, Murray Cumming wrote: > On Fri, 2012-01-13 at 17:09 +0100, Patrick Ohly wrote: > > On Do, 2012-01-05 at 16:55 +0100, Murray Cumming wrote: > > > As far as I can tell, this patch should be applied. Or is there some > > > reason to compile the code in dbus/ if --enable-dbus-service is not > > > used? > > > > For a while I compiled sync-ui and core SyncEvolution separately in > > MeeGo. In that case, D-Bus service is disabled and dbus/glib needs to be > > compiled. > > > > In other words, decoupling dbus compilation from D-Bus service > > compilation makes sense. But probably some of the current checks for > > what needs to be compiled inside dbus are not quite correct, because > > there is no real "enable/disable D-Bus" switch in configure. > > I don't really understand. What is the dbus/ code used for if no > dbus-service is built or used?
It provides the D-Bus client libraries that could be used in combination with a syncevo-dbus-service that was compiled separately. It's a bit unusual to compile the same code twice; I had to do it in the past because of the way how MeeGo was configured in OBS at the time (GTK not part of the core OS). > We also noticed a relinking problem during make install, which is fixed > by this commit: > https://meego.gitorious.org/~krnowak/meego-middleware/krnowaks-syncevolution/commit/d4282ec7e920136c6ad92f82f908e6698178b014 > > It's already in the concurrent-sync-sessions branch, though this > URL will probably stop working after a future rebase: > http://meego.gitorious.org/meego-middleware/syncevolution/commit/cac0725b2f30dcb3f739b3989b3a67ce7a695273 > > I suggest that you put this in master. Thanks, merged. I think I saw that once, but then couldn't reproduce, probably because "make -j" happened to not trigger it all the time. > This is necessary because you install some libraries in > <prefix>/lib/syncevolution/ but other libraries in <prefix>/lib/ and > autotools is apparently not able to deal with that when relinking before > installing. Is there a good reason for installing some libraries in a > sub-directory. Simplifying that might let use remove some hacks from the > build files. I've wondered about that myself recently. In the end I settled on adding some hacks instead of moving the libs, mostly just because it was the smaller change. The original motivation was to avoid file clashes with other packages also providing libgdbus.so. That alone wasn't enough, because later symbols in that lib clashed with similarly named symbols in glib, so the lib and all symbols were renamed. I don't think there still is any reason to install normal libraries in usr/lib/libsyncevolution. It should be used only for modules which get dlopened(). Want to provide a patch? -- 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] http://lists.syncevolution.org/listinfo/syncevolution
