When you reference external code, you will always need to have the headers accessible by your project, otherwise the compiler wouldn’t be able to tell you if you are referencing the external code in a proper manner. E.g. does the method exist, are you providing the right types, etc.
The duplicate symbol problem only exists when you actually define a symbol multiple times. For instance, defining class related Objective-C symbols only happens in a @implementation...@end
block, not in a @interface...@end
block. The latter is only for the compiler to make sense of things.
(This is also why you can define a @interface
for e.g. a private class and use it as normal and not cause duplicate symbols.)
Therefore, you can include such ‘clean’ headers multiple times without having to worry about it. Note that I said ‘clean’, because you can actually define symbols in headers by, for instance, defining C functions in headers or even a Objective-C @implementation
, if you feel especially wicked. But you will simply have to test this.
The linker will complain when you finally link the 3rd-party dependency and yours and there were duplicate symbols after all. In that case, be sure to look into tools such as nm
which list the symbols in an archive.