Clean up the doc/HACKING/* docs a bit.
This commit is contained in:
Karsten Loesing
parent
19e10f95c1
commit
f40dc287bd
|
|
@ -122,7 +122,7 @@ using gcc, you should invoke the configure script with the option
|
|||
"--enable-gcc-warnings". This will give a bunch of extra warning flags to
|
||||
the compiler, and help us find divergences from our preferred C style.
|
||||
|
||||
Functions to use; functions not to use.
|
||||
Functions to use; functions not to use
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
We have some wrapper functions like tor_malloc, tor_free, tor_strdup, and
|
||||
|
|
|
|||
|
|
@ -29,7 +29,7 @@ file that comes with the Tor source for more information on building it,
|
|||
and any high-quality guide to C for information on programming.)
|
||||
|
||||
I'm also going to assume that you know a little bit about how to use
|
||||
Git, or that you're able to fillow one of the several excellent guides
|
||||
Git, or that you're able to follow one of the several excellent guides
|
||||
at http://git-scm.org to learn.
|
||||
|
||||
Most Tor developers develop using some Unix-based system, such as Linux,
|
||||
|
|
|
|||
|
|
@ -46,7 +46,7 @@ The preprocessor define __clang_analyzer__ is used to work around instances
|
|||
where clang picks up behavior that we wish to permit.
|
||||
|
||||
clang Runtime Sanitizers
|
||||
~~~~~~~~~~~~~~~~
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
To build the Tor codebase with the clang Address and Undefined Behavior
|
||||
sanitizers, see the file contrib/clang/sanitize_blacklist.txt.
|
||||
|
|
@ -100,7 +100,7 @@ To run all tests, including those based on Stem or Chutney:
|
|||
make test-full
|
||||
-----
|
||||
|
||||
To run all tests, including those basedd on Stem or Chutney that require a
|
||||
To run all tests, including those based on Stem or Chutney that require a
|
||||
working connection to the internet:
|
||||
-----
|
||||
make test-full-online
|
||||
|
|
@ -247,7 +247,7 @@ to clutter the files with emacs stuff.
|
|||
|
||||
|
||||
Doxygen
|
||||
~~~~~~~~
|
||||
~~~~~~~
|
||||
|
||||
We use the 'doxygen' utility to generate documentation from our
|
||||
source code. Here's how to use it:
|
||||
|
|
@ -256,7 +256,7 @@ source code. Here's how to use it:
|
|||
/**
|
||||
* \file filename.c
|
||||
* \brief Short description of the file.
|
||||
**/
|
||||
*/
|
||||
|
||||
(Doxygen will recognize any comment beginning with /** as special.)
|
||||
|
||||
|
|
|
|||
|
|
@ -25,7 +25,7 @@ memory?
|
|||
Do all the new functions, global variables, types, and structure members have
|
||||
documentation?
|
||||
|
||||
Do all the the functions, global variables, types, and structure members with
|
||||
Do all the functions, global variables, types, and structure members with
|
||||
modified behavior have modified documentation?
|
||||
|
||||
Do all the new torrc options have documentation?
|
||||
|
|
|
|||
|
|
@ -70,7 +70,7 @@ git branches too.
|
|||
scripts/maint/updateVersions.pl to update version numbers in other
|
||||
places, and commit. Then merge maint-0.2.x into release-0.2.x.
|
||||
|
||||
(NOTE: TO bump the version number, edit configure.ac, and then run
|
||||
(NOTE: To bump the version number, edit configure.ac, and then run
|
||||
either make, or 'perl scripts/maint/updateVersions.pl', depending on
|
||||
your version.)
|
||||
|
||||
|
|
@ -78,7 +78,7 @@ git branches too.
|
|||
a while to see if anybody has problems building it. Try to get Sebastian
|
||||
or somebody to try building it on Windows.
|
||||
|
||||
6) Get at least two of weasel/arma/sebastian to put the new version number
|
||||
6) Get at least two of weasel/arma/Sebastian to put the new version number
|
||||
in their approved versions list.
|
||||
|
||||
7) Sign the tarball, then sign and push the git tag:
|
||||
|
|
|
|||
|
|
@ -249,7 +249,7 @@ testsupport.h.
|
|||
|
||||
=== Okay but what should my tests actually do?
|
||||
|
||||
We talk above about "test coverage" -- making sure that your tests visit
|
||||
We talk above about "test coverage" -- making sure that your tests visit
|
||||
every line of code, or every branch of code. But visiting the code isn't
|
||||
enough: we want to verify that it's correct.
|
||||
|
||||
|
|
@ -359,7 +359,7 @@ same process as the Tor test program. Reasons for doing this might include:
|
|||
|
||||
* Testing the actual behavior of Tor when run from the command line
|
||||
* Testing that a crash-handler correctly logs a stack trace
|
||||
* Verifying that a violating a sandbox or capability requirement will
|
||||
* Verifying that violating a sandbox or capability requirement will
|
||||
actually crash the program.
|
||||
* Needing to run as root in order to test capability inheritance or
|
||||
user switching.
|
||||
|
|
@ -379,7 +379,7 @@ The 'stem' library includes extensive unit tests for the Tor controller
|
|||
protocol.
|
||||
|
||||
For more information on writing new tests for stem, have a look around
|
||||
the tst/* directory in stem, and find a good example to emulate. You
|
||||
the test/* directory in stem, and find a good example to emulate. You
|
||||
might want to start with
|
||||
https://gitweb.torproject.org/stem.git/tree/test/integ/control/controller.py
|
||||
to improve Tor's test coverage.
|
||||
|
|
|
|||
Loading…
Reference in New Issue