Re: Glib
- From: Magnus Bergman <magnus bergman observer net>
- To: gtk-devel-list gnome org
- Subject: Re: Glib
- Date: Thu, 4 Mar 2004 16:14:51 +0100
On Wed, 3 Mar 2004 19:23:29 -0500
Bob Rossi <bob brasko net> wrote:
> Hi,
>
> I am the author of an open source project called CGDB. It is a curses
> based interface to the GDB. CGDB is written in C. I have been
> searching the Internet for a good C library that contains useful
> abstract data types.
>
> Glib is the closest thing I could find. However, it seems that Glib
> contains a lot more than what I need. g_threads, ...
>
> It would be nice if Glib could be built into a small C library than
> only had ADT's in it. This way, many small projects could take
> advantage of these data types, without loosing portability. The goal
> of CGDB is to port anywhere that GDB ports.
>
> If I was to change Glib, so that you could do ./configure --only_adt
> or something like that, and it would make a smaller library that only
> contained the ADT's, would this be considered acceptable?
>
> For example, I would only include parts of the library that are not OS
> specific. Such things could be garray, ghash, glist, gqueue, gtree,
> gstring, gcompletion, ...
> This way, Glib could still work the way it always has, but other
> people could take advantage of only the valuable ADT's that have
> derived over time.
>
> If this is possible, then more open source projects could take
> advantage of part of Glib and contribute back bug fixes and more.
> Otherwise, I'll probably just take what I need out of Glib and modify
> it for my own needs. I really think this is a bad idea, so I was
> hoping some sort of solution would present itself.
First of all glib is very portable. For me that's the primary reason for
using it in the first place. But I'm sure you are right in saying that
it is still less portable than your application (and it's other
dependancies). I think the best solution would be to make glib more
portable by disabling some features (like threads) on currently
unsuported platforms. For the currently supported platforms there should
be no need to change anything.
On the other hand there are other libs that only include ADT. Perhaps
one of those would better suit your needs.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]