views:

65

answers:

1

I have a relatively simple goal: I want to create a Cocoa application which doesn't have much functionality itself, but is extendable through plugins. In addition I want to work on a few plugins to supply users with real functionality (and working examples).

As I am planning to make the application and each plugin separate open-source projects (and Git repositories), I'm now searching for the best way to organize my files and the Xcode projects. I'm not very experienced with Xcode and right now I don't see a simple way to get it working without copying files after building.

This is the simple monolithic setup I used for development up until now: There's only one Xcode project with multiple products:

  • The main application
  • A framework for plugin development
  • Several plugin bundles

What I'm searching for is a comfortable way to split these into several Xcode projects (one for the application and framework) and one for each plugin. As my application is still in an early stage of development, I'm still changing lots of things in both the application and the plugins. So what I mean by "comfortable" is, that I don't want to copy files manually or similar inconvenience.

What I need is that the plugin projects know where they can find the current development framework and the application needs to know where it can find the development plugins. The best would be something like a inter-project dependency, but I couldn't find a way to setup something like that in Xcode.

One possible solution I have in mind is to copy both (the plugins and the framework) in a "Copy Files Build Phase" to a known location, e.g. /tmp/development, so production and development files aren't mixed up.

I think that my solution would be enough, but I'm curious if there's a better way to achieve what I want. So any suggestions are welcome.

+3  A: 

First, don't use a static "known location" like you mention. I've worked in this kind of project; it's a royal pain. As soon as you get to the point of needing a couple of different copies of the project around (for fixing bugs in parallel, for testing a "clean" build versus your latest changes, for working on multiple branches), the builds start trashing each other and you find yourself having to do completely clean/builds much more often than you'd want.

You can create inter-project dependencies by adding the dependent project (Add File), right click the Target and choose "Get Info," and then add a Direct Dependency on the General pane.

In terms of structure, you can either put the main app and framework together, or put them in separate projects. In either case, I recommend a directory tree like:

/MyProject
    /Framework
    /Application
    /Plugins
        /Plugin1
        /Plugin2

Projects should then refer to each other by relative paths. This means you can easily work on multiple copies of the project in parallel.

You can also look at a top-level build script that changes into each directory and runs "xcodebuild". I dislike complex build scripts (we have one; it's called Xcode), but if all it does is call "xcodebuild" with parameters if needed, then a simple build script is useful.

Rob Napier
This sounds reasonable, so I'll definitely try this.
Koraktor
It works! Although the "Framework Search Paths" had to be changed to `"\"${SRCROOT}\"/../Application/build/${CONFIGURATION}"`. Otherwise the header files won't be found. All together this isn't a really straight-forward design, but this is a limitation of Xcode.Nevertheless, thank you very much!More: http://www.devklog.net/2007/10/07/improving-the-xcode-sub-project-experience-with-scripts-and-wits/
Koraktor