On Jun 6, 2014, at 2:59 PM, Quincey Morris wrote: On Jun 6, 2014, at 10:45 , Fritz Anderson < email@hidden> wrote: Workspaces aren’t meant to be shared I don’t want to be dogmatic about it (in case I’m wrong) but there’s no problem sharing workspaces AFAIK. Indeed, a shared workspace is an integral part of the automatic clone mechanism that Xcode 5 introduced, IIRC.
Alex’s problem is that a workspace is expected to enclose a reasonable source hierarchy, and if the file names are ambiguous within the workspace then bad things can be expected to result. Perhaps there are some advanced Xcode things that can be done to resolve the ambiguity (header maps and preferences->source trees come to mind as features I’ve heard of but never used), but otherwise a better approach might be to resolve the file ambiguities and/or use multiple workspaces.
Unfortunately, what Xcode does to search for header files (which I suspect is the heart of Alex’s problem) is a mixture of C standard requirements, C pragmatic conventions and Xcode’s own obscure rules. It probably takes some superhuman abilities to understand all 3 and how they interact.
Yeah, thanks. To be clearer, here's the structure of our workspace from the Project Navigator view:
SDK Group SDK 1 SDK 2 Other SDK Apps Group This Awesome App This Other App That Stupid App
Assume that we have a HelpScreenViewController class in All the apps within the Apps group. Assume that they are each different for each app.
Now, assume that there are libs, .a files, that are in each of the SDK group folders. Assume that we will want all of the apps in the Apps group to be able to link to these SDKs.
Now, what happens, is that Xcode wants to let each app see all the classes and view controllers of all the other apps in the workspace.
This is bad. This is not what we want. A storyboard scene within one all will see HelpScreenViewController and it's not only the Help ScreenViewController from that app. It's all/any of them from the entire workspace. Sometimes when replacing a file in an app, Xcode ends up picking one of the other files with the same name from within that workspace. It does not limit where the file could be from to only within that app's folder/group.
If we have classes that are not view controllers, called something like "DataStorage.m/h", or "projectColors.m/h" within multiple apps in the workspace, there is namespace collision within the workspace where one app can (and does) see (and sometimes use) the .h/.m files from other one of the other applicatiopns in the workspace.
What also happens is this: Xcode does let each app see all the libs in the SDK group projects.
This is good. This is exactly what we want.
What I am asking is this, "how can we properly structure our workspace, our apps group and our SDK group so that we can get the lib sharing that we want, but prevent the other issue of one app having access to all the other classes and view controllers in every other app in the workspace?"
We work in a source code controlled environment. Nothing is shared ala file sharing. Everyone checks out a working copy from the repo and updates and commits on a daily basis.
If there are other things, such as those that Fritz referred to, I/we have no idea what they are. We're not emailing around a workspace, it's not shared on a file server, everyone on our team modifies their own checked out local version on their own HD/SSD and commits back to the head trunk on the server.
Thanks guys.
|