3

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

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

我一直在环顾四周，但找不到任何明确的解决方案来解决我的问题（也许没有）。到目前为止，我正在考虑这些选项：

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

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

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

4

2 回答 2

0

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

于 2013-01-24T19:13:58.150 回答
0

第一点——

通知用户 X 库已经包含在项目中，因此他们也不要包含它们

所以你有一个静态库Foolib.a，它有一个第 3 方依赖Barlib.a，为了构建 Foolib，FoolibHEADER_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 的副本 - 链接到您的二进制文件或作为源代码。

于 2013-01-24T21:51:53.657 回答