24.2 Overview of the Two Approaches

The two fundamental approaches to autoconfiscation, which we call
‘quick and dirty’, and ‘the full pull’. In practice each project is
a mix of the two.

There are no hard-and-fast rules when autoconficating an existing
package, particularly when you are planning to track future releases of
the original source. However, since Autoconf is so flexible, it is
usually possible to find some reasonable way to implement whatever is
required. Automake isn’t as flexible, and with ‘strangely’
constructed packages you’re sometimes required to make a difficult
choice: restructure the package, or avoid automake.

Quick And Dirty.

In the quick and dirty approach, the goal is to get the framework up and
running with the least effort. This is the approach we took when we
autoconficated both zip and the Boehm garbage collector. Our reasons
were simple: we knew we would be tracking the original packages closely,
so we wanted to minimize the amount of work involved in importing the
next release and subsequently merging in our changes. Also, both
packages were written to be portable (but in very different ways), so
major modifications to the source were not required.

The Full Pull.

Sometimes you’d rather completely convert a package to GNU Autotools. For
instance, you might have just assumed maintenance of a package. Or, you
might read this book and decide that your company’s internal projects
should use a state-of-the-art configuration system.

The full pull is more work than the quick-and-dirty approach, but in the
end it yields a more easily understood, and more idiomatic package.
This in turn has maintenance benefits due to the relative absence of
quirks, traps, and special cases – oddities which creep into quick and
dirty ports due to the need, in that case, to structure the build system
around the package instead of having the ability to restructure the
package to fit the build system.