GNOME Bugzilla – Bug 686688
Configurable build of libgdata and gtk+ parts
Last modified: 2013-09-14 16:55:52 UTC
EDS comes with a modular architecture. For users of the EDS APIs that are not Evolution mail client, or possibly not even running on a standard desktop platform, it's really not important to compile many of the various fragments in the EDS source tree. In order to ease integration and adaptation of EDS to various platforms, and to reduce hard build time dependencies we would propose configure options to disable modules independently. So for instance, it would be possible to enable/disable building of the independent modules: o addressbook (if enabled, the following options are possible) o file o google o ldap o vcf o webdav o calendar (as with the addressbook, this provides the following independent backends) o caldav o contacts o file o http o weather o libedataserverui (definitely not needed in many configurations) o camel By default, the build scripts would of course just build everything available with the detected dependencies.
I'd rather not chop up E-D-S like this. We've tried it before and it's a mess. There are dependencies amongst these libraries. libebook, for example, depends on libcamel. And libedataserverui depends on both libebook and libecal. If there's really a strong need for this I'd rather break the addressbook and calendar parts into separate git repos and fold libedataserverui back into Evolution, since it has very limited reusability.
Although I have some sympathies for splitting into separate repositories it should be considered that changing the package organization might cause quite some mess and quite some work for distributions. Is that really worth the heat?
Not "might", "will"!
Debian and Ubuntu already ship a separate package per E-D-S library, and we already publish a separate pkg-config file for each library. I don't see it being all that painful, honestly.
I'd very much like to see this implemented in some way. The background is that we started another attempt to get EDS used in other areas than just the traditional "backend of Evolution in a GNOME desktop". Matthew, I hope that this is aligned with your own goals (for example, reducing dependencies on Evolution). Here's a pointer for that work: http://comments.gmane.org/gmane.comp.mobile.syncevolution/4009 All that is needed for that work is the local address book. Having the option to add more backends (and calendar) is an advantage of EDS, but for the initial acceptance of that solution it is important to minimize the impact on the distro. Having to compile everything that EDS supports is a major problem for (compared to a Linux desktop distro) stripped down distros like Tizen. For example, GTK+ is not currently in Tizen. Personally I'd prefer to have more configure options for this. If the different libraries have inter-dependencies that make modular builds difficult, then perhaps these dependencies need to be cleaned up? I don't like splitting up contacts and calendar. They are tied together by the common base (EClient), therefore making changes based on that API would become more difficult when they are in different repos. libedataserverui and camel can and should be split out.
Created attachment 227366 [details] [review] disable optional components (In reply to comment #5) > Having to compile everything that EDS supports is a major problem for (compared > to a Linux desktop distro) stripped down distros like Tizen. For example, GTK+ > is not currently in Tizen. Here's the patch that I used to compile EDS 3.6.x + native backends without GTK+. I'm merely posting this as an example of what could be done, not as a request to merge the patch. At the very least it would have to be split up into independent pieces. Making components like the google backend or libedataui is trivial. I kept SUBDIR unchanged and instead added ifdefs to the subdir's Makefiles, because then the source files in those subdirs continue to be packaged, without having to remember the DIST_SUBDIRS trick. Is that something that would be acceptable by the EDS maintainers? The biggest part, and the one I am not happy with, is the removal of the gcr dependency. gcr would bring back the GTK+ dependency indirectly. It is needed for interactive authentication, which is not needed when using purely the local backends. Therefore I added a --disable-authentication switch for such a deployment and made the usage of gcr depend on that. I am unhappy with that part because of the large number of ifdefs. A better solution might be to keep the source code which uses gcr as it is and instead provide a stub gcr which returns error codes for the relevant API calls. The stub doesn't have to be ABI compatible. It could be provided as part of EDS or even outside (although making it a part of EDS would be easier).
I've discussed this with Matthew on IRC. Here's a summary: * libedataserverui should be moved into the Evolution git repo. * Only gcr-base is needed by EDS. To avoid the indirect dependency on GTK, either gcr should be split into -base and -gtk git repos or a --disable-gtk switch should be added (to be discussed with gcr developers, EDS won't need changes). * Components in EDS which add significant additional dependencies can and should become optional. * Mandatory components: libecal (because libical is small). libcamel (used by libedataserver and libebook; has optional dependency on crypto libs, which can already be disabled) * Mandatory dependencies: libsoup (and thus components depending on it, unless there is another reason for making them optional) * Optional components: gdata ldap
Comment on attachment 227366 [details] [review] disable optional components Some parts of the patch are relevant (like removing the gdata dependency), others are not (gcr).
(In reply to comment #7) > * libedataserverui should be moved into the Evolution git repo. We're on track for this. I've already filed patches for modules still depending on libedataserverui. In most cases the dependency was a historical artifact and could simply be dropped.
(In reply to comment #9) > (In reply to comment #7) > > * libedataserverui should be moved into the Evolution git repo. > > We're on track for this. I've already filed patches for modules still > depending on libedataserverui. In most cases the dependency was a historical > artifact and could simply be dropped. Added the related bugs I found. Are there others bugs we should track?
I think that's all of them. The other cases were corpses only Fedora is still dragging along.
Created attachment 231710 [details] [review] Make libgdata an optional dependency This patch is recreated and cleaned up for master which already removes libedataserverui (makes libdata an optional dependency).
Created attachment 233576 [details] [review] Make GTK+ a soft dependancy This patch makes building of the GTK+ dependant portions of EDS optional. If GTK+ is disabled (--disable-gtk) then the user prompter module will not be built, leaving the user prompter implementation up to a third party. If EDS is installed on a platform without GTK+ and requires the user prompter module (i.e. because some of the backends may try to use it), then an alternative user prompter implementation should also be installed.
Review of attachment 231710 [details] [review]: Works for me, except of the version check on the libgdata. Please commit to master when you fix it. ::: configure.ac @@ +1357,3 @@ +AC_MSG_RESULT([$enable_google]) +if test "x$enable_google" = xyes; then + EVO_SET_COMPILE_FLAGS(GDATA, libgdata) make the above line look like: EVO_SET_COMPILE_FLAGS(GDATA, libgdata >= libgdata_minimum_version)
Review of attachment 233576 [details] [review]: Please add the "Gtk+ yes/no" into "evolution-data-server has been configured as follows:" too, and then commit, it looks good to me and works fine too.
Comment on attachment 231710 [details] [review] Make libgdata an optional dependency Done, committed, thanks.
Comment on attachment 233576 [details] [review] Make GTK+ a soft dependancy Done, committed, thanks for reviewing.
Gathering from comment #7, it's safe to close this now. libgdata & ldap are both optional dependencies now. libedataserverui has also been removed. EDS master also additionally has an optional dependency on GTK+, if GTK+ is found then the user-prompter service has a stock implementation provided by EDS (if no GTK+ is available then no stock user prompter service is built, the user-prompter service is required by several addressbook & calendar backends... if those backends are needed then another user-prompter service should be provided).