Commit f1f1a850 authored by Niels De Graef's avatar Niels De Graef 😁
Browse files

Rename HACKING to CONTRIBUTING.md

This makes it show up in the GitLab UI, and is a bit more user-friendly
as the markdown will be rendered.
parent 9117536d
Pipeline #247530 passed with stages
in 6 minutes and 16 seconds
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.
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.
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment