Note: I mistakenly sent this to the patches mailing list first. I hope I will not get slaughtered for that. My apologises.
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 _______________________________________________ Evolution-hackers mailing list [email protected] http://mail.gnome.org/mailman/listinfo/evolution-hackers
