On Feb 19, 2007, at 12:04 PM, Rua Haszard Morris wrote:
Xcode does not have support for "sub-projects." Xcode has support for cross-project references; a referenced project is a peer of the referencing project. The only information passed between projects is at build time, and that's only the name of the configuration to build.
Understanding this should make clearer a lot of Xcode's behavior when dealing with multiple related projects.
Understanding the limitation doesn't make it acceptable, or at least comparable with CodeWarrior, which did a fantastic job.
A lot of what developers used targets for in CodeWarrior, Xcode uses configurations for. For example, when I was a CodeWarrior user, I had to have completely separate targets for my debug build, my debug build with optimizations on, my release build, etc.
In a similar vein, a lot of what developers used "sub-projects" for in CodeWarrior and Visual Studio and Eclipse, Xcode uses targets for. For example, let's say I want to create an application and a framework that only it will use. In CodeWarrior, I would probably create two projects (mostly because it would be a headache to maintain debug/release targets for each built component in a single project). In Visual Studio or Eclipse, I would create a solution (workspace in Eclipse) and create two projects in it, one for the application and one for the framework. In Xcode I would create a project with two targets, an application target and a framework target.
Given the above, it's well-understood that developers would like cross-project references to be more fully-featured.
Try doing a command click to find a symbol that's defined in a sub-project. You'll be lucky if it ever finds it.
If that symbol declared in a header imported by the project you're working with, its should be found in that header.
"imported" - do you mean added to the project, or #included in a file that is in the build?
My guess is "added to the project", because these are the symbols that I always need Xcode to find for me and it doesn't.
Actually, I meant "#imported or #included." If you #import (Objective-C) or #include (C, C++) a header that has the declaration for a symbol, Xcode should have that symbol declaration in its project index. Command-double-clicking that symbol in your source code should take you to its declaration.
It still won't take you to the definition of that symbol in a different project, because Xcode doesn't necessarily know that the declaration of the symbol in the index for project A strongly corresponds to the definition of the symbol in the index of project B.
It won't necessarily find the definition of that symbol in another project because, as I said above, Xcode does not have "sub-projects" — only references to peer projects.
And this limitation is what a lot of users have a problem with.
Understood. I'm just trying to point out why Xcode behaves the way it does. Xcode's project model is different than CodeWarrior's, and understanding how and why it differs will ultimately save you time and frustration when working with Xcode projects. It certainly doesn't mean that there's no room for improvement in Xcode's project model.