On Feb 23, 2012, at 13:04 , Mirko Viviani wrote: The project contains some frameworks and a couple of static libs with public header files. Xcode doesn't find these header files when archiving.
I'll take a stab at it, but keep in mind that I have to guess, since I can't see your build settings or your projects' file layouts. Run, Profile and Build for (Running, Profiling, Archiving) all produce a running application.
Anyway when I start the Archive phase after a Build for Archiving, xcode recompiles everything (why???)
It's new behavior in Xcode 4. We haven't been told officially why (AFAIK), but presumably it's to make sure that a built, final app really *is* built. Perhaps in the past there have been problems with released code that didn't actually get recompiled when it should. using different include folders.
Yes, since different build schemes can have different settings/parameters, there's a different place in the intermediate data directory for each scenario, though you shouldn't need to care about this. 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.
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.
--
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.
--
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.
FWIW.
|