Feature Request: Make layout tests adaptive to word length of target arch

[wucke13]

Currently, if I run bindgen on a 64 bit machine, the generated layout tests will fail on a 32 Bit machine. The reason is, that the layout tests test the exact layout of the machine on which the bindings where generated. I have a use case where it is quite a burden to ship the c header files with the rust crate. Thus I prefer generating the bindings once, and then shipping the generated bindings. However, if I do so, some layout tests fails, as some structures have different representation depending on the word length of the current system. I think it would be a good enhancement to make the layout tests check that the layout of the rust types matches those of the equivalent C types on the target platform (versus the current behavior, where they try to match the platform where bindgen was invoked).

To my surprise I did not find this request in the issues (maybe I overlooked something obvious?) thus I put it here. Any opinions appreciated 😄 !

[emilio]

This makes sense, but it's pretty hard to do in the general case. Stuff like:

#ifdef SOMETHING
  uint32_t myMember;
#endif

Or similar stuff is pretty common. Similarly, bindgen may manage to align one struct correctly on x86-64, but may need to add a member on x86 to guarantee alignment (though this is fairly uncommon). To be clear the bindgen tests don't depend on the platform bindgen is being invoked, but the target platform.

If you're very very sure that your header is not target-dependent in any way (not per platform, not per arch), then you can probably run the tests on x86-64 and remove them from the bindings you check-in using the options. Otherwise you'd need to generate different sets of bindings (one per target you support) and use them behind a #[cfg]. That should be easy passing different --targets in the clang-flags.

[wucke13]

Would it be possible to add a vec of supported arches to the API? Than one could say something like "bindgen, please generate bindings for these five targets". Then the evaluation of the C code could be done for each target independently, and the resulting rust code features gates the generated code through arch dependeng #[cfg].

[emilio]

Would that be different to running bindgen N times and doing something like:

#[cfg(arch = "foo")]
include!("bindings-foo.rs");

...

? Because usually compiling for different architectures actually also requires a different set of compile flags etc.

[wucke13]

No it would be the same semantically. What I meant was to implement this functionality in bindgen. But actually, for my case I am

sure that [my] header is not target-dependent in any way

So having arch dependent unit tests would be a solution for my particular usecase.

[emilio]

Right, my point is that it's pretty hard to do it in a way that isn't just running bindgen N times.

[wucke13]

Probably a stupid question, but: How do I run rust-bindgen on a x86 machine to generate the header files for another target, e.g. armv7?

[emilio]

Passing --target <arm-target> to the clang flags.