On Mon, 2009-09-07 at 05:48 +0100, Chen, Congwu wrote:
The change at SyncEvolution side has been pushed to eds branch,
Can you move it to a separate branch? We might merge it for 0.9.1, as
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
points need discussing:
1. To make syncevolution core as a library and remove config.h, I have to add
dependencies for libsyncevolution (eds, glib, etc.); this means a backend developer
who does not touch eds stuff has to install eds library to install libsyncevolution.
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
When compiling without that flag and so that only really required shared
objects are linked (CXX="g++ -Wl,--as-needed" CC="gcc
I end up with a libsynthesis.so which only depends on glib and libsoup,
which I consider good enough for now. If there is a strong need to get
rid of those, we could move the glib/soup (basically introduced by
having the HTTP transport in the lib) into a
2. client-test was always linked to backend libraries even when the
built as dynamic library; I am not sure why it worked like this.
You can dlopen() a .so which was already linked.
I have changed so that
client-test will not link to backend libraries but later dynamically loads the backends
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.
3. We have discussed how to scan possible backend libraries both from
a standard path
and the built directory; Patrick pointed out a possible solution to scan the program
which is passed in as argv in main. This still not worked easily because we are
on the static initialization which is before the main routine is called. We may need to
clean up the static initializations if possible.
This may be difficult because the client-test test suites Client::Sync
and Client::Source depend on having a complete list of registered
backends. Creating these tests would have to be moved into main(), after
loading backends. This should be doable and is worthwhile, because right
now the order of global class initialization is somewhat dubious.
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.