kornelski
Is there a better approach than the minimum OS version feature flags?
There have been some occasions where people introduce new APIs but forget to properly specify the respective supported OS or minimum OS version, which is understandable because it's easy to get wrong. I wouldn't be surprised if there were APIs in use today that aren't behind the correct feature flags.
Off the top of my head there might be two ways to improve the situation:
- Make use of
-mmacosx-version-minand related flags to get compile time warnings (ideally errors?) about using APIs which won't be available for the target. If this an improvement, how can we make it easy for users of the crate to use this approach? Are there any issues regarding cross compilation? - Perhaps bindgen could be extended to expose availability info and create feature flags for the rust implementations?
If anyone has thoughts or other suggestions I'd love to hear them.
I don't think Rust is aware of macOS targets. AFAIK it doesn't set -mmacosx-version-min. I guess a crate could try to get MACOSX_DEPLOYMENT_TARGET env var, but that may need build.rs, and it's a bit magical. Crates can't set env vars themselves in something like Cargo.toml, so not setting the right target could break builds.
Overall, I don't think feature flags are that bad.
I think it could be improved by sprinkling #[doc(cfg(feature = "OSX_10_ZZ"))] in the code so that docs.rs will show which flags are needed.
Yeah, that makes sense.
How about a CI job to build the crate with the -m<os>-version-min flag and relevant feature flag set, with warnings set as errors? That should hopefully give early feedback on mistakes.
Do you mean detecting feature errors in security-framework itself, or other crates using it?
Yeah, that may be doable.
GitHub actions doesn't support older versions of macOS, so it's not easy to test on the actual OS, but basic test with MACOSX_DEPLOYMENT_TARGET can work.