[Dovecot] Sieve: problems installing in different prefix

[Andreas Ntaflos]

Hi list, but mainly Stephan :)

when building and subsequently installing the new Sieve plugin I am 
coming across a small difficulty when it comes to "make install". The 
libraries lib90_sieve_plugin.* always get installed in the directory 
/usr/local/lib/dovecot/lda, no matter what "prefix" argument is supplied 
to "make install". Only the libraries seem affected, not the rest of the 
Sieve plugin distribution (i.e. sieve, sievec, sieve-test, ...).

Background: I like using XStow [1] to manage packages built from source. 
With XStow one can configure and build software like Dovecot and Sieve 
as usual (./configure && make) but then install it under a custom 
directory/prefix, like /usr/local/stow/dovecot-1.2.5. The "prefix" 
argument for "make install" is used for this, i.e.:

make install prefix=/usr/local/stow/dovecot-1.2.5

XStow is then used to create symlinks to the correct places in the file 
system. For example the Dovecot binary gets installed in 

/usr/local/stow/dovecot-1.2.5/sbin/dovecot

and a symbolic link is created by XStow:

/usr/local/sbin/dovecot -> ../stow/dovecot-1.2.5/sbin/dovecot

The advantages are clear: installing a software package is a matter of 
configuring, building and then installing under a custom directory, and 
letting XStow create symlinks. Updating is as easy as installing the new 
version in a parallel custom directory and letting XStow update the 
symlinks. Removing a software package just involves letting XStow remove 
the symlinks and doing an rm -rf on the custom directory. No more 
accidentally orphaned files or the need to keep the compiled source 
distribution around to be able to issue a "make uninstall".

Back to the problem: The Sieve source distribution seems to have some 
hard-coded setting to always install the libraries under 
/usr/local/lib/dovecot/lda and not honouring the "prefix" argument for 
"make install". This is probably a libtool issue, but I am not sure.

I know my way around the Autotools but here I am a bit lost. Looking at 
the generated Makefile in dovecot-1.2-sieve-0.1.12/src I can see the 
following:

moduledir = /usr/local/lib/dovecot/ 

It *should* look like this:

exec_prefix = ${prefix}
...
moduledir = ${exec_prefix}/lib/dovecot/ 

This explains why the install prefix is not honoured here. The 
"moduledir" has already been hardcoded, instead of prefixed. 

For comparison look at the Dovecot source distribution. Here all 
libraries are installed correctly under the specified prefix. An example 
is src/lib-sql. The generated Makefile includes these lines, which are 
correctly honouring the prefix:

exec_prefix = ${prefix}
...
moduledir = ${exec_prefix}/lib/dovecot
...
#sql_moduledir = $(moduledir)/sql
AM_CPPFLAGS = \
    -I$(top_srcdir)/src/lib \
    -DMODULEDIR=\""$(moduledir)"\" \
    $(SQL_CFLAGS)

The last few lines seems to make sure that gcc uses the defined 
moduledir, but as usual generated code is not immediately comprehensible 
for the casual viewer :) 

The top-level generated Makefile also contains a correctly defined 
moduledir:

moduledir = ${exec_prefix}/lib/dovecot

So, which knobs have to be turned to have the Sieve source distribution 
use a correct "moduledir" and not a hardcoded path?

I hope I could explain the problem correctly and haven't drawn any wrong 
conclusions here. I will continue to investigate this and maybe even 
provide a patch if I find a solution but it is probably easier for the 
maintainer and author of the build system to look at this and determine 
what to do.

Anyway, apologies for this lengthy post. I hope it wasn't too long to 
read.

Andreas

[1] http://xstow.sourceforge.net/
-- 
Andreas Ntaflos 

GPG Fingerprint: 6234 2E8E 5C81 C6CB E5EC  7E65 397C E2A8 090C A9B4
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://dovecot.org/pipermail/dovecot/attachments/20090928/f712fb66/attachment.bin