During archive Xcode 7.1 does says Restkit/Restkit.h not found but in debug it successfully found the header. It's an old project which do not uses cocoa pods so RestKit is added manually in it. Tried many solutions but not successful. Help required.
Together with your suggestion and this SO post I managed to solve it by adding "$(BUILD_ROOT)/../IntermediateBuildFilesPath/Headers" (recursive) in the project build settings, Header Search Path for Release.
Also set Skip Install = YES (build settings/deployment in the RestKit-project) and changed :
#import <RestKit/RestKit.h> to "RestKit/RestKit.h"
Note. Check in your xcode preferences/locations tab where the derived data is stored. Default is Unique build location. Then look in Finder for the folder IntermediateBuildFilesPath and search for the headers you are missing. Add this folder to the search path.
I had the same issue. I added the following to the Header Search Paths build settings with non-recursive selected, and it solved my issue:
"$(BUILD_DIR)/../IntermediateBuildFilesPath/Headers"
I didn't have to change the import syntax or change any other build settings.
Changing Header Search Paths to:
"$(BUILD_DIR)/../IntermediateBuildFilesPath/Headers" (non-recursive)
was correct way for me, too. For other subprojects, you should change Public headers folder path (Build Settings > Packaging) to
"../../Headers/$(TARGET_NAME)"
in subproject target's settings.
All of the above answers were part of the solution; however, in my case I ran into a detail that had me confused for a little while.
As per the answers above, I also updated the Header Search Paths (under Build Settings) by adding:
"$(BUILD_DIR)/../IntermediateBuildFilesPath/Headers" (non-recursive)
but that didn't work until I realized...
I was only updating the Project, and the Target was keeping the old paths.
So remember to update the Project paths AS WELL AS the Target paths.
ps, I didn't have to change any of the RestKit import statements.
Related
We have Carthage dependencies that take a very long time to fetch and build. I tried putting the /Carthage/Builds folder into source control and pointed the framework paths in the build settings to it, but the team is still forced to do carthage update for it to work, otherwise updated dependencies aren't recognized when pulling from source control (even the updated builds have been checked in).
Is there something I'm missing and not as simple as keeping the builds folder in source control?
It should be enough to add the Builds folder into source control as you described. If you add the frameworks from there and defined your framework search path as $(PROJECT_DIR)/Carthage/Build/iOS (example for iOS) everything should work like a charm. In our project we configured it that way.
If not take a look into the build settings and search for the word carthage. Only result should be your framework search path. Maybe you defined some paths into $(PROJECT_DIR)/Carthage/Checkouts This may be your problem.
In my case, one of the nested frameworks had an absolute path, so the solution was just to add an import path to it's module.map.
This is the warning that it is showing:
directory not found for option '-F/Applications/Xcode-beta.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS9.0.sdk/Developer/Library/Frameworks' "
Can anyone help resolve the warning?
This is how I fixed this problem
Further to a migration of my Xcode project, from Xcode 6.4 to Xcode 7, I get the warning message below (after compilation) for the Test target :
directory not found for option '-F/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator9.0.sdk/Developer/Library/Frameworks'
Actually I found something when comparing a new project vs an older one...
In the old project, the warning was only being produced by the test target of my projects. Under 'Search Paths', I found it was including two items under 'Framework Search Paths':
$(SDKROOT)/Developer/Library/Frameworks
$(inherited)
The new project kept the 'Framework Search Paths' empty.
Deleting those entries in my older project then removed the warning.
Notes:
I have not exhaustively compared settings, so there may be additional differences.
Also, just in case if one day you re-encounter one of the two following warning messages, just remember that you will have to do that: if the warning is for option '-L/...' that is Library Search Paths, delete the stuff there. However if the warning is for option '-F/...' that is Framework Search Paths, delete the stuff there.
Based on the error message, it sounds like the first order of business is to get the target's path straightened out. You can edit the paths as shown in the answers to this StackOverflow question. Be sure to check the path for all your targets if you're not sure which is generating the error --- this threw me for a bit after upgrading a project to the Xcode 7 beta; there was a path in the FRAMEWORK_SEARCH_PATHS for the test target that needed to be deleted. The path that was in there was exactly the path you report getting the warning on; removing the path eliminated it.
King-Wizard is essentially correct, to elaborate a little more -
Xcode 7 is looking for your testing framework XCtest.framework in a path that does not exist. The path set by $(SDKROOT)/Developer/Library/Frameworks under 'Search Paths -> Framework Search Paths' is looking for the framework in /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS9.0.sdk/Developer/Library/Frameworks which is not a valid path. You can delete the line $(SDKROOT)/Developer/Library/Frameworks to remove the error and still be able to run tests.
The correct path to 'XCTest.framework' is /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/Library/Frameworks for those that are curious.
I hope that helps.
I had the same error with Xcode 9.2 and here is my solutions without doing by hand:
Click on your project in Project Navigator
Go to targets and click on MyProjectNameTest
Click on Build Settings and Search for “Framework Search Paths”
Under Framework Search Paths, delete the paths and keep the “$(inherited)”.
For those of you that have the following error:
directory not found for option ‘-L/…
that means it’s a Library Error, so you can try follow the below steps:
Click on your project (targets)
Click on Build Settings, Search for “Library Search Paths”
Under Library Search Paths, delete the paths and keep the “$(inherited)”
i have an app and i want to install GPUImage framework. I did following steps:
1) Adding project to my app. I did following > XCode->Add Files-> then choose GPUImage.xcodeproj, and select "copy items to destination project"
2) Now it says : Next, go to your application's target and add GPUImage as a Target Dependency. Im not really sure how to achieve that, what i did is - in product->Scheme->Edit scheme i add GPUImage.
3) I add libGPUImage.a to Build Phases -> Link binary with Libraries
4) I tried every solution i had found to finally add full path of GPUImage.xcodeproj to header search path. Nothing work at all. There is a warning - GPUImage.h not found. I had tried many ways to add full path here, everything i did found concerning this error, but still, there is an error.
How could i fix that? Maybe i made mistakes in previous steps? I really wonder how i manage to spend many hours just trying to add framework to my app, and still unsuccessfully..
This is what's meant by adding a framework as a target dependency:
Those are all under your project settings. You shouldn't need to do anything with your scheme.
As far as the header file goes, you have to make sure your Header Search Paths are set correctly in your Build Settings. If you look at the sample applications that ship with the project, they have that set to ../../../framework (with the recursive search box checked), which is the relative path to the framework from their project directories.
You need to find what this path is for your application project relative to where you placed the GPUImage source.
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.
I have been in this situation quite a few times where visual studio does not honor the Additional Include Directories when it comes to lib and header source files. For example, I just downloaded MyGUI source code and made sure the include directories were correct. I even put them to absolute paths, Visual Studio still complained that it could not find specific header files.
Does anybody experience the same thing with projects, and if so, is there a solution to this problem?Blockquote
EDIT: My apologies for not being able to explain fully. I know that the library and source files have different include directories. The project that I received had correct directory paths for the Additional Include Directories and Additional Library Directories but Visual Studio still failed to recognize them properly. I can right click and open the header file within Visual Studio but when compiling it still complains it cannot find the required header files. I regularly make projects relying on a framework I myself programmed, so I am quite familiar with how to set up dependencies. This is however the second time this seems to be happening. I don't recall which 3rd party project I was trying to compile last time, but Visual Studio simply refused to believe that the Additional Include Directories paths is where it should look for the header files. I am not sure how to give the complete details of this particular library (MyGUI) but I can point you to the website where you can download it to try and see if it is able to find the header files that are included in the project (if it doesn't compile, that is fine, and it is probably because of additional dependencies, but it should at least be able to find files in the common folder, especially when I put absolute paths in Additional Include Directories)
This happened to me once. It turned out the inconsistency of the Debug vs Release builds. When I modified one build, the other build was being compiled. Please set both builds with same include folders and see if it works. Good luck.
I've just spent some hours battling with failing #include paths in the compiler, inconsistencies between the compiler and intellisense.
What I finally discovered was that in the properties of the *.cpp file -- not the project, but the individual *.cpp file -- the "Additional Include Directories" property was blank. I had to explicitly set it to "inherit from from parent or project defaults" -- there's a checkbox near the lower-left corner of the dialog for editing the directory path.
I had copied this file from another project and used "Add > Existing Item..." to add it to the current project. My hypothesis was that maybe the "Existing Item" procedure skipped a property initialization step that "New Item" would normally perform. But I just tested that hypothesis by Adding another Existing and a New. Both of these files had their property set to inherit from the project, so I don't have an explanation for why my problem file was not initially set to inherit.
Anyway ... after much frustration, found and fixed that one.
I have found (stumbled) on the solution (I think). It has something to do with the character limit imposed by the OS. Although the limit should be 260, for me it falls in the below 150, see this discussion and links to it. I downloaded and unzipped the file to C:\Users\MyUserName\My Documents\Downloads\Downloads From Chrome\MyGui3.0...[and so on]. I learned quite some time ago not to try to compile projects under such long paths, but this time it completely slipped my mind as VS did not give me a warning at all and pointed me in the wrong direction. Anyway, cutting and pasting the project to D:\ fixed the issue. I am not going to checkmark the answer however until someone confirms this.
I have the same problem : Can't find .lib file even though I've added the additional include directory.
From an answer of Additional include directory in Visual studio 2015 doesn't work, I tried:
delete the .suo file and restart VS
Then it works for me.
I had this issue too. Just like sam said - this string value containing path to your framework includes has to be the same for the Debug and Release configurations. So the best way is to choose "Configuration:All Configurations" and "Platform:All Platforms" from the two context checklists on the top of the project properties window before typing it in, or copying from windows explorer adress bar.
Can you elaborate on this? If I recall, there are at least two places in Visual Studio where you can configure this:
Per-installation: Tools/Options/Projects and Solutions/VC++ Directories)
Per-project: Project/Properties/Configuration Properties/"C/C++"/General/Additional Include Directories
If you're adding the include directories per-project (#1), which I think you are, and then trying to include from another project, this will obviously not work. Try adding them at the per-installation level and see if it works.
Also, this may sound stupid/simplistic, but make sure the path is right (i.e. copy-paste into Explorer's path bar and see if the header files are in that folder).
If by lib files you mean library (.lib) files, the directory location is not specified through C/C++/General/Additional Include Directories but rather through Linker/General/Additional Library Directories.
It's logical if you think about it. C/C++ options are all compilation options, settings involved with compiling .cpp and .h files. Linker options are all linking options, settings involved with linking up .obj and .lib files.
I had the same symptoms in my c++ project. Navigating from header to header went fine, but after toggling to the source file of a header (let's say foo.cpp), then the navigation to an #include <bar.cpp> in that source file failed. I got the following error:
File 'bar.cpp' not found in the current source file's directory or in build system paths.
After research I noticed that the system build path given in the error where not extended with the include paths of the project. In other words: IntelliSense didn't know that the source file (foo.cpp) was part of the project, and therefore it didn't use the include paths of the project to search for the #include <bar.cpp>.
The fix for me was creating a file intelliSense.cpp (file name doesn't matter) that is part of the project, but excluded from the build. This file contains an include for each source file. ex:
#include <foo.cpp>
#include <bar.cpp>
...
This way IntelliSense knows that these source files are part of the project, and will therefore use the include paths of the project to resolve the #includes in those source files.
For me the issue was that .vcxproj Project file was read-only and after I added my directory to "Additional directories", the project file did not actually change. I was surprised that VS did not complain about this file being read-only.
So after I made that file write-able I could compile my project.
Here is another 'I had the same...' in vs2015.
For me it turned out that the active setting is also depending on the 'solution configuration' and 'solution platform'. That makes 4 settings which all should be identical.
That solved the problem in my case.
I realize this question is over 10 years old at this point, but I also just ran into this issue and none of the answers fit my scenario. After some playing with my IDE (VS 2019) for a few minutes I realized that the cpp file I was using had it's platform set to Win32, but the libs I was trying to use were built for x64.
As others have stated, make sure your project's configuration is set to
-"All Configurations" when you add the necessary paths to your project as that can also be an issue. I imagine my issue will not be as common, but I figured it was worth sharing. I hope this helps someone else in the future.
One more possible reason not mentioned earlier: make sure you are configuring properties of the correct project in a multi-project solution.
My problem was that I had a solution of two projects each using the same file with includes. Turns out that I correctly configured 'Additional Include Directories' only for one of two projects and totally forgot about another one. Of course error message was stating that only the second project and not the first one had problems.