Xcode 有时会自动查找依赖项。我认为当我是定义关系的人并且当我变得懒惰时，这是可以的......
但我经常发现自己面临着一个具有多个目标的现有（中型到大型）项目。由于该项目是由其他人制作的，因此我发现很难理解哪些目标取决于什么并非所有关系都是明确的.
Xcode 使用什么规则来查找此类关系？（我希望我能理解这个逻辑run它在我的脑海中，也许可以在将来节省我的时间）或者是什么使得一个目标有资格隐式依赖于另一个目标？
一个目标及其创建的产品可以与另一个目标相关。如果一个目标需要另一个目标的输出才能构建，则称第一个目标依赖于第二个目标。如果两个目标位于同一工作区中，Xcode 可以发现依赖关系，在这种情况下，它会按所需的顺序构建产品。这种关系称为隐式依赖关系。
Source: iOS 开发者库 → Xcode 概念 → Xcode 目标 https://developer.apple.com/library/ios/featuredarticles/XcodeConcepts/Concept-Targets.html
这个答案适用于 Xcode 8.x，我认为适用于 Xcode 9.0。
首先，您需要确保在您尝试构建的方案的“构建”面板中启用“查找隐式依赖项”。
可以通过两种方式使目标“A”“隐式”依赖于目标“B”：
- 目标 A 有一个“链接二进制文件与库”构建阶段，该阶段的列表中有一个库，其中包含一样的名字作为 B 的产品。该产品可以位于同一项目中，也可以位于工作区中的另一个项目中。请注意，我说的是“同名”。仅仅因为您从目标 A 选择了 libA.a，并不意味着如果您在不同的目标中有另一个 libA.a 产品，隐式依赖关系将会构建它。详情请参阅下文。
- 目标 A 有一个“复制文件阶段”，用于复制文件基本名称通常，“复制文件”构建阶段不能引用与其目标不在同一项目中的文件，但如果您为“复制文件”创建一个虚拟文件，则可以跨项目设置依赖关系复制文件”阶段来复制与 B 的产品同名的文件。例如，如果您有一个包含两个项目 ProjectA 和 ProjectB 的工作区。 ProjectA 具有创建 libA.a 的 TargetA，ProjectB 具有创建 libB.a 的 TargetB。 TargetA 可以通过将“假”零字节文件作为 TargetA 的一部分（碰巧名为 libB.a）来让 TargetB 构建 libB.a，这足以让 libB.a 生成，即使 libB.a 引用了“复制文件”阶段中的 to 是一个与 TargetB 构建的产品输出完全不同的文件。如果您选中“仅在安装时复制”框，Xcode 实际上不会执行复制，但仍会解析依赖关系。实际上，您可以从驱动器中删除您创建的假文件，该文件只是为了在“复制文件”阶段放入一些内容（但您必须将其保留在您的项目中）。
那么为什么会有人想要制作《2》这样的恐怖片呢？我可以想出几个原因。
- TargetA 需要 TargetB 复制/生成一些文件，但 TargetB 不会生成要链接到的库。您可以通过让 TargetB 生成一个小型虚拟库来解决此问题，但这可能会因为其他原因而变得痛苦。
- 假设我有projectA、targetA和libA.a（以及项目B、C和D的等价物），并且libA.a依赖于libB.a和libC.a，它们都需要首先构建libD.a（可能是一些标头）和/或生成的来源）。您可以使用“与库链接”阶段（也称为解决方案 #1）来完成这一切，但在这种情况下，您最终会在 libA 的最终链接版本中的 libD 中得到 .o 文件的两个副本。如果您做得足够深（例如，一个工作区有 40 个项目，这些项目彼此之间具有不同程度的依赖关系），您很快就会得到巨大的库文件，其中有几个相同的 .o 文件，并且您的链接时间将变得非常可怕。
如果您认为这些都是人为的情况，那么我目前正在将一些遗留代码从一系列显式依赖项移动到隐式依赖项。为什么我要转向隐式依赖？因为 Xcode 中的显式依赖关系需要项目嵌套，一旦获得足够的显式依赖关系，项目浏览器就会变得非常慢，并且您会在 Xcode 中看到很多随机事物的沙滩球。
如果同一工作区中碰巧有两个目标生成具有相同名称的产品并依赖于第三个目标，会发生什么情况？隐式依赖项将选择其中之一。它似乎根据产品的基本名称进行匹配（因此 foo/bar.a 和 baz/bar.a 是相同的），并会选择它找到的第一个。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
