mersive-technologies / gles31-sys Goto Github PK

Hi,

First of all, thanks for your crate. We've been using it in an Android library of ours for over a year now, and it helped us getting some custom video I/O to work.

I was wondering how you feel about simplifying the crate. Right now it needs a lot of machinery (build.rs logic, bindgen, NDK PATH setup) to basically produce the same file over and over again. In a fork of ours we replaced everything with a bat file we basically ran once on a developer machine:

bindgen ^
    ../../../../tooling/x86_64-pc-windows/ndk/android-ndk-r21d/sysroot/usr/include/GLES3/gl31.h ^
    --generate-block ^
    --no-layout-tests ^
    --no-prepend-enum-name ^
    --with-derive-eq ^
    --with-derive-default ^
    --with-derive-hash ^
    --with-derive-ord ^
    --use-array-pointers-in-arguments ^
    -o ../src/bindings.rs ^
    -- ^
    -I../../../../tooling/x86_64-pc-windows/ndk/android-ndk-r21d/sysroot/usr/include/

And our build.rs only contains

fn main() {
    println!("cargo:rustc-link-lib=GLESv3");
}

This gave a bindings.rs we checked in, dramatically sped up CI builds, and made the crate work on Windows.

My proposal would be to upstream these or similar (e.g., different scripts or parameters to call bindgen) changes into your crate. If multiple bindings files are needed (e.g., Android vs. iOS), I think it's still better to pre-generate them into various files and just select the right one at compilation.

Any thoughts?