docs/README-macosx.md
author Ryan C. Gordon
Sun, 27 Aug 2017 22:15:57 -0400
changeset 11365 a9bd2625fa01
parent 10556 007dfe83abf8
child 11400 9eefdf672499
permissions -rw-r--r--
vulkan: Initial Vulkan support!

This work was done by Jacob Lifshay and Mark Callow; I'm just merging it
into revision control.
     1 Mac OS X
     2 ==============================================================================
     3 
     4 These instructions are for people using Apple's Mac OS X (pronounced
     5 "ten").
     6 
     7 From the developer's point of view, OS X is a sort of hybrid Mac and
     8 Unix system, and you have the option of using either traditional
     9 command line tools or Apple's IDE Xcode.
    10 
    11 Preparation
    12 ===========
    13 
    14 1.  Either download [Molten](https://moltengl.com/free-trial/) and unzip it or download the Vulkan headers from Khronos's [Vulkan-Docs](https://github.com/KhronosGroup/Vulkan-Docs/tree/1.0/src/vulkan) repo and put them in a directory hierarchy `include/vulkan`.
    15 2. Set a `VULKAN_SDK` variable in one of the ways described below. Its value should be either the `MoltenVK` directory within the unzipped Molten package or the parent of the `include/vulkan` hierarchy.
    16 	- If you are going to use the command line, set and export a `VULKAN_SDK` environment variable in your shell's start-up file, e.g. `~/.bash_profile`.
    17 	- If you are going to use CMake, either set and export a `VULKAN_SDK` environment variable before running `cmake` or set the `VULKAN_SDK` variable in `cmake-gui` and press *Configure*.
    18 	- If you are going to use the provided Xcode projects, set a `VULKAN_SDK` custom path in Xcode's preferences. Select *Custom Paths* on the *Locations* tab of preferences.
    19 
    20 Command Line Build
    21 ==================
    22 
    23 To build SDL using the command line, use the standard configure and make
    24 process:
    25 
    26     ./configure
    27     make
    28     sudo make install
    29 
    30 You can also build SDL as a Universal library (a single binary for both
    31 32-bit and 64-bit Intel architectures), on Mac OS X 10.7 and newer, by using
    32 the gcc-fat.sh script in build-scripts:
    33 
    34     mkdir mybuild
    35     cd mybuild
    36     CC=$PWD/../build-scripts/gcc-fat.sh CXX=$PWD/../build-scripts/g++-fat.sh ../configure
    37     make
    38     sudo make install
    39 
    40 This script builds SDL with 10.5 ABI compatibility on i386 and 10.6
    41 ABI compatibility on x86_64 architectures.  For best compatibility you
    42 should compile your application the same way.
    43 
    44 Please note that building SDL requires at least Xcode 4.6 and the 10.7 SDK
    45 (even if you target back to 10.5 systems). PowerPC support for Mac OS X has
    46 been officially dropped as of SDL 2.0.2.
    47 
    48 To use the library once it's built, you essential have two possibilities:
    49 use the traditional autoconf/automake/make method, or use Xcode.
    50 
    51 ==============================================================================
    52 Caveats for using SDL with Mac OS X
    53 ==============================================================================
    54 
    55 Some things you have to be aware of when using SDL on Mac OS X:
    56 
    57 - If you register your own NSApplicationDelegate (using [NSApp setDelegate:]),
    58   SDL will not register its own. This means that SDL will not terminate using
    59   SDL_Quit if it receives a termination request, it will terminate like a 
    60   normal app, and it will not send a SDL_DROPFILE when you request to open a
    61   file with the app. To solve these issues, put the following code in your 
    62   NSApplicationDelegate implementation:
    63 
    64 
    65     - (NSApplicationTerminateReply)applicationShouldTerminate:(NSApplication *)sender
    66     {
    67         if (SDL_GetEventState(SDL_QUIT) == SDL_ENABLE) {
    68             SDL_Event event;
    69             event.type = SDL_QUIT;
    70             SDL_PushEvent(&event);
    71         }
    72     
    73         return NSTerminateCancel;
    74     }
    75     
    76     - (BOOL)application:(NSApplication *)theApplication openFile:(NSString *)filename
    77     {
    78         if (SDL_GetEventState(SDL_DROPFILE) == SDL_ENABLE) {
    79             SDL_Event event;
    80             event.type = SDL_DROPFILE;
    81             event.drop.file = SDL_strdup([filename UTF8String]);
    82             return (SDL_PushEvent(&event) > 0);
    83         }
    84     
    85         return NO;
    86     }
    87 
    88 ==============================================================================
    89 Using the Simple DirectMedia Layer with a traditional Makefile
    90 ==============================================================================
    91 
    92 An existing autoconf/automake build system for your SDL app has good chances
    93 to work almost unchanged on OS X. However, to produce a "real" Mac OS X binary
    94 that you can distribute to users, you need to put the generated binary into a
    95 so called "bundle", which basically is a fancy folder with a name like
    96 "MyCoolGame.app".
    97 
    98 To get this build automatically, add something like the following rule to
    99 your Makefile.am:
   100 
   101     bundle_contents = APP_NAME.app/Contents
   102     APP_NAME_bundle: EXE_NAME
   103     	mkdir -p $(bundle_contents)/MacOS
   104     	mkdir -p $(bundle_contents)/Resources
   105     	echo "APPL????" > $(bundle_contents)/PkgInfo
   106     	$(INSTALL_PROGRAM) $< $(bundle_contents)/MacOS/
   107 
   108 You should replace EXE_NAME with the name of the executable. APP_NAME is what
   109 will be visible to the user in the Finder. Usually it will be the same
   110 as EXE_NAME but capitalized. E.g. if EXE_NAME is "testgame" then APP_NAME 
   111 usually is "TestGame". You might also want to use `@PACKAGE@` to use the package
   112 name as specified in your configure.in file.
   113 
   114 If your project builds more than one application, you will have to do a bit
   115 more. For each of your target applications, you need a separate rule.
   116 
   117 If you want the created bundles to be installed, you may want to add this
   118 rule to your Makefile.am:
   119 
   120     install-exec-hook: APP_NAME_bundle
   121     	rm -rf $(DESTDIR)$(prefix)/Applications/APP_NAME.app
   122     	mkdir -p $(DESTDIR)$(prefix)/Applications/
   123     	cp -r $< /$(DESTDIR)$(prefix)Applications/
   124 
   125 This rule takes the Bundle created by the rule from step 3 and installs them
   126 into "$(DESTDIR)$(prefix)/Applications/".
   127 
   128 Again, if you want to install multiple applications, you will have to augment
   129 the make rule accordingly.
   130 
   131 
   132 But beware! That is only part of the story! With the above, you end up with
   133 a bare bone .app bundle, which is double clickable from the Finder. But
   134 there are some more things you should do before shipping your product...
   135 
   136 1) The bundle right now probably is dynamically linked against SDL. That 
   137    means that when you copy it to another computer, *it will not run*,
   138    unless you also install SDL on that other computer. A good solution
   139    for this dilemma is to static link against SDL. On OS X, you can
   140    achieve that by linking against the libraries listed by
   141 
   142        sdl-config --static-libs
   143 
   144    instead of those listed by
   145 
   146        sdl-config --libs
   147 
   148    Depending on how exactly SDL is integrated into your build systems, the
   149    way to achieve that varies, so I won't describe it here in detail
   150 
   151 2) Add an 'Info.plist' to your application. That is a special XML file which
   152    contains some meta-information about your application (like some copyright
   153    information, the version of your app, the name of an optional icon file,
   154    and other things). Part of that information is displayed by the Finder
   155    when you click on the .app, or if you look at the "Get Info" window.
   156    More information about Info.plist files can be found on Apple's homepage.
   157 
   158 
   159 As a final remark, let me add that I use some of the techniques (and some
   160 variations of them) in Exult and ScummVM; both are available in source on
   161 the net, so feel free to take a peek at them for inspiration!
   162 
   163 
   164 ==============================================================================
   165 Using the Simple DirectMedia Layer with Xcode
   166 ==============================================================================
   167 
   168 These instructions are for using Apple's Xcode IDE to build SDL applications.
   169 
   170 - First steps
   171 
   172 The first thing to do is to unpack the Xcode.tar.gz archive in the
   173 top level SDL directory (where the Xcode.tar.gz archive resides).
   174 Because Stuffit Expander will unpack the archive into a subdirectory,
   175 you should unpack the archive manually from the command line:
   176 
   177     cd [path_to_SDL_source]
   178     tar zxf Xcode.tar.gz
   179 
   180 This will create a new folder called Xcode, which you can browse
   181 normally from the Finder.
   182 
   183 - Building the Framework
   184 
   185 The SDL Library is packaged as a framework bundle, an organized
   186 relocatable folder hierarchy of executable code, interface headers,
   187 and additional resources. For practical purposes, you can think of a 
   188 framework as a more user and system-friendly shared library, whose library
   189 file behaves more or less like a standard UNIX shared library.
   190 
   191 To build the framework, simply open the framework project and build it. 
   192 By default, the framework bundle "SDL.framework" is installed in 
   193 /Library/Frameworks. Therefore, the testers and project stationary expect
   194 it to be located there. However, it will function the same in any of the
   195 following locations:
   196 
   197     ~/Library/Frameworks
   198     /Local/Library/Frameworks
   199     /System/Library/Frameworks
   200 
   201 - Build Options
   202     There are two "Build Styles" (See the "Targets" tab) for SDL.
   203     "Deployment" should be used if you aren't tweaking the SDL library.
   204     "Development" should be used to debug SDL apps or the library itself.
   205 
   206 - Building the Testers
   207     Open the SDLTest project and build away!
   208 
   209 - Using the Project Stationary
   210     Copy the stationary to the indicated folders to access it from
   211     the "New Project" and "Add target" menus. What could be easier?
   212 
   213 - Setting up a new project by hand
   214     Some of you won't want to use the Stationary so I'll give some tips:
   215     * Create a new "Cocoa Application"
   216     * Add src/main/macosx/SDLMain.m , .h and .nib to your project
   217     * Remove "main.c" from your project
   218     * Remove "MainMenu.nib" from your project
   219     * Add "$(HOME)/Library/Frameworks/SDL.framework/Headers" to include path
   220     * Add "$(HOME)/Library/Frameworks" to the frameworks search path
   221     * Add "-framework SDL -framework Foundation -framework AppKit" to "OTHER_LDFLAGS"
   222     * Set the "Main Nib File" under "Application Settings" to "SDLMain.nib"
   223     * Add your files
   224     * Clean and build
   225 
   226 - Building from command line
   227     Use pbxbuild in the same directory as your .pbproj file
   228 
   229 - Running your app
   230     You can send command line args to your app by either invoking it from
   231     the command line (in *.app/Contents/MacOS) or by entering them in the
   232     "Executables" panel of the target settings.
   233     
   234 - Implementation Notes
   235     Some things that may be of interest about how it all works...
   236     * Working directory
   237         As defined in the SDL_main.m file, the working directory of your SDL app
   238         is by default set to its parent. You may wish to change this to better
   239         suit your needs.
   240     * You have a Cocoa App!
   241         Your SDL app is essentially a Cocoa application. When your app
   242         starts up and the libraries finish loading, a Cocoa procedure is called,
   243         which sets up the working directory and calls your main() method.
   244         You are free to modify your Cocoa app with generally no consequence 
   245         to SDL. You cannot, however, easily change the SDL window itself.
   246         Functionality may be added in the future to help this.
   247 
   248 
   249 Known bugs are listed in the file "BUGS.txt".