HACKING GCR and GCK libraries
BUILD OPTIONS
---------------
Build options for developers:
--enable-strict: Build with -Werror, disable deprecations, and fatal warnings
--enable-debug: Turn off compiler optimization
--disable-debug: Turn off all debug options and output.
--enable-coverage: Build coverage, use 'make coverage' for summary.
PATCHES
----------
Patches should be submitted to bugzilla:
http://bugzilla.gnome.org/enter_bug.cgi?product=gnome-keyring&component=gcr
The gnome-keyring mailing list is:
gnome-keyring-list@gnome.org
egg
Various bits of code shared with other modules
gck
A public library for accessing PKCS#11 modules.
gcr
A public library for bits of crypto UI and parsing etc...
schema
Desktop settings schemas for crypto stuff
testing
Testing CA, gnupg and other mock setups
----------------------------------------------------------------------------------
CODING STYLE
----------------------------------------------------------------------------------
Our coding style is very similar to the linux coding style:
http://lxr.linux.no/linux/Documentation/CodingStyle
Summary below. Differences from Linux coding style are marked with a plus
instead of an asterisk:
+ Space between function name and parentheses.
my_function_call (arg1, arg2);
* Braces on the same line as conditional with spaces around braces:
if (test) {
do_y ();
do_z ();
}
switch (value) {
case CONSTANT:
do_z ();
break;
default:
break;
}
* Braces around functions on a separate line from function name,
return value on a separate line, arguments on separate lines.
static void
my_special_function (int arg1,
int arg2)
{
/* body of function */
}
* Don't use braces unnecessarily:
if (test)
do_this_thing ();
* But use braces here, when one section has more than a line:
if (test) {
do_this_thing ();
} else {
do_other_thing ();
smile_nicely ();
}
* Use of tabs for 8 char indent.
------->if (test) {
------->------->Value;
------->------->Value;
------->}
* No trailing whitespace on lines. Git will warn you about this.
Please enforce it like so (in gnome-keyring checkout):
$ cp -ipv .git/hooks/pre-commit.sample .git/hooks/pre-commit
* The '*' in a pointer declaraction belongs with the variable name:
char *name;
+ Extra long wrapped lines should wrap to function opening brace
using spaces past indentation point.
------>my_function_call ("this is a very long argument here",
------> "wrapped argument is indented with spaces");
* Function names are in lower case with _ separators.
this_is_a_long_function_name ();
* Constants are all in upper case with _ separators.
THIS_IS_A_CONSTANT
+ Structures should be typedefed to avoid saying 'struct' and names
are CamelCase:
ThisIsAStruct
* One line comments should look like:
/* This is a one line comment */
* Multi line comments should look like:
/*
* This is a multiline comment.
* And it has a useless second line.
*/
When in doubt adapt to the style of the code around your patch.