Next: The development team Up: CLAM Additional Information Previous: Graphical interfaces
The cross-platform spirit of the CLAM framework has influenced and condition the selection of tools and the way they were used. We will first explain the development tools used such as compiler and concurrent version control systems and later explain the tools and resources that CLAM offers to its users.
CLAM is implemented in C++[Stroustrup, 1997]. The choice of the language was obvious at that time and during this time we have had nothing to make us thing it was not the correct decision. C++ was chosen for the following reasons:
From the very beginning many incompatibility issues between gcc and Visual C++ compiler had to be addressed. Microsoft Visual C++ 6.0 came with a compiler full of flaws and bugs and lacked support for some important parts of the C++ ISO standard such as the absence of template partial specialization. Microsoft Visual C++ 6 also came with other major problems like an extremely bad implementation of the C++ Standard Template Library (STL). As a matter of fact, Microsoft's development environment was always the one that limited the development. Some solutions existed at that time, for instance using Intel's C++ compiler that turned out to be much more robust and compliant to the standard. But we could not make our development depend on yet another proprietary tool that is no that much extended in the development community.
As for gcc, some major problems had to be faced with version 2.96. This was an unstable version of the compiler but that made it through to the RedHat 7 GNU/Linux distribution. The main flaw in this implementation of the GNU compiler was that lacked support for dynamic casting. The CLAM framework could not do without some dynamic casts that were applied on polymorphic variables at crucial points of the code. For this reason, CLAM did not (and still does not) support gcc version 2.96. When version 3.X of the compiler were published, some minor changes had to be applied to the code, especially due to the increased strictness in some syntax rules. But the framework was soon compiling under this version. When CLAM was ported to Mac OSX and compiled with the gcc version there included no major problems were found either.
All these problems are specially true when it comes to the use of the most recent C++ features, such as templates, and related techniques, such as meta-programming and static dispatching. These techniques where initially considered as potentially useful in the CLAM framework, but the lack of language support in most compilers, together with the need of optimizing the compiling speed of the library, has led to a rather scarce use of them.
On the other hand, a technique considered obsolete as it is the use of C macros, has proven very useful to minimize programmer's effort and enable the implementation of rather complex behaviors (one of the good things of developing with a multi-paradigm language like C++ is that you can always find a more or less immediate workaround). Also, C macros are a simple compiler feature which is available in all C++ development platforms.
All code for CLAM is written in a collaborative manner and no code ownership is promoted. CVS [Fogel, 1999] was used from the very beginning although its usage has been improved and rationalized with every new release. First there was a single CVS branch. Later on, a second branch called ``devel'' was introduced. Major development was on this branch while the ``main'' branch was far more stable and only bugfixes were committed in between releases. When CLAM became public a new ``public'' repository was started. This repository was a mirror of the internal main-trunk except for the exclusion of folders marked as ``private'' (mainly drafts). It was updated on every new release or major bugfix using a semi-automatic script. Internal projects that used CLAM had their own repositories in which they had some particular CLAM-related applications. In release 0.5 the public CVS repository was removed and substituted by tarballs that are automatically generated from the main branch of the internal repository. Nevertheless, public CVS access is planned when the framework becomes more stable (i.e. reaches the 1.0 version).
Other web-based tools are used in order to manage the framework. Mantis [www-Mantis, ] is used for bug reporting and tracking. A public mailing list is also available at clam@iua.upf.es.
As for documentation, several approaches are followed. On one hand Doxygen [www-Doxygen, ] is used to automatically generate html source code documentation from javadocs comments available in the source files [Microsystems, ]. On the other hand an html document is maintained through CVS and published in the web in different formats including an automatically generated pdf file.