Development Policy

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.

• 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")

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.

• usualy we define a "something_t" typedef for every "struct something" and use the something_t name.

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

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

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

• "make maintainer-clean" removes all generated files. See this  mail on opensc-devel list.

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

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