wrapper for AURenderEvent?

[rustaudio]

wrapper for AURenderEvent?

[wtholliday]

Ah so AURenderEvent is defined in an Objective-C header, even though it is just a C type. I'm guessing that's why the binding generator skips it.

Perhaps I could pull AURenderEvent out into a separate header and add it here:

coreaudio-sys/build.rs

Line 50 in 5837e3a

headers.push("AudioToolbox/AudioToolbox.h");

[wtholliday]

How about this?

audulus@e4df360

[MichaelHills]

Did you just hand-write the header file instead of generating it because it's an ObjC header? I believe @simlay had made changes to bindgen to allow generating ObjC headers as well.

I remember that enabling it seems to change a few things in the generated code which if I remember right was not a big deal (but needed fixing). One problem was that by adding in ObjC generation, coreaudio-sys as a dependency takes wayyy longer to compile which doesn't seem ideal to have on by default.

Maybe there's a path forward where ObjC headers can be generated via an opt-in feature? I haven't used Rust since the work I did for adding iOS support, so perhaps with what I have mentioned above we can figure out a path forward? @simlay are you able to elaborate on the ObjC support?

I did some digging and found this https://rust-lang.github.io/rust-bindgen/objc.html and this https://github.com/simlay/uikit-sys/blob/master/build.rs#L55

I also found the thread where I mentioned disabling the ObjC support in some PR #33 (comment) So those would be the flags needed to re-enable it I think unless bindgen has changed a lot.

While adding your one header file manually would not make things any slower and would be faster than enabling ObjC support, it's my understanding that this goes against the point of the library which is to generate the headers?

[wtholliday]

@MichaelHills I copy-pasted the code from the apple header. I didn't know bindgen had any ObjC support. In this case, I don't think it's too bad because Apple can't change AURenderEvent without breaking existing binaries. What do you think?

The library is still generating the bindings from headers.

[simlay]

@MichaelHills I copy-pasted the code from the apple header. I didn't know bindgen had any ObjC support.

Yeah! I added a lot of the Objective-c support last year. I'll admit that it's definitely not perfect. It's missing rust-lang/rust-bindgen#1784.

In this case, I don't think it's too bad because Apple can't change AURenderEvent without breaking existing binaries. What do you think?

I mean, I think they can? I don't follow the SDK release notes well enough to know how often this happens.

[MichaelHills]

In this case, I don't think it's too bad

Personally I don't think it makes sense to manually cut/paste code from ObjC headers one file at a time as different people want them. The whole point of the library is to automatically (and completely?) generate bindings for different subsets of the coreaudio functionality. I think adding in ObjC support would be the better approach, but as @simlay pointed out whatever is currently in bindgen is not perfect.

I'll at least try re-activating the ObjC support and see what happens, and see if AURenderEvent comes out with it. Perhaps will also see if ObjC generation can be an opt-in flag if it's as slow as I remember it being. It's probably just slower because there's just so much more code to generate, but if I was using the library and it got 2x slower overnight with no way of turning it off I'd probably call that a performance regression.

[MichaelHills]

AURenderEvent does appear when objc support is enabled, see #55 but it's not quite working yet due to compile errors.