iOS-在另一个Xcode项目中包含静态库项目…标头问题

Question

So here's the scoop:

I have an xcode project that builds a standard library. This standard library produces a ".a" file, along with a few header files that need to be visible to whatever client is using said lib.

The standard lib builds to a set directory:

/builds/foo/bar/build/

Which looks like this after I build the library:

/builds/foo/bar/build/
    lib.a
    headers/
        head1.h
        head2.h
        head3.h

I have a client application that needs to consume this library. It's required that I rebuild the standard lib with every build of the client app, so I set it up as follows:

I created a client application, added the standard lib .xcodeproj file to it, and hooked it up as a direct dependency. I linked it appropriately in the "Link Binary with Library" section. Then, following standard suit, I set it up the client app to search for the header files at the following location:

/builds/foo/bar/build/headers/

And this works... sort of. If I delete the directory listed above and try to rebuild, it will fail because it cannot find the header files.

"Well, Duh! You deleted the directory that contains the header files!".

True, but the way the client build is setup is such that the static library is compiled and placed within /builds/foo/bar/build directory (including header files), before the client application builds. It SHOULD be finding these header files. They exist before the client is compiled, and the 'Header Search Path' is set correctly.

As I said before, if I delete the directory that contains the lib and header files, and try a clean build of the client application, it fails. Although the build fails, the /builds/foo/bar/build directory gets created and populated, meaning all subsequent builds and cleans succeed.

Any idea how to fix this issue?

Answer 1

Usually Xcode 4 handles the building of dependent projects correctly; but I have found circumstances where it does not. You could try editing the scheme and making the static library dependency explicit.