Re: [Evolution-hackers] Win32 portability issues

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

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]