[exim-dev] [Bug 139] Dynamically loadable lookup modules

Top Page
Delete this message
Reply to this message
Author: Tony Finch
Date:  
To: exim-dev
Subject: [exim-dev] [Bug 139] Dynamically loadable lookup modules
------- You are receiving this mail because: -------
You are the QA contact for the bug.

http://bugs.exim.org/show_bug.cgi?id=139




--- Comment #21 from Tony Finch <dot@???> 2008-05-14 16:18:16 ---
On Wed, 14 May 2008, David Woodhouse wrote:
>
> When you're building from source, why would you ever build modules
> dynamically? You can just turn off the ones you don't want (or don't
> have the necessary development environment for).


I was thinking of situations where you want one build for a few
different machines that use different sets of lookups. It saves time to
only load the lookups that are required.

> When you say "creating a unified package", you mean a package such as
> the existing distro packages, with all the lookups present -- except
> that they're as modules, not built-in? That kind of defeats the object
> of having them modular, surely?


Not entirely. Exim could ship with the ldap lookup and would work even if
the ldap libraries are not installed, and could support ldap when they
are. (I'm imagining feeble package managers with weak dependency
handling.)

> The reason I _don't_ like it is because it means you have to edit your
> config when you (or your distro) switch to building with
> dynamically-loaded modules.


A valid point.

I suppose I'm wondering if this feature can usefully be generalized to
non-linux-packagey situations, but I'm happy to be convinced that there's
no point.

Your packaging plan is exactly what I thought you had in mind, and I
expect it would suit Debian fine as well.

> > lookupapi.h:
> >
> > This file is missing the copyright and end-of-file rubric.
>
> University of Cambridge 1995-2007?


/* $Cambridge$ */

/*************************************************
*     Exim - an Internet mail transport agent    *
*************************************************/


/* Copyright (c) University of Cambridge 1995 - 2007 */
/* See the file NOTICE for conditions of use and distribution. */

CODE GOES HERE

/* End of lookupapi.h */

On the other hand, why not include the contents of lookupapi.h in
structs.h?

> I suspect that the end-of-file rubric might be something we could start
> to dispense with.


I quite like it :-)

> (One of these days I might even be brave enough to suggest running the
> whole thing through indent, too. It makes my brain hurt :)


No, the history is too useful to screw up for trivial reasons.

> > The LMM1 comment should be less cryptic.
>
> Can you be a little more specific about what you want it to say?


/* This magic number is used by the following lookup_module_info structure
for checking API compatibility. It's equivalent to the string "LMM1". */

> Will play with that; thanks. Which bits are gmake-only?


All the conditional stuff, and the magic $(LOOKUP_$*_INCLUDE) expansions.
(I might have missed something else.) It's probably easy to find most of
the make portability bugs by trying to build with BSD make. (Dunno what
Red Hat calls it.)

Tony.


--
Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email