ObjC:如何编译包含依赖第三方库的可选类的静态库 [英] ObjC: How to compile static library that includes optional classes that depend on a third party library

问题描述

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

I'm trying to find the best way to package a static library(lets call it Lib1) that includes an optional class(say, ClassA), which itself requires a second static library(Lib2). In other words, Lib2 is only needed if ClassA is referenced in the project's code. Things seem to work fine, unless Lib1 is used in a project that doesn't use ClassA(and hence does not include Lib2), but requires the -ObjC linker flag(because of other project dependencies, not mine).

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

I'm trying to come up with a an easy solution for the following three scenarios:
1) project includes my static lib, does NOT use the optional class, does not specify the -ObjC flag
2) project includes my static lib, does NOT use the optional class, but requires -ObjC flag
3) project includes my static lib + second static library, and DOES use the optional class (we don't care about the -ObjC flag at this point)

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

Is there a linker flag out there to strip my optional class out of the final project app so that it doesn't require the second static lib? I guess my other alternatives are to release multiple versions of my static lib, one that includes the option class(the standard choice), one that does not(the alternate, for projects with -ObjC requirements), or maybe supply a stub file, that supplies empty implementations of all the classes needed from the second static library? This seems like it could be a common problem in the static library world... is there a best practice for this scenario?

谢谢！

1) 建议我的 -ObjC 用户改用 -force_load.(谢谢罗！)
2) 对于不能做 1 的用户，我将有一个不包含 ClassA 的替代构建

1) Suggest to my -ObjC users that they use -force_load instead. (thanks Rob!)
2) For users that can't do 1, I'll have a alternate build that does not include ClassA

推荐答案

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

The best practice is always to have the final binary link all the static libs required. You should never bundle one static library into another. You should absolutely never bundle a well-known (i.e. open-source) static library into a static library you ship. This can create incredible headaches for the final consumer because they can wind up with multiple versions of the same code. Tracking down the bugs that can come from this is insanely difficult. If they're lucky, they'll just get confusing compiler errors. If they're unlucky, their code will behave in unpredictable ways and randomly crash.

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

Ship all the static libraries separately. Tell your clients which ones they need to link for various configurations. Trying to avoid this just makes their lives difficult.

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

Some other discussions that may be useful:

• 重复符号错误:SBJsonParser.o?(示例一位客户遇到了对他这样做的供应商)
• 链接静态库，共享另一个静态库
• 为什么 iOS 框架依赖项在应用程序项目中不需要显式链接到静态库项目或框架项目?

• Duplicate Symbol Error: SBJsonParser.o? (Example of a customer who ran into a vendor doing this to him)
• 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?

-ObjC 标志应该完全阻止 ClassA 的自动剥离，无论是否使用(请参阅 TN1490 了解更多详情).

The -ObjC flag should be preventing the automatic stripping of ClassA entirely, whether its used or not (see TN1490 for more details).

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

If ClassA is never used except in certain circumstances and you want to save space, you should probably move ClassA into its own static library. Or use #ifdef to conditionally compile it.

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

Alternately, you can remove the -ObjC flag and use -force_load to individually load any category-only compile units (which is the problem -ObjC is used to address).

这篇关于ObjC:如何编译包含依赖第三方库的可选类的静态库的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！