Skip to content
Permalink
Browse files

*** empty log message ***

  • Loading branch information
slouken committed Nov 2, 2001
1 parent dccda2e commit 8963b3ed16ddb97881bb6e8957ba3edd1990348e
Showing with 158 additions and 115 deletions.
  1. +22 −49 README.MacOSX
  2. +0 −6 sdl-config.in
  3. +0 −11 sdl.m4
  4. +2 −1 src/joystick/linux/SDL_sysjoystick.c
  5. +1 −2 src/main/Makefile.am
  6. +3 −7 src/main/macosx/SDLMain.h
  7. +130 −27 src/main/macosx/SDLMain.m
  8. +0 −11 test/acinclude.m4
  9. +0 −1 test/testgl.c
@@ -25,79 +25,52 @@ use the traditional autoconf/automake/make method, or use Apple's Project Builde
Using the Simple DirectMedia Layer with a traditional Makefile
==============================================================================

In the following, it will be mostly assumed that you are using autoconf and
automake to setup your SDL project, and furthermore that you use the AM_PATH_SDL
macro provided by SDL in sdl.m4. If you are not using these tools, you can
still use SDL but it will be somewhat hard to get running.
An existing autoconf/automake build system for your SDL app has good chances
to work almost unchanged on OS X. However, to produce a "real" MacOS X binary
that you can distribute to users, you need to put the generated binary into a
so called "bundle", which basically is a fancy folder with a name like
"MyCoolGame.app".

Only step 1) is really required to get started, but for full OS X support you
will want to do the other steps, too.

1) Update your acinclude.m4 file in case you have copied an older version of
sdl.m4 into it. This is essential as AM_PATH_SDL now performs some additional
tasks when used on MacOS X

Rationale: AM_PATH_SDL copies /usr/local/share/sdl/Info.plist and the folder
/usr/local/share/sdl/SDL_main.nib/ into the directory where configure is invoked.
This is essential for the configure script to be able to run the test code
that detects SDL.

2) Copy SDL's Info.plist.in file (from src/main/macosx) into your project's main
folder (the same spot that your configure.in sits), and edit it to suite your
needs. Then add it to your AC_OUTPUT list in configure.in

Rationale: The Info.plist file can be used to specify an icon file for
your app, and also to provide a human readable version/copyright string
and other meta-information to the user via the Finder's Get Info dialog.

3) Add something like the following rule to your Makefile.am:
To get this build automatically, add something like the following rule to
your Makefile.am:

