Packaging for Mac

[Yggdrasil]

As GAE and MegaGlest both use CMake and CPack to compile on Mac we can easily work together to get a working bundle packaged. First of all, i have no knowledge about Mac and bundles. Never used a Mac. So all i know is from this page:
http://www.cmake.org/Wiki/CMake:CPackPackageGenerators#Bundle_.28OSX_only.29

Bruce mentioned in this thread that all needed libraries should be packaged in the bundle, probably data too. I would just install the libraries in a subfolder lib and set DYLD_LIBRARY_PATH to this folder so the linker finds it, like in the wiki example.

in CMakeLists.txt:

Code: [Select]

if(APPLE)
install(FILES ${LUA_LIBRARIES} ... DESTINATION lib)
endif()
In MegaGlest it is currently installed in ../Frameworks. I don't know if this is still in the bundle and a better location than lib.

CPACK_BUNDLE_STARTUP_COMMAND would then point to a shell script:

Code: [Select]

#!/bin/sh

GLEST_BUNDLE="`echo "$0" | sed -e 's|/Contents/MacOS/.*||'`"
GLEST_RESOURCES="$GLEST_BUNDLE/Contents/Resources"

export "DYLD_LIBRARY_PATH=$GLEST_RESOURCES/lib"
export "PATH=$GLEST_RESOURCES/bin:$PATH"

exec "$GLEST_RESOURCES/bin/glestadv" -datadir "$GLEST_RESOURCES/share/glestae"
The exec command is probably quite different in MegaGlest. In GAE we install all binaries in bin and all data in share/glestae.

I don't know if we need to start X11 like in the wiki example. One other problem: How do we package the map editor and g3dviewer? Especially, how do we start these programs? There's only one startup command and no "menu shortcuts" or similar things. Can someone with Mac knowledge please enlighten me?

Maybe using PackageMaker is an easier option than bundles...

[Bruce]

Agreed that it should be reasonably easy now to come up with a working bundle.

