Re: is glib too bloated?

[Brandon Casey <casey nrlssc navy mil>]

On Mon, 23 Apr 2007, Emmanuele Bassi wrote:
> On Mon, 2007-04-23 at 14:01 -0500, Brandon Casey wrote:
> > On Mon, 23 Apr 2007, Murray Cumming wrote:
> > > On Mon, 2007-04-23 at 11:46 -0500, Brandon Casey wrote:
> > > [snip]
> > > > What do we do?
> > > [snip]
> > >
> > > We wait until someone has an actual need for such a change, or an actual
> > > problem.
> >
> > Uh, I don't get it. Do you imply the problem and need I described are
> > not actual?

Whoa. That stirred up a hornets nest. I thought Murray's comment was a
little sarcastic so I responded with a little sarcasm myself. But he's
right, I didn't actually state a problem. It wasn't intentional, I just
didn't think my specific case was important.

> honestly, I still don't quite understand the problem you have, as you've
> been pretty vague about what problems you encountered in porting GLib on
> a 'non-linux' platform.

The problem I had was in compiling glib on IRIX and its dependency
on gettext. I had some trouble compiling gettext, but I did not see
that as the issue, rather glib's dependency on gettext. I'm not sure
if glib should have any dependencies. With enough effort you can get
anything to compile on any system. For me it was gettext, for someone
else maybe iconv, for someone else maybe some other dependency that is
already installed on my system.

I think the value of glib, to developers not creating a gtk+ program,
is in the data structures it provides. Good, stable, implementations
of lists, arrays, hashes, binary trees, etc. I also find the portability
macros useful. If you are writing a gtk+ program, it doesn't matter
because you need everything anyway.

So this low-level core library requires gettext, and iconv and all of
this Unicode manipulation functionality that isn't needed to implement
a good linked list or g_malloc or a gint32.

I think I'm starting to ramble, so I'll just end with..
I think glib has strayed somewhat from being a low-level core library
with the inclusion of unicode handling for one and possibly other
features. My point is _not_ that these features are not useful, just
that glib would be a better library with a more strict focus and useful
to more developers if some of this functionality were moved to a
separate library. This would make glib leaner and easier to compile
(with fewer dependencies), and hence more portable.

-brandon


> dependencies? yes, they are an issue, but unfortunately stuff that is
> considered "core features" of GLib requires them. GLib maintainers have
> been very wary about adding dependencies, so you cannot accuse them to
> be "dependencies happy".
>
> if you want to target a specific system you can remove stuff from GLib
> yourself, by adding switches to configure.in; for instance, you can
> remove most of the main loop, gmarkup and gkeyfile without really
> creating much of an hassle; obviously, the resulting library would be
> completely useless on most of the platforms following the GMAE stack, so
> I don't think a patch introducing those switches would be applied
> upstream.
>
> ciao,
> Emmanuele.
>
> --
> Emmanuele Bassi,  E: ebassi gmail com
> W: http://www.emmanuelebassi.net
> B: http://log.emmanuelebassi.net
>
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list