静态 (iPhone) 库、分发和依赖项

Posted 2023-02-27

【中文标题】静态 (iPhone) 库、分发和依赖项

【英文标题】：Static (iPhone) libraries, distribution, and dependencies

【发布时间】：2009-12-10 01:36:07

【问题描述】：

（除了我们可能会使用框架或动态库这一事实之外，可能以下问题不是 iPhone 特定的。）

我正在为客户构建一个专有的 iPhone SDK，以与他们的 Web 后端集成。由于我们不想将源代码分发给客户，因此我们需要将 SDK 作为静态库分发。这一切都很好，我已经验证我可以将新的 iPhone 应用程序与库链接并将它们安装在设备上。

我担心我们的 SDK 所依赖的第三方库。例如，我们目前正在使用 HTTPRiot 和 Three20（确切的库可能会改变，但这不是重点）。我担心如果客户也在他们的应用程序中使用这些库中的任何一个（甚至可能是不同的版本），这可能会导致冲突。

这方面的最佳做法是什么？有没有办法从我们自己的静态库中排除依赖库的符号（在这种情况下，客户必须手动链接到我们的 SDK 以及 HTTPRiot 和 Three20）？还是有其他既定机制？

我试图在易用性和灵活性/兼容性之间取得平衡。理想情况下，客户只需将我们自己的 SDK 放入他们的项目中并进行最少数量的构建设置更改，但如果它使事情变得更加健壮，那么让客户单独链接多个库可能更有意义。或者我想我们可以分发多个版本的 SDK，无论是否包含第三方依赖项，以涵盖这两种情况。

我希望我的问题是有意义的...主要来自 Ruby 和 Java 背景，我已经很长时间不用处理编译库（传统意义上的）了...;)

【参考方案1】：

如果是我，我会准确指定我的库与这些 3rd 方库的哪些版本进行互操作。然后，我将对它们进行测试，记录它们，并可能与发行版中包含的那些特定版本一起交付。

我会担心两件事： - 我想确保我的客户安装它时它“正常工作”。 -我不想保证支持这些 3rd 方库的任意未来版本。

包含让客户迁移到新版本的流程很好，但如果有任何问题不起作用，那么我希望客户为该开发工作付费，作为增强功能，而不是免费的错误修复（除非您将其包含在原始许可/支持安排中）。

到那时，确保您的特定版本的 3rd 方库可以与客户需要的任何其他东西（在您的情况下是 Web 后端）一起愉快地工作就成了一个问题。以我的经验，这通常是图书馆的一个功能，例如有些不是为了让多个版本可以并行运行而设计的。

【讨论】：

听起来是一种合理的方法。版本控制有点棘手，因为一些第三方库以源代码形式分发并且没有明确的版本控制。但我想我可以指出一个特定的 Github 提交或日期。您提到了为客户升级 3rd 方库包括（不受支持的）流程的可能性。我该怎么做呢？这似乎会导致冲突，因为第 3 方符号实际上成为了我们自己的 SDK 的一部分。

还没来得及思考这个问题，但是“弱链接”对您有帮助吗？ developer.apple.com/iphone/news/archives/november2009/…

我猜你可以给他们一个脚本来重建整个产品（包括你的图书馆和其他第 3 方的）？只要他们安装了（> 2GB）iPhone SDK，您就可以给他们一个脚本，为一个简单的Xcode项目调用xcodebuild，将所有东西放在一起？不过有点乱。最简单的事情是强制版本并坚持他们与您联系（并支付）针对升级后的库的新版本。您也可以在价格中包含一些验收测试... IMO 您这样做是完全合理的。

我会阅读弱链接。如果这为我的 SDK 提供了一种针对第三方静态库进行构建的方法，而无需将它们实际包含在我们的静态库中，那么这可能会很好地解决问题。

至于您的其他评论：澄清一下，实际上有三方：我自己、我的客户和客户的客户。我是一名顾问，但出于所有意图和目的，我在这种情况下代表客户。我真正关心的是客户的客户。 SDK 使他们能够将我的客户端的功能集成到他们自己的 iPhone 应用程序中。问题是我们正在使用的一些第三方库（例如 Three20）很受欢迎，所以客户很可能已经在使用这些（可能还有不同的版本）。