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

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
line wrap: on
line diff
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/mupdf-source/thirdparty/zint/backend/tests/README	Mon Sep 15 11:43:07 2025 +0200
@@ -0,0 +1,175 @@
+% backend/tests/README 2024-11-18
+
+Zint backend test suite
+-----------------------
+
+In order to build the zint test suite, zint has to be compiled with the
+ZINT_TEST option enabled:
+
+  cd <project-dir>
+  mkdir build
+  cd build
+  cmake -DZINT_TEST=ON ..
+  cmake --build .
+
+When using generators that support multiple build configurations, such as
+Visual C++ Project Files (the default generator on win32), the configuration
+can be provided via --config:
+
+  cd <project-dir>
+  mkdir build
+  cd build
+  cmake -DZINT_TEST=ON -DCMAKE_BUILD_TYPE=Debug ..
+  cmake --build . --config Debug
+
+Note specifying a matching CMAKE_BUILD_TYPE is required to set the test PATH
+environment for Windows.
+  
+------------------------------------------------------------------------------
+
+In order to run the test suite, the path of the zint library may need to be
+communicated to the runtime linker. On UNIX-like systems, this is done by
+exporting LD_LIBRARY_PATH to the path containing the zint library, which is
+<build-dir>/backend:
+
+  cd <project-dir>
+  cd build
+  export LD_LIBRARY_PATH=$(pwd)/backend
+
+Setting LD_LIBRARY_PATH is not required if the zint library to be tested is
+installed into a system library path ( /usr/lib for example ) prior to running
+the tests, or if the tests are not run individually.
+
+(On Windows, the PATH may need to be set to include the DLL location.)
+
+------------------------------------------------------------------------------
+
+To run all tests (within <build-dir>):
+
+  ctest
+
+When using a generator that does support multiple build configurations, the
+configuration that was used to build the project has to be explicitly provided
+to ctest, even if it was the default one:
+
+  ctest -C Debug
+
+For various useful options, e.g. matching (-R) and excluding (-E) tests, see
+https://cmake.org/cmake/help/latest/manual/ctest.1.html#options
+
+Tests can also be run individually, eg:
+
+  backend/tests/test_common
+  backend/tests/test_vector
+
+To run a single test function within an individual test, use '-f <func-name>':
+
+  backend/tests/test_common -f utf8_to_unicode
+  backend/tests/test_dotcode -f input
+
+To exclude a single test function, use '-n <func-name>':
+
+  backend/tests/test_common -n utf8_to_unicode
+  backend/tests/test_dotcode -n input
+
+To run all test functions that match (i.e. contain) a string, use '-m <string>':
+
+  backend/tests/test_common -m not_sane
+  backend/tests/test_dotcode -m encode
+
+To run a single dataset item in a single test function, use '-i <index>':
+
+  backend/tests/test_dotcode -f input -i 2
+
+To run a range of dataset items in a single test function, use '-i <start>-<end>':
+
+  backend/tests/test_dotcode -f input -i 2-5
+
+The '<start>' or '<end>' can be left out:
+
+  backend/tests/test_dotcode -f input -i 2-
+
+To exclude a single dataset item in a single test function, use '-x <index>':
+
+  backend/tests/test_dotcode -f input -x 4
+
+This can also take a range, '-x <start>-<end>':
+
+  backend/tests/test_dotcode -f input -x 4-6
+
+Exclude can be used multiple times (unlike '-i'):
+
+  backend/tests/test_dotcode -f input -x 4 -x 6-8
+
+The include and exclude options can be used together:
+
+  backend/tests/test_dotcode -f input -i 2-7 -x 4 -x 6
+
+To show debug info (if any), use '-d <flag>':
+
+  backend/tests/test_dotcode -f input -i 2 -d 1
+
+E.g. to print which dataset items are being run, use '-d 16':
+
+  backend/tests/test_dotcode -f input -d 16 -i 2
+
+(for other flags see <project-dir>/backend/tests/testcommon.h)
+
+To run a test against BWIPP (if any), use '-d 128':
+
+  backend/tests/test_composite -d 128
+
+(see also <project-dir>/backend/tests/tools/run_bwipp_tests.sh)
+
+To run a test against ZXing-C++ (if any), use '-d 512':
+
+  backend/tests/test_rss -d 512
+
+(see also <project-dir>/backend/tests/tools/run_zxingcpp_tests.sh)
+
+To generate test data (if available), use '-g':
+
+  backend/tests/test_dotcode -f encode -g
+
+------------------------------------------------------------------------------
+
+If the zint library was built with static linkage support, i.e. ZINT_STATIC
+is ON, an additional test executable, which uses the zint-static library, will
+be built. The static variant of each test shares the test name, but has a
+"-static" suffix. For example,
+
+  backend/tests/test_dotcode
+
+would run the dotcode test that uses the shared zint library, while
+
+  backend/tests/test_dotcode-static
+
+runs the same test built against the zint-static library.
+
+------------------------------------------------------------------------------
+
+To make with gcc sanitize, first set for libzint and make:
+
+  cd <project-dir>
+  cd build
+  cmake -DZINT_SANITIZE=ON ..
+  make && sudo make install
+
+Similarly to make with gcc debug:
+
+  cd <project-dir>
+  cd build
+  cmake -DZINT_DEBUG=ON ..
+  make && sudo make install
+
+To undo sanitize/debug, remake each after setting:
+
+  cmake -DZINT_SANITIZE=OFF ..
+  cmake -DZINT_DEBUG=OFF ..
+
+To get a clean libzint, set the above and also:
+
+  cmake -DZINT_TEST=OFF ..
+
+(The tests will now fail to link.)
+