[HarfBuzz] Further splitting libharfbuzz.so

[Behdad Esfahbod]

Hey everyone,

One of the issues I have to address before releasing harfbuzz-1.0 is to figure
out how to split libharfbuzz.so into smaller libraries, as after 1.0 I have to
maintain ABI.

We had this same problem with cairo, and never addressed it.  That's bad,
because distros can't enable all cairo backends without pulling in every
library on earth.  So I want to get it right with harfbuzz.  Earlier this week
I split hb-icu out and was going to be happy with it.  But thinking more about
it today, I'm leaning towards moving hb-glib and hb-ft out too.  In the future
I may be adding hb-cairo, and I definitely wouldn't want cairo to be added as
a libharfbuzz dep.  So, please help me decide.

  * hb-ft is a very small piece; convenience code you can even call it.  Most
"serious" users of harfbuzz don't use hb-ft, but small users all use it.
harfbuzz proper doesn't depend on FreeType.  So, separate it into
libharfbuzz-ft.so?

  * hb-glib has three purposes:

    - Map between glib and harfbuzz types.  That's needed for Pango and other
glib-using text layout systems,

    - As the default Unicode callback provider.  If glib is disabled, harfbuzz
builds an internal piece of code called UCDN that provides the same data.  It
results in an extra 100kb of binary as well as duplicated data.  I like to
avoid that, but don't want it to affect my ABI.

    - Soon, I'll add gobject bindings for harfbuzz types.  That would pull in
gobject.

So, is there any interest in separating harfbuzz-gobject from harfbuzz-glib
even?  An interim option is to move the above all in libharfbuzz-glib, but
make harfbuzz privately link to glib for the Unicode data.


Another alternative is to add a libharfbuzz-gnome that gets the ft, glib, and
cairo deps :).  On the one hand I don't like many small libraries.  On the
other hand, the overhead is probably so negligible that it shouldn't affect
these decisions.

Please discuss.


Cheers,
behdad
-- 
behdad
http://behdad.org/