Skip to content

Commit d7cf45e

Browse files
author
Michi Henning
committed
More build env scaffolding.
1 parent 4c8f38d commit d7cf45e

File tree

8 files changed

+121
-1
lines changed

8 files changed

+121
-1
lines changed

CMakeLists.txt

+1
Original file line numberDiff line numberDiff line change
@@ -77,6 +77,7 @@ enable_testing()
7777

7878
include(EnableCoverageReport)
7979

80+
add_subdirectory(src)
8081
add_subdirectory(tests)
8182

8283
enable_coverage_report(

HACKING

+117
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,117 @@
1+
Building the code
2+
-----------------
3+
4+
By default, the code is built in release mode. To build a debug version, use
5+
6+
$ mkdir builddebug
7+
$ cd builddebug
8+
$ cmake -DCMAKE_BUILD_TYPE=debug ..
9+
$ make
10+
11+
For a release version, use -DCMAKE_BUILD_TYPE=release
12+
13+
14+
Running the tests
15+
-----------------
16+
17+
$ make
18+
$ make test
19+
20+
Note that "make test" alone is dangerous because it does not rebuild
21+
any tests if either the library or the test files themselves need
22+
rebuilding. It's not possible to fix this with cmake because cmake cannot
23+
add build dependencies to built-in targets. To make sure that everything
24+
is up-to-date, run "make" before running "make test"!
25+
26+
To run the tests with valgrind:
27+
28+
$ make valgrind
29+
30+
It doesn't make sense for some tests to run them with valgrind. For
31+
example, the header compilation tests don't need valgrind because
32+
we'd just be testing that Python doesn't leak. There are also some
33+
tests that run too slow and time out under valgrind and, occasionally,
34+
valgrind crashes for a particular test.
35+
36+
There are two ways to suppress tests:
37+
38+
You can add a test name to CTestCustom.cmake.in to suppress that
39+
test completely. That makes sense for the header compilation tests,
40+
for example.
41+
42+
If a specific test case in a test program causes a valgrind problem,
43+
you can selectively disable a section of code like this:
44+
45+
#include <valgrind/valgrind.h>
46+
47+
if (!RUNNING_ON_VALGRIND)
48+
{
49+
// Code here crashes valgrind...
50+
}
51+
52+
That way, the test will still be run as part of the normal "make test"
53+
target, but will be ommitted when running "make valgrind".
54+
55+
56+
Coverage
57+
--------
58+
59+
To build with the flags for coverage testing enabled and get coverage:
60+
61+
$ mkdir buildcoverage
62+
$ cd buildcoverage
63+
$ cmake -DCMAKE_BUILD_TYPE=coverage
64+
$ make
65+
$ make test
66+
$ make coverage
67+
68+
Unfortunately, it is not possible to get 100% coverage for some files,
69+
mainly due to gcc's generation of two destructors for dynamic and non-
70+
dynamic instances. For abstract base classes and for classes that
71+
prevent stack and static allocation, this causes one of the destructors
72+
to be reported as uncovered.
73+
74+
There are also issues with some functions in header files that are
75+
incorrectly reported as uncovered due to inlining, as well as
76+
the impossibility of covering defensive assert(false) statements,
77+
such as an assert in the default branch of a switch, where the
78+
switch is meant to handle all possible cases explicitly.
79+
80+
If you run a binary and get lots of warnings about a "merge mismatch for summaries",
81+
this is caused by having made changes to the source that add or remove code
82+
that was previously run, so the new coverage output cannot sensibly be merged
83+
into the old coverage output. You can get rid of this problem by running
84+
85+
$ make clean-coverage
86+
87+
This deletes all the .gcda files, allowing the merge to (sometimes) succeed again.
88+
If this doesn't work either, the only remedy is to do a clean build.
89+
90+
91+
Code style
92+
----------
93+
94+
Please maintain the existing coding style. For details
95+
on the style, see lp:canonical-client-development-guidelines.
96+
97+
We use a format tool that fixes a whole lot of issues
98+
regarding code style. See the HACKING file of lp:unity-scopes-api
99+
for details on the tool.
100+
101+
102+
Undefined behavior and address sanitizer
103+
----------------------------------------
104+
105+
Set SANITIZER to "ub" or "address" to build with the
106+
corresponding sanitizer enabled.
107+
108+
If a test runs too slowly under address sanitizer, you can
109+
hide a section of code from address sanitzer with:
110+
111+
#if defined(__has_feature)
112+
#if !__has_feature(address_sanitizer)
113+
114+
// Code here takes forever under address sanitizer...
115+
116+
#endif
117+
#endif

debian/changelog

+1-1
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,4 @@
1-
storage-framework (VERSION) UNRELEASED; urgency=medium
1+
storage-framework (0.0.1) UNRELEASED; urgency=medium
22

33
* Initial release.
44

src/CMakeLists.txt

+1
Original file line numberDiff line numberDiff line change
@@ -0,0 +1 @@
1+
add_subdirectory(client)

src/client/CMakeLists.txt

+1
Original file line numberDiff line numberDiff line change
@@ -0,0 +1 @@
1+
add_subdirectory(internal)

src/client/internal/CMakeLists.txt

Whitespace-only changes.

ubsan-suppress

Whitespace-only changes.

valgrind-suppress

Whitespace-only changes.

0 commit comments

Comments
 (0)