ruby-prism-sys: cross-compilation fails out of the box; consider pregenerated bindings

[sorafujitani]

ruby-prism-sys runs both cc and bindgen at build time. When host != target, clang gets --target but no target sysroot, so it parses host headers and fails.

Reproduction (macOS arm64 host)

$ cargo new xrepro --lib && cd xrepro
$ cargo add ruby-prism@1.9
$ rustup target add x86_64-unknown-linux-gnu
$ cargo build --target x86_64-unknown-linux-gnu

vendor/prism-1.9.0/include/prism/defines.h:12:10: fatal error: 'ctype.h' file not found
failed to build Prism from source

In environments where the C toolchain is configured per target (rake-compiler-dock, building precompiled Ruby gems), the C stage succeeds and the same failure moves to bindgen:

/usr/include/features.h:461:12: fatal error: 'sys/cdefs.h' file not found
Unable to generate prism bindings: ClangDiagnostic(...)

Suggestion

#4169 (unreleased) adds RUBY_PRISM_CFLAGS, and CFLAGS_<target> / BINDGEN_EXTRA_CLANG_ARGS_<target> already work — but all of these require users to discover and hardcode per-target sysroot paths.

Would you consider shipping pregenerated bindings (run bindgen at release time, like most -sys crates)? Prism's public API is largely fixed-width types, so the bindings should be target-independent. Cross-compilation would then work out of the box, and the libclang build requirement would go away.

[sorafujitani]

if the problem formulation is correct, i'd like to move on to implementation.

[sorafujitani]

Workaround confirmed for rake-compiler-dock cross builds (all 7 platforms): the rb-sys images already ship correct per-target sysroot flags as BINDGEN_EXTRA_CLANG_ARGS_<target_with_underscores>, but the bindgen invocation in ruby-prism-sys 1.9.0 only picks up the dashed-triple form, which shells cannot export. Bridging through Cargo's [env] config works:

# .cargo/config.toml, generated before the build
[env]
"BINDGEN_EXTRA_CLANG_ARGS_aarch64-apple-darwin" = "--sysroot=/opt/osxcross/target/SDK/MacOSX11.1.sdk/"

Generation script for reference: https://github.com/sorafujitani/rfmt/blob/feat/ruby-prism-spike/scripts/ci/cross_env.sh — pregenerated bindings would still remove the need for any of this.

[kddnewton]

Can you show me some prior art on other *-sys crates so I can understand the bindgen at release time path? I just want to make sure I understand.

At the same time, if you want to work on setting that up, I think that's a good way to go.

[sorafujitani]

@kddnewton
bindgen at release time in practice means: commit the generated bindings, and regenerate them only when the vendored headers change.
prior art

• libsqlite3-sys: pregenerated bindings shipped; build-time bindgen is opt-in via the buildtime_bindgen feature
• zstd-sys: bindings.rs committed, maintainers regenerate with update_bindings.sh; bindgen feature opts back in
• linux-raw-sys: "bindings are generated offline, rather than in a build.rs, making downstream builds simpler"

prism current bindgen output uses only fixed-width types and ::std::os::raw::* aliases, with no layout-test assertions, so one pregenerated file works for all targets (CI can verify by regenerating and diffing).