objc-sys

Objective-C运行时的原始绑定

此README有意保持简短，以便于合并文档，有关更多详细信息，请参阅Rust文档。

此crate是objc2项目的一部分，有关相关crate，请参阅该项目。

lib.rs:

Objective-C运行时的原始绑定

这些绑定几乎没有任何文档，因此强烈建议阅读Apple的Objective-C运行时文档，Apple的运行时参考，或使用objc2::runtime，它提供了一个更高级的API。

运行时支持

Objective-C有一个运行时，存在多种运行时的实现，它们的行为略有不同。默认情况下，Apple平台链接到Apple的运行时，但如果你使用其他运行时，你必须使用功能标志来告诉它这个库（你可能需要先禁用默认的apple功能）。

有人可能会问，为什么还要支持其他运行时？对我来说，主要原因是健壮性。通过在CI中使用这些替代运行时进行测试，我们间接地更有信心，我们的实现不依赖于脆弱的不确定行为，并且可以在不同的macOS和iOS版本上工作。

Apple的objc4

• 功能标志：apple。

默认使用，具有最高的支持优先级（所有 objc2 都将与此运行时兼容）。

支持的运行时版本（更高版本允许编译器启用更新的优化，但可能不支持旧操作系统）可以通过标准 X_DEPLOYMENT_TARGET 环境变量选择

• macOS: MACOSX_DEPLOYMENT_TARGET，默认 10.12，在 Aarch64 上为 11.0。
• iOS / iPadOS: IPHONEOS_DEPLOYMENT_TARGET，默认 10.0。
• tvOS: TVOS_DEPLOYMENT_TARGET，默认 10.0。
• watchOS: WATCHOS_DEPLOYMENT_TARGET，默认 5.0。

默认（和最小）版本与 Rust 本身拥有的版本相同。

GNUStep的libobjc2

• 功能标志：gnustep-1-7，gnustep-1-8，gnustep-1-9，gnustep-2-0和gnustep-2-1，具体取决于您使用的版本。

微软的WinObjC

• 功能标志：unstable-winobjc。

不稳定：尚未在 Windows 上进行测试！

基于GNUStep的 libobjc2 版本 1.8 的分支，对用户界面的更改很少。

ObjFW

• 功能标志：unstable-objfw。

不稳定：目前还不能使用！

待办事项。

其他运行时

此库可能仅支持“现代” Objective-C 运行时，因为支持像 objc_retain 和 objc_autoreleasePoolPop 这样的引用计数原语对于大多数应用程序是必不可少的。

这排除了 GCC libobjc 运行时（见此处）、mulle-objc 运行时和 cocotron。 （但可能添加对 darling 的支持）。有关不同运行时的更多信息，请参阅 GNUStep 的 Objective-C 编译器和运行时常见问题解答。

高级链接配置

此 crate 在 Cargo.toml 中定义了 links 键，因此可以更改链接到 libobjc，请参阅相关 cargo 文档。

将来，此 crate 可能会提供所需的源代码以自动构建和链接到运行时。在这里选择静态链接或动态链接也可能成为选项。

Objective-C 编译器配置

Objective-C 编译器（如 clang 和 gcc）需要配置调用 ABI 以匹配您使用的运行时

• clang 使用了 -fobjc-runtime 标志，其中包含几个不同的 选项。
• gcc 使用了 -fgnu-runtime 或 -fnext-runtime 选项。请注意，现代 Objective-C 功能支持不佳。

如果你在构建脚本中构建和链接自定义 Objective-C 源代码，这很重要。为了帮助编译 Objective-C 源代码，此 crate 的构建脚本将 DEP_OBJC_0_3_CC_ARGS 环境变量暴露给下游构建脚本。

在你的 build.rs 中的示例用法（使用 cc crate）如下

fn main() {
    let mut builder = cc::Build::new();
    builder.compiler("clang");
    builder.file("my_objective_c_script.m");

    for flag in std::env::var("DEP_OBJC_0_3_CC_ARGS").unwrap().split(' ') {
        builder.flag(flag);
    }

    builder.compile("libmy_objective_c_script.a");
}

设计选择

我们知道，此库的主要消费者将是 macOS 应用程序，其次是 iOS 应用程序。因此，在构建脚本中未选择使用 bindgen[^1]，以避免增加这些目标的编译成本。

已弃用的函数也未包括在内，以实现未来兼容性，因为它们可能在任何 macOS 版本中删除，然后我们的代码就会中断。如果您需要这些，请提交问题，我们可以讨论它！

一些项（特别是 objc_msgSend_X 系列）具有防止在不同平台上使用的 cfg，它们在 semver-stable 意义上只会变得更加宽松，而不会更加严格。

[^1]: 话虽如此，其中大部分都是在 bindgen 的命令行接口的帮助下创建的，因此向他们表示巨大的谢意！