objective-c - ObjC : How to compile static library that includes optional classes that depend on a third party library

Question

我正在尝试找到打包静态库(我们称之为 Lib1)的最佳方法，其中包含一个可选类(例如 ClassA)，它本身需要第二个静态库(Lib2)。换句话说，只有在项目代码中引用了 ClassA 时才需要 Lib2。事情似乎工作正常，除非 Lib1 用于不使用 ClassA 的项目(因此不包括 Lib2)，但需要 -ObjC 链接器标志(因为其他项目依赖项，而不是我的)。

我正在尝试针对以下三种情况提出一个简单的解决方案:
1) 项目包括我的静态库，不使用可选类，不指定 -Objcflags
2) 项目包括我的静态库，不使用可选类，但需要 -Objcflags
3) 项目包括我的静态库 + 第二个静态库，并且确实使用了可选类(此时我们不关心 -Objcflags)

是否有一个链接器标志可以将我的可选类从最终项目应用程序中剥离出来，以便它不需要第二个静态库？我想我的其他选择是发布我的静态库的多个版本，一个包含选项类(标准选择)，一个不包含(替代，对于具有 -ObjC 要求的项目)，或者可能提供 stub 文件，提供第二个静态库所需的所有类的空实现？这似乎是静态库世界中的一个常见问题……是否有针对这种情况的最佳实践？

谢谢!

---

解决方案:

1) 建议我的 -ObjC 用户改用 -force_load。 (感谢罗布!)
2) 对于不能执行 1 的用户，我将有一个不包含 ClassA 的替代构建

Answer 1

最佳实践始终是让最终的二进制链接所有需要的静态库。您永远不应该将一个静态库捆绑到另一个静态库中。您绝对不应该将众所周知的(即开源)静态库捆绑到您发布的静态库中。这会给最终消费者带来难以置信的麻烦，因为他们可能会得到相同代码的多个版本。追踪可能由此产生的错误非常困难。如果幸运的话，他们只会遇到令人困惑的编译器错误。如果他们不走运，他们的代码将以不可预测的方式运行并随机崩溃。

单独运送所有静态库。告诉您的客户他们需要为各种配置链接哪些。试图避免这种情况只会让他们的生活变得困难。

其他一些可能有用的讨论:

• Duplicate Symbol Error: SBJsonParser.o? (遇到供应商对他这样做的客户示例)
• Linking static libraries, that share another static library
• Why don't iOS framework dependencies need to be explicitly linked to a static library project or framework project when they do for an app project?

---

-Objcflags应该完全阻止 ClassA 的自动剥离，无论是否使用它(有关更多详细信息，请参见 TN1490)。

如果 ClassA 除了在某些情况下从不使用，并且您想节省空间，您应该将 ClassA 移到它自己的静态库中。或者使用#ifdef 条件编译。

或者，您可以删除 -ObjC 标志并使用 -force_load 单独加载任何仅类别的编译单元(这是问题 -ObjC 用于寻址)。