On Tue, 24 Apr 2007, Murray Cumming wrote: > 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. > [snip] > > But, if you mention your gettext build problems in detail, someone might > be able to help you.
The problems I ran into compiling gettext and glib are not problems I had yesterday. They are older problems that have since been solved. I appreciate your offer to help, it's just not why I was posting. I guess that's why I didn't lay out a problem from the beginning. My posting was intended to suggest that glib would be a better library if its focus was narrowed. I think some of what has been added, including unicode handling has expanded the scope of glib beyond its stated goal of being a low-level core library. It's hard for me to think of unicode as being low-level when it adds so much overhead to string handling. Please don't interpret this to mean that unicode is not important or worth it. The only suggestion is that glib is not the right place for it. I hope you will consider it, maybe there will be an opportunity to change glib in the future if it's worth it. -brandon >> 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 > [EMAIL PROTECTED] > www.murrayc.com > www.openismus.com > > _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
