forked from libcheck/check
-
Notifications
You must be signed in to change notification settings - Fork 0
/
HACKING
197 lines (140 loc) · 5.75 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
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
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
Coding Standards
================
Please try and stick to the GNU coding standards. A lot of hard work
went into making Check compatible with the standards, and would be
nice if that work didn't erode. I decided on the standards because
they work well for a lot of programs much bigger than Check. Ok,
since you're wondering, the advantages of sticking to the standards
are three-fold:
1) consistent style within the project
2) being familiar with the standards lets you work on lots of
different GNU standards-compliant projects pretty easily
3) it reduces the number of decisions that must be made
Doxygen Reference for Development
================
You can use `doc/doxygen-devel` target to generate a verbose doxygen reference.
Resulting documentation will be placed into `doc/doxygen-devel`. This option
needs graphviz installed to render call graphs. If graphviz is not found they
won't be rendered.
Release Process
===============
To create a release one will need to be a member of the libcheck organization
on GitHub. If you are not a member, a current member can add you
by going to:
https://github.com/orgs/libcheck/people
and submitting an invite.
1) To create a release, start in a configured in-place
checkout of the Check project:
$ git clone https://github.com/libcheck/check.git
$ cd check
2) Determine the version of Check to release, and update
the configure.ac script:
AC_INIT([Check], [0.10.1], [check-devel at lists dot sourceforge dot net])
CHECK_MAJOR_VERSION=0
CHECK_MINOR_VERSION=10
CHECK_MICRO_VERSION=1
(Remember to update both the AC_INIT line and each of the CHECK_*_VERSION fields).
3) Update the header in the NEWS file to mention the release:
Sun Aug 2, 2015: Released Check 0.10.1
2015-08-02 19:21:14 +0000
based on hash f399542eeceb97703bca496b68bb39044e8baa01
4) Update index.html mentioning the release. Look for the following:
<!-- Update this section during a release -->
5) Attempt to build the release locally
$ autoreconf -i
$ ./configure
$ make distcheck
If this passes, a tarball with the current release number will be in the current
directory. Make note of this, as it will be uploaded to GitHub later.
6) Commit the changes to configure.ac, NEWS, and index.html to the Check project's
master branch, with the commit message:
"Update for release"
7) Log On to GitHub and navigate to:
https://github.com/libcheck/check/releases
Click "Draft a New Release".
Enter the release version to the Tag Version box, and enter the
git hash into the Target selector.
Fill in the Release Title field.
Describe the release with something similar to the following:
=====
<some sentence about the release, e.g. "This is a bug fix release.">
Please test it out and report any problems you might have.
Changes:
<paste contents of NEWS here for the release>
=====
Attach the tarball for the release, then publish the release.
8) Use the following template to announce the release via email:
=====
Subject: check-X.Y.Z released
Hi,
<some sentence about the release, e.g. "This is a bug fix release.">
Please test it out and report any problems you might have.
https://github.com/libcheck/check/releases
Thanks,
`whoami`
<paste contents of NEWS for the release here>
=====
9) Update the development header in the NEWS file and commit the result.
10) Push updated website (see section below)
Congratulations, you are done!
Update website
==============
The Check website is automatically hosted from the contents of
the gh-pages branch in the Check git repository. To update
the website, merge the contents of the master branch into
the gh-pages branch.
To update the generated documentation for the website:
$ git remote -v
github https://github.com/libcheck/check.git (fetch)
github https://github.com/libcheck/check.git (push)
$ git fetch github
$ git checkout github/gh-pages -b gh-pages
Branch gh-pages set up to track remote branch gh-pages from github.
Switched to a new branch 'gh-pages'
$ git merge github/master
First, rewinding head to replay your work on top of it...
Fast-forwarded gh-pages to github/master.
$ autoreconf -i
$ ./configure
$ make clean
$ make
$ make doc/check_html
$ make doc/doxygen
$ git add doc
$ git commit -m “Update documentation”
$ git push github gh-pages:gh-pages
Automatic building of pull requests
===============
The GitHub project is configured to build requests automatically.
This is done using GitHub Actions and AppVeyor. GitHub Actions is
configured to build and test against Linux, macOS, and Windows, using
the configurations under:
.github/workflows
AppVeyor builds and tests Check for Windows, using the configuration
in appveyor.yml. These are started automatically on pull requests,
and the results are reported in the pull request when finished.
Using gcov
===============
The gcov tool can be used to determine the unit test coverage in Check
itself. This is currently supported on GNU/Linux only. To enable the
necessary build time flags, add the following argument to the
configure script:
--enable-gcov
Once the unit tests have been run with
$ make check
assuming the terminal is in the top src directory, the following will
generate summary information using gcov:
$ cp src/*.c src/.libs/
$ cd src/.libs
$ for file in `ls *.c`; do
gcov -f $file > $file.gcov.summary.txt
mv $file.gcov $file.gcov.txt
done
The *.gcov.txt files will contain the source code annotated with
the number of times each line was executed. The .*gcov.summary.txt
files will contain a line execution summary per function.
To determine the line execution summary for all of Check, either
the gcovr tool can be used, or the following quick-and-dirty script:
$ for file in ls *.summary.txt; do cat $file; done \
| grep "Lines executed" | cut -d ":" -f 2 | tr -d "%" \
| awk '{checked+=$1*$3/100; total+=$3} END {print checked/total*100}'