>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
>for 1.0.
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
>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.

>> 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'). 

>>  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.
It works, at least 'client-test --help' prints the right information. However 
maybe
a cleanup of the global class initiations would be better.  

_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution

Reply via email to