Re: A FAQ? What do I need to build GTK+ these days?

[Havoc Pennington <hp redhat com>]

Rick Campbell <rick campbellcentral org> writes:
> 
> I wouldn't phrase it quite that way, but perhaps, ``Don't force
> support for disabled users and/or internationalization on those that
> don't need it.''  This is the approach that XEmacs development takes
> on things ranging in importance from internationalization down to
> native support for X-Face images in e-mail.  For almost every option
> that requires an additional package to be linked in, there's a
> ./configure option that disables it.
> 
> This doesn't necessarily mean that functions disappear completely, but
> they may behave differently.  The advantage of this approach is that
> people who really want/need to keep things lean and mean are able to
> do so, while those who want/need all possible features are also able
> to do so.
> 

We do have these options for the image libraries (though this raises
the question - say you configure without PNG support, what happens
when you have an app that assumes said support is there? - so arguably
we aren't doing you any favors, unlike XEmacs other apps expect GTK to
behave a certain way, the main reason for allowing the build without
image libs is to support custom embedded builds where this tradeoff is
OK).

For accessibility, ATK is just a bunch of stubs; the actual
functionality will be in dynamically-loaded add-on modules. So as you
say, the function doesn't disappear completely but may behave
differently. ATK is in a separate package so non-GTK can use it, but
the forthcoming giant gtk-all tarball should address that.

For i18n, English and European languages go through a nearly identical
codepath to Arabic or Chinese, so there's not much you could strip
out. The language-specific functionality is already in
dynamically-loaded modules so you don't pay runtime cost for languages
you don't use. Again, Pango is separate so non-GTK apps can use it.

For other dependencies, there's libiconv, but this is a replacement
for stuff that's supposed to be in the C library and isn't needed
unless your C library is a broken piece of junk. So if you need
libiconv, complain to your operating system vendor. ;-)

So there are a few ways to remove a dependency:
 a) nuke the feature
 b) make the feature optional
 c) bundle the dependency in the tarball

a) is mostly not acceptable, because image loading, i18n, etc. are
pretty fundamental features.

b) works sometimes, but for a library where other apps expect features
to exist, it's pretty hard. e.g. look at how GModule is an optional
feature; you're supposed to call g_module_supported() to check before
using it. Now survey the apps using GModule and see how many of them
do something sane if !g_module_supported()...

We are doing b) and will do more of b) in order to support embedded
builds, but actually using this feature for a desktop build is just
asking for pain.

c) has the evils of cut-and-paste, and annoys everyone who already
does have the dependency, which e.g. for the image libs is a solid 95%
of our users... still, we have done it from time to time,
e.g. sticking fribidi into pango, and the gtk-all tarball will bundle
up the 4 libs we maintain ourselves. I'd add the image libs and
libiconv to the big tarball except it would take a lot of rearranging
their build system and writing new Makefiles for them, and I just
don't have time.
 

My point is basically that with gtk-all, ability to disable image
libs, including fribidi, dynamically loading stuff most people won't
use, etc. we are doing our best to manage this issue and are certainly
aware of it. However our goal is a full-featured industrial-strength
toolkit, and there are no free lunches.

Havoc