6

I have a workspace, Application.xcworkspace, that builds two frameworks and an executable that uses those frameworks. Here is roughly how they are laid out:

  • Framework_1 - Built and output to ugly DerivedData path.

  • Framework_2 - Depends on Framework_1, which is included in the Frameworks area of the project and specified in the "Link Binary with Libraries" Build Phase, and output to ugly DerivedData path.

  • Application - Depends on Framework_1 and Framework_2, which are included in the Frameworks area of the project and specified in the "Link Binary with Libraries" Build Phase. Output directory is again that ugly DerivedData path.

The problem I have is that the paths in the project file for the referenced frameworks are the DerivedData ugly path - they are like ../../Library/Developer/XCode/DerivedData/Application-longuglyuniquestring/Build/Products/Release/Framework_1.framework.

If I copy the source to another directory, or check it into version control and check it out to another machine, then those framework paths are no longer valid. They get re-generated. The referenced frameworks show up as red in the project.

So far, when I want to build the workspace in another folder, the way I have fixed the problem is to:

  • Build the workspace - Framework_1 builds.
  • Go to the "Products" node for that framework and show it in Finder.
  • Copy the new ugly path.
  • Open the project files for Framework_2 and Application and correct the path for Framework_1 and Framework_2.
  • All the red items should be resolved and everything should build.

That process is tedious and I am lucky the project file can be edited. It is worse for colleagues that do not understand the little I know about the project files, and just want to check the code out and have it build.

Is there something I need to do to the Build Output Directory for the frameworks? I have been leery of changing it since the ugly path is recommended. Is there a copy files option I can use to put those frameworks in some predictable location relative to my workspace?

Any help would be appreciated. I am sure I am missing something simple - it makes no sense that code checked out of source control or copied to another directory would not just build.

GTAE86
  • 1,780
  • 3
  • 29
  • 39
  • That's unusual as I have a workspace with a `.dylib` and `.app` and they are both put into the same folder (`.../DerivedData/.../Build/Products/Debug`). I then have a script as part of the `.app` build to copy the `.dylib` into the `.app/Resources/Frameworks` directory. – trojanfoe Oct 10 '13 at 16:15
  • Not a problem with app outputs - all the required frameworks are put in the app /Frameworks directory. This is a build-time problem. Included framework binaries, used in "Link Binary With Libraries" Build Phase are in the app DerivedData directory. That directory changes when the project is built from a different directory. All project files/source are under one directory under root. If I copy them to another directory, the project will not build because the library paths for linking will be different. – GTAE86 Oct 10 '13 at 17:12
  • If the old directory and new directory are peers, then the problem will be masked because the relative path to the old binaries will still be valid. That can result in changes made to referenced frameworks not "showing up" in the app because it is still linking with the old versions. Easiest way to see the problem is to copy source to a machine that is clean with respect to the workspace/projects. Even though everything is in place, it will not build until the paths for linking to frameworks are corrected. – GTAE86 Oct 10 '13 at 18:29
  • It looks like I could go to XCode Preferences, Locations and set the Build Location to Custom, Relative to Workspace, but that seems like it would apply to all projects. That is, there does not seem to be project-level granularity.... Not sure if that is a good thing or not. From looking at https://developer.apple.com/library/ios/recipes/xcode_help-locations_preferences/DerivedData/DerivedData.html, it seems the only downside would be the dangers of checking binaries into SCM or inadvertently sending them to others. – GTAE86 Oct 10 '13 at 20:02

1 Answers1

2

Looks like there is a way to set the DerivedData directory on a per-workspace basis - Xcode 4 - build output directory

I just set DerivedData to be relative to my workspace, then edited the project files accordingly. The only down-side is if I were to use one of those projects in another workspace that was using the default DerivedData path, I would have to change them back.

Many thanks to user DaGaMs - he got an upvote.

I am still seeing bad behavior from XCode 5: I got the project working on my machine. Copied it to another, lower, directory and verified it still worked. Exited XCode and copied the containing directory to a network drive, and from there onto another Mac. When I opened it on the other Mac it was like I never made some of the changes. Even worse, as I worked to fix it, XCode went nuts and added 6 extra '\' characters to each end of my FRAMEWORK_SEARCH_PATHS paths!

Part of the problem stems from the subproject directories in my app being absolute rather than relative. The projects in the top of the workspace are "Relative to Group", so I changed the subprojects to have the same attribute. That seems to have solved the problem, though for some reason when I copy all the files to another machine, the Derived Data redirection does not go with it.

Community
  • 1
  • 1
GTAE86
  • 1,780
  • 3
  • 29
  • 39