Release 0.3.1 fixes a few minor autoconf/automake-related issues.
See the CHANGELOG for a detailled list of all changes.
The newest hamsterdb version can be downloaded here:
http://www.crupp.de/dl/hamsterdb-0.3.1.tar.gz.
Merry Christmas 
I just received word that my configure-script does not properly check for BerkeleyDB headers.
My unit test tool in the ./tests-subdirectory uses hamsterdb and BerkeleyDb (i.e. for benchmarking). Therefore the compilation fails, if BerkeleyDb headers are not installed. This shouldn’t be a problem since the libraries are built nevertheless (in ./src/.libs), but i’ll fix this in the next few days.
This release features significant performance improvements; hamsterdb performs a lot faster in all benchmarks. A new option (HAM_OPTIMIZE_SIZE) creates smaller files by merging freelist entries. (This option comes at the cost of performance, therefore it’s disabled by default.)
The build infrastructure was ported to autoconf/automake. Since autoconf uses special naming conventions, this version is 0.3.0 and not 0.1pre3.
See the CHANGELOG for a detailled list of all changes.
The newest hamsterdb version can be downloaded here: http://www.crupp.de/dl/hamsterdb-0.3.0.tar.gz.
For the next release i will finally port the library to Windows and also to PowerPC-Linux, and make sure that big endian-architectures are supported. Then i will implement iterators and duplicate items.
When I started to write hamsterdb, I used hand-written makefiles. They quickly became a nightmare to maintain, and I didn’t want to spend more time for writing makefiles than for writing code. So I looked for alternatives, and decided to settle on SCons instead of GNU Autotools (autoconf and automake).
And now I decided to revert my decision. Why? Because SCons is far more complicated than it looks, while autoconf/automake is far more simple than it seems.
The main advantage of SCons is that it’s a python application. Even the SCons recipes (the aequivalent of the makefiles) are pure python. And that’s also the drawback - the SCons environment has many objects and is quite complex.
Also, python is an interpreted language. You can write bad code but will never get an exception, unless the bad code is executed. And the execution usually depends on your build settings, your environment etc. This is a big source for errors, and needs a lot of testing - voila, I’m back at the beginning when writing (and testing) a Makefile was more time consuming than the coding itself…
Of course the autotools are bizarre. The M4 syntax of autoconf reminds me of a creepy Sendmail configuration file. And automake is only acceptable to me because I am used to work with Makefiles and gmake. But in the end, both scripts (makefile.in for automake, configure.in for autoconf) are quite simple and short, and there’s a lot of documentation available, and many many libraries use autotools and you can use their files as templates.
And using autotools brings another huge advantage - the infrastructure is already available on every Unix/Linux system. SCons needs python (usually available) and the SCons program (almost never available). If somebody wants to test hamsterdb, he has to install another program first, just for the compilation - that’s quite tedious.
I have not yet finished the transition to automake/autoconf. But I’ll do my best to release it this year
Here’s more documentation about autoconf and automake: