Open Gnurou opened 4 months ago
https://crates.io/crates/cargo-c would solve that problem and some more. I can get you a patch for it, if it is fine for you.
Reading the code I figured out that you refer the the bindings to video4linux itself. Those should probably be a separate v4l2-sys
. Are they really architecture specific or it is better to clean up the bindgen output from libc strays and such?
Hey, thanks for looking into this. So the bindings are architecture-specific indeed, and possibly even platform-specific (i.e. you don't want to include fields that don't exist if your kernel version doesn't support them, even though it should theoretically not be a problem).
It goes even deeper, as you may want to use 64-bit bindings even though you are on a 32-bit platform (the use-case for that being virtio-media which specifies 64-bit structures are to be used). So at the bare minimum we need to be able to choose between 32-bit and 64-bit bindings, and the best case we could also generate bindings during build using the headers of the host system (and a desired architecture to interpret them).
This sounds like it should be a separate crate. It should not be platform specific otherwise it would be binary incompatible.
I'd need to find time to diff the two and look at the original headers.
I've tried moving the bindings to a separate sys
crate but that might be difficult. lib
implements some traits on the generated bindings, and we cannot do that unless they are part of the same crate.
We currently have two generated bindings for 32 bit and 64 bit platforms, but the bindgen output is dependent on the architecture as well. Thus there doesn't seem to be a good way to provide pre-generated bindings and they should be created at build time to ensure consistency.