[Dovecot] compiling dovecot-sieve
Fintec
mailing_list at fintec.co.nz
Mon Oct 16 00:57:50 UTC 2006
On Mon, 2006-10-16 at 00:52 +0200, Axel Thimm wrote:
> On Mon, Oct 16, 2006 at 12:50:48AM +0300, Timo Sirainen wrote:
> > On Mon, 2006-10-16 at 10:47 +1300, Fintec wrote:
> > > Our server is an CentOS4.4 box and we use the atrpms built RPMs for
> > > installing dovecot. I am wanting to use the sieve plug-in so I've
> > > followed the dovecot wiki instructions, downloaded the files from CVS,
> > > but I'm not sure what configure options to use. When I try without any
> > > options I get:
> > >
> > > dovecot-config not found from /usr/src/dovecot-sieve, use
> > > --with-dovecot=PATH
> > > to give path to compiled Dovecot sources
> > >
> > > I tried using "./configure --with-dovecot=/usr/libexec/dovecot" but get
> > > the same problem.
> >
> > You'll need to have Dovecot sources somewhere, and you must have run at
> > least "configure" script for them. And preferrably you should also be
> > running Dovecot installed from those sources, since if the binary
> > package was built with different options the Sieve plugin might just
> > crash..
>
> There is already a request & patch to add that to the packages:
>
> http://bugzilla.atrpms.net/show_bug.cgi?id=904
>
> There are two paths:
>
> a) Like the patch above, build both in one sweep
> b) Have the main dovecot tarball install files (headers,
> dovecot-config etc) for developing against dovecot.
>
> The advantage of a) is that it can be done right away. The advantages
> of b) are longer-term: It decouples the builds of dovecot vs sieve,
> and thus allows to have a faster (or different) development cycle for
> sieve, e.g. a) implies rebuilding all dovecot packages for any change
> in the sieve sources.
>
> And if another extension/plugin requires dovecot's development files
> and lives external to dovecot it will require the same handling making
> b) even more worth while.
>
> There is also
>
> c) Upstream (Timo) doesn't yet want to see dovecot-sieve distributed
> in packages because he considers it not ready yet and will merge
> the dovecot-sieve sources into dovecot proper when he things it's
> ready.
>
> :)
I can see the advantages & disadvantages of both and my opinion is that
option b) would be better for now. When Timo is happy that the cmuseive
plug-in code is stable then it could be built automatically with
dovecot.
I haven't been able to get the cmusieve plug-in working yet so I'm keen
for either a) or b)! :)
Gavin
More information about the dovecot
mailing list