So far the effort to port Evolution to Windows has concentrated on the more "remote" and basic dependencies, like ORBit2, libbonobo, libgnome, gnome-vfs, gal, libsoup etc. So far my changes have met with no resistance, even if I sometimes have broken something by accident/braino, like in gnome-vfs some weeks ago. But now I am getting closer to Evolution itself. More specifically, evolution-data-server. I fear that getting required portability changes accepted into e-d-s will not be possible without controversy... Looking at e-d-s has raised some questions: - libdb. Is there any specific reason why libdb (4.1.25) source is included as such in e-d-s? Would using a separately installed libdb be OK? (If necessary, just on Win32.)
Yeah there's a good reason it is done. You could check the hackers archives perhaps for more discussion. In short, because db's format changes with different versions, we had to force a specific version. And when we did that, distro's often had to build a separate libdb just for evolution, which made it difficult for them. It was even harder for users to find the appropriate libdb version sources. Or worse, the distro's just used a newer version, and broke people's evolution data.
(libdb's Win32 build setup as distributed is for MSVC, and the ltmain.sh they include is too old to build DLLs on Win32. Plus the config.h template doesn't contain the Win32 bits that the pre-built header for MSVC does. So it requires some hacking to make it build also using autofoo/libtool/gcc also on Win32. But why build libdb at all, when there is a Win32 distribution by Sleepycat already?)
As above. I guess it is up to you to decide.
libdb is designed to be an embedded db, I dont think it was intended to be a system library which could change version underneath the application.
- pthreads vs GLib. A Win32 port needs to use GLib's facilities and not pthreads. (Yes, there is an implementation of pthreads for Win32, but, of course, it also just wraps the native Win32 concepts, like gthreads does. As it attempts to provide all the pthreads API (which is much wider in scope than gthreads), it is much heavier than gthreads, so I would prefer not to use it.) Introducing lots of ifdefs for pthreads vs. gthreads doesn't sound attractive. On the other hand, presumably there is some (perceived) good reason why e-d-s hasn't converted to GThread/GMutex/GCond already? Will suggesting such a conversion cause controversy?
I suppose there isn't much we can do about this. I don't think GThread even existed when we started, so that is definitely part of the reason. Glib's api's are generally sucky, and with mutex's there is no difference, e.g. forcing a completely different api for static mutexes is quite annoying.
It is also missing pthread_once. And I don't know what maps to pthread_*_specific, I guess g_private does.
Camel has different requirements than most of eds, and comes from a completely separate development stream. And libedataserver only just got things like e_util* functions. So yeah, I guess there is some duplication.- lack of reuse. I don't have any exhaustive list of examples to point at, but my gut feeling is that while going through the other dependencies, and now looking at e-d-s, I see more or less similar stuff again and again. In areas like pathname manipulation, URI manipulation, higher-level socket abstraction, and asynchronous cancellable tasks. Oh well, one trivial example: e_util_mkdir_hier() in e-d-s/libedataserver vs. camel_mkdir() in e-d-s/camel vs. e_mkdir_hier() in gal/util. Surely this functionality would preferrably be in GLib? It could be added to GLib HEAD, and we could then use some #if GLIB_CHECK_VERSION() to use it from GLib if available.
Should libsoup be used more? It seems a bit odd that both libsoup and camel have asynchronouos DNS lookup functionality, for instance. Maybe gnome-vfs also. Is this just the NIH syndrome? Or reluctancy to suggest new API or extended semantics to somebody else's code, so instead people prefer to reimplement the same thing (more or less) with just slightly different semantics?
What is NIH?
Again as above, camel has specific requirements, that things like libsoup and gnome-vfs dont always meet. For example, the asynchronous dns lookup is cancellable using a global camel cancellation mechanism, and it is thread-safe. Camel cannot depend on many gnome-related libraries because of the threading issue - including anything that uses gobject.
In short, Camel should be treated separately from the rest of eds.
