1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
|
Contributing to GCR, GCK libraries
==================================
Code merging
------------
This is the work flow for modifying the gcr repository:
1. File a bug for the given flaw or feature (if it does not already exist) at
https://gitlab.gnome.org/GNOME/gcr/issues.
2. Create a fork of the main repository on gitlab.gnome.org (if you haven't
already) and commit your work there.
3. If this is a non-trivial flaw or feature, write test cases. We won't accept
significant changes without adequate test coverage.
4. Write code to fix the flaw or add the feature. In the case that tests are
necessary, the new tests must pass consistently.
5. All code must follow the project coding style (see below).
6. Make a Merge Request from your fork to the main gcr repository.
7. The project must remain buildable with all meson options and pass all
tests on all platforms. It should also pass the CI.
8. Rework your code based on suggestions in the review and submit new patches.
Return to the review step as necessary.
9. Finally, if everything is reviewed and approved, a maintainer will merge it
for you. Thanks!
Repository Structure
--------------------
* egg: Various bits of code shared with other modules (private)
* gck: A public library for accessing PKCS#11 modules.
* gcr: A public library for bits of crypto and parsing etc...
* ui: A public library that provides a GTK UI for several objects in gcr.
* schema: Desktop settings schemas for crypto stuff
* testing: Testing CA, gnupg and other mock setups
* po: Contains translation files
Coding style
------------
Our coding style is very similar to the linux coding style:
http://lxr.linux.no/linux/Documentation/CodingStyle
+ 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.
* The '*' in a pointer declaration 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.
|
