Can you move it to a separate branch? We might merge it for 0.9.1,
part of providing a nicer API for external developers, whereas the EDS
enhancements wouldn't bring any benefits for 0.9.1 and thus are material
Ah, I will make it.
libsyncevolution.so shouldn't depend on EDS. We should move the
remaining dependencies into a shared library which is used by both the
ecal and ebook backend. Currently, EvolutionSyncSource contains some
code which ends up in both backends, which isn't very clean (lazy
What exactly are our dependencies? I can think of only one:
* the EDS wrapper layer in eds_abi_wrapper.*, enabled via
Disable --enable-evolution-compatibility and with --as-needed removed
dependency on eds but after a check there still other dependencies:
libsynthesis, libical, libOrbit, libsqlite3, etc. Looks we better strip such dependencies
to another dynamic library.
> 2. client-test was always linked to backend libraries even when
> built as dynamic library; I am not sure why it worked like this.
You can dlopen() a .so which was already linked.
But in this case, backend developers could not utilize the exiting test framework
out of tree. They still have to link with client-test before runtime (This of course
is a trade off because it will require additional dependency library 'cppunit').
> I have changed so that
> client-test will not link to backend libraries but later dynamically loads the
> library at runtime if enable-shared is on.
Does --enable-unittests still work when doing that?
I'm just wondering, because CPPUnit depends on static registration of
its tests. Loading the backend .so files might happen in time to get
their embedded tests included in the overall CPPUnit suite.
It works, at least 'client-test --help' prints the right information.
a cleanup of the global class initiations would be better.