-
-
Notifications
You must be signed in to change notification settings - Fork 60
/
HACKING
109 lines (69 loc) · 3.18 KB
/
HACKING
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
* Don't commit directly, instead make a pull request on GitHub.
Building from git
-----------------
To build from git, or without relying on the generated files in a source
release, automake, autoconf, libtool, pkg-config and git must be installed.
(Note, the exact packages needed for certain distros may be found in
.github/workflows/c-cpp.yml.)
Run
./bootstrap && ./configure --enable-relocatable
to set up and configure the source tree; optional configure arguments can be
supplied as normal.
See INSTALL (which is created by bootstrap) for instructions from this point
on.
Working in libenchant
---------------------
When writing libenchant our priorities are
1) Portable
2) Maintainable & Documented
3) Modular and well designed
When you submit code for inclusion in libenchant, please keep those
things in mind. Performance is not generally an issue: Enchant leaves the
heavy lifting to its spelling providers. Specifically, this means:
- Clarity of design and function are paramount
- Make sure your code does not generate warnings
- Please follow the formatting style
Formatting style
----------------
The formatting style of libenchant is a mix of various styles. Please
follow the style that seems to predominate in any given area of the code base; broadly, there are different styles for the Vala library code, providers and commands, and the tests. The public header files are written in GLib style.
Emacs users should use the supplied .dir-locals.el.
Remember: Use tabs for indentation: that will keep your
code honest as you will be forced to split your routines into more
modular chunks (as detailed by Linus).
On top of that, please in Vala follow the conventions of typical Vala
code, and in C/C++:
- Follow the Gtk+ cleanliness conventions for function
prototypes.
- Follow the Gtk+ namespace convention for function names:
module_submodule_operation
- Do not submit code that is just a temporary workaround for a
full fledged feature. We do not want to maintain limited
features. It is better to submit an implementation designed
to be expanded and enhanced, even if it is not completely
finished.
All of this is to ensure the libenchant code will be kept within
reasonable margins of maintainability for the future: Remember, in two years
you will probably be far too busy to maintain your own contributions, and they
might become a burden to the program maintainers.
libenchant is intended to be a foundation for a various document-centric
projects.
Simplifying code in libenchant is important. Simplifications are almost
always welcome. But please don't reformat code you're not editing, even
where the formatting is inconsistent or ugly, as it makes the history of the
project harder to understand.
API documentation
-----------------
To generate API documentation, run
make doxygen
and open doxygen/html/index.html in a web browser.
Making a release
----------------
To make a release, you'll need woger:
https://github.com/rrthomas/woger
and gh:
https://cli.github.com
Having tested and pushed all the changes, update the version number in
configure.ac and write the NEWS entry and push those too.
Then execute:
make release