On Jun 15, 2012, at 8:45 AM, Bill Cheeseman wrote: Does nobody have an answer?
On Jun 13, 2012, at 8:50 AM, Bill Cheeseman wrote:
My projects stopped building when I upgraded to Xcode 4.3.3. The reported error was that Xcode could not find my #imported <framework/framework.h>, even though Xcode 4.3.2 had no difficulty in this regard.
After fooling around a while, I discovered that I could make it start building again if I added an explicit "/Library/Frameworks" to the Framework Search Paths build setting.
But that is not ideal, because it assumes my framework is finished, installed and unchanging. I would prefer to get the framework headers from ~/Library/Developer/Xcode/DerivedData as before, since I include the frameworks in my workspace so I can build them automatically if I make changes in them during development of the dependent application project. That used to work in 4.3.2, but no longer in 4.3.3. Why not? My Xcode preferences still specify the default derived data location, and I thought that was supposed to override any settings in Framework Search Paths for these purposes.
Or, a more general question, what is the proper setup when a shared framework is in the same workspace with an application project that is dependent on the framework? I found a simple and intuitive solution, but it surprises me: I had to add my shared framework to my application target and make it an explicit dependency in the Target Dependencies build phase of my application target.
In Xcode 4.3.2 this was not necessary; it was sufficient to include the framework in my application's workspace and rely on the Find Implicit Dependencies setting in the application target's Build scheme. This is no longer true in Xcode 4.3.3. In 4.3.3, until I set up an explicit dependency, the build fails when it gets to the first '#import <framework/framework.h>' in the application headers, saying it can't find the framework. The framework was not getting built first, so it didn't show up in the DerivedData folder where Xcode expected to find it..
My shared framework is weak linked in the application project using -weak_framework in the Other Linker Flags build setting. That was true when I was using Xcode 4.3.2, too, so this has nothing to do with the issue. And it wouldn't, anyway, because the build fails way before it gets to linking.
So, my only question now is: Is the failure of Xcode 4.3.3 to find the implicit dependency a bug? I can't image why Apple would want to kill that feature in the move from 4.3.2 to 4.3.3.
|