On Tue, 2009-09-08 at 14:45 +0100, Chen, Congwu wrote:
> >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
> >Patrick...).
> >
> >What exactly are our dependencies? I can think of only one:
> > * the EDS wrapper layer in eds_abi_wrapper.*, enabled via
> > --enable-evolution-compatibility
> 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
have yet).
The second point might be the most problematic one right now, because
there is no strict separation between "external" and "internal" header
files and thus includes might creep into header files where they don't
belong.
> >> 2. client-test was always linked to backend libraries even when the backend
> >is
> >> 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
doesn't ;-)
--
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
