7

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

我试图为以下三种情况提出一个简单的解决方案：
1）项目包含我的静态库，不使用可选类，不指定 -ObjC 标志
2）项目包含我的静态库，不使用可选类，但需要 -ObjC 标志
3) 项目包括我的静态库 + 第二个静态库，并且确实使用可选类（此时我们不关心 -ObjC 标志）

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

谢谢！

解决方案：

1) 建议我的 -ObjC 用户改用 -force_load。（感谢 Rob！）
2）对于不能做 1 的用户，我将有一个不包括 ClassA 的替代版本

4

1 回答 1

7

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

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

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

-ObjC 标志应该完全防止自动剥离ClassA，无论是否使用（有关更多详细信息，请参见TN1490）。

如果ClassA除非在某些情况下从未使用过并且您想节省空间，那么您可能应该移动ClassA到它自己的静态库中。或用于#ifdef有条件地编译它。

或者，您可以删除该-ObjC标志并用于-force_load单独加载任何仅类别的编译单元（这是-ObjC用于解决的问题）。

于 2012-09-27T21:25:48.717 回答