<html xmlns="http://www.w3.org/1999/xhtml" xmlns:html="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>
DevelopmentPolicy – OpenCT
</title><style type="text/css">
@import url(trac.css);
</style></head><body><div id="content" class="wiki">
<div class="wikipage searchable">
<h1 id="DevelopmentPolicy">Development Policy</h1>
<p>
It is easier for all developers if the whole software of a project is homogenous,
follows the same basic rules for function names, coding style, and so on. None of
the rules mentioned in this document are set in stone, however please follow the
rules for now, and if you feel something should be changed: start a discussion
on the opensc-devel mailing list.
</p>
<ul><li>Coding Style: we follow mostly the coding style as the linux kernel. So you
can have a look at the "Documentation/CodingStyle" document in the linux
kernel source for details, and use the "scripts/Lindent" script from linux
kernel source to indent source files. ("-npro -kr -i8 -ts8 -sob -l80 -ss -ncs")
</li></ul><blockquote>
<blockquote>
<p>
Note that indenting is meant to make the code more readable. Please check if the
indent tool actualy made it more readable, and only commit your changes if it did.
Sometimes functions are too nested and it is very hard to rewrite the code with
less nesting. It is prefectly fine to deviate from the norm in such cases.
</p>
</blockquote>
</blockquote>
<ul><li>usualy we define a "something_t" typedef for every "struct something" and use
the something_t name.
</li></ul><ul><li>build system: we use autoconf, automake and libtool to make the building as easy
as possible. We test on debian sarge (autoconf 2.59, automake 1.9.5, libtool 1.5.6), if you have
different versions of these tools and run into problems, please let us know.
Note: for security reasons (insecure use of tmp files) automake 1.9+ is recommended.
</li></ul><ul><li>we use and/or provide pkg-config files, to ease linking with our libraries and detecting
libraries. While alternatives might be marginaly better, the additional work might be
not worth it.
</li></ul><ul><li>svn files: we store only files in subversion that are not generated in any way.
bootstrap will generate most files like configure and Makefile.in. "make dist" will
generate or update the documentation. To do that it uses wget to get snapshots of
our wiki webpage.
</li></ul><ul><li>"make maintainer-clean" removes all generated files. See this <a class="ext-link" href="http://opensc-project.org/pipermail/opensc-devel/2005-September/007002.html" shape="rect"><span class="icon"> </span>mail on opensc-devel</a> list.
</li></ul><ul><li>"cvs is not a replacement for developer documentation." That rule works well for subversion, too.
We think it is very important all changes are discussed first before commiting. We welcome new
developers, but ask you to post any changes to the opensc-devel mailing list for peer review,
if everything is fine one of the few developers with svn write access will commit the changes.
Once we see someone is sending patches that can be applied without discussion we get lazy and
hand out write access.
</li></ul><ul><li>Things that you commit should at least compile, preferably on all supported platforms
(Linux, Mac OS X, Windows and if possible Solaris). Conforming things to the Linux style is nice
but take care not to increase the burden on other platforms.
</li></ul>
</div>
</div><div class="footer"><hr></hr><p><a href="index.html">Back to Index</a></p></div></body></html>
