* HACKING: Update various bits.
This commit is contained in:
parent
6f3208a783
commit
332f830d58
1 changed files with 24 additions and 25 deletions
45
HACKING
45
HACKING
|
|
@ -86,30 +86,29 @@ Avoiding org-mode runs
|
||||||
The files in doc/org/ are org-mode files (a mode of Emacs that we use
|
The files in doc/org/ are org-mode files (a mode of Emacs that we use
|
||||||
to author documents that embed executable snippets), they are used to
|
to author documents that embed executable snippets), they are used to
|
||||||
generate the doc/userdoc/ HTML documentation. If for some reason you
|
generate the doc/userdoc/ HTML documentation. If for some reason you
|
||||||
don't have emacs, or you simply want not to rebuild these files, use
|
don't have emacs, or you simply want not to rebuild these files, use:
|
||||||
another "magic touch":
|
|
||||||
|
|
||||||
touch doc/org-stamp
|
% touch doc/org-stamp
|
||||||
|
|
||||||
|
|
||||||
Silent Building with automake
|
Silent Building with automake
|
||||||
-----------------------------
|
-----------------------------
|
||||||
|
|
||||||
The classical makefiles generated by automake are very verbose during
|
The classical makefiles generated by automake are very verbose during
|
||||||
build beacause they prints the full command line of every stage. This
|
build beacause they print the full command line of every stage. This
|
||||||
verbosity is very usefull to help (remotely) users to compile
|
verbosity is very usefull to help (remotely) users to compile Spot.
|
||||||
Spot. Nonetheless, for developpers, these compilations lines may be
|
Nonetheless, these compilations lines may be annoying for some
|
||||||
annoying. To reduce this verbosity, just run:
|
developers. To reduce this verbosity, just run:
|
||||||
|
|
||||||
make V=0
|
% make V=0
|
||||||
|
|
||||||
|
|
||||||
Executing a single test
|
Executing a single test
|
||||||
-----------------------
|
-----------------------
|
||||||
|
|
||||||
All tests in subdirectories of tests/ are executed through the
|
All tests in subdirectories of tests/ are executed through the
|
||||||
tests/run script. That run script defines PATH and other environment
|
tests/run script. That script defines PATH and other environment
|
||||||
variables necessary so that Shell and Python scripts will use the
|
variables necessary so that shell and Python scripts will use the
|
||||||
version of Spot under development. For instance to execute
|
version of Spot under development. For instance to execute
|
||||||
tests/core/acc.test, do:
|
tests/core/acc.test, do:
|
||||||
|
|
||||||
|
|
@ -216,20 +215,19 @@ Finally generate a coverage report in HTML:
|
||||||
|
|
||||||
This should create the directory html/.
|
This should create the directory html/.
|
||||||
|
|
||||||
|
Coverage tests are automatically performed by our continuous
|
||||||
|
integration builds. You can find a report for each branch in the
|
||||||
|
artifacts of the debian-unstable-gcc-coverage job.
|
||||||
|
|
||||||
|
|
||||||
Link-time optimizations
|
Link-time optimizations
|
||||||
-----------------------
|
-----------------------
|
||||||
|
|
||||||
This is currently a bit tricky to setup, because the toolchain is not
|
This used to be bit tricky to setup, but is now quite well supported.
|
||||||
mature enough. However this is getting better and better. The Debian
|
Our Debian packages are built with link-time optimization.
|
||||||
packages we build nightly are mostly built with link-time optimization
|
|
||||||
(the shared library uses link-time optimization, but the command-line
|
|
||||||
binary are built without because of some bug with exception
|
|
||||||
propagation).
|
|
||||||
|
|
||||||
|
|
||||||
You need:
|
You need:
|
||||||
1. a version of GCC (>= 4.9) with gold and pluing linker enabled.
|
1. a version of GCC (>= 4.9) with gold and pluging linker enabled.
|
||||||
2. a version of Libtool that knows how to deal with
|
2. a version of Libtool that knows how to deal with
|
||||||
-flto flags (Libtool 2.4.2 will work)
|
-flto flags (Libtool 2.4.2 will work)
|
||||||
|
|
||||||
|
|
@ -250,9 +248,9 @@ Log driver for testsuite
|
||||||
|
|
||||||
The PASS/FAIL status for each test of the testsuite is printed by
|
The PASS/FAIL status for each test of the testsuite is printed by
|
||||||
tools/test-driver. This script can be changed to format the output
|
tools/test-driver. This script can be changed to format the output
|
||||||
differently. When we use Teamcity (for continuous integration) we
|
differently. In the past, when we used teamcity (for continuous
|
||||||
change the output format to something that Teamcity will understand
|
integration) we changed the output format to something that teamcity
|
||||||
with:
|
would understand with:
|
||||||
|
|
||||||
make check LOG_DRIVER=$PWD/tools/test-driver-teamcity
|
make check LOG_DRIVER=$PWD/tools/test-driver-teamcity
|
||||||
|
|
||||||
|
|
@ -402,8 +400,9 @@ Comments
|
||||||
Issue #123 / issue #123 / Fixes #123 / fixes #123
|
Issue #123 / issue #123 / Fixes #123 / fixes #123
|
||||||
|
|
||||||
(When gitlab sees a commit message containing "Fixes #123" or
|
(When gitlab sees a commit message containing "Fixes #123" or
|
||||||
"fixes #123" pushed to branch "next", it will automatically close
|
"fixes #123" pushed to branch "next", it should automatically
|
||||||
the issue.)
|
close the issue. But these days, it does not seem to work and
|
||||||
|
often require manual closing.)
|
||||||
|
|
||||||
Formating
|
Formating
|
||||||
---------
|
---------
|
||||||
|
|
|
||||||
Loading…
Add table
Add a link
Reference in a new issue