Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add the CoreAudioTypes framework #467

Closed

Conversation

samuelsleight
Copy link
Contributor

This PR adds support for the CoreAudioTypes framework, as an initial, (somewhat) simple start to the road of eventually adding AVFoundation.

As simple and small a library as it is (almost exclusively type/constant definitions and header-only, not even any linking), it did throw a couple of curveballs at me:

  • I needed to support four character codes, as they were used in several of the enum definitions in here. I've opted to do this by pulling this library in as a dependency of the header translator, and outputting the underlying u32 into the generated code so it's completely silent to the icrate library itself. I'm not 100% convinced I've done this in the best way, so I'm very much open to discussion here!
  • One of the exposed constans required a cast as part of it's definition, so I needed to add that as a fix manually. Feels like that should be a solvable problem, but I'm not sure it actually is at this stage?

With regards to the generated code, I appear to have added a large number of deprecated attributes - I'm not sure if this is some issue with my SDK setup or whether the submodule just hasn't been updated since some relevant change! Happy to look into that if needed.

More than happy for discussions on any decisions I've made in here, given I've not added anything here before!

@madsmtm
Copy link
Owner

madsmtm commented Jun 20, 2023

* I needed to support four character codes, as they were used in several of the enum definitions in here. I've opted to do this by pulling [this library](https://github.com/shurizzle/rust-four-char-code) in as a dependency of the header translator, and outputting the underlying `u32` into the generated code so it's completely silent to the `icrate` library itself. I'm not 100% convinced I've done this in the best way, so I'm very much open to discussion here!

I think it's best to put it in header-translator, the reasoning mostly being "we can, and it's faster for consumers". I'll definitely accept this code!

* One of the exposed constans required a cast as part of it's definition, so I needed to add that as a fix manually. Feels like that _should_ be a solvable problem, but I'm not sure it actually is at this stage?

The reason is that the anonymous enum ends up having a different type from the real enum. I think the general fix would just be to always cast when defining enum constants. I've just sorta assigned it as "part of #310" for now.

With regards to the generated code, I appear to have added a large number of deprecated attributes - I'm not sure if this is some issue with my SDK setup or whether the submodule just hasn't been updated since some relevant change! Happy to look into that if needed.

Yeah, the bindings are currently using the SDK from Xcode 14.2. I can update it to Xcode 14.3.1, but that requires me to do a 7GB download on a metered connection (I'm outside my home country currently), so I've been reluctant to do so. I'll do it at the start of August in any case, but if it's bothering you a lot, I can do it now.

More than happy for discussions on any decisions I've made in here, given I've not added anything here before!

You've done great so far, thank you!

@samuelsleight
Copy link
Contributor Author

think the general fix would just be to always cast when defining enum constants.

I did actually contemplate this one, though when I tried it I ran into issues when we special-case NSIntegerMax and NSUIntegerMax - though having said that, it would be equally trivial to un-special case that! I'm happy to try that if you think it's a reasonable solution?

Yeah, the bindings are currently using the SDK from Xcode 14.2

The odd thing is that in theory I am using the 14.2 SDK, as I noted on my other PR - there I just didn't commit any of the deprecated additions, and that seems to have worked fine, so I cna do the same here and only commit the CoreAudioTypes addition which I expect would also work (which I did split into a separate commit for this purpose), but I would like to attempt to work out why I'm seeing the difference.

@madsmtm
Copy link
Owner

madsmtm commented Jun 20, 2023

The odd thing is that in theory I am using the 14.2 SDK, as I noted on my other PR - there I just didn't commit any of the deprecated additions, and that seems to have worked fine, so I cna do the same here and only commit the CoreAudioTypes addition which I expect would also work (which I did split into a separate commit for this purpose), but I would like to attempt to work out why I'm seeing the difference.

Ah, then I think the issue is that you're using a newer clang than I am, which converts API_DEPRECATED attributes on the @interface into deprecated attributes on the methods as well. Probably an internal change to help Swift out, I don't think it really matters much whether we have it or not.

The reason I'm not staying up to date here is that my Mac is from 2013, and not new enough to run the latest Xcode versions. I'll be buying a new one once I get home too, but it probably makes sense to merge that commit so that others who's using the latest Xcode (@simlay?) won't have this problem.

@samuelsleight
Copy link
Contributor Author

Ah, then I think the issue is that you're using a newer clang than I am, which converts API_DEPRECATED attributes on the @interface into deprecated attributes on the methods as well.

Ahhhhhh, that makes sense! If we kept it, would it then be annoying for those that don't have the newer version?

@madsmtm
Copy link
Owner

madsmtm commented Jun 20, 2023

would it then be annoying for those that don't have the newer version?

I suspect that's only me, but I guess we could also add a hack for doing the propagation ourselves?

@samuelsleight
Copy link
Contributor Author

but I guess we could also add a hack for doing the propagation ourselves?

That could work, to be fair, though it depends how worth it it is likely to be versus how soon you'd be updating anyway, I guess

@madsmtm
Copy link
Owner

madsmtm commented Jun 20, 2023

Yeah. Though actually, I think our CI currently uses the clang from Xcode 14.2, so we'd probably have to either bump or support that too? So maybe it actually does make sense to add this hack, if not only to set some kind of precedent for how easy we make it to contribute to header-translator?

@samuelsleight
Copy link
Contributor Author

Ah yeah, that's a good point, and I'm definitely in favour of making things easier for people if possible

@samuelsleight
Copy link
Contributor Author

@madsmtm cheers for the update of xcide etc - that should definitely make things easier!

Apologies, I'd not (intentionally) abandoned these PRs, I'd just been relatively busy recently - should be able to bring them at least up to date at some point this week though

@madsmtm
Copy link
Owner

madsmtm commented Aug 28, 2023

No problem, I've been busy with other stuff myself

@madsmtm
Copy link
Owner

madsmtm commented Dec 9, 2024

I've added the four character code support in 4961dda and the CoreAudioTypes in c89bf6f, both based on your implementation, thanks for your work!

@madsmtm madsmtm closed this Dec 9, 2024
@madsmtm madsmtm added the A-framework Affects the framework crates and the translator for them label Dec 9, 2024
@samuelsleight
Copy link
Contributor Author

Wow, I really did say "this week" over a year ago huh

@madsmtm cheers for utilising some of this and #471 despite me definitely abandoning them, intentionally or not!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-framework Affects the framework crates and the translator for them
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants