Using Open Source Static Libraries in Xcode 四

Using Open Source Static Libraries in Xcode 4

Xcode 4.0.1 allows us to more easily create and use third party libraries in iOS projects. I think the process is still more complicated than it needs to be. Xcode’s documentation suggests that it should automatically detect implicit dependencies and index classes across workspaces but I have not found this to be the case. Here I’ll cover the steps I have found for creating and sharing code between projects and with other developers.

1. Background
2. Using a Static Library
3. Creating a Static Library
4. Future Improvements

Background

Workspaces:

Xcode 4 introduced the concept of?workspaces?as containers for multiple projects. There are a couple of key behaviors of workspaces which we want to build on when choosing how to share code across projects.

• By default, all the Xcode projects in a workspace are built in the same directory, referred to as the workspace build directory.
• Xcode examines the files in the build directory to discover implicit dependencies.
• Each project in a workspace continues to have its own independent identity.

  Schemes:

  Within a workspace or within a project which is a member of a workspace we have?schemes. Schemes replace the Active Target, Build Configuration, and Executable settings from Xcode 3 and define which targets to build, the order in which to build them, and what action to take when a build is complete. We’ll want our shared code to easily fit into the scheme of any projects which use it. The?Xcode 4 Transition Guide?covers this new structure in more detail.

  Targets:

  Within a scheme we have one or more build?targets?which define a set of source files to build, the settings used to build those files, and any dependencies on the build products of other targets which must be completed first. Ultimately we would like a consumer of our code to be able to state that their project’s build target depends on our shared code and have Xcode build this shared code and make it available to the active build target. We can achieve that by providing a project containing the code to be shared and a static library build target which packages it into a build product other developers can add as a build target dependency.
  

  Using a static library

  1. Creating a workspace
  2. Adding projects to a workspace
  3. Adding build target dependencies
  4. Adding the static library’s headers
  5. Configuring the project’s scheme
  6. Fixing indexing

  Creating a workspace

  We can create a new empty workspace from Xcode’s file menu or open an existing project and select “Save As Workspace…” to create a new workspace containing our project. This will create a “.xcworkspace” package in the file system.

  
  

  ?

  Adding the static library’s headers

  We also need to make sure that our app’s build target can locate the public headers used in this static library. Open the “Build Settings” tab and locate the “User Header Search Paths” setting. Set this to “$(BUILT_PRODUCTS_DIR)” (or “$(BUILT_PRODUCTS_DIR)/static_library_name” if we want to be more specific but then we’ll have to update this setting every time we add another library) and check the “Recursive” check box. Now our built target will search our workspace’s shared build directory to locate linkable header files.

  ?

  Setting the public headers path for the static library

  
  

  ?

  Exclude user specific files from VCS

  Our workspace and project include a number of files which contain data relevant only to our user account; window positions, open files, and so on. There’s no need to check these into source control, at least not in our release branch, so let’s set some reasonable ignore rules in git or whatever VCS we are using. Github provides a convenient set of?.gitignore files
  

  Future Improvements

  Hopefully Xcode 4 will eventually live up to the promise of it’s documentation and consistently auto-detect implicit dependencies and index files across the workspace correctly. There certainly seem to be a number of other developers struggling with this behavior:[1], [2], [3], [4], [5], [6], [7], [8]. Until that indexing improves I find that this process is at least somewhat simpler and cleaner than trying to maintain simulator and device compatible static library builds in Xcode 3.
  I’ve found this pattern preferable to copying third party classes directly into my projects as it allows me to easily keep version history and make updates to static library projects in my workspace and avoids coupling my project too closely to the private structure and contents of the static library.
  Please let me know if you can see any areas where this pattern could be improved or if you’ve found your own alternative means of sharing code.

  转载：http://blog.carbonfive.com/2011/04/04/using-open-source-static-libraries-in-xcode-4/