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

[Philip Van Hoof <spam pvanhoof be>]

Oh, oeps. This was supposed to be sent to the hackers mailing list.

My mistake

On Thu, 2006-07-20 at 12:30 +0200, Philip Van Hoof wrote:
> 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