Let's collaborate on objc2!

[madsmtm]

Greetings @youknowone

I fairly recently completed an initial version of icrate over at the objc2 project, and wanted to tell you about it, as you seem to be doing a lot of the same in this project.

The desire with icrate is basically to be your one-stop-shop for all of Apple's frameworks, but importantly, with correct memory management and type-safety.

A few differences between apple-sys:

• The bindings are generated beforehand, so that the user doesn't have to run clang in their build script, and so that we can support docs.rs
• I went with creating the binding generator from scratch instead of using bindgen, since there were just too many things that would need changing to support (to name two things, multiple architectures in the same repo, and a nice file diff). In any case, the binding generator implementation is an implementation detail, and I actually intend to change it again
• I have something similar to Bindgen.toml called translation-config.toml. But for the most part, the intention is that fixes are implemented in normal Rust code, instead of imbedded in that file.

Feel free to ask me any questions if there's something I haven't fully explained!

(I discovered your project a little while ago when researching names for icrate, and didn't really think much of it then, but I see that you are still active here, so I figured I would try to recruit you - or at the very least, get input from you if icrate doesn't suit your needs ;) ).

[youknowone]

Hi, thank you for contacting!

I didn't know there are similar trial for these work. Although I thought I need a few modules from this crate when I started to work on, I actually don't have my own use case of this crate now.
I am working on this project mostly for fun because it can be done in that way but I couldn't find similar things (at that time).

For last 2 days, I actually also created prebuilt version of this crate. https://github.com/youknowone/apple-sys-prebuilt
But having trouble to upload it to cargo due to its package size.

Here is the sys part patch: #10

I am very amateur at this field. Please tell me if I have anything to help.

[madsmtm]

For last 2 days, I actually also created prebuilt version of this crate

Cool! I think that's a much better user-experience

But having trouble to upload it to cargo due to its package size.

Yeah, I suspect I will hit that issue at some point too :/

You could probably contact the crates.io team and ask them for help (since it will be difficult, if not impossible, to factor the frameworks out into their own crates).

I am very amateur at this field. Please tell me if I have anything to help.

I'm honestly not quite sure atm., I mostly just wanted to inform you

I think it would be nice to have some more eyes on header-translator, I have some plans for iOS support in there as well, see madsmtm/objc2#408, I'm quite unsure about that one so help would probably be appreciated there.

[silvanshade]

I wonder if one approach that might work for combining these two approaches would be if we could use a kind of multi-phased strategy for generating icrate.

Something like this:

1. Use apple-bindgen to generate bindings (per-platform) for a lot of the lower-level frameworks header-translator currently doesn't handle well, e.g., a lot of the Core* stuff.

2. Build up some tooling around this that would allow us to scan the output modules from (1), collect module items, deduplicate across platforms (in the same sense as iOS/tvOS/watchOS/visionOS support in framework crates madsmtm/objc2#408), and re-place them into specific points in the icrate module hierarchy (similar to the fixes modules). This step would need some sort of TOML configuration file that would allow us to specify only the items we care about including in the final icrate output (since a lot of the output from (1) will be redundant), along with rules for customization like renaming or derives or whatever

3. Run header-translator as normal

This would have the advantage of giving us coverage in icrate of the lower level frameworks much more quickly, as well as making it less tedious to look up and manually include little fixes for definitions from system headers which are missing from the header-translator output.

It would also be an easier to maintain and safer approach than manually including those little fixes, since if the headers change, the output from apple-bindgen will also change, whereas we currently have no good way to keep track of where some of our manual fixes might break in the future.

[madsmtm]

I would honestly be all aboard if not for the fact that I think the correct way to go is rather to not reimplement the stuff that Swift has already done, which is, well, C++, which is not Rust and shiny and a language I know, but probably the only real solution looking forwards :/

Good points all around though.