Development Policy

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.