gnulib, libegg, foo

[Andy Wingo <wingo pobox com>]

Hi!

At the recent desktop summit there was some discussion about GTK's [0]
role as a repository for blessed widgets.  At one point Johan Dahlin,
who works with business applications, argued that GTK needed more
businessy widgets -- reporting facilities, a spreadsheet-like table,
etc.  He eventually backed off from this position, admitting that such
widgets need not be in GTK proper, but there was concern that people
should be able to share widget implementations, but there was common
aversion to something like a libgtkextra.

Now, the old solution to this problem was libegg.  It was a library that
was to be included in a project's source tree, or parts thereof.  But
there were no tools to manage updates, copies got out of sync, and (I
hear) it was a bit difficult to get something into libegg.

So libegg is mostly gone now.  But the problem remains.

Now, GNU has a nice solution to this sort of issue, and it is gnulib:
http://gnu.org/s/gnulib/.  It solves a slightly different problem, but
GTK could take pieces of it and make a new libegg.

Like libegg, gnulib is designed to be included in your source tree.  In
GNU it is used to present the illusion that the target platform is the
GNU system, and to extend the platform in various ways.  For example,
there is a module that ensures the presence of a working `stdint.h'.  If
you don't have one, that fact is detected at configure-time, and a
stdint.h will be provided at build time.  But if you have a stdint.h,
then that is also detected at configure-time, and so nothing extra is
compiled in.

The same approach works for bigger modules too.  For example, gnulib
used to include a copy of libunistring,
http://www.gnu.org/s/libunistring/.  This provides a proper unicode
library for GNU systems, like libICU.  It grew in gnulib and eventually
graduated to be its own package.

Gnulib is integrated into your package via the "gnulib-update" tool,
which is in the root of the gnulib git module.  You tell it what modules
you need, what license compatibility you need, and it imports those
modules and their dependencies into your module, ensuring that the
license complies.  Typically you then add them to source control, and
later, before your release, you update your gnulib checkout and run
gnulib-update again to update your copies of the modules.

I tell you all this because I think that gnulib is great.  It can reduce
the amount of #ifdeffery in your code.  It's actively maintained, and
generally works OK on MinGW systems too, as well as HP-UX and all those
other unices.  Anything that doesn't use GLib should use gnulib, and
some GLib-using projects might like gnulib as well.

But that's not really my point.  My point is that the gnulib approach to
code sharing can work well for widgets, or other works for which you are
unwilling to commit to a stable interface.  It allows the right amount
of decoupling: not too little, hampering people's abilities to work on
their project, and not too much, proliferating copies without
propagating useful fixes upstream.

I don't have much time to work on this myself, unfortunately.  But I do
hope that this "experience report" from GNU can help GTK folks in
figuring out the right size for GTK, and the right way to share any code
that doesn't fit in that size.

Happy hacking,

Andy

[0] Unrelated to this point, but Matthias and Benjamin's presentation
was titled "Towards GTK 4" or something like that -- without the +!  I
don't know if that was conscious or not, but it sounds like a positive
change to me.  (Har har.)
-- 
http://wingolog.org/