Ios – Xcode: How to make xcodebuild build a project that contains sub-projects

I’ve just set a test project up, pretty much as you describe in version 3, by creating a new workspace and dragging the two Xcode project into it, nested as shown.

You can delete the sibling project if you have it already.

Hitting build on this and it just works, as far as I can see.

I imagine there is internal path-confusion if you have two projects, and I’d be inclined to fiddle with location settings in "View"->"Utilities"->"File Inspector" and see what effect that has.

Another thing to try is to set your paths up in Xcode "Preferences…"->"Source Trees" and refer to them that way, as described here: Easy, Modular Code Sharing Across iPhone Apps: Static Libraries and Cross-Project References

HTH. Andy W.

You are definitely on the right track with respect to the .xcscheme file -- I had this problem appear while setting up my own projects!

For posterity, or at least anyone getting here from a search, here are two versions of things -- the "I'm busy, so just the facts please" version and a more involved discussion and rationale. Both of these versions assume you are trying to build from a Workspace file; if you aren't then my apologies as this mostly applicable to workspace-based projects.

Condensed 'Fix-it' Version

The root cause is that the default behavior of Schemes is to keep schemes 'private' until they are specifically marked as shared. In the case of a command-line initiated build, the Xcode UI never runs and the xcoderun tool doesn't have its own cache of Schemes to work with. The goal is to generate, share, and commit the scheme you want Bamboo to run:

1. On a clean working copy of the code, open your Project's workspace.
2. Choose Scheme > Manage Schemes... from the Product Menu.
3. The list of Schemes defined for the project appears.
4. Locate the Scheme Bamboo is trying to run
5. Ensure the 'Shared' box is checked for that scheme and that the 'Container' setting is set to the Workspace and not the project file itself.
6. Click 'OK' to dismiss the Manage Schemes sheet.
7. A new .xcscheme file has been created in your project at WorkspaceName.xcworkspace/xcshareddata/xcschemes.
8. Commit this file to your repository and run a Bamboo build.

Deeper Discussion and Rationale

Xcode 4 introduced Workspaces and Schemes as a way to help try and tame some of the chaos that is inherent to dealing with the mechanics of wiring related Xcode projects, build targets, and build configurations together. The workspace itself has its own set of configuration data that describes each of the smaller 'boxes' of data it contains and acts as a skeleton for attaching .xcodeproj files and a set of shared configuration data that gets mirrored to each developer machine or CI system. This is both the power and pitfall of Workspaces -- there are 1) lots of ways in which one can get things configured 100% correctly, but put into the wrong container or 2) put into the correct container, but configured improperly thus rendering data inaccessible by other parts of the system!

The default behavior of Xcode 4 schemes is to automatically generate new schemes as projects are added to the Workspace file. Those of you that have added several .xcodeproj files may have noticed that your scheme list quickly becomes unruly especially as project files are added, then removed, and then readded to the same workspace. All schemes, autogenerated or manually created, default to being 'private' schemes visible only to the current user even when .xcuserdata files are committed with the project's data and configuration. This is the root cause of that cryptic build error Bamboo reports from xcodebuild -- Because Bamboo operates the build through the command line and not the Xcode UI, it doesn't have an opportunity for Schemes to get automatically generated and relies only on those that are defined in the workspace itself. Assuming you've configured Bamboo to build from a workspace using a command like this:

xcodebuild -workspace MyWorkspace.xcworkspace -scheme MyApplication -configuration Debug

xcodebuild goes looking for file <'scheme' Parameter Value>.xcscheme existing at <'workspace' Parameter Value>/xcshareddata/xcschemes.

Obviously there are bunches of ways in which one could configure both Bamboo and a workspace, so keep in mind that your unique configuration may not map 100% to what is presented here. The key takeaways:

1. Certain automated tasks the Xcode UI magically takes care of are not available via the Xcodebuild CLI.
2. You can attach scheme and build configuration data to many places in the 'container hierarchy' -- Make sure your data winds up in the right container (Workspace, Project, and/or Build Target)
3. Consider where in the container hierarchy the xcodebuild tool may be looking for configuration data; a great indicator of where it will start looking is based on the use of '-workspace' or '-project' arguments.

The 'Shared' box is already checked...now what?

I encountered this same issue on my own Bamboo instance; it turned out that the scheme that was committed in my repository was outdated and the latest version of the command line tools wasn't handling it gracefully. Since this existed previously, I took a look through the settings to make sure there wasn't anything glaringly custom about the scheme, deleted and recreated the scheme ensuring that I marked it as 'Shared', and recommitting the new .xcscheme file to the repository.

If everything looks good and rebuilding it doesn't solve the issue, double check that container setting -- it is really easy to get that scheme attached to the wrong container in the hierarchy!