Building a distributable binary

dengjen-espeak-rs-sys’s build script compiles eSpeak NG’s data files (dictionaries, voices, phoneme tables) and, since it needs some directory to build into, generates them inside `target/<profile>/build/dengjen-espeak-rs-sys-<hash>/out/…​ — an ephemeral, cache-keyed path that disappears the moment target/ is deleted or the crate is rebuilt with a different hash. Copying only the compiled binary out of target/ and discarding the rest (e.g. cargo build --release followed by rm -rf target) breaks it at runtime with:

To make this easy, the build script bakes that build-cache path into a compile-time constant inside the compiled dengjen-espeak-rs-sys crate, instead of copying data next to the binary. At runtime, dengjen-espeak-rs looks for espeak-ng-data (in this order) in:

So for a plain cargo build --release / cargo run --release on the same machine, it just works — no env var needed, since (2) already resolves to the data baked in during that build.

That baked-in path is only valid on the machine and build cache that produced the binary: it lives under target/, so it disappears the moment target/ is deleted (rm -rf target) or the crate rebuilds with a different build hash, and it never travels if you copy just the binary elsewhere. To ship a binary elsewhere, copy espeak-ng-data alongside it explicitly and point PIPER_ESPEAKNG_DATA_DIRECTORY at it at runtime:

dengjen-espeak-rs-sys-* matches a build-hash suffix that changes across profiles/toolchains; ls -td …​ | head -n1 picks the most recently modified match if more than one such directory exists (stale ones from earlier builds).