developer information and guidelines

this page exists to help introduce new developers to the rapple project and to document the decisions reached by the development team. prospecitve contributors should become familiar with the material in this section before proceeding to the roadmap. if you have comments or feedback then please get in touch with me.

project organisation

the rapple project is currently divided into the following modules (top level CVS directories)

• rapple the project source code (incl. unit test cases);
• website the project website resources;
• resources optional supporting materials (e.g., sample XSLTs etc.);
• tests testing related materials (e.g., sample input files etc.)

tools of the trade

to support quality and consistency of development the rapple development team has reached consensus concerning guidelines on the use of certain tools. these tools are widely used in open source projects and are well documented elsewhere on the web. please take the time to acquire a working proficiency with these tools and to understand our guidelines if you intend to contribute to rapple (we assume that you are already familiar with the standard tools, e.g., diffutils/patch, gdb etc. and so have no specific guidelines to add).

• cvs a version control system used to record the history of sources files, and documents [Guidelines]
• autotools build tools (automake, autoconf etc.) used to support build portability [Guidelines]
• ssh a network connectivity tools suite [Guidelines]
• indent a code style formatter [Guidelines]
• cunit a unit test framework for writing, administering, and running unit tests in C [Guidelines]
• doxygen a code documentation system [Guidelines]

in addition to the above the rapple development team also recommends (but does not mandate) the use of the following

• valgrind a suite of tools for debugging and profiling x86-Linux programs (currently not supported on OpenBSD)

which editor you use is largely a matter of your own taste (e.g., vi, emacs, IDE etc.) but please use a tool that does not impose itself on other developers (e.g., by insering tool specific generated code into source files etc.) and if your tools uses external resouces (e.g., vi with ctags) then please do not check these in as they represent your working view of the code.