http://bugzilla.moblin.org/show_bug.cgi?id=6181
pohly <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #4 from pohly <[email protected]> 2009-09-17 04:42:37 --- (In reply to comment #0) > SyncEvolution core should be packaged as a library, hence third party > developers can provide their add-ons upon this. Which add-ons is important, because it determines the public API and helps us decide question like "do users of the library need to know whether we support and/or use glib". > One example is the database backend. Third party developers can develop their > own backend libraries with libsyncevolution and make it usable by simply > dropping its library into a standard path. IMHO this is the only use case that we need to support, at least at the moment. UI developers should either use the D-Bus API (generic SyncEvolution in Moblin and normal Linux desktops) or compile their own SyncEvolution binary (Mac OS X, phone, Palm?). In the later case, they have full control over the compilation and can enable and disable features as needed. (In reply to comment #1) > >> >We can keep the config.h usage and the ifdefs in our header files. We > >> >just have to be careful that we include config.h like this > >> > #ifdef HAVE_CONFIG_H > >> > # include <config.h> > >> > #endif > >> >and that none of the ifdefs affect structs that are part of the API. > >> > > >> >For example, in EvolutionSmartPtr.h, "#ifdef HAVE_GLIB" only adds some > >> >declarations. The header file can be used just fine by a client program > >> >without those if it doesn't provide a config.h or doesn't use GLib > >> >itself. > >> Yes, but I will first try to split some non-api stuff to another > >> library (EvolutionSyncClient, Transport Implemenation) > > Maybe not get your idea, but: > Is it a potential problem, if we built libsyncevolution with no glib; while > the > library user defines HAVA_GLIB and indeed have glib library. > > So the library developers built the library with a set of assumptions, and the > library user can use the library with another set of assumptions, is it > workable? The library user must not make any assumptions beyond what is documented in the API. If glib usage of the core engine is neither visible in the API (datatypes, struct members) nor documented (with a comment that describes some internal implementation detail), then it doesn't matter whether libsyncevolution.so was compiled with or without glib support. [finding backends] > I now add a configuration option: enable-maintainence-mode, when with it we > will just scan backends/**/.libs/*.so otherwise we will stick to > $prefix/libsyncevolution/backends/*.so Looks good. Please add it to the recommended options in the HACKING document. Also beware of the typo: it should be --enable-maintenance-mode. I always have trouble spelling that word. Perhaps better use --enable-developer-mode? (In reply to comment #3) > Instead of splitting the library into the api and implementation part, maybe > we > can distribute only api related header files; other header files > (CurlTransport > Impl, SoupTransport Impl, ObexTransportImpl, EvolutionSyncClient, > SynthesisEngine related) will not be distributed. Exactly. > This reduces the dependency as well as keeping it clean. If we later decide to > distribute more functionality,change the make rule to distribute more > corresponding library headers. > > Is it better? Perfect. The problem will be to ensure that these headers remain self-contained and meet some quality requirements: with just the CFLAGS from syncevolution.pc (-I<syncevo include dir>) and synthesis.pc (-I<synthesis include dir>) on the command line, can g++ parse every header file? I really mean invoking it once on each file separately. A common bug is to not include relevant header files, which is not found when some other header file included them first. Then we have namespace issues (bug #3472). I wonder whether we can integrate checks for these kind of issues into "make distcheck". -- Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching someone on the CC list of the bug. _______________________________________________ Syncevolution-issues mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution-issues
