policy -- adding an XP dependency on a peer library


Subject: policy -- adding an XP dependency on a peer library
From: Paul Rohr (paul@abisource.com)
Date: Tue Aug 21 2001 - 13:36:04 CDT


One of the reasons AbiWord is such a cool XP product is that we *like* to
stand on the shoulders of giants, where it makes sense to do so.

Anyone familiar with the AbiWord sources will notice that we rely on a
number of peer libraries, many of which were Unix-only before we adopted and
adapted them. The last time I did a line count, over a third of the sources
used to build AbiWord came from other Open Source efforts!!

Since most of the available Open Source libraries and tools still come out
of the Unix world, it's fairly common for Unix folks to propose that we add
a dependency on another existing library or tool that they're familiar with.
For developers on other platforms this is both:

  - exciting (free functionality!) and
  - scary (how bad will it be to build & maintain?).

In our experience, sometimes the integration work required to make those
libraries XP is trivial, because the libraries (expat, zlib, libpng, etc.)
already were widely used on a number of platforms. In other cases, the
libraries began as Unix-only, but were coded cleanly enough that XP
integration wasn't bad. And then there's the venerable ispell, which now
allows us to spell-check in dozens of languages on all our platforms, but
only after much agony and heartache. ;-)

Thus, here are my proposed criteria for adding a new XP dependency on an
existing Unix peer library.

1. If you're replacing existing functionality, you do so completely.
2. You check the library into CVS as a peer module.
3. You ensure that it builds cleanly and works on non-Unix platforms.
4. You do the makefile magic so a clean Abi build will create & link it.
5. If step #3 requires any patches, you submit them upstream.

Of these, note that steps 1 and 3 are usually the hardest to accomplish.
It's fine to recruit platform-specific experts to help you solve those
issues, but whoever's driving adoption of the library has the final
responsibility for seeing that they happen.

Paul



This archive was generated by hypermail 2b25 : Tue Aug 21 2001 - 13:28:07 CDT