On Feb 24, 2012, at 8:07 AM, Quincey Morris wrote: I've tracked that a static library included in the project installs its public headers in:
~/Library/Developer/Xcode/DerivedData/<.>/ArchiveIntermediates/Lyn/InstallationBuildProductsLocation/usr/local/include
while the compile tasks of the archive log includes a non-existant folder:
~/Library/Developer/Xcode/DerivedData/<.>/ArchiveIntermediates/Lyn/BuildProductsPath/Release/usr/local/include
In Xcode 3, it was easy to find built things in the 'build' directory hierarchy, but in Xcode 4, the equivalent locations (the derived data directory hierarchy) are more-or-less private to Xcode.
--
So, with regard to your static libraries:
Xcode has never had (AFAIK) an intrinsic concept of an install location for static library headers. Perhaps with Xcode 3 you had a custom build phase that copied them to a known location relative to the 'build' directory? If so, you're going to have to "install" them somewhere else in Xcode 4 -- somewhere not relative to the intermediate products directory. The same is true of the static library itself.
The static library target has the standard Copy Headers phase for your Public/Protected/Private headers. What I said in the previous paragraph applies if you *don't* want projects using the static library to know where the static library project (and its source files) can be found. In that case, put the built library and its public headers in a known directory (e.g. /Users/yourname/Projects/MyStaticLibrary), and use them from there, adding a "Include search path" for this directory to your app's target's build settings.
It's a thing that I don't want to do since it's cause of problems. --
An alternative approach is to make an Xcode 4 workspace for your app. Put your app's project *and* the static library project in this workspace. Then, in your app's "Link against libraries" build phase you should be able to add the static library and Xcode will figure out exactly where to find it. However, you'll still need to add the static library project location to your app's target's "Include search path" build setting. The advantages of this approach are:
1. When you build your app, Xcode knows if the static library project's target is up to date, and will rebuild it automatically if necessary.
2. Xcode includes the debug or release version of the static library according to the configuration of the app. This means you can easily debug into the static library when debugging the app.
3. Xcode can be clever about not copying or rebuilding library components sometimes, but (internally) mucking around with directory paths. This is the reason why there was a non-existent folder -- Xcode decided it didn't need to create the folder.
The disadvantage of this approach is that your app isn't prevented from accessing private headers of your static library, unless you rearrange your static library source to separate the public and private headers into different directories, and set the "Include search paths" to find only the public header directory.
Public/private headers is not a problem. Anyway the main project already references and has dependecies to other framework/static libs' xc projects, so there is no (or shouldn't be) difference using a workspace as I can navigate them from Main proj/Projects/other xc projs… apart for the crashes I've had creating the workspace.
To be clear the project as viewed from Xcode is as follow:
Lyn Classes … Projects Framework1 xc project Framework1 xc project
If I create a workspace like this:
Lyn project Classes … Projects Framework1 xc project Framework1 xc project
it does not change anything.
Xcode is not able to find the Static Lib's public headers from Lyn while Archinving and I can't navigate from a symbol in the app's source to the definition in the library. Also after referencing lib's headers in the main project!
As a worst thing, the debugger can't step into the Static Lib! Fortunately there aren't problem with the frameworks.
Another problem arises with the new LLVM 3.1 compiler (as of 3.0) that still does not compile correcly my project under i386 (x86_64 works correctly):
ld: bad codegen, pointer diff in __ZN9OLImageIO11scoped_lockINS_5mutexEE4lockEv to global weak symbol __ZTIN5boost10lock_errorE for architecture i386
Command /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ failed with exit code 1
And with a problem like that (with 1000+ source files), how can I provide a test case for Apple??? I tought it was for a symbol visibility problem of the boost libs, but now that the symbols are fixed, the problem persists.
Here an explanation for Xcode 4 and in a sublink for Xcode 3:
Standard ibtool included in Xcode 4 can't compile some of my xib due to plugins dependencies and copying ibtool included in Xcode 3 sometimes hang the ide, who knows why. Anyway Xcode 4.3 also ships with ibtool3 that does the job… after renaming it. (/Applications/Xcode.app/Contents/Developer/usr/bin/ibtool3)
2012-02-28 16:10:07.568 ibtoold[57445:a03] Exception raised while decoding document objects - Could not instantiate class named BWUnanchoredButtonContainer /* com.apple.ibtool.errors */ /Users/mirko/src/PointsDeVue/src/English.lproj/WebAccountsPreferencePane.xib: error: Unable to resolve plug-in dependency for "WebAccountsPreferencePane.xib". Recovery Suggestion: Locate the com.brandonwalkin.BWToolkit Interface Builder plug-in to continue opening this document. Consider using the --plugin option or Interface Builder's plug-in preferences to resolve this dependency. Underlying Errors: Description: Can't load plugin, as there is no bundle at /Users/Accounts/mirko/src/bwtoolkit/build/Release/BWToolkit.ibplugin.
I've also had to restore ppc support and now I'm able to archive without errors, also if at the moment I don't need it.
The only BIG problem is now the debugger, how could I manually add source dirs to LLDB?
As you can see, it requires a different conceptualization to do the Xcode 4 equivalent of what you did in Xcode 3. I think the above is more or less correct, though no doubt I have some of the details wrong or incomplete. However, the first step to re-architect your file organization so that you *don't* reference parts of the intermediate data directory hierarchy directly.
The file organization is ok, the problem is that Xcode 4.3, while it has some nice features, is still very bugged in others! A nightmare!
It remembers me the era of NeXTSTEP for intel and then OPENSTEP!
Thanks for the help!
|