在iOS库项目中包含库

时间:2013-01-24 18:16:57

标签: ios xcode cocoapods

我正在编写一个依赖于其他一些开源库的iOS库。显然,不可能有两个具有相同名称的类,因此库可能会编译,并且可能会使用它的项目也会编译,但它们不能很好地协同工作(在链接阶段)。 / p>

该库面向大量受众,因此我无法对这些开发人员是否将导入相同的库,或者他们是否使用相同库的不同,不兼容版本做出任何假设。

我一直在四处寻找,但找不到任何明确的解决方案(也许没有)。到目前为止,我正在考虑这些选择:

  • 通知用户X库已包含在项目中,因此它们也不包含它们。这意味着他们无法使用不同版本的X库。
  • 作为第一个的精炼版本,使用CocoaPods,因此依赖关系会自动解决。仍然有一个缺点,即两个版本的库不能共存。
  • 导入并重命名我的库所依赖的所有类,为它们添加前缀,因此这些名称不会与原始名称冲突。这是一项繁琐的工作,但更重要的是,它的缺点是我无法从原始库中拉/推代码,因为代码会发生太大的变化。从用户的角度来看,在我看来仍然是最好的选择。

你能想到更好的主意吗?我对图书馆项目很陌生,所以也许有一些我不知道的东西。

我们仍然没有决定是以二进制或源代码形式分发。如果有理由选择其中一个,我也想听听你的意见。

2 个答案:

答案 0 :(得分:0)

当我遇到这个问题时,我选择了你的第三个选项并在我的库中加上了依赖类的前缀。您可能想要考虑这样做而不是依赖用户导入其他内容的原因是您可以保证兼容性,并且您不必担心您依赖的版本。

答案 1 :(得分:0)

第一点 -

  

通知用户X库已包含在项目中,   所以他们也不包括它们

所以你有一个静态库 Foolib.a ,它有第三方依赖 Barlib.a ,为了让Foolib构建,Foolib的HEADER_SEARCH_PATHS必须设置为Barlib的公共标题的路径。不再。

如果您要分发源代码,可以使用CocoaPods(这是一个很好的方法),或者您可以将Barlib的存储库添加为存储库的git子模块(或您选择的任何VCS)和硬编码HEADER_SEARCH_PATHS到那个路径,或者你可以要求你的用户抓住他们自己的Barlib并手动编辑HEADER_SEARCH_PATHS到正确的路径(如果你去CocoaPods或子模块路线,用户也可以轻松地做到这一点,所以有更多的选择)。

Barlib的任何内容都不在您的项目中。

另一方面,如果您要为用户分发二进制文件以链接到他们的应用程序,则必须在说明中指定 Foolib 要求将 Barlib 链接到该应用程序。关于如何掌握Barlib的说明会很好。

Barlib的任何内容都不在您的项目中或编入您的图书馆。

第二点 -

  

使用CocoaPods,因此依赖关系会自动解决。还有   缺点是两个版本的库不能共存

一个App中同一个库的两个版本是不可能的,但最终用户已经需要Barlib 3.0的情况想要使用你的Foolib,但是Foolib要求Barlib 4.0不一定会出现 - 这取决于你是开发者。你可以慷慨并支持多个版本的Barlib(即所有Foolib需要工作的是Barlib1.0,Barlib2.0,Barlib3.0或Barlib4.0链接到应用程序 - 类似于编写支持iOS5和iOS6的应用程序)或者,您可能会认同并要求特定版本,如果用户已经要求使用不同版本的Barlib,运气不好,如果他们想要使用您的库,他们将不得不更改他们的代码。

第三点 -

  

导入并重命名我的库所依赖的所有类,为它们添加前缀,   所以这些名字与原来的名字没有冲突

这对我来说太可怕了。遗憾。

Barlib的任何内容都不会出现在您的项目中或编译到您的库中。您不会分发任何Barlib副本 - 无论是链接到您的二进制文件还是源代码。