The design of Doozer++ involves a distinct separation between the tools used and the tasks performed. As a result of this separation, there exists the possibility to extend Doozer++ to use tools other than Autoconf and GNU make. Moreover, different combinations are allowed. For example, we have found that make(1) does not deal well with compiling Java code in general. A more appropriate tool for this task has come out of the Apache Jakarta Project called Ant. Within Doozer++, we could make use of Ant instead of or in addition to GNU make to compile Java software. Nothing restricts users to Autoconf and/or GNU make.
The basic idea behind the separation is the following: detect and configure the static information needed to execute tools that compile a (potentially complex) software system. This leads to a two-step process: configuration and compilation. These steps are described in the following subsections.
During the configuration stage, we determine what tools are available that meet a given set of needs. Typically, this means finding suitable compilers and determining what options the compilers support. Of course, most projects have more complicated needs than this. For example, VR Juggler can be compiled with several different versions of GCC (2.95.3 through 3.1 as of this writing). When moving between platforms, the GCC C++ compiler will almost always be called g++, but it may not always be the same version[2]. For that reason, it may be necessary to perform several version-specific detection steps, including, but not limited to, the following:
Whether a given option is required or even supported (for
example, -fexceptions or
-LANG:<arg>)
What header files are available
(hash_map.h, hash_map,
ext/hash_map, or none of the preceding, for
example)
What libraries are needed for linking shared libraries or
executables (libdl,
libposix4, or
ws2_32.lib, for example)
Moving beyond compiler-specific issues, it may be necessary to detect the installation of third-party libraries or programs. Often times, simply finding an installation is not sufficient. The version of the installation must also be checked to ensure compatibility with the user's project.
This all boils down to one thing: automation. The job of the configuration step is to automate as much as possible. In so doing, the code used to write the compilation can be simplified. In effect, the compilation step becomes a very generic process that is configured based on many platform-, compiler-, and site-specific details that cannot be detected easily by a tool designed for compiling.
As we just described in the preceding section, the compilation step should be a very generic process. Compiling software tends to be a very serialized or step-by-step process. Subsequent steps depending on proper completion of preceding steps. Nothing in particular about compiling software (or code generation in general) has to be tied to a specific set of tools. The process should depend more on the source code and what steps are necessary to generate the desired outcome.
While it is possible to construct build system software that does everything in the compilation step (a la Doozer proper), such systems tend to be very inflexible. Everything that could provided more generically through the configuration phase must be defined statically in makefiles (or whatever specification file is being used to direct the build process) and in the code. For example, consider the following C++ code:
#if defined(HAVE_HASH_MAP) #include <hash_map> #elif defined(HAVE_EXT_HASH_MAP) #include <ext/hash_map> #elif defined(HAVE_HASH_MAP_H) #include <hash_map.h> #else #error "std::hash_map is not available with this compiler" #endif
The code above is not tied to any specific compiler or any specific compiler version. Now, consider the following code that achieves the same result:
#if defined(__GNUC__) # if __GNUC__ < 3 && __GNUC__ >= 2 && __GNUC_MINOR__ >= 95 # include <hash_map> # elif __GNUC__ >= 3 # include <ext/hash_map> # else # include <hash_map.h> # endif #elif defined(__MSVC_VER__) # if __MSVC_VER__ >= 7 # include <hash_map> # else # error "std::hash_map is not available with this compiler" # endif #elif defined(__sgi__) # include <hash_map> #else # error "std::hash_map is not available with this compiler" #endif
The former is much shorter and hides all the platform- and
compiler-specific details in the definition of the various
HAVE_* symbols. The latter code is clearly much
more complicated and only supports three compilers: GCC, Visual C++,
and MIPSpro. (The latter example may also have inaccuracies. Think
of it more as pseudo-code than something taken from real C++ code.)
Certainly, the latter could be simplified by adding command-line
options defined in platform- and compiler-specific makefile stubs
(-DHAVE_HASH_MAP and so on), but such options would
have to be provided for all possible cases. That method has obvious
scalability problems, however.
Many other projects provide a variety of platform- and tool-specific makefile stubs that set up a build environment at the time of compilation. This inevitably leads to an ever growing number of stubs as the software becomes more portable or as external tools (especially compilers) evolve. For example, omniORB 3.0 (an excellent, freely available ORB implementation) has forty makefile stubs, four of which are for use on varying configurations Linux/i386. The upcoming omniORB 4.0, on the other hand, uses Autoconf to separate the platform-specific pieces from the generic, platform-independent compilation work.
[2] On a platform with multiple GCC installations, the executable names typically vary based on the version. For example, a FreeBSD 4.x installation with multiple GCC builds may have the executables g++, g++30, g++31, and g++32 for versions 2.95.4, 3.0, 3.1, and 3.2 respectively. On RedHat Linux 7.2, g++ is GCC 2.96 while g++3 is GCC 3.0.4.