program code [was: [cvs] bogofilter/src ...]

[David Relson]

On Mon, 14 Mar 2005 09:40:41 -0500
Tom Anderson wrote:

> ----- Original Message ----- 
> From: "David Relson" <relson at osagesoftware.com>
> >
> > Yes these things are spread out.  We also build 4 major programs --
> > bogofilter, bogoutil,  bogolexer, and bogotune.  They share many
> > options, but each has some of its own.  The result is 4 sets of option
> > definitions, parsing routines, and help routines.
> >
> > So be it.
> 
> Why not put these routines into a common library?

Hi Tom,

Look at bogofilter's Makefile.  Most of the code goes into
libbogofilter.a and the linker pulls out what's needed.

When supporting multiple databases, at some place in the build process
the compiler/linker needs to know _which_ database read and write
routines to load.  Are Berkeley_Read and Berkeley_Write needed, or is
it QDBM_Read and QDBM_Write, or is it TDB_Read and TDB_Write?
Bogofilter's way of dealing with this is to have separate files for
BerkeleyDB, QDBM, TDB, etc, with each file defining the needed
routines, i.e. read, write, etc.  Using autoconf and automake, the
configuration procedure, i.e. ./configure, generates a Makefile
configured for the requested database.

The "4 sets ..." comment addresses the fact that there are 4
executables built by "make all" and the options needed differ (though
some are shared).  Think of it as a partitioning problem:  Do you put
the 4 help messages in a single file or in 4 separate files?  How do
you deal with the parts that are common to all programs?  Is it better
to have separate files or 1 complex file that prints different messages
when called with help("bogofilter"), help("bogoutil"), help
("bogolexer"), etc.  

AFAICT, there's no best solution for all situations.  We've picked one
way for bogofilter that has strengths and weaknesses.  We enjoy the
strengths and live with the weaknesses.

> > to C code which was then compiled.  Consequently anything doable in C++
> > can be done in C, if one cares to make the effort.  AFAICT, we're
> 
> True of any Turing complete language ;-)
> 
> > The fact that it _can_ support 4 distinct database systems (BerkeleyDB,
> > tdb, qdbm, and sqlite) indicates that _something_ in the datastore
> > architecture is done right.  Of course it could also be argued that
> > supporting more than 1 database backend is going off on a tangent.
> 
> Can individual database code be split into seperate libraries?  Then instead 
> of tangents, they will be seperate projects.  Just make sure they all 
> support the same basic API.

We have separate code files for each database.  They're in src/
database_db_*.c.  As explained above, the appropriate one is specified
via ./configure, src/Makefile is generated appropriately, and "make
all" does the compile and build.  Given that the databases require few
specific files, there's no need to build libBerkeley, libQDBM, libTDB,
etc.  Generating the object files and linking them works fine.
 
David

_______________________________________________
Bogofilter-dev mailing list
Bogofilter-dev at bogofilter.org
http://www.bogofilter.org/mailman/listinfo/bogofilter-dev