One of our builds was breaking recently, and the error messages reported from Xcode 3.0's xcodebuild command were unusual. Xcode 3.0 has broken dependency handling, at least in one case.
The setup: our build has a number of dylibs, but the basic idea is that the failed build is project A, which is building libA.dylib, and depends on Project B's libB.dylib. If this was all the interaction that project A and B had, there is no problem. But project A also must copy libB.dylib into a local "dist" directory. With this addition, Xcode reports a build error: "target B may depend on itself." Visually, the project layout is like this:
The "Copy Files" build action is problematic. This build action is copying the libB.dylib (from B's project build directory) into A's project's "Product" directory. Xcode 3.0 has trouble differentiating the source of B from the copy of B, and reports that B depends on itself. Further, if I remove that Copy Files action to isolate it in a sibling Target of A, the problem persists, and the build fails again.
The workaround is to remove the normal Copy Files action, and perform an explicit copy from a shell script. This doesn't have the dependency issues of a Copy Files action, and in fact makes this aspect of the build a little "looser" (not strictly bound to checked dependencies). By bundling targets together, the shell script execution condition can be tighted to a reliable state.
"But," you may ask, "why does this matter if Xcode 3.1.x is the current version?" While my team is using 3.1.x for our development, the automated build systems we use are not; they have 3.0 installed. Xcode 3.1.x does not have this dependency-handling bug for Copy Files. Also, this bug is unaffected by Xcode project file version, and we tried this with 2.4- and 3.0-formatted project files to the same effect.