Mercurial > sdl-ios-xcode
view README.Porting @ 4324:1496aa09e41e SDL-1.2
Steven Noonan to sdl
While trying to build the SDLMain.m included with SDL 1.2.14, with
#define SDL_USE_NIB_FILE 1:
/Users/steven/Development/darwinia/targets/macosx/Darwinia/SDLMain.m:
In function '-[SDLMain fixMenu:withAppName:]':
/Users/steven/Development/darwinia/targets/macosx/Darwinia/SDLMain.m:122:
warning: 'sizeToFit' is deprecated (declared at
/Developer/SDKs/MacOSX10.6.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSMenu.h:281)
/Users/steven/Development/darwinia/targets/macosx/Darwinia/SDLMain.m:
In function 'main':
/Users/steven/Development/darwinia/targets/macosx/Darwinia/SDLMain.m:376:
warning: 'poseAsClass:' is deprecated (declared at
/Developer/SDKs/MacOSX10.6.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSObject.h:127)
/Users/steven/Development/darwinia/targets/macosx/Darwinia/SDLMain.m:376:
error: 'poseAsClass:' is unavailable (declared at
/Developer/SDKs/MacOSX10.6.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSObject.h:127)
/Users/steven/Development/darwinia/targets/macosx/Darwinia/SDLMain.m:377:
warning: passing argument 2 of 'NSApplicationMain' from incompatible
pointer type
Eric Wing to Sam
I don't have time today to look at this in detail, but the problem is definitely the poseAsClass: method.
This was deprecated in Obj-C 2.0 and not retained in 64-bit.
I've never used this method and it has always been limited to esoteric uses. I think this is why Apple wanted to dump it (among complicating some other things they do). I have read about others getting bit by this when migrating. Long story short, there really isn't a migration path for this method. The question that then must be asked is why are we using it (what does it accomplish), and then figure out the 'proper' way of accomplishing that.
Glancing at SDLMain.m, it's not obvious to me why it is there or what it is really accomplishing. My only speculation is that NSApplicationMain hardcodes something to look for NSApplication and a subclass (SDLApplication) fails for some reason (assuming that the original coder did this for good reason).
Three thoughts come to mind.
1) The Info.plist has properties to control things related to the startup class and nib.
NSPrincipalClass, NSMainNibFile
Maybe principle class needs to be SDLApplication and we can delete the poseAs
2) I was told that 10.6 introduced new APIs to make programatic NIB wrangling and avoidance easier. Unfortunately, I don't know the specifics.
3) Instead of subclassing NSApplication in SDLMain.m, maybe we can just add a category. It looks like the following is the only thing that is done (quick glance):
@interface SDLApplication : NSApplication
@end
@implementation SDLApplication
/* Invoked from the Quit menu item */
- (void)terminate:(id)sender
{
/* Post a SDL_QUIT event */
SDL_Event event;
event.type = SDL_QUIT;
SDL_PushEvent(&event);
}
@end
So instead, we change this to: (warning written in mail and untested)
@interface NSApplication (SDLApplication)
- (void) terminate:(id)sender;
@end
@implementation NSApplication (SDLApplication)
/* Invoked from the Quit menu item */
- (void)terminate:(id)sender
{
/* Post a SDL_QUIT event */
SDL_Event event;
event.type = SDL_QUIT;
SDL_PushEvent(&event);
}
@end
Then everywhere SDLApplication is used, we change it to NSApplication (and remove the poseAsClass line).
Perhaps you could ask the bug reporter to try this solution (#3).
And if that fails, maybe try #1.
-Eric
Steven Noonan to Sam
The suggested change (diff below) seems to work fine.
- Steven
author | Sam Lantinga <slouken@libsdl.org> |
---|---|
date | Mon, 12 Oct 2009 21:07:12 +0000 |
parents | b2b476a4a73c |
children | 103760c3a5dc |
line wrap: on
line source
* Porting To A New Platform The first thing you have to do when porting to a new platform, is look at include/SDL_platform.h and create an entry there for your operating system. The standard format is __PLATFORM__, where PLATFORM is the name of the OS. Ideally SDL_platform.h will be able to auto-detect the system it's building on based on C preprocessor symbols. There are two basic ways of building SDL at the moment: 1. The "UNIX" way: ./configure; make; make install If you have a GNUish system, then you might try this. Edit configure.in, take a look at the large section labelled: "Set up the configuration based on the target platform!" Add a section for your platform, and then re-run autogen.sh and build! 2. Using an IDE: If you're using an IDE or other non-configure build system, you'll probably want to create a custom SDL_config.h for your platform. Edit SDL_config.h, add a section for your platform, and create a custom SDL_config_{platform}.h, based on SDL_config.h.minimal and SDL_config.h.in Add the top level include directory to the header search path, and then add the following sources to the project: src/*.c src/audio/*.c src/cdrom/*.c src/cpuinfo/*.c src/events/*.c src/file/*.c src/joystick/*.c src/stdlib/*.c src/thread/*.c src/timer/*.c src/video/*.c src/audio/disk/*.c src/video/dummy/*.c src/joystick/dummy/*.c src/cdrom/dummy/*.c src/thread/generic/*.c src/timer/dummy/*.c src/loadso/dummy/*.c Once you have a working library without any drivers, you can go back to each of the major subsystems and start implementing drivers for your platform. If you have any questions, don't hesitate to ask on the SDL mailing list: http://www.libsdl.org/mailing-list.php Enjoy! Sam Lantinga (slouken@libsdl.org)