Xcode 如何找到隐式目标依赖项?

声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow 原文地址: http://stackoverflow.com/questions/37794402/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me): StackOverFlow

提示:将鼠标放在中文语句上可以显示对应的英文。显示中英文
时间:2020-09-15 08:52:57  来源:igfitidea点击:

How does Xcode find implicit target dependencies?

iosxcodemacos

提问by nacho4d

Xcode finds dependencies automatically sometimes. I think is is ok when I am the one who is defining the relationships and when I get lazy ...

Xcode 有时会自动查找依赖项。我认为当我是定义关系的人并且当我变得懒惰时是可以的......

But more than often I find myself facing an existent (medium to large size) project with several targets. Since the project has been made by someone else I find it very difficult to understand what targets depends on what since not all the relationships are explicit.

但我经常发现自己面临着一个具有多个目标的现有(中型到大型)项目。由于该项目是由其他人制作的,我发现很难理解目标取决于什么,因为并非所有关系都是明确的

What are the rules Xcode use to find such relationships?( I hope I can understand the logic so runit in my mind and maybe save me some time in the future) Or What makes a target qualifiable to be implicitly dependant of another?

Xcode 使用什么规则来查找此类关系?(我希望我能理解逻辑,所以在我的脑海中运行它,也许可以在未来节省我一些时间)或者是什么让一个目标有资格隐含地依赖另一个?

A target and the product it creates can be related to another target. If a target requires the output of another target in order to build, the first target is said to depend upon the second. If both targets are in the same workspace, Xcode can discover the dependency, in which case it builds the products in the required order. Such a relationship is referred to as an implicit dependency.

一个目标及其创建的产品可以与另一个目标相关联。如果一个目标需要另一个目标的输出来构建,则称第一个目标依赖于第二个目标。如果两个目标都在同一个工作区中,Xcode 可以发现依赖关系,在这种情况下,它会按照所需的顺序构建产品。这种关系称为隐式依赖。

Source: iOS Developer Library → Xcode Concepts → Xcode Target

来源:iOS 开发者库 → Xcode 概念 → Xcode 目标

采纳答案by dmaclach

This answer applies to Xcode 8.x, and I think for Xcode 9.0.

这个答案适用于 Xcode 8.x,我认为适用于 Xcode 9.0。

First off, you need to be sure that "Find Implicit Dependencies" is enabled in the the Build panel of the Scheme that you are attempting to build.

首先,您需要确保在您尝试构建的 Scheme 的 Build 面板中启用了“Find Implicit Dependencies”。

A target "A" can be made "implicitly" dependent on target "B" in two ways:

可以通过两种方式使目标“A”“隐式”依赖于目标“B”:

  1. Target A has a "Link Binary With Libraries" build phase that has a library in its list that has the same nameas a Product of B. This product can either be in the same project or another project in the workspace. Note that I said "same name". Just because you chose libA.a from target A doesn't mean that implicit dependencies will build it if you have another libA.a product in a different target. See below for details.
  2. Target A has a "Copy Files Phase" that copies a file with a base namethat matches a product of B. Normally a "Copy files" build phase cannot refer to a file that isn't in the same project as its target, but you can set up a dependency across projects if you create a dummy file for the "copy file" phase to copy that has the same name as a product of B. For example, if you have a workspace that contains two projects ProjectA and ProjectB. ProjectA has TargetA that creates libA.a, and ProjectB has TargetB that creates libB.a. TargetA could get TargetB to build libB.a by having a "fake" zero byte file as part of TargetA that happened to be named libB.a, and this would be sufficient to get libB.a made, even though the libB.a referred to in the "Copy Files" phase is a totally different file than the product output of the TargetB build. If you check the "Copy Only When Installing" box, Xcode won't actually perform the copy, but will still resolve the dependency. You can actually delete the fake file off your drive that you created solely to have something to put in the "Copy Files" phase (but you must leave it in your project).
  1. 目标 A 有一个“Link Binary With Libraries”构建阶段,它的列表中有一个与 B 的产品同名的库。这个产品可以在同一个项目中,也可以在工作区中的另一个项目中。请注意,我说的是“同名”。仅仅因为您从目标 A 中选择了 libA.a 并不意味着如果您在不同的目标中有另一个 libA.a 产品,则隐式依赖项会构建它。详情请见下文。
  2. 目标 A 具有“复制文件阶段”,用于复制具有基本名称的文件匹配 B 的产品。通常,“复制文件”构建阶段不能引用与其目标不在同一项目中的文件,但是如果您为“复制文件”阶段以复制与 B 的产品同名的文件。例如,如果您有一个包含两个项目 ProjectA 和 ProjectB 的工作区。ProjectA 具有创建 libA.a 的 TargetA,而 ProjectB 具有创建 libB.a 的 TargetB。TargetA 可以让 TargetB 构建 libB.a,方法是将“假”零字节文件作为 TargetA 的一部分,碰巧命名为 libB.a,这足以使 libB.a 生成,即使 libB.a 引用“复制文件”阶段的 to 是一个与 TargetB 构建的产品输出完全不同的文件。如果您检查“

