How do you get implicit dependencies to work with workspaces in Xcode 4?

Question

I want to manage projects in workspaces using Xcode 4 with Cocoa Touch Static Library projects which contain shared code that I could reference from other projects. Accordin

Answer 1

Here is all instructions in one Google Docs document.

Answer 2

To solve problems regarding spaces in the user header search paths, use

"${BUILT_PRODUCTS_DIR}"

Answer 3

I have just spent the best part of two days building and rebuilding our project, struggling with just this very issue. Whilst I now have a project that builds and links correctly AND has working codesense I am not 100% happy with one of the steps as it seems to be a bit of a hack and certainly doesn't fit my concept of "Automatic implicit dependencies".

FWIW here are the steps I took:

1. Create a new Workspace in Xcode.
2. Add a new project to the workspace for your static library. You can also add an existing project, I found this to work too.
3. Test that the library builds as expected.
4. Add a new project to the workspace for your main project. Again I managed to add an existing one, but importantly it did not have any build settings already that linked to the library. If you add a new project its fairly easy to just add existing source files to it. My particular situation was complicated by a very large pre-existing SVN repository that I did not want to restructure.
5. At this stage I am going to assume that your source code already contains imports of headers from the static library.
6. In the build phases for the main project, expand the "link binary with libraries" section and click the + symbol. Select the target from your static library project.
7. If you want at this stage you can build the main project to confirm that it fails as shown in the OP screen shots with "No such file..." errors for the header imports.
8. Now this is the bit I don't really like. In your main project create a new group and call it Dependent Headers or whatever. Now in the project navigator drag any used headers from your static project to this new group. In the options pop up I just left it as the default settings.
9. You may also need to link your main project with any dependent libraries used by your static library. For example my static library makes use of libxml2 and CFNetwork and even though my main project does not use them directly I had compile errors if I did not add them to the "link binary with libraries" build phase.
10. Your main project should now (hopefully) build.

I really don't like steps 8 and 9. This really feels like XCode is not doing what it is advertised to do. However if and when it gets fixed at least these steps are fairly easy to back out so that it works correctly.

I think "implicit dependencies" should work without needing to go past step 6, maybe even step 5 but that might be a little bit too automagical for a lot of people's taste.

Answer 4

This really does seem to be a bug in Xcode's handling of implicit dependencies during the build process.

In a workspace with two projects, I was able to have Project A see classes in Project B and successfully build by copying the .h header files for Project B's classes into Project A's directory. NOTE: I did not add them to Project A in Xcode I just put them in Project A's directory in the Finder.

This is a much easier solution than I've seen outlined elsewhere, as it requires no changes to workspace schemes or to the build settings of either project. With the .h files in Project A's directory, Xcode was able to automagically find and resolve all of Project A's implicit dependencies on Project B.

Unfortunately you cannot put the .h files in their own subdirectory called "XcodeBugWorkaroundHeaderFiles". They have to be in a directory that the project is already reading .h files out of. Also, Aliases won't work, but Symbolic Links will, so by using SymLinks you don't have to worry about out-of-date copies.

With all of this said, I'm not sure that having "stealth" .h files that the build build will fail without is a good idea, though. Until the bug is fixed in Xcode, it is probably best just to add them to the project so you can see them in Xcode.

Answer 5

I got this to work by doing the following. 1. Adding the Library as a second project to the workspace. 2. Link Binary with Libraries > Add the static library.

-- THE IMPORTANT PART --

1. Add the following to the "Header Search Paths" under build settings

   ${BUILT_PRODUCTS_DIR}

This will link the built header files to the project. No more build errors.

Answer 6

Another option is to just include the root of each "subproject" as a recursive header path. For example if you have AcmeLib, you can go to the main project's build options and add the path to AcmeLib to the User Header Search Path, with the recursive option enabled. Then your AcmeLib's header files will be automatically searched.

To maintain path independence between developers you can make the path relative to an source directory variable, say $ACME_LIB, which each developer can device in the XCode preferences "Sources" pane.

So to use AcmeLib in a new project, just drag in the project, add $ACME_LIB to the header search path, and you are good to go. XCode's implicit linking should hook up the dependencies.