Table of Contents
When the first Autoconf-based VR Juggler build system was started in mid-1998, we had to make a decision: should we use Automake in addition to Autoconf? At the time, we felt that there were several problems with Automake, including the following:
The generated makefiles were too complex to debug
Use of compilers other than GCC was too difficult
Restrictions on the structure and contents of the source tree were undesirable
In four years, we have only been proven wrong on point #3. In our experience, Automake still generates extremely complex makefiles (though it does it very nicely from extremely simple input), and use of compilers such as the MIPSpro Compilers or Microsoft Visual C++ is still very hard.
Based on our needs for VR Juggler (and many other projects that have been developed at Iowa State University's Virtual Reality Applications Center), we identified the following as key goals for Doozer++:
Simplify the use of Autoconf
Allow the use of any operating system
Allow the use of any compiler
Allow code to be written in any language
Use the best tool for a given task
Each of these goals will be addressed in the following sections.
Time and time again, we have seen a resistance to the use of Autoconf because of its (seemingly) arcane language constructs. While macro languages are difficult to use and sh(1) syntax is not immediately intuitive, neither tool can be considered arcane. Indeed, sh(1) is a much more powerful language than most other shell scripting languages, but because of its unique syntax, people tend to shy away from its use.
Further complicating the issue is the complexity of Autoconf in general. It contains many, many macros, and it defines rules for the order of executing those macros. In order to use Autoconf effectively, build system developers must read a fair amount of documentation (all of which is readily available). In our experience, however, many people feel that development build system software should be immediately obvious[1] and should not require much effort to learn.
As a result of these issues, we have attempted to make Doozer++
easier to use than “raw” Autoconf-based <>configure
scripts. Doozer++ macros hide some common details that
often trip up configure script authors. Many utility macros are
provided to reduce code duplication between
configure.in files. For example, code for
verifying that an existing installation of a software package meets a
version requirement is provided. The code for performing the check is
modularized to separate the common tasks involved with this. Namely,
Doozer++ provides macros comparing two version numbers, acting on the
results of the comparison, and caching the results to speed up future
tasks. Each macro is used as the basis for the next so that users have
the freedom to choose how they want their code to behave. We feel that
this offers a level of flexibility not available with Autoconf
2.13.
[1] Of course, little, if anything, is “immediately obvious” in reality. Users tend to want something that is similar to existing tools or something that allows them to make use of existing knowledge.