Kaldi C++ Build System ↔ Docker / Conda

Kaldi C++ Build System ↔ Docker / Conda

When setting up a repeatable Kaldi development environment, teams often choose between building the native C++ code inside a Docker container or encapsulating dependencies in a Conda environment. The goal is to produce identical binaries and ensure that the online2 feature‑extraction pipeline behaves consistently across both setups. However, the current documentation does not clarify whether the binaries built in Docker are ABI‑compatible with those built in Conda on the same host, nor does it describe how differing OpenFst optimization flags affect numerical stability.

Key constraints include:

• Docker images provided by the community are not officially maintained and may lag behind source releases.
• Conda packages for Kaldi are sparse, often requiring manual recipe creation.
• Compiler flags and library versions (e.g., OpenFst, MKL) can differ between environments.

Given these uncertainties, the unresolved decision is whether a Docker‑based or Conda‑based environment is preferable for continuous integration pipelines that demand reproducible Kaldi binaries.

Specific questions:

1. Will the binaries built in Docker be ABI‑compatible with those built in Conda on the same host?
2. Does the optimization level used when compiling OpenFst alter the numerical output of the online2 pipeline in a Docker versus Conda build?
3. Which environment—Docker or Conda—provides a more reliable path for CI pipelines to produce reproducible Kaldi binaries?