Let's say I'm trying to use one and only one 3rd-party library in an xcode project - a pretty typical scenario, seemingly harmless.
I plug in the path location of my include files to the project's "header file search path" setting. I haven't even modified any code to make use of the code in the library yet.
It turns out that the project couldn't compile.
Xcode complained something like "Cannot find interface declaration for NSObject", which is pretty absurd. By examining the Build Result, the complained error comes from a header file of the 3rd-party library - it looks something like
So it is indicated in the Build Result that xcode is mistaken that Foundation.h is referring to the assert.h of that 3rd-party library instead of the iOS' built-in assert.h (4th sub-item)
Is there a way to fix the collision of the file names of #import include files?
(Needless to say, I'm new to obj-c -___-)
Related
I have an open source, Objective-C library that I maintain. It has been around for a long time, and I've always distributed it as an embeddable Xcode project that builds a framework, as well as through Carthage and Cocoapods. (The library in question is ORSSerialPort.)
I recently added support for installing it with Swift Package Manager (see this commit), by creating a Package.swift file. I was able to do so without making any source or structure changes, which was helpful because I need to continue to distribute it as a framework as well for the foreseeable future.
However, Xcode 12 included a new (or at least newly on by default?) warning when you do #import with double quotes in public headers in a framework. I had done that in a couple places, so switched to angle brackets as is correct for a framework (see this commit).
I've only now discovered that SwiftPM no longer builds the package because of that. It fails with the following error:
In file included from /Users/andrewmadsen/Developer/ORSSerialPort/Source/ORSSerialPort.m:28:
/Users/andrewmadsen/Developer/ORSSerialPort/Source/ORSSerialRequest.h:28:9: fatal error: 'ORSSerial/ORSSerialPacketDescriptor.h' file not found
#import <ORSSerial/ORSSerialPacketDescriptor.h>
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.
[0/1] Compiling ORSSerial ORSSerialPort.m
One possible solution (that does work, but is kinda gross), is to conditionalize any import with an #ifdef, then pass in a define in the cSettings argument when creating the target in Package.swift, but that seems kind of gross and unwieldy. In this project it's not bad, but in another project I have many, many more headers affected by this issue.
So, to the root of my question:
Is there a way to convince SPM to build an Objective-C package where the public headers use <> angle brackets to include other public headers in the package?
I've already tried specifying a header search path in cSettings, but this produces the same error:
.target(
name: "ORSSerial",
path: "Source",
exclude: ["ORSSerialBuffer.h"],
publicHeadersPath: ".",
cSettings: [
.headerSearchPath(".")
]
)
(All .h and .m files are in the same Source folder.)
I had the same issue recently. The only way I found to work around this was to change the includes to standard user-style includes
#import "ORSSerialPacketDescriptor.h"
Of course, this breaks the header for Objective-C clients. But since Swift uses the module map, you can still use it from Swift code.
This question already has answers here:
AFNetworking.h file not found
(5 answers)
Closed 1 year ago.
#import <AFNetworking/AFNetworking.h>
I imported AFNetworking.h file to .m file but an error occurred like this:
'AFNetworking/AFNetworking.h' file not found
I deleted pods folder and Podfile.lock, and reinstalled Podfile but didn't solved. What should I do? (I opened the workspace file.)
Linking !== Copying.
there is C style #include ... and Objective-C style #import ...
both work almost the same..
where #import reads the header but does not include again if done once. As this can and does fail sometime (usually because mixing C,C++,Objc,Objc++ in different dialects) we often use #define rules to make sure the enclosed code is read once for sure and not again, which in turn works also when code is included and declared with #include. It would be included but not compiled twice.
#ifndef SOME_HumanReadableFlag_h
#define SOME_HumanReadableFlag_h
// ... your header code here..
#interface XyzObject : FromInheritedClass
#end
#endif
Now why does it matter?
It might happen that a #define rule enclosing the header files content hides the header from the viewpoint of other classes.. This can & does happen often when classes are not properly written with the end developers structure in mind. It might work on the workbench of the developer but not for everyone else implementing it.
Your error clearly tells "File not found .."
So first see what both import/include rules differentiate in general
#import <LibFrameworkName/LibFrameworkName.h>
means you have to link the framework or library, even if you developed one on your own in that project. The rule is relative to your project, LibFrameworkName is a Framework/Lib. Where if found somewhere #include <LibFrameworkName/LibFrameworkName.h> is not correct unless you want to c-style include this framework header into your binarys header, 2) tells you a bit about why..
#import "LibFrameworkName/LibFrameworkName.h"
means you have to copy/offer this header into your project with a subfolder with name LibFrameworkName. Once somewhere declared properly Xcode might find and apply the headers even if declared with the wrong rule later on in that specific class, you should also get a warning in the IDE then. In case of AFNetworking you dont want to copy System SDK Frameworks into your project, also not into third party frameworks unless you know what you do. This rule is relative to the files place in project structure, meaning here it would try to look out for some folder with name LibFrameworkName below the file that carries this rule.
what it says: because the Framework is not linked, the compiler tries to find it with the given name ignoring < & > so as if it where like 2) a file with that folder name, then will not find it and throws the error or warning.
To force the precompiler to parse thru some specific folders we use sometime the header search path to explicit tell where to find it. Widely used and mostly troublesome because it also hides wrongly defined rules to the developer as Xcode skips the still existing wrong import rules in code assuming it knows this headers already. Or it throws warnings while everything is actually fine. Other developers experience trouble then, the file structure and header list don't match at all. So keep in mind, when you can avoid making use of header search path lists, go for it. It also will and should not fix your issue.
'<AFNetworking/AFNetworking.h>' File not found means a Framework module is not known to your project. This header is part of a Framework.
Solution: You have to go to your Projects Settings and scroll down to Frameworks and Libraries, hit [+] below this list. It should open the dialog presenting all SDK from your choosen Project Target and all known Pods or known frameworks of your own project when you developed some. Search for the Framework or Lib by name, click it, hit "Add".. done..
From there - there are some options to get used to it..
Because Linking does not mean Copying into your Resources at compile time by default. Usually Xcode knows it does not have to copy System SDK into a projects Framework Folder, all macUsers have those Frameworks preinstalled on their system of course in the right version.. Linking against some specific folder like ${SOMEFLAGWHEREEVERTHISPOINTSTO}/AFNetworking/AFNetworking.framework/Headers is actually wrong unless someone wanted to overrule the systems framework header and maybe also binary.
So AFNetworking should not appear under Build Phases > Copy Bundle Ressources list but after the process above is done it will appear under Link Binary with Libraries, it might also be placed in Dependencies when Xcode needs to know for some Library/Framework it must have this to compile. Last mentioned option is because you could have a framework that adapts at runtime when some framework is missing or not available. So this Entry helps Xcode to figure out in which sorting it has to compile your stuff.
finding ${PODS_CONFIGURATION_BUILD_DIR}/AFNetworking/AFNetworking.framework/Headers in Header Search Paths there must be something wrong i guess.. because the framework is very likely not copied into the Pods folder. It should be relative to your SDKs folder that come with Xcode. The Linking process told above should fix that and you can erase that entry from your header search path then.
I've downloaded a toolkit (namely IRTK from Imperial college) and I have compiled and installed it using CMake.
As part of the installation it has copied all of the relevant header files into /usr/local/include
I want to use classes from this toolkit so I include a relevant header file from /usr/local/include, for example irtkFileVTKToImage.h, however this class inherits from a superclass, irtkFileToImage and the include of the superclass occurs in irtkFileVTKToImage.cc not in irtkFileVTKToImage.h.
This means when I try to include the class I get a compilation error
error: unknown class name 'irtkFileToImage'
What should I do to be able to use these header files. I didn't write the tool kit so going through and adding all of the includes to the header files could take me a long time, is there some easier way to do this?
------ UPDATE ------
As a work around I've included the entirety of the toolkits source in my project and now my code compiles fine. Not ideal but at least it works
My guess is that you should compile and use the toolkit as a library, this way you will only have to include the headers of the final classes you want to use in your own code. It would be easier than trying to just use bits of it, knowing that there's a lot of dependancies.
I am trying to add GLM to a project in Xcode 4, but I cannot get it to compile. I have added the glm files to my project through the add files dialog.
I get a lexical/preprocessor issue and Xcode cannot find the file <cmath>.
I am not sure what I need to tweak to get this to build.
I have seen How do I add OpenGL Mathematics (GLM) to Xcode 4? already.
All you need to do is add the files to the project and #import "glm.hpp" (for Objective-C++; for simple C++ it should just be #include "glm.hpp").
A couple things to be careful of:
The OpenGL Mathematics library, when you download it, comes with a bunch of stuff you don't need (test code, extraneous utilities). Adding these to your project will result in compile errors which I could not get rid of. The only directory you need is the glm/ directory; you can delete the test/, util/, doc/, and bench/ directories. If you were trying to follow "How do I add OpenGL Mathematics (GLM) to Xcode 4?" and were still having problems, this may be the thing which was tripping you up.
The OpenGL Mathematics documentation tells you to include the or files. In Xcode 4, you should include them like "glm.hpp" or "*.hpp". Xcode will find the files no matter where in the project they are. Supposedly you can add a user-defined build setting "USE_HEADERMAP" and set it to "NO" to disable this, but I didn't have any luck with that.
And, just in case, note that your code files using the OpenGL Mathematics library must be Objective C++ files (ending in ".mm"), not the default/plain Objective C files (ending in ".m"). It is very much a C++ library after all... :-)
I hope that help. I was just working through this myself, and I haven't had the chance to really push this (e.g. I've basically just added a mat4 object or two and made sure things still compiled), but it seems to be working.
I ran into the same problem and I solved it remaning my ViewController.m to ViewController.mm. Change the extension to .mm tells XCode that the file may contain C++ code inside. The article Write Object-C Code explains this in the Classes and Objects section.
Just stumbled into something strange with Xcode 4 and Cocoa frameworks. I've a meta-framework that is essentially a .h file with constants needed by a number of other frameworks I've created. I'm capable of creating and building the framework but every time I try to include it in a project Xcode would throw a hissy fit during the build phase, saying it couldn't find the framework, even though the .framework folder was there and the .h file was set to be publicly visible.
After many a hours of running in circles I decided to throw in a .m and corresponding .h files, just so I could have something binary in there and now Xcode is happy as Larry.
Can someone explain this behaviour to me? Why do I need a useless executable to make Xcode see my framework?
The hissy fit is presumably coming from the linker. (Always post your error messages! Guessing isn’t that much fun.) As far as the linker is concerned, the binary is the framework. If you just want the header, you can include the framework in your search paths and #include the header without linking to the framework.