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.) (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 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? Cheers, --tml _______________________________________________ evolution-hackers maillist - [email protected] http://lists.ximian.com/mailman/listinfo/evolution-hackers
