The current objc crate stack is completely unmaintained and has severely fallen out of date with no updates for over 4 years. The metal-rs crate, built on top of this architecture, is completely written by hand which is tedious to keep up-to-date, not to mention has inconsistencies in its implementation.
All of this is superseded by the new objc2 crate stack built by @Madsmtm. Beyond providing what seems like a better, safer abstraction over Objective-C, all bindings are completely autogenerated meaning we'll no longer lag behind upstream bindings (requiring painstaking manual patching) or have inconsistencies in the implementations, as long as the generator is properly able to represent the bindings.
This PR is a draft to allow me to get a better understanding of Objective-C, as well as for @Madsmtm to chime in on the current use of Metal bindings. Who also helpfully provided me a branch with planned future improvements, including changing the generated bindings to be closer to metal-rs to make other migrations easier to manage.
One important thing that is missing from this PR is interop with older metal-rs types. objc2(-metal) has the typical Id::from_raw() interop that could allow us to upgrade gpu-allocator here while still using metal-rs for a little while longer in our own codebase. Such interop could be provided like the public-winapi optional feature, or hand-rolled in our codebase if so desired.
The current
objccrate stack is completely unmaintained and has severely fallen out of date with no updates for over 4 years. Themetal-rscrate, built on top of this architecture, is completely written by hand which is tedious to keep up-to-date, not to mention has inconsistencies in its implementation.All of this is superseded by the new
objc2crate stack built by @Madsmtm. Beyond providing what seems like a better, safer abstraction over Objective-C, all bindings are completely autogenerated meaning we'll no longer lag behind upstream bindings (requiring painstaking manual patching) or have inconsistencies in the implementations, as long as the generator is properly able to represent the bindings.This PR is a draft to allow me to get a better understanding of Objective-C, as well as for @Madsmtm to chime in on the current use of Metal bindings. Who also helpfully provided me a branch with planned future improvements, including changing the generated bindings to be closer to
metal-rsto make other migrations easier to manage.One important thing that is missing from this PR is interop with older
metal-rstypes.objc2(-metal)has the typicalId::from_raw()interop that could allow us to upgradegpu-allocatorhere while still usingmetal-rsfor a little while longer in our own codebase. Such interop could be provided like thepublic-winapioptional feature, or hand-rolled in our codebase if so desired.