Re: is glib too bloated?

[Murray Cumming <murrayc murrayc com>]

On Mon, 2007-04-23 at 17:44 -0500, Brandon Casey wrote:
> The problem I had was in compiling glib on IRIX and its dependency
> on gettext.

Thanks, finally. Details are good. I note that this is about building
from source, not at all about performance.

I can't imagine that anyone is seriously using IRIX (or other obscure
Unixes) for something non-commercial. If it's commercial, I can
recommend that you get prebuilt packages from
http://www.thewrittenword.com/

They even have gtkmm and applications such as Inkscape in their set.
I've done some porting work for them.

Building from source is difficult and always will be. People shouldn't
have to build from source. I'd expect the glib developers to only really
be worried about that kind of thing if package builders have difficulty
building from source.

But, if you mention your gettext build problems in detail, someone might
be able to help you.

>  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.

-- 
Murray Cumming
murrayc murrayc com
www.murrayc.com
www.openismus.com