HACKING

   1
   2 HACKING GCR and GCK libraries
   3
   4 BUILD OPTIONS
   5 ---------------
   6
   7 Build options for developers:
   8
   9   --enable-strict: Build with -Werror, disable deprecations, and fatal warnings
  10
  11   --enable-debug: Turn off compiler optimization
  12   --disable-debug: Turn off all debug options and output.
  13
  14   --enable-coverage: Build coverage, use 'make coverage' for summary.
  15
  16
  17 PATCHES
  18 ----------
  19
  20 Patches should be submitted to bugzilla:
  21
  22 http://bugzilla.gnome.org/enter_bug.cgi?product=gnome-keyring&component=gcr
  23
  24 The gnome-keyring mailing list is:
  25 gnome-keyring-list@gnome.org
  26
  27 egg
  28    Various bits of code shared with other modules
  29
  30 gck
  31    A public library for accessing PKCS#11 modules.
  32
  33 gcr
  34    A public library for bits of crypto UI and parsing etc...
  35
  36 schema
  37    Desktop settings schemas for crypto stuff
  38
  39 testing
  40    Testing CA, gnupg and other mock setups
  41
  42 ----------------------------------------------------------------------------------
  43   CODING STYLE
  44 ----------------------------------------------------------------------------------
  45
  46 Our coding style is very similar to the linux coding style:
  47
  48   http://lxr.linux.no/linux/Documentation/CodingStyle
  49
  50 Summary below. Differences from Linux coding style are marked with a plus
  51 instead of an asterisk:
  52
  53  + Space between function name and parentheses.
  54
  55                 my_function_call (arg1, arg2);
  56
  57  * Braces on the same line as conditional with spaces around braces:
  58
  59                 if (test) {
  60                         do_y ();
  61                         do_z ();
  62                 }
  63
  64                 switch (value) {
  65                 case CONSTANT:
  66                         do_z ();
  67                         break;
  68                 default:
  69                         break;
  70                 }
  71
  72  * Braces around functions on a separate line from function name,
  73    return value on a separate line, arguments on separate lines.
  74
  75                 static void
  76                 my_special_function (int arg1,
  77                                      int arg2)
  78                 {
  79                         /* body of function */
  80                 }
  81
  82  * Don't use braces unnecessarily:
  83
  84                 if (test)
  85                         do_this_thing ();
  86
  87  * But use braces here, when one section has more than a line:
  88
  89                 if (test) {
  90                         do_this_thing ();
  91                 } else {
  92                         do_other_thing ();
  93                         smile_nicely ();
  94                 }
  95
  96  * Use of tabs for 8 char indent.
  97
  98         ------->if (test) {
  99         ------->------->Value;
 100         ------->------->Value;
 101         ------->}
 102
 103  * No trailing whitespace on lines. Git will warn you about this.
 104    Please enforce it like so (in gnome-keyring checkout):
 105
 106         $ cp -ipv .git/hooks/pre-commit.sample .git/hooks/pre-commit
 107
 108  * The '*' in a pointer declaraction belongs with the variable name:
 109
 110         char *name;
 111
 112  + Extra long wrapped lines should wrap to function opening brace
 113    using spaces past indentation point.
 114
 115         ------>my_function_call ("this is a very long argument here",
 116         ------>                  "wrapped argument is indented with spaces");
 117
 118  * Function names are in lower case with _ separators.
 119
 120         this_is_a_long_function_name ();
 121
 122  * Constants are all in upper case with _ separators.
 123
 124         THIS_IS_A_CONSTANT
 125
 126  + Structures should be typedefed to avoid saying 'struct' and names
 127    are CamelCase:
 128
 129         ThisIsAStruct
 130
 131  * One line comments should look like:
 132
 133         /* This is a one line comment */
 134
 135  * Multi line comments should look like:
 136
 137         /*
 138          * This is a multiline comment.
 139          * And it has a useless second line.
 140          */
 141
 142 When in doubt adapt to the style of the code around your patch.