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.
|