In an Xcode 4 workspace, how do I cascade build settings & configs to subprojects

Question

Overview

I'm using static libraries and Xcode 4 workspaces to effect modularity in iOS development, an increasingly common technique. For example, I might have a workspace which contains an App project, and a Library project, like so¹:

You would then have a scheme to build these that looked something like this:

What I would like to do is have the "App build" control the "Library build" it initiates, in at least a couple of ways:

1. Map App configurations (e.g. Debug, AdHoc) to arbitrary Library configurations

2. Passing through some subset of -D defines, and/or specifying these for the library build.

I'll deal with each of these in their own section, but it's worth making a few clarifications.

Clarifications

• I'm using App/Library here as an easy proxy for any Superproject/Subproject relationship you may have.

• From what I've seen, Xcode 3 style embedded subprojects don't seem to work any differently in Xcode 4 than workspace "peers". I'd love to be wrong about this.

• I know I could do almost anything with a "Run Build Script" build phase, and xcodebuild. But I'm trying to work within the system here, where the dependencies are specified in the scheme, and otherwise somewhat loosely coupled.

• The Library exists to be used in more than just this project, and so you cannot arbitrarily load it up with junk specific to this App's build, or reference anything particular to the App or Workspace. For the general case, this rules out including static .xcconfig from the App project as a way to convey build information from the App to the Library.

• Building the Library outside the workspace sacrifices too much, not an option.

Configuration Mapping

As I understand it, building a particular App configuration will:

1. If a configuration exists in the Library of the same name, it will build the Library using that.
2. Otherwise, it will build the active configuration of the Library, as specified in the Library's project file.

To my knowledge, without resorting to the aforementioned run-build-script hack, that is the extent of the control one has over subproject build configurations. Please tell me different.

Ideally, I would be able to specify (in the scheme, presumably):

AppConfigA -> LibConfig1
AppConfigB -> LibConfig2

While Debug, AdHoc, & Release may be the only configurations some ever use, complex projects often outgrow that.

Defines

I've not yet found way to pass -D defines from the App build to the Library, without resorting to xcodebuild, which can take, e.g., an .xcconfig file.

The App's build settings can be accessed in Library build run-build-script phase. However, doing that introduces a dependency in the Library on the App project, which for good reason is verboten (cf. Clarifications). But even then, I haven't found a way to use those settings to directly control the Library's build (much²).

So crazy it just might...

One scheme I came up with while writing this would be:

1. The Library bases it's build configurations on an empty (dummy) LibraryExternals.xcconfig file within it's own project.

2. A clean of Library deletes that file. A standalone build of the Library will create an empty one if it does not already exist.

3. That file is overwritten by an App Build run-build-script phase, and contains anything the app wants to communicate to the Library build.

Seems kind of complicated, but I'm looking for anything right now. I'll push this to an answer if nothing better comes along.

---

¹ Apps shown are Max OS X. I find command line apps make for simpler tests. Same applies.

² Cf. Info.plist preprocessing, which I learned about during this investigation.

Answer 1

If you modify your project structure to use a single project with multiple targets then each target's build settings will automatically inherit from the project. From there, you can modify ones that you want to be different, or select an individual setting and press the delete key to set it to the default specified by the project.