Compile, Build or Archive problems with Xcode 4 (and dependencies)

Solution 1:

NB: The steps below will solve 90% of your Xcode archive issues however, from the comments it is suggested you try quitting Xcode first. This may save you hours of setting tweaking.

1. Check the "user header paths" are correct (Add "" to paths for spaces, both in your project and dependencies)
2. Set "Always search user paths" to YES
3. Create a group call "Indexing headers" in your project and drag the headers to this group, DO NOT add to any targets when prompted. This includes any headers inside your .xcdatamodeld, you'll need to right-click and view package contents to find them.
4. For all dependencies set "Skip Install" build setting to "Yes"
5. Moving any "Public" headers in Build Phases to "Project"
6. Set the Build Setting "Installation Directory" on your Target to $(LOCAL_APPS_DIR)
7. Change the target build setting "scan all source files for includes" to YES. (link)
8. With newer versions of Xcode (> 4.2) you might want to read this question related to workspaces.
9. Manually delete the project.xcworkspace files form all referenced projects

Solution 2:

I had the same problem in XCode 4: "Lexical or preprocessor issue MyFile.h not found". However, MyFile.m was not a static library, just a standard class. And MyFile.m and MyFile.h were included properly and indexed in the project.

So ... I quit XCode and the Simulator, then restarted them and the problem disappeared.

Solution 3:

I found that the problem went away when I changed the target build setting "scan all source files for includes" from no to yes.

Solution 4:

I was able to resolve this issue without any changes to any of the build settings by simply copying the .h files into the Project's directory in the finder. I did NOT add them to the project at all. Just having them in the project's filesystem directory seemed to be enough to allow Xcode's implicit linking to work properly. More details here.

Solution 5:

I had a weird issue like this. Changing "Scan all resource files..." to Yes didn't help. I took a look at the Framework Search Paths and noticed that I had

• $(inherited)
• "$(SRCROOT)"
• "$(SRCROOT)/my/correct/path"

It seemed right but was still failing. I then tried rearranging the order of 2 & 3 and all of a sudden it built fine. So not sure why that was the hickup, but wanted to add it to the list of things to try in case it helps someone else.