On Wed, 2007-02-07 at 16:21 +0000, pod wrote:
My first thoughts were to simply move the dovecot-sieve code into the dovecot tree (I imagine under src/plugins/cmusieve or similar) and rework the autoconf setup as appropriate. This sidesteps the problem for this case but does not help other 'third party' dovecot plugins.
I've been thinking that it should be possible to unpack tarballs under some plugin directory and have configure automatically pick them up and build them. But I'm guessing it'll be annoyingly difficult to implement it with automake, so I haven't yet botherered to try.
If however a simple plugin build environment were to exist as part of a dovecot install then plugins could be distributed and built as independent packages. I quite understand that this additionally burdens dovecot development with 'stable API' concerns which may not be considered worth the effort.
The 1.0.x series will have pretty stable API, but the problem I see with this is that it'd either require creating some special simple and limited plugin API (which I think is stupid), or including almost all the .h files. The latter is possible though, the same thing is done with irssi already in several distros. I guess there could be dovecot-dev package containing all the .h files..
The reason why Sieve plugin wants .a files then is because it wants to build standalone binaries as well. I'm not sure what could be done about that.