I'm having a myriad of problems with Xcode 4 and nested projects that worked just well under Xcode 3.2. Here's a very basic one I cannot solve:
I'm building a cocoa framework that requires another cocoa framework for which I have the source. So I perform the usual steps:
Drag the .xcodeproj file of the required framework into my main framework project
In my main framework under TARGETS > MyFramework > Build Phases > Target Dependencies: Add the nested project's target
Make sure the header files of the nested framework are public
In Xcode Settings > Locations > Build Location I have it set to Place build products in derived data location (recommended)
Build products path of both targets are set to ${BUILT_PRODUCTS_DIR} and tell me they are at the DerivedData/Debug (or Release) location
Architecture settings for both targets are identical
Then I hit [CMD] + B to build and it tells me that it doesn't find the header files of the nested framework. When I check the settings, User Header Search Paths contain the path to DerivedData/Debug, and inside there is the nested framework target with the header files in Versions/A/Headers.
I'm sitting here, anybody an idea what I'm doing wrong?
The issue goes away when building for Debug when I change the User header search paths to ${BUILT_PRODUCTS_DIR}/MyFramework.framework/Headers. However this doesn't work when building for Distribution as the frameworks then use their Release settings, which ends up in a different subdirectory...
My temporary solution is to also define a Distribution configuration for the nested projects. This way the headers are found and the linker can link successfully.
Here's my synthesized knowledge so far:
Forget the whole public header thing with Xcode, it's a PITA and doesn't work correctly when archiving your app. Instead, have all static library header files on the project level and tell your app where to find it.
Ease your pain by making sure all targets have the same name for the build configuration (i.e. add an "AdHoc" and "Deployment" configuration to the static libraries).
In build settings, point the Header Search Paths (if you use #include <file.h>) or User Header Search Paths (if you use #include "file.h") to the directory of the static library project. If the static library project is inside your app directory, use this:
"$(PROJECT_DIR)" (recursive enabled)
If you have a directory which contains a) the static library project and b) your app, then this should work:
"$(PROJECT_DIR)/.." (recursive enabled)
If the submodule contains compiled libraries, set your Library Search Paths to:
"$(TARGET_BUILD_DIR)"
Make sure all the static library projects that you use have Skip Install set to YES.
Again, no public header files (Build Phases » Copy Headers) in any of the static libraries, otherwise Xcode will not be able to archive an app.
Make sure to tell Xcode when to build the static libraries, as shown in this Tech Doc from Apple.
Old Answer:
I still haven't found a real solution to this problem with static libraries. What works for me is:
Create an "AdHoc" Configuration for the static library
Add $(BUILT_PRODUCTS_DIR) to User Header Search paths for the application (with recursive checked) -> this is used when running the app
In the Xcode menu, select Product > Build For > Build For Archiving
This works, the app finds the header files and builds itself, it ends up in DerivedData//Build/Products/AdHoc-iphoneos/ as an App bundle. Following these simple instructions (dead link) from TestFlightApp.com I can pack this App into an IPA and send it around. Simply selecting to Archive the app from Xcode does again not find the headers, even if they truly are in the AdHoc-iphoneos build directory.
(As of Xcode 5.1)
When the subproject is built by XCode, the subproject header files are copied into the build directory. When archiving, it seems that this copy destination directory is not added to the header/include search path. You'll want to go to your Build Settings and add
$(BUILD_ROOT)/../IntermediateBuildFilesPath/UninstalledProducts/include
to the "Header Search Paths" for the scheme that you use for archiving.
If you're not sure which scheme is used for archiving, go to Product -> Scheme -> Edit Schemes and look for Archive in the left column.
Make sure your third party framework is added as «group» to your main project, so you can see it in your project's hierarchy...
I had the same problem here and I could solve the problem by setting "Build Location" to Place build products in locations specified by targets"
I had this problem: I could build both Debug and App Store configurations, but not Ad Hoc. Building Ad Hoc gave me errors because it couldn't find .h files needed by nested projects.
Turned out I had an expired provisioning lingering in my Release configuration. I updated that provisioning link and now I can both build Ad Hoc and use the Archive feature to package it.
Took me hours to figure it out! My mind just didn't jump from missing .h files to provisioning errors just by itself. =) There might have been an error or warning complaining about the missing provisioning, but if so it was well buried among the hundreds of .h related errors.
I was having the same issue with a Configuration named "Ad Hoc" (as per TestFlight recommendation at http://help.testflightapp.com/customer/portal/articles/402782-how-to-create-an-ipa-xcode-4) and the main project could not find some of the headers from the nested projects. I renamed the project to "AdHoc" (no spaces) and the problem went away; seems like spaces can mess up header search paths in some cases, although I haven't figured out the specifics of when that might happen and why.
I was having this issue with a nested project that built a static library. I found this doc on apples site that completely saved my life.
http://developer.apple.com/library/ios/#DOCUMENTATION/Xcode/Conceptual/ios_development_workflow/AA-Developing_a_Static_Library_and_Incorporating_It_in_Your_Application/archiving_an_application_that_uses_a_static_library.html
I'm so glad I didn't have to muck around with the derived data paths.
For me, this happened after a GIT merge, which created many conflicts, one of them related to the project file. After the merge, I'm sure the structure of the project file changed.
What I ended up doing was going into the project "Build Settings", then looking for "Always Search User Paths" and turning it to Yes.
I guess the merge turned this boolean to No, therefore the project wasn't looking in the right places for the header files.
Related
Like many others here SO, I am having issues using libraries in my XCode workspace. The idea is I have my main project (MyApp) and two libraries (lib1 and lib2) which were added to the workspace after the code was finalized.
For background, lib1 is dependent on lib2, since there are some protocols that need to be implemented in order to make use of lib2. MyApp is dependent on both. I have tried following the Apple guides, which implies what I would like to is simple. After that, I have followed pretty much every post here on SO that has come up in my searches (2 days worth of Googling), plus many other blogs and posts that claim to have solutions, many of which are XCode 3 specific.
Yet, my project does not build. I am using Xcode 4.2 on OS 10.6 (upgrading to Lion is not an option). Is there a simple tutorial to follow on how to create a library project, and use this library in an application.
I came across this answer while writing this question (where the question had the same error I had), which I will look into, but I have reached the point of copying source files over just to get a demo working.
UPDATE:
Here is list of issues that have come up. I will add more when they arise:
**directory not found for option '-L/Users/myhomedir/iphoneprojects/MyApp/../BLProfile/build/Release-iphoneos'**
Here is how to create a static library and a project that use it.
Step 1: Create a workspace: File > New > Workspace. This is not mandatory but it helps organize the projects.
Step 2: Create a static library project: File > New > Project > Framework and Library > Cocoa Touch Static Library. Lets call it MyLib.
Step 3: Create an Application Project: File > New > Project > Application> Empty Application, or any other application template. Lets call this project MyApp. If you placed the projects in different folders, you may have to use a different path.
Now you have the following Projects in the workspace.
Step 4: Configure the app so that it finds the .h files of the library. To do that, add the parent folder "../" and check the recursive checkbox.
Step 5: Link the app to the library.
Open Main Project where you would like to add static library.
Save as workspace.
Add library's project package. No need to check copy while adding project package.
Update Xcode preferences location to Custom-Relative to Workspace. Products as 'Build/Products' and Intermediates as Build/Intermediates
In your Main project -> target -> build settings, Add Header and Library Search Path as $(BUILD_PRODUCTS_DIR)
Build Library Project. So a new library will be created in mentioned build path.
Remove existing library from Build Phases and move to trash. Open Build Phases -> Link Binary With Libraries and add newly created library from build directory.
[UPDATE 03/04/2015]
The question is now 4 years old, and applies to a specific version of XCode which I have now specified in the subject.
I have searched a lot for this argument, but I couldn't find a solution, I even post on stackoverflow, but I soon deleted the question becuase of very little access.
Now I am trying again.
I have a workspace with two distinct projects A and B.
B has two targets, one that build a static library Blib.a, and one that build a bundle B.bundle. All of them get built in the derived directory.
In project A I can easily add the static library from the build phases. However I cannot find a way to include the bundle. B.bundle is not visible from "copy resource" tab in A.
Therefore I need to add manually, with all that implies.
I also thought about using a script, but I would like to use this as a very last option.
Has someone a solution for this ? Did I miss something ?
thanks
After long investigation, it came up there's no easy way of doing this. The B.bundle is never visible to A project, and there's no settings in workspace to change that.
At this point there are three solutions:
Include the bundle manually from "copy resources->other", I started with this, but everytime there's a change you have to drop and include the bundle again
Create a script to be run in build phase, if everything is built into the PRODUCTS dir you can find the bundle easily and having copied automatically into the app.bundle. This is not a bad solution. If you are using svn the script got included in project, and users have it for free without additional work.
As suggested by Apple tech support, use folder references.Build bundle B into a folder and add such folder to project A using the "Create Folder References for any added folders" option. Xcode 4 will update your bundle into that folder every time you built it.
The added folder will appear as blue once included in your project A.
Thats's it, I personally use the script, because this solution is path independent if you use standard xcode reference variable such as BUILT_PRODUCTS_DIR and so on, and the shell script is just a cp -r-f
[UPDATE 03/04/2015]
I would like to point out that the question is now 4 years old. At that time there weren't many "official" options available. I even spoke with Apple Tech Support, which proposed solution 3 as the only available solution. It is of course very likely that things are now changed, and there is a much better solution. Just to speak, I also like to add that the three above are not "hacks" but "solutions", maybe technically outdated, but they can still be used nowadays. I intend a "hack" as a..."hack", which means it probably not going to work in future software release.
Here is how I did it.
Drag and drop B.bundle from Project B → Products → B.bundle into the Copy Bundle Resources build phase of your app in Project A (select the Create groups options when asked). This will add B.bundle at the root of your Project A outline. You can move it into the Frameworks directory near Blib.a if it you prefer.
Select B.bundle and check its Location in the Identity and Type right panel (Utilities area). By default, Xcode chooses Relative to Project. This is wrong, select Relative to Build Products instead.
The path to B.bundle will now look something like ../../../../../../../../Projects/MyApp/B.bundle. This is not what you want, but you can easily fix it. Open ProjectA.xcodeproj/project.pbxproj in a text editor, search for this path and delete everything in it except for B.bundle. Your project.pbxproj should look like this:
explicitFileType = wrapper.cfbundle; name = B.bundle; path = "B.bundle"; sourceTree = BUILT_PRODUCTS_DIR; };
Save your project.pbxproj file. Xcode will automatically reload your project and your app should build just fine.
After searching for a long time and failing many times, I found this resource that has been an absolutely great tutorial to create Static Libraries and include bundles in your main project or even for distribution to 3rd party developers that may consume your library.
Absolutely recommended:
https://github.com/jverkoey/iOS-Framework
In project A, is the product of project B a dependency in your scheme's Build action? I think you might have to set up this dependency (sometimes disabling the automatic dependency discovery option is best) for it to show up and be available for copying into another target. I believe this is because it doesn't really exist (like an image resource file) until it's built and Xcode needs to ensure it's built before working with it from another target.
As of Xcode 5.1.1 I was able to drag and drop B.bundle from the Project Navigator to the Copy Bundle Resources list of project A Build Phases. I assume creating B.bundle target is not an issue.
Switch build to Generic iOS Device. This step is needed to create a non-simulator reference.
Drag the .bundle to the other project's Copy Bundle Resources.
Select the .bundle in the Project navigator of the other project, and change its Location to Relative to Build Products
Make sure your .bundle in added to Target Dependencies of your static library
Many people including me trying to make a kind of Static Library framework for iOS to archive some kind of modularity. Framework is best way to do this, but it doesn't provided by Apple, and workarounds don't work well.
https://github.com/kstenerud/iOS-Universal-Framework/tree/master/Fake%20Framework/Templates
Fake framework cannot be referenced from linking tab in Build Phases.
Real framework needs modification of system setting. And still not work smoothly on every parts.
Problem is static library need header files, and it's impossible to reference header files on project at another location on different project without some script. And script breaks IDE's file management abstraction.
How can I use static library project like a convenient module manner? (just dragging project into another project to complete embedding)
I've since updated the template to do away with the script target. It now builds the universal framework from your regular target, so you can include it in workspaces or as a project dependency.
With a real framework target, you can just add it to "Link Binary With Libraries", and it will show up fine.
With a fake framework, Xcode doesn't recognize the target type, so you need to add the link command manually. For example, assuming your framework is called Foo:
Expand the "Products" group of your framework project, then drag "Foo.framework" into the "Link Binary With Libraries" build phase of your app target.
In your app target, edit "Other Linker Flags" in the build settings and add: "-framework Foo"
Framework template link for anyone not sure what we're talking about: https://github.com/kstenerud/iOS-Universal-Framework
Solution.
Goto Project or Target's Build Settings.
Find Public Headers Folder Path. (definition name = PUBLIC_HEADERS_FOLDER_PATH)
Set it as YourLibrary.framework/Headers. I have used ${PRODUCT_NAME}.framework/Headers for automatic syncing with project name.
Goto Build Phases and find Copy Headers step.
Move all required headers to Public pane.
Now all header files will be formed like Framework and copied with product binary. IDE will copy all of them as a unit into some temporary folder like app's build folder. So referencing app project can use the headers automatically.
This is a trick. The created directory structure is not real framework. Because it doesn't contain any binary. However we don't need real framework to archive just this functionality. IDE works with frameworks without any binary. And I don't want to hack IDE without documentation about internal structure.
This works well, however you'll experience some problem when you Archive. This happens because Xcode4 behaves specially when Archiving. Here's workaround.
For each embedded library project, SKIP_INSTALL = YES in target build settings.
For final product project, FRAMEWORK_SEARCH_PATHS = "${OBJROOT}/UninstalledProducts". Take care about this setting should be set only for Release build mode.
Now it'll be archived well.
At the case of cross platform library, there can be many projects for many platforms. But sometime Xcode will show some product as red color even it compiled successfully.
This is a bug of Xcode. IDE display depends SDKROOT of Project build setting. So if you set the SDKROOT differently on Target, it won't work. You can check the the product will become black color after changing the SDKROOT of the Project build setting. See this Open Radar entry for details.
http://openradar.appspot.com/9636211
If you wish to fix this bug, please report this to Apple's Radar. Duplicated bugs will make attention of Apple. Just copy & paste my report :)
I found this : http://db-in.com/blog/2011/05/creating-universal-framework-to-iphone-ios/
It seems to work.
My case is simple, a workspace with two sibling projects: one main (iOS) app and a project that builds several static library targets used by the app.
Here's how I have configured the build:
pointed a 'user header search path' in the main app's build settings to the library project location (via a source tree)
in my app's main target's editor -> build phases -> "Link Binary With Libraries" section, added the library products I want to use.
in the scheme, ticked 'Find Implicit Dependencies'
After a clean (and deletion of the derived data), a build nets me this error during the build of the main project:
ld: library not found for -lChipmunk
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Command /Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin/clang failed with exit code 1
Sure enough, if I look in the newly-created derived data, the only object files to be found are for the main app, not the libraries. A widespread 'find' for *.o files doesn't reveal anything relevant, so the libraries aren't getting lost, they're definitely not being built.
Some supplementary points:
when I've asked about this on the Apple dev forums, it's been suggested that I should add explicit deps in the main target's Build Phases->Target Dependencies editor. But you can only add deps here to targets in the same project or subprojects; in my case I have the app and library projects as workplace siblings.
if I build each library manually before the main build, all is fine.
Update:
I've just figured out a workaround, which is to add all the deps' targets into the 'build' part of the main app's scheme. I had tried this before without success, but hadn't realised that I could drag the targets around in the list to get the right build order. Builds now happen in the correct order, both after a clean, and after changes in either library or main app source.
I'm leaving the question here, because manually sorting out a build order surely shouldn't be necessary. There has to be something wrong with how I have things set up.
Editing the scheme (swapping around build targets, un-/check "Parallelize Build" and/or "Find Implicit Dependencies") didn't work for me. I still had to clean build the project, after any code change in the static lib. Searching the dev forums, I finally found this answer, which worked wonders.
Make sure the Identity and Type inspector is showing and select the libWhatever.a file in your application's project (not the library). If you see Location: Relative to Project [or Relative to Group], this is your problem.
Click Relative to Project and change it to Relative to Build
Products.
This will change the type of the link, but it will still
be broken.
Click the locate button and find the output file.
Adding a static lib to an existing project via Build Phases -> Link Binary with Libraries automatically makes it "Relative to Group" (if both are siblings in the same workspace). Changing its location the way described above resolves the build dependency problem and in the project navigator your .a file should appear in black letters (instead of red).
I described the way I've been setting up multiple projets in a workspace here: http://blog.carbonfive.com/2011/04/04/using-open-source-static-libraries-in-xcode-4/
I agree that manually adjusting the build target order in the scheme should be unnecessary, based on Xcode's documentation, but that's the best solution I've found so far.
Edit: Whenever possible I recommend using https://github.com/CocoaPods/CocoaPods to manage project dependencies at this point.
Try dragging the library project into the main project:
In my case, the only way i could have that sibling configuration build is by manually adding the path "../MyLibProject/build/Debug-iphoneos" (checking recursive just to make sure) in my Build Settings -> Library Search Paths.
Adding the .a file in the Main project alone didn't prevent the "lib not found" error at link time.
I'm an experienced VS.NET user and trying to get up and running on Xcode 3.1.1.
Here's what I'm trying to accomplish:
I'd like a static library ("Lib") to have its own xcodeproj file. I'd an executable application ("App") that makes use of Lib to reference Lib's xcodeproj file so that changes to Lib cause App to relink. Ideally, I'd like to be able to edit Lib's source files inside App's Xcode workspace so I don't have to task around all the time to make changes.
I figured out from the online help that I can simply drag the static lib xcodeproj in to my app's project and it gets the reference. I see that once my static lib xcodeproj is in my app's project, I can simply drag it to the App's target and it understands that App depends on Lib. This seems like the right path, but things aren't quite working the way I'd like yet.
Here are my questions:
It seems that simply having App depend on Lib doesn't cause App to link with Lib. It seems that I have to explicitly drag libLib.a from the Lib folder into App's "Link Binary With Libraries" build stage. In VS.NET, simply specifying the project as a solution dependency adds it to the link line. I just want to make sure I'm not missing anything.
When I have App open in Xcode and I drag Lib.xcodeproj into it, I don't get any of Lib's source files there. I only get libLib.a under the "Lib.xcodeproj" folder. In VS.NET, I can edit Lib's source files right there and rebuild it, etc... but with this approach in Xcode, changes to Lib.cpp don't cause Lib to rebuild when I rebuild App. Ideally, I'd get all of Lib's source files and targets to show up when I drag Lib.xcodeproj into App. Is there any way of doing this?
Thanks in advance for any responses!
You're correct that making target A depend upon target B (whether within the same project or across projects) does not cause target A to link against target B. You need to specify them distinctly; this is because they're separate concepts, and you might have dependencies between targets that you don't want to link to each other — for example, a command-line tool that gets built by target C and is used as part of the build process for target A.
Also, you're correct that referencing project B from within project A will not let you see project B's source code in project A's window. That's because Xcode does not have the same "workspace" model that Visual Studio and Eclipse do; you above alluded to the existence of "a workspace containing project A" but Xcode doesn't really have any such thing, just a window representing project A.
Open the App project. Right-click on the App target and choose "Get Info." Then go to the "General Tab" and find "Direct Dependencies." Click the ( + ) (plus sign) button to add a direct dependency. The Lib.xcodeproj should appear among a list of possibilities for you. Choose the Lib target from that list.
That should accomplish that the Lib project must build (or rebuild) when you build the App target.
(Editing my own post now. I realize I said nothing about point number 2 in the question. I am actually still thinking about number 2. I am not sure if that is possible or not.)
I'm also novice to Xcode 3.1, just played with mentioned by you issues and found that there is no problem regarding to your second question. Whatever application you use to edit the dependence library source code, your main project will rebuild the dependence target. I checked it by:
edited the source file, of the library your app depend on, by notepad application.
Selected dependence library project reference, mouse right-click, and select 'Open With Finder', then selected wanted source file and edited it.
Everything working well.
I am also a fairly new user of Xcode. Most of what I know I learned from an Xcode book by James Bucanek (ISBN 047175479x). It is an older book that was written for/with Xcode 2.2, but I find that pretty much all of it still applies for me today, and I currently use Xcode 3.1
You can probably find a cheap used copy if you are interested.