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.