Re: [Evolution-hackers] Win32 portability issues

[Not Zed <notzed ximian com>]

On Tue, 2005-05-03 at 18:19 +0300, Tor Lillqvist wrote:
> 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.

> - 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.
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.

> 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.