Re: Library Location
Re: Library Location
- Subject: Re: Library Location
- From: Richard Charles <email@hidden>
- Date: Tue, 14 Mar 2017 06:51:36 -0600
> On Mar 13, 2017, at 7:12 PM, Quincey Morris <email@hidden> wrote:
>
> In regard to the desirability of using shared folders, I think I’d put it this way: I have no problem with a specific workflow that leverages a shared build folder between (say) project A and project B like you have. However, in that case, I think it would be better to achieve that by using the File -> Project Settings dialogs in the two projects, rather than changing your Xcode preferences.
>
> If nothing else, by changing the settings globally, you risk file name clashes in future, when building different projects that happen to re-use the same names for sub-components that come from different source code. Let’s say you duplicated your library project to make a version with additional logging, that you might occasionally use to debug intractable bugs. Your two library projects would then interfere with each other, unless you were very certain to rename everything (targets, modules, etc) that affects build directory file names. You risk very hard-to-find bugs as a result of using un-recompiled files.
Point well taken.
> On Mar 13, 2017, at 12:26 PM, Quincey Morris <email@hidden> wrote:
>
> But there’s something else going on here that complicates understanding. What you open in Xcode is not really a project, but a workspace containing the project. In the simplest case, when you use File -> Open and choose a project, what gets opened is a private/invisible workspace which logically contains the project, although the workspace file (with workspace settings in it) is embedded within the project file package. Xcode actively maintains this fiction, for example by changing the “Workspace Settings” item on the File menu to “Project Settings” when the workspace is embedded in the project privately.
Yes you are exactly right. When you change the Derived Data: location using File > Project Settings rather than Xcode > Preferences > Locations you are actually changing a setting in the private/invisible workspace. The embedded project file never gets modified and the change will never be committed to the git repository. This make sense because the workspace is meant to be a more flexible container which is able to adapt to individual needs. So it is best to keep this kind of information out of the repository. So as you pointed out File > Project Settings became an illusion when Apple introduced workspaces.
Another point to make is that all of the Derived Data: Advanced settings are completely hidden from view in the user interface and only exposed or visible when the Advanced button clicked again. So it is very easy to forget that a change to this setting was ever made. So I guess Apple figures that if you are smart enough to use the advanced setting you are smart enough to remember than you did it.
Also none of the Derived Data: Advanced settings can be put into an Xcode configuration file. This is because this setting is not a build setting in the normal sense. It is a setting that is over, above, or beyond all other build settings contained in the embedded project file.
Thanks for your help and insight with this issue.
--Richard Charles
_______________________________________________
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