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.