|
| 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 |
0 commit comments