9:42 p.m.
http://bugzilla.moblin.org/show_bug.cgi?id=6181
pohly <patrick.ohly(a)intel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |patrick.ohly(a)intel.com
--- Comment #4 from pohly <patrick.ohly(a)intel.com> 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.