The standard folder for internal (or private) frameworks is PrvFrameworks. The structure of an application bundle is essentially this (i'll use glest.app for the purposes of the example):

glest.app (the application)
/ Contents
  -- info.plist
  -- Resources
  -- MacOS
  -- Frameworks
  -- (anything else)

The info.plist file stores the application properties - things like who bundled it, what its called etc. It's auto-generated form the XCode project (or from the PackageMaker).

The Resources folder contains things like icons and any GUI bits and pieces that may be needed by the application for it to display appropriately in Finder. For the purposes of Glest (incl GAE and MG), that folder will probably just contain the icon (in a .icns file).

The MacOS folder is what effectively stores the binary - it's what gets built by XCode and what is actually run by MacOS. This content is generated entirely by XCode so you don't have to worry about that.

The Frameworks folder contains all of the private frameworks (libraries) that are required for the application. Yggdrasil is right - this is where things like Xerces.Framework, OpenAL.Framework etc should go. In the current MegaGlest app (I can't seem to compile GAE, but I can get MG working), Xerces, Vorbis, SDL, ogg and libpng are all present in there, as is liblua.dylib. So most of the frameworks are there, but it would be good to include everything required. It also means that if an update by Apple is released and one of the system frameworks is updated and the update breaks the glest code the game won't break - it'll continue to use the private version (at which point developers can work out what changes need to be made to the code to use the new framework for the next point release).

Because bundles can include other stuff, you can add folders in here (such as a data folder) that would contain all of the GlestData. The only problem with that is it makes it indirectly accessible (i.e. you can't just navigate to it - you need to Open the package contents before you can access it), so the better option would be to install the glest data in /Volumes/System/Library/Application Support/MegaGlest (or GAE or Glest as appropriate). By using that folder the data is accessible to all users (~/Library/Application Support is user specific) and easy to access by browsing the filesystem. It also means that updates to the data can be installed without having to stuff around inside the application bundle (a good idea, particularly for non-tech ppl).

As for how to package other apps (like the map editor for example) - the Mac way would be to actually create 3 application bundles that reside in a folder, and that folder gets installed into Applications.

i.e. instead of:
/Applications/MegaGlest.app
/Applications/mapEditor.app
/Applications/g3dviewer.app

you would create them like this:
/Applications/Megaglest/Megaglest.app
/Applications/Megaglest/mapEditor.app
/Applications/Megaglest/g3dviewer.app

All three would essentially be separate applications, but you just make sure they reside in a common location and you should be able to use relative paths to point to any resources that may need to be accessible in other apps (so yes, you can point to ../megaglest.app/resources if need be).

PackageManager could be used to combine all 3 application bundles later for distribution if need be - that's something I'm quite good at even though I'm still getting my head around some of the other dev aspects.

I think we're at a point where there's a REALLY good opportunity to get Glest out there and a bit more visible. If you weren't aware, Apple have just announced OS X Lion and part of that includes the introduction of the Mac App Store (like the App Store on iOS). If we could get Glest bundled up and working properly before the App Store comes out (which is due in abt 3 months), then it could become a good way of getting exposure for it!

[Yggdrasil]

If you have compile problems with GAE then please tell us about them, otherwise nothing will change.

I would really like to stick with CMake/CPack because we already have it in use for Linux packages and the Windows installer. CPack installs by default everything in Resources. Only the "startup command" gets copied to MacOS. We install all data in share/glestae. This would be Resources/share/glestae in the bundle. It's no problem that the user can't write to this location as we have an addons folder for adding and manipulating files which is in the home directory. MegaGlest has something called "MyData". Not quite sure how it works and if it is usable for this situation.

So, Frameworks is a better place to install the dependencies? Is it searched by the linker automatically?

Creating extra bundles for the tools would add quite some redundancy. You have 3 copies of the dependencies then. The only solution to still use one bundle i can think of: Starting a launcher gui at first. Is there a scripting language with gui bindings pre-installed on the mac which we could use to get such a program quickly together? Compiling a wxWidgets program and starting it at first is also possible but involves more work.

I'll try to get a patch for GAE together which adds the bundle generator for mac. But as i already said in the first post i've no way to test this and would need some testers who can compile svn trunk of GAE.

[Bruce]

The reason Uhaven't been more specific with compile problems is because I've been testing other things first to make sure the problem is not related to my configuration. I've now identified what the cause of all my compile issues has been - compilation on Snow Leopard allows i386 or x86_64, and I've had frameworks and libraries that have been a mixture of the two. It appears as if there is no reliable 64 bit version of OpenAL for OS X at this stage, so I now have i386 frameworks for everything and compilation is going much more smoothly. Only issue now is physfs - can't seem to get my hands on an i386 build for SL, but I'll keep looking tomorrowand will see what I can find.

Until I get GAE to build I'm not able to experiment with private frameworks or anything yet. MegaGlest appears to be doing the private frameworks properly so I reckon it should be trivial to bring that aspect across to GAE. I think CMake will still be fine for building, but we may need to package a slightly different way for it to function as desired. That's a trivial process once compilation is working.

I appreciate all the work that's been done to get the project to here - I'm just trying to do my bit to make sure Glest for Mac behaves as Mac users expect, or you won't get them interested in the game. 

[Yggdrasil]

I committed the first try to svn branch 0.3.x. Would be nice if someone could try it out. Building the target PACKAGE in the XCode project should do the trick, i guess. If not try to run cpack on command line in the build directory.

Every dependency is installed in Resources/lib and the startup command executes glestadv. All data is included. The map editor and g3d viewer are in the bundle too, but probably not accessable (in Resources/bin). Just the first test.

[Bruce]

I'll try to take a look in the next few days and will let you know how it goes. Would be good to transfer any co-dependencies over to MG as well.