bundle_contents = APP_NAME.app/Contents
APP_NAME_bundle: EXE_NAME
mkdir -p $(bundle_contents)/MacOS
mkdir -p $(bundle_contents)/Resources
mkdir -p $(bundle_contents)/Resources/SDL_main.nib
echo "APPL????" > $(bundle_contents)/PkgInfo
$(INSTALL_DATA) Info.plist $(bundle_contents)/
$(INSTALL_DATA) SDL_main.nib/*.nib $(bundle_contents)/Resources/SDLMain.nib
$(INSTALL_PROGRAM) $< $(bundle_contents)/MacOS/

You should replace EXE_NAME with the name of the executable. APP_NAME is what
will be visible to the user in the Finder. Usually it will be the same
as EXE_NAME but capitalized. E.g. if EXE_NAME is "testgame" then APP_NAME
usually is "TestGame". You might also want to use @PACKAGE@ to use the package
name as specified in your configure.in file.

If your project builds more than one application, you will have to do a bit more.
For each of your target applications, you need a seperate rule. Furthermore, each
needs its own Info.plist file, since that has to contain the exact name of the
executable (i.e. EXE_NAME above). One way to do that is to use sed in your make rules
and modify a single master Info.plist.
You should replace EXE_NAME with the name of the executable. APP_NAME is what
will be visible to the user in the Finder. Usually it will be the same
as EXE_NAME but capitalized. E.g. if EXE_NAME is "testgame" then APP_NAME
usually is "TestGame". You might also want to use @PACKAGE@ to use the package
name as specified in your configure.in file.

Rationale: on Mac OS X, executables have to be put into so-called "bundles".
The make rule given above will construct such a bundle around the executable
for you. You need to make a copy of it for each target application.
If your project builds more than one application, you will have to do a bit
more. For each of your target applications, you need a seperate rule.

4) If you want the create bundles to be installed, you may want to add this
rule to your Makefile.am:
If you want the created bundles to be installed, you may want to add this
rule to your Makefile.am:

install-exec-hook: APP_NAME_bundle
rm -rf $(DESTDIR)$(prefix)/Applications/APP_NAME.app
mkdir -p $(DESTDIR)$(prefix)/Applications/
cp -r $< /$(DESTDIR)$(prefix)Applications/

This rule takes the Bundle created by the rule from step 3 and installs them
into $(DESTDIR)$(prefix)/Applications/.
This rule takes the Bundle created by the rule from step 3 and installs them
into $(DESTDIR)$(prefix)/Applications/.

Again, if you want to install multiple applications, you will have to augment
the make rule accordingly.
Again, if you want to install multiple applications, you will have to augment
the make rule accordingly.


==============================================================================
Using the Simple DirectMedia Layer with Project Builder
==============================================================================

These instructions are for using Apple's Project Builder IDE to build SDL applications.
These instructions are for using Apple's Project Builder IDE to build SDL
applications.

- First steps

@@ -56,12 +56,6 @@ while test $# -gt 0; do
@ENABLE_STATIC_TRUE@ libdirs="-L@libdir@ @SDL_RLD_FLAGS@"
@ENABLE_STATIC_TRUE@ echo $libdirs @SDL_LIBS@ @SYSTEM_LIBS@
@ENABLE_STATIC_TRUE@ ;;
@TARGET_MACOSX_TRUE@ --nib)
@TARGET_MACOSX_TRUE@ echo @datadir@/sdl/SDLMain.nib
@TARGET_MACOSX_TRUE@ ;;
@TARGET_MACOSX_TRUE@ --plist)
@TARGET_MACOSX_TRUE@ echo @datadir@/sdl/Info.plist
@TARGET_MACOSX_TRUE@ ;;
*)
echo "${usage}" 1>&2
exit 1
11 sdl.m4
@@ -59,17 +59,6 @@ dnl Now check if the installed SDL is sufficiently new. (Also sanity
dnl checks the results of sdl-config to some extent
dnl
rm -f conf.sdltest
case "$target" in
*-*-darwin*)
cp -r `$SDL_CONFIG --nib` .
dnl create an Info.plist file, unless one exists
if test -f Info.plist ; then
:
else
cp `$SDL_CONFIG --plist` .
fi
;;
esac
AC_TRY_RUN([
#include <stdio.h>
#include <stdlib.h>
@@ -61,9 +61,10 @@ static const char *special_joysticks[] = {
"'Microsoft SideWinder Dual Strike USB version 1.0' 2 1 0",
"'WingMan Interceptor' 3 3 0",
/* WingMan Extreme Analog - not recognized by default
"'Analog 3-axis 4-button joystick' 2 1",
"'Analog 3-axis 4-button joystick' 2 1 0",
*/
"'WingMan Extreme Digital 3D' 4 1 0",
"'Analog 2-axis 4-button 1-hat FCS joystick' 2 1 0",
NULL
};
#else
@@ -4,12 +4,11 @@
# This is necessary because some platforms have special program
# entry points, which require special application initialization.

SUBDIRS = macosx

ARCH_SUBDIRS = $(srcdir)/beos \
$(srcdir)/epoc \
$(srcdir)/linux \
$(srcdir)/macos \
$(srcdir)/macosx \
$(srcdir)/win32

# Build a separate library containing the main() entry point.
@@ -1,15 +1,11 @@
/* SDLMain.h - main entry point for our Cocoa-ized SDL app
Darrell Walisser - dwaliss1@purdue.edu
/* SDLMain.m - main entry point for our Cocoa-ized SDL app
Initial Version: Darrell Walisser <dwaliss1@purdue.edu>
Non-NIB-Code & other changes: Max Horn <max@quendi.de>
Feel free to customize this file to suit your needs
*/

#import <Cocoa/Cocoa.h>

@interface SDLMain : NSObject
{
}
- (IBAction)quit:(id)sender;
- (IBAction)makeFullscreen:(id)sender;
- (void)applicationDidFinishLaunching:(NSNotification *)aNotification;
@end

0 comments on commit 8963b3e

Please sign in to comment.