Dependency on unmaintained crates

[newAM]

This is minor, but I did not see any existing issue for it.

This crate depends on 3 unmaintained crates:

CoreFoundation-sys: dcuddeback/core-foundation-sys#11
IOKit-sys: dcuddeback/iokit-sys#13
mach: fitzgen/mach#63, RUSTSEC-2020-0168

Crate:     mach
Version:   0.1.2
Warning:   unmaintained
Title:     mach is unmaintained
Date:      2020-07-14
ID:        RUSTSEC-2020-0168
URL:       https://rustsec.org/advisories/RUSTSEC-2020-0168
Dependency tree:
mach 0.1.2
├── IOKit-sys 0.1.5
│   └── serialport 4.2.2-alpha.0
└── CoreFoundation-sys 0.1.4
    ├── serialport 4.2.2-alpha.0
    └── IOKit-sys 0.1.5

[sirhcel]

Thank you for reporting this issue @newAM! Do you know if there are (de-facto) successors to these crates? Especially to IOKit-sys?

[newAM]

For mach there is mach2.
For IOKit-sys and CoreFoundation-sys the leading alternative is apple-sys.

[tommy-gilligan]

I've gone ahead with using apple-sys here
#125

Another alternative
https://github.com/servo/core-foundation-rs

[sirhcel]

[...] For IOKit-sys and CoreFoundation-sys the leading alternative is apple-sys.

Thank you pointing out these alternatives @newAM! Having a first glance at apple-sys, makes it stick out from other sys crates I know by generating is code on the fly where I was expecting a crate just containing the actual bindings.

As far as I'm overseeing this for now, we could experience issues at build time from an incompatible change in the APIs exposed from Apple's SDK but no breaking API from serialport-rs. I'm considering the former as having no impact as the APIs in question should be stable. If things get removed from these APIs, then we would have to handle this anyway. On top, we are using IOKit and CoreFoundation only for enumerating ports which also limits potential impact.

As we are not exposing anything from IOKit and CoreFoundation we are safe with respect to semver compatibility when Apple extends APIs with newer Framework versions.

We would lose the ability to build serialport-rs on a macOS system which does not have XCode command line tools installed. But it looks to me that this is no practical use case.

Has anyone of you already used this crate in production code and some experience?

I've gone ahead with using apple-sys here #125

Thank you @tommy-gilligan for this PR! There are some build issues as of now but nothing which looks like we couldn't iron out quickly.

Another alternative https://github.com/servo/core-foundation-rs

I've seen this one as well but it seems to just provide bindings for Core Foundation and not for IOKit. I found no alternative for the latter at a first glance and dcuddeback/iokit-sys#13 has gone unanswered for about half a year. Does anyone of you know of one?

[newAM]

We would lose the ability to build serialport-rs on a macOS system which does not have XCode command line tools installed. But it looks to me that this is no practical use case.

Adding a build-time dependency is a minor annoyance for package maintainers (e.g. nixpkgs for MacOS), but this is a pretty common requirement for building MacOS packages. I doubt it would cause anyone problems.

[tommy-gilligan]

Thank you pointing out these alternatives @newAM! Having a first glance at apple-sys, makes it stick out from other sys crates I know by generating is code on the fly where I was expecting a crate just containing the actual bindings.

We would lose the ability to build serialport-rs on a macOS system which does not have XCode command line tools installed. But it looks to me that this is no practical use case.

Adding a build-time dependency is a minor annoyance for package maintainers (e.g. nixpkgs for MacOS), but this is a pretty common requirement for building MacOS packages. I doubt it would cause anyone problems.

This might be obvious but is there a reason why apple-sys doesn't release versioned crates of generated code? Is this something it could do?

[tommy-gilligan]

• I've taken a stab at just avoiding the Apple API on macOS. Unfortunately, this option is not available for iOS. Put use of Apple SDK behind feature #126
• I've also tried bringing IOKit to iOS in apple-sys but having trouble with that Add IOKit to iOS youknowone/apple-sys#16 Swap out unmaintained dependencies for apple-sys #125
• Another alternative that I haven't tried yet: https://github.com/jtakakura/io-kit-rs

[tommy-gilligan]

Looks like there is a crate downstream of apple-sys that needs updating for latest version of SDK https://github.com/indygreg/apple-platform-rs/blob/main/apple-sdk/

[sirhcel]

Thank you for all the research @tommy-gilligan!

This might be obvious but is there a reason why apple-sys doesn't release versioned crates of generated code? Is this something it could do?

It looks to me that not including the binding code is a proclaimed goal of apple-sys: just maintaining the binding generator tools and not the actual generated code with will change over time.

* Another alternative that I haven't tried yet: https://github.com/jtakakura/io-kit-rs

This crate looks like the replacement for IOKit-sys I was looking for. I bet I missed it when looking at crates.io due to the dash in its name.

I would prefer using the curated core-foundation-sys in combination with io-kit-sys instead of apple-sys and will have a look a them the next days. I will also look into the other points and come back later.

[tommy-gilligan]

Thank you @sirhcel !

This might be obvious but is there a reason why apple-sys doesn't release versioned crates of generated code? Is this something it could do?

Sorry, reading this back, I feel like I completely butchered what I was trying to ask.

I was interested in: is it technically possible for somebody to use apple-sys as part of a pipeline to generate published crates eg. apple-sys-core-foundation maybe using IOS SDK version as crate version (for a more stable dependency)? Maybe not a great question on reflection. Basically anything is possible.

I maybe went a bit extra earlier and will calm my farm now to limit thread noise.

[sirhcel]

Just a quick update on using core-foundation-sys and io-kit-sys a spin in a test branch and it builds and the example list_ports enumerates ports as before.

• The constness of the parameter plane of IORegistry... functions does not match my expectation for passing const values there but could be changed easily
• The missings I/O registry could be added easily as well

I've filed two PRs for io-kit-sys. Let's see how this plays out there.

[tommy-gilligan]

Fantastic work!

Using core-foundation-sys and io-kit-sys is definitely the best of the alternatives.

Hopefully io-kit-sys is able to get to PR soon. I might still pursue apple-sys solution when I have a moment as a less desirable 'plan b' but also as a way to drive some improvements to apple-sys crate.