Project roots vs various search paths
Project roots vs various search paths
- Subject: Project roots vs various search paths
- From: Fritz Anderson <email@hidden>
- Date: Fri, 26 Feb 2010 10:13:56 -0600
Can I have some clarification about what project roots can do for me? I find that feature, and including one project in another, have surprisingly little effect on cross-project functionality. I need to know for instructional purposes.
Here's what the Xcode 3.2 release notes say:
> Xcode supports multiple project roots for a single project to configure a project made up of multiple independent directories. This supports certain project configurations where the project sources are scattered across several directories. Identifying each directory separately instead of a a single root directory, which may contain undesired subdirectories, significantly improves the performance of snapshots, source control, and project find operations. It has no effect on building.
Here's my scenario:
StatProject.xcodeproj and AppProject.xcodeproj, and their respective source code, are in sister directories. Both are controlled under Subversion.
StatProject has libStat.a as one of its products. AppProject will require libStat.a. The user adds StatProject to AppProject.
He also adds ../StatProject/ to AppProject's project roots.
The user would like to have as much access as possible to StatProject from the AppProject window.
FIRST UNEXPECTED THING: He opens the General tab of Target "App" Info. He makes App (AppProject's only product) dependent on StatProject > libStat.a. He then tries to add libStat.a to the linked libraries list by clicking [+]. The list of available libraries and frameworks contains only the OS SDK libraries, NOT StatProject > libStat.a. If libStat.a were a direct product of AppProject, it would be listed. He is surprised and chagrined, as he thought he'd done everything possible to make AppProject aware of StatProject.
To accomplish the same thing, in the Groups & Files list, he drags libStat.a from StatProject into the Link... phase of App.
He'd like to #import "Stat.h" in an AppProject .m file. He types '#import "Sta' and waits in vain for CodeSense to complete it. The multiple roots feature "has no effect on building," so even when the #import is completed, gcc doesn't find the header; that's disappointing, but the user had been warned.
The non-completion is the SECOND UNEXPECTED THING, because, again, he'd thought he'd done everything possible to make AppProject aware of StatProject and its directory. Completion doesn't work with libStat.a's symbols, either.
He'd like to look up some libStat.a API. He opens the Project Find window, and enters 'NewStats'. The string is not found as a literal, which is the THIRD UNEXPECTED THING, as the release notes really do say "project find operations" benefit from multiple roots.
FOURTH UNEXPECTED THING: But Project Find _does_ find NewStats as a symbol, even though CodeSense won't complete any of libStat.a's symbols in the editor.
FIFTH UNEXPECTED THING: Even though NewStats shows up in a search for symbols, it does _not_ turn up in the project "Symbols" group.
The Unexpected Things are still there if StatProject is open at the same time as AppProject. I do know that if it were, during debugging, the two would share breakpoints.
SUMMARY AND QUESTIONS:
So it appears that while multiple project roots relieves some (potentially big) headaches with SCM, and tucks away a benefit for global symbol _searches_, it doesn't do anything else that one might think of as being part of a project's structure. Further, no benefits (aside from build dependencies and configuration-sensitive linkage, which ain't hay) accrue from including one project in another.
1) In general, do I have this right?
2) Is there a clean way to get cross-project symbol sharing?
3) Search path sharing?
This may all be a matter of, "Great feature ideas. Post some Radars," but I want to be sure I'm not missing something.
— F
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden