compile: Upgrade to bindgen 0.61 and use Builder with Clone

[MarijnS95]

Depends on #21 for pub use bindgen; (perhaps all extern crate should be replaced since moving to edition 2021?)

As announced earlier in #20 when introducing BindgenOptions, upstream bindgen didn't yet allow cloning nor copying their Builder struct, limiting it to generate a single binding per Builder object. This doesn't fit with ispc-rs's Config struct which explicitly allows multiple libraries to be compiled using (partially) the same base configuration (barring any side-effects from fn compile(&mut self, lib) updating various fields depending on lib).

This issue has since been addressed upstream, and now allows us to move and clone the bindgen::Builder around instead of implementing a very limited subset of config fields and manually reconstructing the builder every time.

[MarijnS95]

In hindsight I'm not really sure if it was/is a good idea to expose the entire bindgen Builder struct (EDIT: In #20 (review) it was pointed out that it'd be nice to expose all config options to the user, I suppose to give them maximum control for i.e. experimenting), since it's pretty tied to ispc what bindings end up being generated from the header, and what config options ultimately make sense / should be settable by the user.

At the same time updating this bindgen_builder struct means reconstructing a new bindgen::Builder and passing it to bindgen_builder() (but most builder functions are additive anyways, iirc, so it might be better to "start over" in most cases or let the user figure out when to .clone() an earlier copy of their builder). It might be desired to "move" a builder out of and back into Config though, within a closure or just by .take()-replacing it with Default.

(barring any side-effects from fn compile(&mut self, lib) updating various fields depending on lib)

Perhaps we should refactor this.

[Twinklebear]

Thanks @MarijnS95 ! I think this will work well to expose the full bindgen options so that people can control whatever bindgen settings they want to without having to request each one to be added to ispc-rs. The best way to build things/clone/reuse/etc will depend on what different app's build configurations are like so just exposing the options is a good path.

Good point about the side effects in compile, that's something that would be good to address too so that the Config is more re-usable after being setup.

[Twinklebear]

I'm not sure if we'd want to make the additional fixes to make compile not modify things (so it can be more re-used) and then put out a release or if it'd be helpful to push this up sooner as a release? The changes here break the API for the bindgen setting so it'd be a major version bump

[MarijnS95]

@Twinklebear Perhaps a good idea to fold in those changes at the same time, assuming they may be breaking as well?

[Twinklebear]

Yeah, that's my thought as well. I should have some time to make those changes this week/weekend

[MarijnS95]

@Twinklebear Thanks! Better if you look into it 👍

[Twinklebear]

@MarijnS95 just to give you a heads up, I made that last change to the Config::compile API and pushed 2.0 out: https://github.com/Twinklebear/ispc-rs/releases/tag/2.0.0

[MarijnS95]

@Twinklebear thanks a ton! I've just upgraded our crates to use the new release and it all seems to work great! Immutability changes look great too!