3

Due to security reason cannot paste the original code hence tried to be more intent full

  1. Have a project called Utils.xcodeproj which has an objective c files called Resources.m and its header is exposed as public header.
  2. Have another project called main.xcodeproj in which this Utils project is referenced.

Now when compiling the main.xcodeproj I get error "Duplicate interface definition for class Resources" iOS/Utils/Utils/Resources.h:23:1: @interface Resources : NSObject

Build/Products/Debug-iphoneos/include/Utils/Resources.h:23:12: note: previous definition is here @interface Resources : NSObject

Is there a way to overcome this error or turn this error into a warning?

Class Resources.h

@protocol ResourcesDelegate;

@interface Resources : NSObject

@property (weak, nonatomic) id<ResourcesDelegate> delegate;
+ (void) setDefault:(UIView *)view;
@end


@protocol ResourcesDelegate <NSObject>
@required
- (void)loadFromSDK:(NSString*)Name;

@end



Class Utils-Bridging-Header.h
#import "Resources.h"

Class XYZ in main.xcodeproj
#import "Utils/Resources.h"

[Resources setDefault:view]
arihant jain
  • 115
  • 1
  • 8
  • Could be import issue, eg in A you import B and C. In B you import C and so A ends up with two definitions of C. Maybe, maybe not ... but you can solve this as follows. Use ```@class C;``` in B. This will define a class called C (in B) without actually giving a definition. It depends on your setup, you need to do figure out where the duplication occurs and there replace the ```#import``` with ```@class``` to prevent it. This is a guess - it could be that you did duplicate the file and are compiling it twice or maybe even you have two Resources, one in the Main and one in the other project ... – skaak Oct 27 '20 at 13:52
  • ... ps ... it is of course difficult to solve something so vague but at least those are things you can try ... but something tells me you are very persistent ... – skaak Oct 27 '20 at 14:05

1 Answers1

2

also you could..

#ifndef Resources_h
#define Resources_h

// ... your #import or @import, #include <...> rules here...

// ... announcing a 
// @class SomeClassWithName
// here if needed. This will make SomeClassWithName available
// to this header even if its interface is declared later on. (skaak's solution)

// ... all your @interface stuff here ...

#endif

This should keep it from being implemented twice per project.

Why is this working?
Because once #import "Resources.h" is done Resources_h would be defined and when #import "Utils/Resources.h" is processed the definition is jumping over the second attempt to declare the class.

Edit forgot to mention that this approach should be used in header files of course. While it is not forbidden to make use of it in implementation files. In fact in cross platform source you will see this is used heavily.

Edit2 have a look at the following nice explained answer what is going on when #include is used and what was meant to work fine when using #import sven's stackoverflow answer

  • so the #import preprocessor command reminds the files that have been imported already, but that seems to fail when files and with it declarations are re-established from another project with its own folder structure. In short: "Resources.h" and "Utils/Resources.h" are different files to the preprocessor so your class definitions are duplicate of each other.
Ol Sen
  • 3,163
  • 2
  • 21
  • 30
  • Anyhow, back to business ... that is old C way of preventing duplicates when using *include* ... does *import* not give you that out the box? – skaak Oct 27 '20 at 14:51
  • 1
    Ok in reply to your next comment ... maybe I can time travel (so I did not win, I was cheating ... or maybe I am just cleaning up ) ... yes those questions have been increasing ... – skaak Oct 27 '20 at 14:55
  • FWIW I made classes A and B and tried to break the system. So main imports A and B and A imports B e.g. I had to work very hard to break it and could only do so with include. Even if I do import and immediately below it include the exact same thing, no trouble. The include had to be first to break it. Seems robust at least in latest Xcode. – skaak Oct 28 '20 at 16:06
  • i think the trouble starts when the precompiler does not get it that one class declaration given from two imports out of different directories are one and the same file. Which is what the #ifndef can circumvent nicely. – Ol Sen Oct 28 '20 at 17:31
  • I thought so too and tried that as well. Not as extensive as the normal imports but it seemed to work / not break, at least in simple cases. Easiest to break it was to have two classes with the same name ... this just results from my own tests but I was also thinking maybe that is what is happening here. – skaak Oct 28 '20 at 17:39
  • 1
    following my own Edit2 here #include makes the problem worse because it just copies the files content in place and duplicates are even more easy made, so no wondering anymore why almost any framework has those `#ifndef` rule on top. – Ol Sen Oct 28 '20 at 18:22