Re: [Evolution-hackers] Failing to build latest GIT code

2009-11-27 Thread Patrick Ohly
On Wed, 2009-11-25 at 15:05 -0500, Matthew Barnes wrote:
 On Wed, 2009-11-25 at 08:23 -0500, Paul Smith wrote:
  You will only hit this if you don't already have Evo installed.  If
  you have it installed then the link will use the installed version.
  Most likely that's the problem: the linker found a different libeshell
  somewhere on your system.
 
 Do you know of a good way to make that more detectable for developers,
 short of uninstalling Evolution?

On Debian, debootstrap and schroot are great for these kind of
light-weight build environments that are independent of the developers
personal Linux installation.

-- 
Bye, Patrick Ohly
--  
patrick.o...@gmx.de
http://www.estamos.de/


___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Failing to build latest GIT code

2009-11-27 Thread Matthew Barnes
On Fri, 2009-11-27 at 16:26 +0100, Patrick Ohly wrote:
 On Debian, debootstrap and schroot are great for these kind of
 light-weight build environments that are independent of the developers
 personal Linux installation.

Oh, excellent tip!  And I noticed all the recent LIBADD bugs were from
Debian people.

I'll play around with that and see if I can work it into my standard
release preparation checklist.

Matthew Barnes

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Camel Manifesto

2009-11-27 Thread Matthew Barnes
On Thu, 2009-11-26 at 14:24 +, Michael Meeks wrote:
   So - I'm well up for hiding complexity behind an asynchronous API in
 general; that's a great goal. I guess there is also the mail-to-e-d-s
 red herring to consider in the mix - that (potentially) adds a layer
 of asynchronicity to the equation in the form of remote dbus calls;
 perhaps worth considering that in parallel - though it would be cut at a
 different place (potentially).

In fact the mail-to-eds effort is part of what's motivating all this.

Your point about the backends devolving into complex, hard-to-follow
state machines is well taken.  Evolution itself is what I'm really
aiming to de-thread, and having thought about it further I think I can
accomplish that without having to disrupt the Camel backends too much.

To make the discussion more concrete, these are my current plans for
Camel's extreme makeover.  The final API will hopefully feel like a
natural extension of GIO.

- Convert Camel to GObject and discard the redundant parts of its
  custom type system.  (That's mostly done now on my branch.) 

- Replace CamelException with GError, and make sure all methods that
  take a GError return -something- so failures can be detected without
  having to test the GError directly.  (I'm slogging through all that
  now -- over the holiday weekend, no less!)

- Gradually add GObject introspection annotations to the public API.

- Once GIO gets SSL support, replace all the CamelStreams with stock
  GIO (and GNIO) streams plus our own GIO stream subclasses for things
  like filtered streams, NULL streams, etc. [1]

- Every method that can block will take a GCancellable argument.  This
  will address one of my major problems with Camel's current API, which
  is that you can't easily tell which functions block and which ones do
  not.  This will make it obvious and explicit.

- All (or at least most) of the POSIX or GLib-wrapped POSIX calls for
  file I/O will be replaced with cancellable GIO equivalents.

- And finally the async aspect: taking a cue from GIO, blocking methods
  will have asynchronous variants whose default behavior is to simply
  call the corresponding synchronous method from an isolated thread.
  Subclasses (including the backends) can override the default async
  methods if they want to.

Evolution will then be free to call Camel's async methods from the main
thread.  I'll still have to deal with queuing up operations in order on
the Evolution side, but everything will be cancellable (and actually
cancel when you tell it to, especially when the network is flaky) and
we'll hopefully have far fewer issues with frozen UIs.

Does that sound like a more down-to-earth approach?

Matthew Barnes


[1] Alex's new GConverter interface also caught my eye as a potential
replacement for CamelMimeFilter sometime in the distant future.

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers