irrlicht (1.8.5, and the head of the 1.8 branch and trunk) fails to build for me on OS X 10.9.x only. It succeeds on Mac OS X 10.6 thru OS X 10.8 and on OS X 10.10 thru macOS 13.
On OS X 10.9 I'm using Xcode 6.2 which includes the OS X 10.10 SDK and I think the problem probably relates more to the SDK version than to the OS X version. On OS X 10.10, I'm using Xcode 7.2.1 which has the OS X 10.11 SDK. This is fairly normal in that the last version of Xcode for any major macOS version typically contains the SDK for the next major OS version.
Anyway the error with 1.8.x is:
source/Irrlicht/MacOSX/CIrrDeviceMacOSX.mm:499:23: error: cannot initialize a parameter of type 'id<NSFileManagerDelegate>' with an rvalue of type 'id<NSApplicationDelegate>'
[NSApp setDelegate:(id<NSApplicationDelegate>)[[[AppDelegate alloc] initWithDevice:this] autorelease]];
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from source/Irrlicht/MacOSX/CIrrDeviceMacOSX.mm:10:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/System/Library/Frameworks/Cocoa.framework/Headers/Cocoa.h:12:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:31:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSFileManager.h:109:47: note: passing argument to parameter 'delegate' here
@property (assign) id <NSFileManagerDelegate> delegate NS_AVAILABLE(10_5, 2_0);
^
This is probably what prompted this fix to be committed back in 2015, introducing a cast to id<NSFileManagerDelegate>, which wasn't correct, as I'll explain below. While this fixed the build with the 10.10 SDK it broke the build for every earlier (and, what couldn't be known at the time, later) SDK.
With irrlicht 1.8.4, which contained that fix, the opposite problem was reported:
source/Irrlicht/MacOSX/CIrrDeviceMacOSX.mm:499:23: error: cannot initialize a parameter of type 'id<NSApplicationDelegate> _Nullable' with an rvalue of type 'id<NSFileManagerDelegate>'
[NSApp setDelegate:(id<NSFileManagerDelegate>)[[[AppDelegate alloc] initWithDevice:this] autorelease]];
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
and the fix for that, changing the cast from id<NSFileManagerDelegate> to id<NSApplicationDelegate>, was applied in 2019 and was included in irrlicht 1.8.5. This broke the build for the 10.10 SDK and fixed it for every other SDK.
NSApp is supposed to be a global variable that holds the result of [NSApplication sharedApplication]. The problem is that in the OS X 10.10 and earlier SDKs, NSApp is declared as:
APPKIT_EXTERN id NSApp;
It's just a generic Objective-C id. When you call [NSApp setDelegate:] the compiler doesn't know what type of object it is and it apparently goes searching for any class that has a setDelegate: method. In the 10.9 and earlier SDKs, it somehow successfully finds the method of the NSApplication class that we wanted, but in the 10.10 SDK, for whatever reason (maybe a change in the way in which the various OS frameworks include each other's headers), it instead finds the method of the NSFileManager class, and it complains that we're not passing in an id that conforms to the NSFileManagerDelegate protocol. The fix should not have been to cast the app delegate object to be an NSFileManagerDelegate-conforming id to satisfy NSFileManager; instead, we need to convince the compiler that we are calling the method of NSApplication and not of NSFileManager.
I imagine Apple noticed this problem some time after the release of OS X 10.10 because in the OS X 10.11 and later SDKs, NSApp is declared as:
APPKIT_EXTERN __kindof NSApplication * __null_unspecified NSApp;
In other words, it's now a pointer to an NSApplication, so when you call [NSApp setDelegate:] it's now clear to the compiler that you want the setDelegate: method of an NSApplication object.
The solution I've seen employed elsewhere and the one I'm submitting in this patch that lets this build with any SDK is not to use NSApp here, but instead to use [NSApplication sharedApplication]. [NSApplication sharedApplication] has always been declared as:
+ (NSApplication *)sharedApplication;
so this will always find the right class's method.
While this is the only change necessary to fix the problem, my patch includes a further change. I declare the app delegate class to conform to the NSApplicationDelegate and NSWindowDelegate protocols. This makes the cast to id<NSApplicationDelegate> when calling setDelegate: unnecessary, since the compiler will already know at that point from the class declaration that it conforms to that protocol. Later, when retrieving the app delegate and trying to set it as the window's delegate, a cast is still necessary, but I've changed it to more accurately reflect which class of object is being returned. The compiler already knows from the class declaration that this object conforms to that protocol.
I've attached patches for both the 1.8 branch and trunk. I've verified they fix this problem on OS X 10.9 using the OS X 10.10 SDK and that they don't break the build on macOS 12 using the macOS 12 SDK.
My patches contain a mixture of line ending styles because your code files contain a mixture of line ending styles.
The trunk patch.
Thanks for all the work to digg that deep into this bug and giving such a solid explanation. It's applied in r6520 in 1.8 branch and will be in Irrlicht 1.8.6
Also applied in r6521 in svn trunk