On Wed, 2009-09-16 at 07:10 +0100, Chen, Congwu wrote: > >There's the "libsyncevo" branch now. I just had a look at it and have > >some comments/questions. > > > >Do we want to install header files in "/usr/include/syncevo" or > >"/usr/include/syncevolution"? I suggested the later and still prefer the > >full name instead of the shorthand. > I did not use syncevolution because our binary is already named > syncevolution, which cased two files/directory with the same name > under src. Maybe we have to change the binary name to something like > sync-evolution?
Argh, name clash. Hadn't thought of that. No, the command line tool can't be changed, users probably depend on it in scripts. Ignoring this particular problem for a second, let's think about whether "syncevolution" or "syncevo" are more useful in code (include statements, name space, ...). My only objection against it is that it still looks unfamiliar to me, but perhaps I should simply get used to it? One strong point in favor of "syncevo" is that it is shorter and thus requires less typing. Thoughts anyone? > >If I read the last patch in that branch right, then EDS and glib header > >files are now a hard dependency for using libsyncevolution > >(syncevolution.pc.in: Requires: libedataserver-1.2 libebook-1.2 > >libecal-1.2 glib-2.0; #ifdefs removed from several header files). Is > >that intentional or is the goal to change that again? > I am still working on this yet. The goal is to reduce such > dependencies by splitting to another library (With Obex, additional > dependencies introduced). True, but if none of these dependencies' development files are required when compiling (= we include some of their header files) or linking (= we provide libsyncevolution as static library or these dependencies contain static libraries themselves), then it is perfectly possible and desirable to ignore these additional dependencies. That libsyncevolution.so is linked against a libfoo.so.1 is transparent, -lfoo is not needed again when linking against libsyncevolution.so. > >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) I'm not entirely convinced that this is necessary. I think a clean API (self-contained header files which do not expose more than necessary, a libsyncevolution.so which only exports the public symbols) can also be achieved without splitting the library. In fact, if it is only one library, then we can hide the internal symbols in the libsyncevolution.so, like it is already done in libsynthesis.so. If we have multiple libraries (libsyncevolution.so with the API, libsyncevolution_internal.so with the implementation), then all internal symbols which are needed by libsyncevolution.so must be exported by libsyncevolution_internal.so and therefore are visible globally when linking. -- 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
