Building

Requirements

  • CMake 3.14+
  • A C++17 compiler (GCC or Clang) with a working C compiler alongside it
  • Git — CLI11 and CaDiCaL are fetched and built from source automatically
  • Linux. The runtime plugin loader (see {doc}architecture) uses /proc/self/exe and dlopen, so this build is currently Linux-only.

Build

mkdir build && cd build
cmake ..
make

This produces two binaries in build/:

  • just_count — the CLI tool
  • test_counter — the test suite (run via ctest or directly)

as well as a build/cadical-plugins/ directory containing one shared library per bundled CaDiCaL version (see {doc}architecture).

What happens during the build

CMakeLists.txt:

  1. Runs git describe --always --dirty --tags at configure time and bakes the result into a generated version.h, alongside the default bundled CaDiCaL version — this is what just_count --version and the startup banner report.
  2. Fetches CLI11 via FetchContent for command-line parsing.
  3. For each entry in CADICAL_VERSIONS / CADICAL_TAGS (currently 3.0.0, 2.2.1, 1.9.5 — the first entry is the default; see {doc}investigation for why), builds that CaDiCaL release from source with CFLAGS=-fPIC CXXFLAGS=-fPIC ./configure && make, then links it into its own small shared-library plugin.
  4. Builds just_count and test_counter against counter_lib, which contains no CaDiCaL code at all — only the runtime plugin loader.

Building three full CaDiCaL source trees takes a few minutes the first time; incremental rebuilds after touching only just_count’s own sources are fast.

Adding another bundled CaDiCaL version

Add its version number and git tag to the parallel CADICAL_VERSIONS / CADICAL_TAGS lists near the top of CMakeLists.txt and reconfigure — add_cadical_plugin() handles building and wiring up the new plugin. If the new version changes the freeze/add/solve/val/set signatures used by src/cadical_plugin_impl.cpp, that file needs a matching update.

Running the tests

cd build
ctest --output-on-failure
# or directly:
./test_counter