[Date Prev][Date Next]
Re: back-bdb2 <-> back-ldbm
On Wed, 24 Feb 1999, Hallvard B Furuseth wrote:
> Date: Wed, 24 Feb 1999 18:09:21 +0100 (MET)
> From: Hallvard B Furuseth <firstname.lastname@example.org>
> To: Kurt Spanier <email@example.com>
> Cc: openldap-devel@OpenLDAP.org
> Subject: Re: back-bdb2 <-> back-ldbm
> Kurt Spanier writes:
> > To avoid conflicts, I have moved ALL non-static functions in back-bdb2
> > into their own name-space, bdb2_ and bdb2i_, respectively. That is the
> > situation for the moment.
> Oh, I see. Personally I wouldn't have moved any files until they needed
> to be moved, but I guess that's a matter of taste.
actually, my first approach to the new backend was to shift all internal
functions to the new name-space, and keep the entry functions
(ldbm_back_add, ldbm_back_search ...) to their original names. Since
'back-bdb2' will be build BEFORE 'back-ldbm' and the respective libraries
will be ar'ed in that order to 'libbackends.a', I HAD a total replacement
of back-ldbm by 'back-bdb2' :-) Only when I shifted to backend specific
names even for the entry functions, I had both backends again available at
the same time.
As I said, I have discussed with Kurt to totally replace back-ldbm by
back-bdb2, once you configure --with-bdb2, but he argued, that we should
stay with the possibility to use a GDBM backend together with a BDB2
backend. Maybe, Kurt should comment on that.
Of course, once we have that decission to totally skip back-ldbm when we
use back-bdb2 (which I would strongly support, not because I am the
principal developer of back-bdb2, but because NDBM/GDBM CANNOT be used
at the same time due to the #ifdefs #elif and whatever in ldbm.[ch]),
code hassels could be reduced to some extend by re-using the functions.
> > Now, how could you merge certain source files, when functions in those
> > files will call backend-specific versions of functions that completely
> > differ from each other ?
> Compile bdb2 with -DUSE_BDB2 or something, and maybe back-ldbm with
> -DUSE_LDBM. Then say
> #ifdef USE_BDB2
> # define db_some_func bdb2i_some_func
> # define db_some_func ldbm_some_func
> and call/declare `db_some_func' in the .c file and proto-*.h file
> instead of calling/declaring `bdb2_some_func' & `ldbm_some_func'.
> > You had to decide on the functions' name at run-time, depending in the
> > question, which backend you really use at the moment.
> I don't see why anyone would use ldbm if they had bdb2, but if you do
> need to support both at the same time, that's easy enough:
> back-bdb2/foo.c could contain simply
> #include "../back-ldbm/foo.c"
> or Makefile could compile ../back-ldbm/foo.c or copy it.
> back-bdb2/Makefile would compile with -DUSE_BDB2, back-ldbm/Makefile
> with -DUSE_LDBM.
> > Merging the code of both backends again would also be no alternative.
> > Unless you really prefer one backend over the other, you had to include
> > a lot of run-time decision code (not #ifdef, since that compile-time
> > decision), that would make the implementation much more ugly, I fear.
> I don't quite understand what you mean here, but I did assume that only
> some files would be merged. Files that are too different would have
> gotten an #ifdef mess which was worse than having 2 separate files.
> > But if you have a look to
> > libraries/libldbm/ldbm.c and include/ldbm.h it's easy to see, that
> > Berkeley DB really is preferred over the others, once you have it. So
> > running the others in parallel is a non-possibility, even with the 'old'
> > back-ldbm. Why not really shut off back-ldbm when you configure
> > '--with-bdb2' ? This would indeed give the possibility to merge the code
> > again.
> Agreed. And like I said, it wouldn't be hard to hack it to support both
> anyway, if someone really wants it.
Kurt Spanier, Zentrum fuer Datenverarbeitung, +49 7071 29-70334
Universitaet Tuebingen, DE
firstname.lastname@example.org +49 7071 29-5912
Dr. Kurt Spanier, Zentrum fuer Datenverarbeitung,
Universitaet Tuebingen, Waechterstrasse 76, D-72074 Tuebingen
finger "Kurt Spanier"@x500.uni-tuebingen.de