54 as EXE_NAME but capitalized. E.g. if EXE_NAME is "testgame" then APP_NAME |
54 as EXE_NAME but capitalized. E.g. if EXE_NAME is "testgame" then APP_NAME |
55 usually is "TestGame". You might also want to use @PACKAGE@ to use the package |
55 usually is "TestGame". You might also want to use @PACKAGE@ to use the package |
56 name as specified in your configure.in file. |
56 name as specified in your configure.in file. |
57 |
57 |
58 If your project builds more than one application, you will have to do a bit |
58 If your project builds more than one application, you will have to do a bit |
59 more. For each of your target applications, you need a seperate rule. |
59 more. For each of your target applications, you need a separate rule. |
60 |
60 |
61 If you want the created bundles to be installed, you may want to add this |
61 If you want the created bundles to be installed, you may want to add this |
62 rule to your Makefile.am: |
62 rule to your Makefile.am: |
63 |
63 |
64 install-exec-hook: APP_NAME_bundle |
64 install-exec-hook: APP_NAME_bundle |
73 the make rule accordingly. |
73 the make rule accordingly. |
74 |
74 |
75 |
75 |
76 But beware! That is only part of the story! With the above, you end up with |
76 But beware! That is only part of the story! With the above, you end up with |
77 a bare bone .app bundle, which is double clickable from the Finder. But |
77 a bare bone .app bundle, which is double clickable from the Finder. But |
78 there are some more things you should do before shipping yor product... |
78 there are some more things you should do before shipping your product... |
79 |
79 |
80 1) The bundle right now probably is dynamically linked against SDL. That |
80 1) The bundle right now probably is dynamically linked against SDL. That |
81 means that when you copy it to another computer, *it will not run*, |
81 means that when you copy it to another computer, *it will not run*, |
82 unless you also install SDL on that other computer. A good solution |
82 unless you also install SDL on that other computer. A good solution |
83 for this dilemma is to static link against SDL. On OS X, you can |
83 for this dilemma is to static link against SDL. On OS X, you can |
84 achieve that by linkinag against the libraries listed by |
84 achieve that by linking against the libraries listed by |
85 sdl-config --static-libs |
85 sdl-config --static-libs |
86 instead of those listed by |
86 instead of those listed by |
87 sdl-config --libs |
87 sdl-config --libs |
88 Depending on how exactly SDL is integrated into your build systems, the |
88 Depending on how exactly SDL is integrated into your build systems, the |
89 way to achieve that varies, so I won't describe it here in detail |
89 way to achieve that varies, so I won't describe it here in detail |
118 normally from the Finder. |
118 normally from the Finder. |
119 |
119 |
120 - Building the Framework |
120 - Building the Framework |
121 |
121 |
122 The SDL Library is packaged as a framework bundle, an organized |
122 The SDL Library is packaged as a framework bundle, an organized |
123 relocatable folder heirarchy of executible code, interface headers, |
123 relocatable folder hierarchy of executable code, interface headers, |
124 and additional resources. For practical purposes, you can think of a |
124 and additional resources. For practical purposes, you can think of a |
125 framework as a more user and system-friendly shared library, whose library |
125 framework as a more user and system-friendly shared library, whose library |
126 file behaves more or less like a standard UNIX shared library. |
126 file behaves more or less like a standard UNIX shared library. |
127 |
127 |
128 To build the framework, simply open the framework project and build it. |
128 To build the framework, simply open the framework project and build it. |
160 * Add your files |
160 * Add your files |
161 * Clean and build |
161 * Clean and build |
162 |
162 |
163 - Building from command line |
163 - Building from command line |
164 Use pbxbuild in the same directory as your .pbproj file |
164 Use pbxbuild in the same directory as your .pbproj file |
165 |
165 |
166 - Running your app |
166 - Running your app |
167 You can send command line args to your app by either invoking it from |
167 You can send command line args to your app by either invoking it from |
168 the command line (in *.app/Contents/MacOS) or by entering them in the |
168 the command line (in *.app/Contents/MacOS) or by entering them in the |
169 "Executibles" panel of the target settings. |
169 "Executables" panel of the target settings. |
170 |
170 |
171 - Implementation Notes |
171 - Implementation Notes |
172 Some things that may be of interest about how it all works... |
172 Some things that may be of interest about how it all works... |
173 * Working directory |
173 * Working directory |
174 As defined in the SDL_main.m file, the working directory of your SDL app |
174 As defined in the SDL_main.m file, the working directory of your SDL app |
179 starts up and the libraries finish loading, a Cocoa procedure is called, |
179 starts up and the libraries finish loading, a Cocoa procedure is called, |
180 which sets up the working directory and calls your main() method. |
180 which sets up the working directory and calls your main() method. |
181 You are free to modify your Cocoa app with generally no consequence |
181 You are free to modify your Cocoa app with generally no consequence |
182 to SDL. You cannot, however, easily change the SDL window itself. |
182 to SDL. You cannot, however, easily change the SDL window itself. |
183 Functionality may be added in the future to help this. |
183 Functionality may be added in the future to help this. |
184 |
184 |
185 |
185 |
186 Known bugs are listed in the file "BUGS" |
186 Known bugs are listed in the file "BUGS" |