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

问题描述

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

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.

一些其他有用的讨论:

• 重复的符号错误:SBJsonParser.o?(示例遇到一个向他这样做的供应商的客户)
• 链接共享另一个静态库的静态库

• 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的自动剥离，无论是否使用它(请参见

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).

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