This answer applies to Xcode 8.x, and I think for 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.
A target “A” can be made “implicitly” dependent on target “B” in two ways:
- Target A has a “Link Binary With Libraries” build phase that has a library in its list that has the same name as 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.
- Target A has a “Copy Files Phase” that copies a file with a base name that 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).
So why would anyone ever want to do the horror that is “2”? I can come up with a couple of reasons.
- 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.
- 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.
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.
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.