Closed madsmtm closed 2 years ago
I would argue that it isn't a breaking change, or at least, it's such a small one that it doesn't warrant a major version bump:
Remember, the headers that bindgen
uses haven't changed, and so accordingly, the generated code haven't changed (apart from ordering); only the linking is different.
Of course, every change is observable; technically the user could have only enabled the audio_unit
feature, and then expected the symbols (specifically just the symbols, not the bindgen
-generated functions) from AudioToolbox
to be available. In reality, nobody would be doing this.
(Also note that the first linking change was not something widely noticed the first time around, and was done in 0.2.5 -> 0.2.6
).
@simlay looks like the requested changes have been made?
@madsmtm Also my apologies for ever changing this in the first place... at the time somewhere in the back of my mind I was thinking maybe I should just leave it alone, but the Apple documentation seemed crystal clear. Thanks for diving into it and figuring out the details. Next time I'll just tread lightly and not make arbitrary changes unless I have all the details figured out.
I've just verified that this works with the bevy iOS example.
Replaces / builds upon https://github.com/RustAudio/coreaudio-sys/pull/49, see that discussion first.
In particular, I've reverted the linking on iOS, since there, the AudioUnit framework is not (and newer were) linkable, instead one should link to AudioToolbox.
Kinda weak source, but verified by looking at simulator runtimes (this is what I could find) for version 9.3 and 10.3, on both of these AudioUnit does not contain a dylib (unlike most other frameworks). Also, in all SDK versions it's missing an AudioUnit.tbd file (which describes e.g. which symbols the library exposes).
A quick tip: You can gain a lot of knowledge from looking at the headers from previous SDKs e.g. these for macOS or these for iOS (both links are non-official).