Mercurial > hgrepos > Python2 > PyMuPDF

comparison mupdf-source/thirdparty/zint/backend/tests/README @ 2:b50eed0cc0ef upstream

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
ADD: MuPDF v1.26.7: the MuPDF source as downloaded by a default build of PyMuPDF 1.26.4. The directory name has changed: no version number in the expanded directory now.
author Franz Glasner <fzglas.hg@dom66.de>
date Mon, 15 Sep 2025 11:43:07 +0200
parents
children
comparison
equal deleted inserted replaced
1:1d09e1dec1d9 2:b50eed0cc0ef
1 % backend/tests/README 2024-11-18
2
3 Zint backend test suite
4 -----------------------
5
6 In order to build the zint test suite, zint has to be compiled with the
7 ZINT_TEST option enabled:
8
9 cd <project-dir>
10 mkdir build
11 cd build
12 cmake -DZINT_TEST=ON ..
13 cmake --build .
14
15 When using generators that support multiple build configurations, such as
16 Visual C++ Project Files (the default generator on win32), the configuration
17 can be provided via --config:
18
19 cd <project-dir>
20 mkdir build
21 cd build
22 cmake -DZINT_TEST=ON -DCMAKE_BUILD_TYPE=Debug ..
23 cmake --build . --config Debug
24
25 Note specifying a matching CMAKE_BUILD_TYPE is required to set the test PATH
26 environment for Windows.
27
28 ------------------------------------------------------------------------------
29
30 In order to run the test suite, the path of the zint library may need to be
31 communicated to the runtime linker. On UNIX-like systems, this is done by
32 exporting LD_LIBRARY_PATH to the path containing the zint library, which is
33 <build-dir>/backend:
34
35 cd <project-dir>
36 cd build
37 export LD_LIBRARY_PATH=$(pwd)/backend
38
39 Setting LD_LIBRARY_PATH is not required if the zint library to be tested is
40 installed into a system library path ( /usr/lib for example ) prior to running
41 the tests, or if the tests are not run individually.
42
43 (On Windows, the PATH may need to be set to include the DLL location.)
44
45 ------------------------------------------------------------------------------
46
47 To run all tests (within <build-dir>):
48
49 ctest
50
51 When using a generator that does support multiple build configurations, the
52 configuration that was used to build the project has to be explicitly provided
53 to ctest, even if it was the default one:
54
55 ctest -C Debug
56
57 For various useful options, e.g. matching (-R) and excluding (-E) tests, see
58 https://cmake.org/cmake/help/latest/manual/ctest.1.html#options
59
60 Tests can also be run individually, eg:
61
62 backend/tests/test_common
63 backend/tests/test_vector
64
65 To run a single test function within an individual test, use '-f <func-name>':
66
67 backend/tests/test_common -f utf8_to_unicode
68 backend/tests/test_dotcode -f input
69
70 To exclude a single test function, use '-n <func-name>':
71
72 backend/tests/test_common -n utf8_to_unicode
73 backend/tests/test_dotcode -n input
74
75 To run all test functions that match (i.e. contain) a string, use '-m <string>':
76
77 backend/tests/test_common -m not_sane
78 backend/tests/test_dotcode -m encode
79
80 To run a single dataset item in a single test function, use '-i <index>':
81
82 backend/tests/test_dotcode -f input -i 2
83
84 To run a range of dataset items in a single test function, use '-i <start>-<end>':
85
86 backend/tests/test_dotcode -f input -i 2-5
87
88 The '<start>' or '<end>' can be left out:
89
90 backend/tests/test_dotcode -f input -i 2-
91
92 To exclude a single dataset item in a single test function, use '-x <index>':
93
94 backend/tests/test_dotcode -f input -x 4
95
96 This can also take a range, '-x <start>-<end>':
97
98 backend/tests/test_dotcode -f input -x 4-6
99
100 Exclude can be used multiple times (unlike '-i'):
101
102 backend/tests/test_dotcode -f input -x 4 -x 6-8
103
104 The include and exclude options can be used together:
105
106 backend/tests/test_dotcode -f input -i 2-7 -x 4 -x 6
107
108 To show debug info (if any), use '-d <flag>':
109
110 backend/tests/test_dotcode -f input -i 2 -d 1
111
112 E.g. to print which dataset items are being run, use '-d 16':
113
114 backend/tests/test_dotcode -f input -d 16 -i 2
115
116 (for other flags see <project-dir>/backend/tests/testcommon.h)
117
118 To run a test against BWIPP (if any), use '-d 128':
119
120 backend/tests/test_composite -d 128
121
122 (see also <project-dir>/backend/tests/tools/run_bwipp_tests.sh)
123
124 To run a test against ZXing-C++ (if any), use '-d 512':
125
126 backend/tests/test_rss -d 512
127
128 (see also <project-dir>/backend/tests/tools/run_zxingcpp_tests.sh)
129
130 To generate test data (if available), use '-g':
131
132 backend/tests/test_dotcode -f encode -g
133
134 ------------------------------------------------------------------------------
135
136 If the zint library was built with static linkage support, i.e. ZINT_STATIC
137 is ON, an additional test executable, which uses the zint-static library, will
138 be built. The static variant of each test shares the test name, but has a
139 "-static" suffix. For example,
140
141 backend/tests/test_dotcode
142
143 would run the dotcode test that uses the shared zint library, while
144
145 backend/tests/test_dotcode-static
146
147 runs the same test built against the zint-static library.
148
149 ------------------------------------------------------------------------------
150
151 To make with gcc sanitize, first set for libzint and make:
152
153 cd <project-dir>
154 cd build
155 cmake -DZINT_SANITIZE=ON ..
156 make && sudo make install
157
158 Similarly to make with gcc debug:
159
160 cd <project-dir>
161 cd build
162 cmake -DZINT_DEBUG=ON ..
163 make && sudo make install
164
165 To undo sanitize/debug, remake each after setting:
166
167 cmake -DZINT_SANITIZE=OFF ..
168 cmake -DZINT_DEBUG=OFF ..
169
170 To get a clean libzint, set the above and also:
171
172 cmake -DZINT_TEST=OFF ..
173
174 (The tests will now fail to link.)
175