Compile-time checks aren't exhaustive.
Building EDS backend together with sqlite finishes OK, but produces unusable installation. syncevolution's complains are in Summary.
The least can be made for this is having a table (at Wiki or Doc) showing conflicting backends.
(In reply to comment #0)
> Compile-time checks aren't exhaustive.
This cannot be checked at compile time. SyncEvolution was designed so that backends can be installed independently. Therefore it is possible to compile "conflicting" backends and then let the user (or image builder, in the case of MeeGo) choose which one he wants to use by installing just that one.
> Building EDS backend together with sqlite finishes OK, but produces unusable
> installation. syncevolution's complains are in Summary.
The installation is usable. Just follow the hint and configure your "backend" values explicitly:
syncevolution --configure backend=evolution contacts @default addressbook
> The least can be made for this is having a table (at Wiki or Doc) showing
> conflicting backends.
I think this is overkill. Realistically speaking, only SQLite conflicts with EDS, and the SQLite backend probably should not recognize the "addressbook" alias in the first place. Furthermore, the SQLite backend is just a demo backend, no normal user will ever run into this.
I'm curious - why did you enable it?
Yes, looks everything is in place.
(In reply to comment #1)
> I'm curious - why did you enable it?
for packaging. I didn't completely understand it's a demo plugin, useless for real use.