[evolution-patches] A tool to build a lighter camel: camel-lite-builder

[Philip Van Hoof <spam pvanhoof be>]

Hi there,

This camel-lite-builder tool to build a light version of Camel.

It will, using a script that should be invoked before the autogen.sh (or
configure), get the original Camel sources from the original repository
(I will of course make sure that the repository will always point to the
right one. For example in case of a Subversion migration).

It doesn't use a branch, it uses the HEAD of Camel. Except applying the
mmap patch, it doesn't change code. To avoid this patching (which could
be interpreted as forking, but for me it certainly isn't), I might
switch to the mmap branch that will be created soon.

It will apply a small patch to some Makefile.am files of Camel. This to
make sure that the providers don't unnecessarily link with libedata-
server and so that libcamel can link with a static version of a size
reduced libedataserver.

There's a libedataserver that I don't checkout from the original repos-
itory because I had isolate the files that are needed. Compiling only
those reduces .so file size.

I might change this by getting it from the repository and afterwards
letting the script delete the unneeded files (if that makes people feel
better about it, I certainly will). The Makefile.am of libedataserver,
however, needs a more intrusive change. The one that you can find in
this repository will build it as a noinst static library.

http://svn.tinymail.org/svn/camel-lite-builder/trunk/

I on purpose called it a "builder". This is to avoid confusing it with a
fork, which it isn't.

The primary target audience for the resulting Camel binaries will be
people who want to test E-mail clients based on tinymail on mobile
devices that don't come with evolution-data-server or with a version of
evolution-data-server that doesn't contain the mmap patches nor a future
improvement.

I might consider renaming the libcamel .so to libcamel-lite to avoid any
type of clashing. I'm not sure if that would make people feel bad about
it smelling like a fork. If so, I will most certainly not do that and I
will allow "Camel" packages to detect a installation of a "Camel" that
was build using camel-lite-builder, so that they can upgrade to a
version of "Camel" that isn't build by camel-lite-builder.

The idea is to keep the "Camel" that comes out of camel-lite-builder ABI
and API compatible with a normal Camel build.

I've put "Camel" between double quotes not to show that there's a
difference, but to show that there's "no" difference. Both are "Camel".

-- 
Philip Van Hoof, software developer at x-tend 
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
work: vanhoof at x-tend dot be 
http://www.pvanhoof.be - http://www.x-tend.be