Practice and experience

introduction, concepts, components, examples, patterns, experience, conclusions, references
In developing and maintaining or framework we encountered a number of problems, having to do with platform/compiler dependencies, configuration management and documentation.

Platform/compiler dependencies

The software was originally developed under SunOS 4.1 on a Sun Sparc workstation with the AT&T 3.0.1 compiler. Our first problem was to develop a version for the GNU g++/gcc compiler. As an example, it appeared that the GNU compiler did not allow for a construct like: 
    class handler { ... }
  
    class widget : public handler {
    public:
      ...
      void handler( class handler* h );  // to install a default handler
      ...
    };
Consequently, we had to rename the widget::handler function into widget::installhandler. However, we decided to overload the widget::bind function to allow for installing a default handler.

Much time was spent in finding ways to satisfy both the GNU compiler and the AT&T compiler (and later the Sun CC 4.0 compiler). A situation which is unfortunately still characteristic for working with C++. Much time was also spent in adapting to differences in include files and linking conventions when moving to Solaris. We deal with different platform and compilers now by providing configuration set up files, trying to avoid as much as possible to clutter our code with conditional compilation macro instructions.

Configuration management

Apart from compiler and platform dependencies, users/installers will generally differ in their preference of what libraries and tools the want to have installed. (Including the various public domain libraries that we use, such as for example the QvLib and MesaGL libraries for our most recent VRML extension, the DejaVu source code is wll over 50 megabytes!) To deal with this problem we organised our software in levels to allow users/installers the choice whether to include a group of libraries when installing the framework. In addition, for each level the installer may indicate which particular libraries she wants to have installed. The levels distinguished include: This approach allows for managing different versions of the software packages in a fairly easy way, by modifying the appropriate configuration file. We decided not to use the GNU autoconfigure program program since it proved to be less flexible for managing user preferences. However, many of the packages (including Tcl/Tk and its extensions) do provide their own configuration programs to deal with platform and compiler differences. In addition, we do provide the possiblity to run a configuration program giving advice on how to define the configuration setup file.

Documentation support

An important aspect of framework development is the development of (and maintainance of) appropriate documentation. Users/developers need documentation to know how to use the (framework) classes in their programs and contributors need to know the requirements and constraints their software must satisfy to fit within the framework. Apart from user guides and manuals, we decided to document the various packages by employing literate programming techniques and to allow for looking at annotated include files, examples and selected parts of the source code with a standard Web browser. We use a code to HTML filter from the tools level for this. In the end we wish to provide documentation of our framework that also provides animated examples and demos when viewed with an appropriate (read: our own) Web browser.
introduction, concepts, components, examples, patterns, experience, conclusions, references