[Evolution-hackers] Win32 portability issues

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

(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?)

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

- 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

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?


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