Prior to this, wstp-sys has been using bindings to wstp.h that were
pre-generated. This required using the generate-versioned-bindings.rs
script to create a new file for each {<System ID>, <Wolfram Language version>}
combination that wstp-sys wanted to support. This was fragile and time
consuming, and inevitably always out of date.
Using pre-generated bindings made some sense before
wolfram-app-discovery was written, but it makes little sense now.
There is a small compile-time tradeoff to doing this: the compile time
of wstp-sys now includes the time needed to compile the new bindgen
dependency, and the time to use bindgen to generate the WSTP Rust
bindings file. However, the maintenance and "it actually works" benefits
I think outweigh that consideration.
I've left the pre-generated bindings files and code in place for now.
At the very least, a minimal version of that logic is needed long-term
so that wstp-sys can be built successfully in the docs.rs built
environment (where we don't have access to a WSTP SDK to generate the
bindings on the fly).
It's possible it may make sense to enable usage of pre-generated
bindings using a cargo feature. More experience with real-world usage is
needed.
Prior to this, wstp-sys has been using bindings to wstp.h that were pre-generated. This required using the
generate-versioned-bindings.rsscript to create a new file for each{<System ID>, <Wolfram Language version>}combination that wstp-sys wanted to support. This was fragile and time consuming, and inevitably always out of date.Using pre-generated bindings made some sense before wolfram-app-discovery was written, but it makes little sense now.
There is a small compile-time tradeoff to doing this: the compile time of wstp-sys now includes the time needed to compile the new
bindgendependency, and the time to use bindgen to generate the WSTP Rust bindings file. However, the maintenance and "it actually works" benefits I think outweigh that consideration.I've left the pre-generated bindings files and code in place for now. At the very least, a minimal version of that logic is needed long-term so that
wstp-syscan be built successfully in the docs.rs built environment (where we don't have access to a WSTP SDK to generate the bindings on the fly).It's possible it may make sense to enable usage of pre-generated bindings using a cargo feature. More experience with real-world usage is needed.