Build from Source¶
Prerequisites¶
| Tool | Minimum | Notes |
|---|---|---|
| CMake | 3.16 | |
| C compiler | C99 | GCC or Clang — builds the entire core library, including the optional NATS stream component (libdoppler_stream, vendors nats.c). No C++ compiler is needed anywhere. |
Python extensions
make pyext additionally requires Python 3.9+ with development
headers and NumPy.
Ubuntu / Debian¶
Arch (incl. Manjaro, EndeavourOS, CachyOS)¶
Fedora / RHEL (incl. Rocky, AlmaLinux)¶
openSUSE (Leap / Tumbleweed)¶
macOS¶
Windows¶
The C library builds natively on Windows and its full C test suite passes, with either of clang's two drivers against the MSVC runtime:
| Compiler | How to get it |
|---|---|
clang-cl (MSVC-style driver) |
Visual Studio's C++ Clang tools for Windows component, or LLVM for Windows |
clang (GNU-style driver) |
the same install |
Both also need CMake 3.16+, Ninja, and the Windows SDK (installed with Visual
Studio's C++ workload). MSVC's own cl.exe cannot build doppler: it has
no C99 _Complex, and native/inc/doppler/dp_complex.h stops the build with an
#error saying so.
From a Developer PowerShell for VS (x64), which puts the SDK and linker on the path:
cmake -B build -G Ninja -DCMAKE_BUILD_TYPE=Release -DCMAKE_C_COMPILER=clang-cl
cmake --build build
ctest --test-dir build --output-on-failure
This is the build .github/workflows/windows.yml runs, once per driver, on
every push to main and on pull requests that touch the C. The clang-cl
build is binding (ci.yml's Windows job) and is what every release
publishes as doppler-<version>-windows-x86_64.zip — see
Install the C library → Windows to use it without building.
For Python on Windows, pip install doppler-dsp installs a pre-built wheel;
see Install for Python. On Windows the static library is
doppler_static.lib, because doppler.lib is already the DLL's import
library. The CMake target names (doppler::doppler, doppler::doppler-static)
are the same on every platform.
Not available on Windows yet. These are not ported, and CMake leaves them out of a Windows build rather than failing:
- the NATS stream layer (
libdoppler_stream,dp_pub_*/dp_sub_*), and everything built on it: the wfmStreamSink, thewfmgenCLI anddoppler_wfmgen, and the streaming examples; - the Rust crate, which is built and tested on Linux and macOS only. (The
Python extensions do build on Windows, without
doppler.streamandStreamSink; CI builds and tests them with clang-cl on every PR.) - a few tests of POSIX-only behaviour (signal chaining in
dp_interrupt, a memory soak that readsgetrusage).
Each carve-out is tracked on #1364.
Build¶
Or directly with CMake:
Maximum performance
make blazing adds -march=native to enable all CPU extensions
(AVX2, NEON, SVE, …) for the current machine. Binaries built this
way are not portable to other machines.
CMake options¶
| Option | Default | Description |
|---|---|---|
BUILD_PYTHON |
OFF |
Build Python C extensions (make pyext enables this) |
ENABLE_SIMD |
ON |
SIMD / fast-math flags (disable for strict portability) |
Python3_EXECUTABLE |
auto | Override Python interpreter (ensures correct ABI suffix) |
Example — build Python extensions against a specific interpreter:
cmake -B build -S . \
-DCMAKE_BUILD_TYPE=Release \
-DBUILD_PYTHON=ON \
-DPython3_EXECUTABLE="$(which python3)"
cmake --build build --parallel
Make targets¶
| Target | Description |
|---|---|
make |
Configure + build (Release) |
make pyext |
Build Python extensions into src/doppler/ |
make test |
Run CTest suite (requires make pyext first) |
make test-python |
Run pytest |
make test-all |
CTest + pytest + example smoke tests |
make test-rust |
Build C library + run Rust FFI tests |
make bench |
Run C + Python benchmarks on this machine |
make debug |
Clean + Debug build |
make release |
Clean + Release build |
make blazing |
Clean + Release + -march=native |
make clean |
Remove build/ and compiled .so files |
make help |
Show all targets and overrides |