[mdb-dev] GLIB Dependency?

[Jakob E. <jab...@gm...>]

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?

Best regards,
Jakob Egger


On 09.08.2011, at 16:34, Nirgal wrote:

> On Monday 08 August 2011 21:56:26 Brian Bruns wrote:
>> Excellent, my mac is back up and running.  I'll likely get to all
>> these patches sometime tonight.
> 
> Good :)
> 
> If you are lost, I have a serie of patches there:
> http://www.nirgal.com/mdbtools/debian.squeeze/debian/patches/
> 
> But there are other incompatible ones on github :/
> 
> 
> What will be the name of next release?
> Does 1.0 comes after 0.6pre1? Or is that 0.6.1?
> 
> 
> I think we should stop exporting these symbols from libmdb before releasing:
> sanitize_name, kkd_to_props, _mdb_put_int16, _mdb_put_int32 and buffer_dump
> All other symbols matches the "mdb_*" mask (new map file)
> 
> ------------------------------------------------------------------------------
> uberSVN's rich system and user administration capabilities and model 
> configuration take the hassle out of deploying and managing Subversion and 
> the tools developers use with it. Learn more about uberSVN and get a free 
> download at:  http://p.sf.net/sfu/wandisco-dev2dev
> _______________________________________________
> mdbtools-dev mailing list
> mdb...@li...
> https://lists.sourceforge.net/lists/listinfo/mdbtools-dev