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
>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
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.
>If I read the last patch in that branch right, then EDS and glib
>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
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
>just have to be careful that we include config.h like this
> #ifdef HAVE_CONFIG_H
> # include <config.h>
>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
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.