So why would anyone ever want to do the horror that is "2"? I can come up with a couple of reasons.

那么为什么会有人想要制作“2”的恐怖片呢?我可以想出几个原因。

  1. TargetA needs some some files copied/generated by TargetB, but TargetB doesn't generate a library to link to. You could probably work around this by having TargetB generate up a small dummy library, but that may be painful for other reasons.
  2. Let's say I had projectA, targetA and libA.a (and equivalents for project B, C and D), and libA.a depended on libB.a and libC.a which both needed libD.a to be built first (possibly some headers and/or sources generated). You could do it all using the "Link With Libraries" phase (aka solution #1) but in that case you would end up with two copies of the .o files in libD in the final linked version of libA. If you do this deep enough (eg a workspace that has 40 projects that have varying levels of dependencies on one another) you will quickly end up with huge library files with several identical .o files in them, and your link times will become horrific.
  1. TargetA 需要一些由 TargetB 复制/生成的文件,但 TargetB 不生成要链接的库。您可以通过让 TargetB 生成一个小的虚拟库来解决这个问题,但由于其他原因这可能会很痛苦。
  2. 假设我有 projectA、targetA 和 libA.a(以及项目 B、C 和 D 的等价物),而 libA.a 依赖于 libB.a 和 libC.a,它们都需要首先构建 libD.a(可能是一些头文件)和/或生成的源)。您可以使用“链接库”阶段(又名解决方案#1)来完成这一切,但在这种情况下,您最终会在 libA 的最终链接版本中获得 libD 中 .o 文件的两个副本。如果您这样做足够深入(例如,一个工作区有 40 个项目,这些项目彼此之间具有不同程度的依赖关系),您很快就会得到巨大的库文件,其中包含几个相同的 .o 文件,并且您的链接时间将变得可怕。

If you think these are contrived situations, I'm currently hitting both of them moving some legacy code from a series of explicit dependencies to implicit dependencies. Why am I moving to implicit dependencies? Because explicit dependencies in Xcode require project nesting, and once you get enough explicit dependencies, the project browser gets extremely slow, and you will see a lot of beachballs inside of Xcode for random things.

如果您认为这些是人为的情况,我目前正在尝试将一些遗留代码从一系列显式依赖项移动到隐式依赖项。为什么我转向隐式依赖?因为 Xcode 中的显式依赖需要项目嵌套,一旦你得到足够多的显式依赖,项目浏览器就会变得非常缓慢,你会在 Xcode 内部看到很多随机事物的沙滩球。

What happens if you happen to have two targets inside the same workspace that generate products with the same name and depend upon them from a third target? Implicit dependencies will pick one. It appears to do a match based on the base name of the product (so foo/bar.a and baz/bar.a are the same), and will pick the first one it finds.

如果您碰巧在同一个工作区中有两个目标生成具有相同名称的产品并依赖于来自第三个目标的产品,会发生什么情况?隐式依赖将选择一个。它似乎根据产品的基本名称进行匹配(因此 foo/bar.a 和 baz/bar.a 是相同的),并将选择它找到的第一个。

回答by yoAlex5

Xcode Dependency[About]is a dependency required to builda selected target.

Xcode Dependency[About]构建选定目标所需的依赖项。

Implicitdependency

Implicit依赖

  • source codeaka Non-compiled dependencies. Xcode allows to add a dependency from the whole workspace. A good example is a Project from GitHub or CocoaPods[About]with source code
  • closed codeaka Precompiled dependenciesaka External- external binary, CocoaPods, Carthagewith closed code
  • 源代码又名Non-compiled dependencies。Xcode 允许从整个workspace. 一个很好的例子是来自 GitHub 的项目或带有源代码的CocoaPods[About]
  • 封闭代码又名Precompiled dependencies又名External-外部二进制,CocoaPodsCarthage与封闭的代码

Implicit dependencyis a dependency that is necessary to successfully build a target, but aren't explicitly defined.

Implicit dependency是成功构建目标所必需的依赖项,但未明确定义。

  1. No dependency in Build Phases -> Target Dependencies
  2. Specified in General -> Embedded Binariesand Linked Frameworks and Libraries[Link vs Embed]
  1. 没有依赖 Build Phases -> Target Dependencies
  2. General -> Embedded Binaries[链接与嵌入] 中指定Linked Frameworks and Libraries

To turn on this functionality[No such module]

开启此功能[无此模块]

Edit Scheme -> Build -> Find Implicit Dependencies

[Explicit dependency]

[显式依赖]

[Vocabulary]

[词汇]