【问题标题】:Include libraries in iOS library project在 iOS 库项目中包含库
【发布时间】:2013-01-08 14:27:44
【问题描述】:

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

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

我一直在环顾四周,但找不到任何明确的解决方案来解决我的问题(也许没有)。到目前为止,我正在考虑以下选项:

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

你能想出更好的主意吗?我对图书馆项目很陌生,所以也许我缺少一些明显的东西。

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

【问题讨论】:

  • 您是否考虑分发源代码或二进制文件?
  • 我在描述中添加了这个,谢谢hooleyhoop

标签: ios xcode cocoapods


【解决方案1】:

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

【讨论】:

  • 我最终做到了,谢谢。我仍然想知道是否有更好的选择,但似乎没有。
【解决方案2】:

第一点——

通知用户 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,因此依赖关系会自动解决。还是有 两个版本的库不能共存的缺点

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

第三点——

导入并重命名我的库所依赖的所有类,为其添加前缀, 所以名字不会和原来的相冲突

这对我来说太可怕了,目前无法考虑。对不起。

Barlib 中的任何内容都不会“在”您的项目中或编译到您的库中。您不会分发任何 Barlib 副本 - 链接到您的二进制文件或作为源代码。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2015-01-31
    • 2020-07-17
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多