Produce portable output (avoid generating system-dependent tests + configuration to improve type replacements)

[dimbleby]

I prefer to generate my FFI code once and then distribute that, rather than generate it at build time. I see that you recommend the opposite, but even so: I expect that plenty of my potential users - especially on Windows - won't have the required dependencies installed. Better for me to figure out once how to get bindgen working, and be done with it.

At the moment, though, I have to do a little massaging of the code produced by bindgen to make it portable. My life would be that little bit easier if bindgen could be persuaded to produce portable output in the first place.

Ways in which I currently hand-modify output, and suggestions as to how this might be avoided:

• The exact definition of various types defined in system headers varies. So I blacklist them, and then modify the autogenerated code to import a portable version of those types eg use libc::timeval

  • WIBNI I could tell bindgen where to get a type from

• One consequence of this is that Debug can be wrongly derived. Eg it is derived on a structure containing an in_addr, which I obtain as libc::in_addr, which doesn't implement Debug.

  • (Actually libc::in_addr probably should be Debug - derive Debug on structures? libc#302).
  • But it isn't, so I have to manually un-derive Debug for structures that contain it
  • WIBNI bindgen didn't assume that things that it didn't know about (or which were blacklisted) were Debug

• autogenerated testcases all assume that pointer size is per the machine on which they were generated. So I delete them.

  • WIBNI I could tell bindgen to not generate such testcases

None of this is a big deal for me - bindgen is great and the work I just described really isn't very much. Feel free to close this out if it's not of interest to you!

[emilio]

So the autogenerated tests are useful for plenty of reasons (most notably sanity-check when you're using C++), but it's a fair concern and should be pretty easy to add an option to avoid generating them.

Re. deriving Debug, that's a bit more tricky, but it's a fair use case, so we could try to support that. Probably we could add configuration to avoid deriving debug for blacklisted types or something like that.

Do you have any thoughts @fitzgen?

[fitzgen]

An option to avoid layout tests is fine by me. Options surrounding control of deriving Debug seems fine by me.

The larger concept of intimately understanding portability and types in bindgen and the bindings we emit is a -1 for me. That sounds like too much complexity, and I think C++ and templates has already eaten our whole complexity budget.

[dimbleby]

Ha, yes, the title of this issue is maybe a bit grander than it ought to be!

What I'm actually interested in of course is just the three specific suggestions that I made. I'm very happy for you to consider them on their own merits - without anyone having to be sucked into some more general and complicated project.

[fitzgen]

Ok, then yeah those things all seem fine to me.

[emilio]

An option for disabling deriving debug landed today, disabling test generation should be straight forward.

[highfive]

Please make a comment here if you intend to work on this issue. Thank you!

[fitzgen]

A good first bug even!

[jdm]

@andrew-x You might be interested in fixing this (it's a tool that is used to support Servo, rather than directly in Servo proper).

[andrew-x]

Hi @jdm I'd like to take a shot at this. I'll try to set up a development environment first then I'll likely come back with a bunch of questions.