【问题标题】:How to manage a dependency tree containing duplicate dependencies? (XCode, iOS)如何管理包含重复依赖项的依赖项树? (XCode,iOS)
【发布时间】:2015-10-04 20:42:27
【问题描述】:

我正在开发一个相当复杂的 iOS 应用程序。为了使开发合理化,我已经开始将每个模块开发为一个独立的项目,然后将它们组合到顶级应用程序项目中,从而形成一个依赖树。

我以前成功地采用过这种方法,但这次有一个共享依赖项 (C),这会导致问题:

     A
    /|\
   / | \
  B  C  D
 / \     \
C   E     C

其中 A 是顶级应用程序项目,C 是函数的“核心库”。此核心库是 A 本身以及模块 B 和 D 的依赖项。由此产生的多重编译会导致构建文件夹中出现重复符号并导致链接失败。

现在,我可以务实一点,只需从 A 中删除引用,因为无论如何这将由 B 编译到构建文件夹中,如果 D 不参与,这将起作用。但是我该如何解决 B 和 D 中 C 依赖的重复呢? 单独编译 B 和 D 项目时仍然需要对 C 的引用,但是在 A 的上下文中编译两次时会发生冲突。

我可以想象一些复杂的解决方案,使用 objcopy 并为其赋予唯一的前缀,但这会有点低效,因为它是相同的代码。我可以忍受这个,但有更好的方法吗?如果存在的话,也许一些编译器或链接器标志可以重用构建文件夹中的现有符号,而不是再次编译?

感谢您的建议。

【问题讨论】:

  • 从技术上讲,这与以下问题相同:stackoverflow.com/questions/11784917/… ...但尚未得到充分回答。
  • 我看不到问题,一个静态库,在构建时不会链接到其他库,但会暴露依赖关系,只有当该库链接到可执行文件时才会解决这些依赖关系。在你的情况下“A”。看来 B、C、D、E 不是静态库,否则您的问题将没有意义。
  • @Till:“一个静态库,在构建时不会链接到其他库”。是的,确实如此,这正是问题所在!无论如何,我已经通过显式省略顶层以下目标的链接阶段解决了这个问题,这确实会导致您描述的行为。
  • 是的,我知道有时这样做会导致所谓的“便利库”——但并不常见,正如你所说,通常可以避免。

标签: ios dependencies duplicates static-libraries


【解决方案1】:

最适合我的解决方案是在每个模块项目中设置两个目标: 和我称为 -NoLink 的一个。

这两个目标是相同的,只是在-NoLink中省略了链接阶段。结果,只创建了中间.o文件,构建可以一直进行到根项目,最终链接到所有模块。 p>

链接的目标 仍然存在,保留了在树中的任何点链接所有依赖项的灵活性,为任何模块生成独立的 .a 文件。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2014-04-04
    • 2017-12-24
    • 2011-09-04
    • 2013-06-22
    • 2016-03-03
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多