On Tue, 2009-09-08 at 14:45 +0100, Chen, Congwu wrote:
>libsyncevolution.so shouldn't depend on EDS. We should move
>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.
Are you sure these libs are needed by libsyncevolution.so itself
("objdump --all libsyncevolution.so | grep NEED" vs. "ldd
syncevolution.so", which is transitive)?
If SyncEvolution is compiled as shared library *and* the header files
which are included by our header files that are needed by a backend
developer do not include header files of these other libraries, then
their development packages are not needed by a backend developer.
If SyncEvolution is a shared library, then the libraries it needs to not
have to be added to the link line of backends. libtool might not handle
that well, though, which is dealt with by not installing a
libsyncevolution.la and using syncevolution.pc instead (which we don't
The second point might be the most problematic one right now, because
there is no strict separation between "external" and "internal"
files and thus includes might creep into header files where they don't
>> 2. client-test was always linked to backend libraries even
when the backend
>> 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').
Yes, out-of-tree extensions to the test system might require more work.
At this point, you probably know better than I what works and what
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.