Re: [mdb-dev] GLIB Dependency?

[Alexander L. <le...@ed...>]

On Wed, 10 Aug 2011, Jakob Egger wrote:

> Maybe its a bad timing so shortly before the release, but I was wondering if there is a good reason why the MDB-Tools use GLIB.
>
> I've looked through the source code, and MDB Tools, and here are the main GLIB features used:
> - GLIB typedefs such as guint23, gbool, etc.
> - pointer arrays
> - hash tables
> - gmalloc() and gfree()
>
> I thought about these things and concluded:
> - The GLIB types would be trivial to change to some standard types (such as those from types.h) with a simple search and replace.
> - Pointer arrays could be reimplemented from scratch with about 100 lines of code
> - hash tables are used only for the backend stuff, but we could rewrite that to just use pointer arrays, there's no need for the speed of hash tables here
> - gmalloc() and gfree() could probably be replaced with malloc() and free()
>
> Why am I thinking about this? Glib is a very heavy library. It depends on gettext and iconv. I haven't yet managed to compile Glib myself on Mac OS, I only managed to do it with MacPorts. But even if you manage to compile Glib, it weighs more than 2MB, plus 2MB for iconv (i didn't manage to link GLIB to the system provided libiconv). That is very large compared to 200KB for libmdb. For small apps thats a lot of wasted disk space. Now, on Linux this is no problem, because Linux users will have GLIB installed. But on Mac OS, the dependency on GLIB makes using mdbtools very difficult and much less portable.
>
> I think that removing the dependency of GLIB (for the core library) would strongly increase adoption of libmdb.
>
> What are your thoughs on the matter?
>

I solved this problem by providing the required glib 
types and functions myself. The hash is implemented using STL 
containers.
Of course it is not any longer a plain-C project, but for my needs it did 
the job.
If you are interested, I can offer my code. Its one header and one source 
without touching the mdblib sources.

Alex.