Release package

[katajakasa]

We need somekind of instruction manual on how to install before we release. It should at least contain the following:

• Game installation (windows, linux... should we package for debian ?)
• Installing resource files (download link for these, let's not package them with the executable for now)

We also need to compile the release versions somehow.

[katajakasa]

Manual done, but will probably need a typo & grammar check.

[Vagabond]

I'd really rather see us build a static binary that people can just drop in a directory and run. Otherwise we'll be at the mercy of distro packagers with regards to library versions and such.

[katajakasa]

Moved this for 0.6. Static linking of all libraries will require some more work on the CMake front, and it will take a while.

[TheOnlyJoey]

Static compiling is easy. I have some spare time tomorow so will dive into it. On Dec 15, 2013 2:21 PM, "Tuomas Virtanen" notifications@github.com wrote:

Moved this for 0.6. Static compiling will require some more work on the CMake front, and it will take a while.

— Reply to this email directly or view it on GitHubhttps://github.com/omf2097/openomf/issues/67#issuecomment-30605068 .

[Vagabond]

I'd like to at least try to make it work for 0.5, so we can have a real binary release.

[Vagabond]

Bear in mind though, that we cannot statically link openAL, because of LGPL licencing issues. I think all the other dependencies can be statically linked, though.

[katajakasa]

OpenAL is similar to OpenGL in how it is used. It's meant to be dynamically linked, and the environment should supply one or more openal implementation libraries through the api, from which we could pick an output device. So we shouldn't link that statically anyways.

Glew can be linked statically as usual, but needs a special define before including the header.

I'm not sure about the wisdom of doing a static SDL library link. Since we are using the basic SDL2.0.0 stuff (well, 2.0.1 later maybe), I doubt we would run into any trouble by trusting that the environment has SDL2. Either it has it, in which case any version will do (later ones might have bug/speed fixes). If it doesn't, then it can be installed by package manager.

[Vagabond]

SDL 2.0 is so new that any of the other distros will not have a package for it. If we build the openomf package on like centos 5 or something ancient and statically link it against a bunch of libraries, it'll run out of the box more or less anywhere.

[Vagabond]

Last night I was able to make an OSX 'app bundle' for openomf with all the resources and libraries included inside it. It has some problems with segfaulting that I do not currently understand, but I was able to start and run the game. The tool that I used to adjust the library paths in the binary so they could be stored in the app bundle was this:

http://macdylibbundler.sourceforge.net/

There are notes on the app bundle directory/file layout here:

http://stackoverflow.com/questions/1596945/building-osx-app-bundle

[Vagabond]

I am now able to package successfully for OSX, here are some packaging notes:

https://gist.github.com/Vagabond/2df8ab8f6d26bd4e12f4

When the time comes I can build releases for OSX Lion, which should probably work on mountain lion and mavericks as well.

[katajakasa]

I've got a script for building windows 32bit and 64bit release packages.

[katajakasa]

I think we still need some kind of packages for linux, though. Maybe we should add .deb packaging files to master ?

[Vagabond]

Just make 'make install' work and leave the packaging to the distributions.

[katajakasa]

We have macosx, win32, win64 packages for 0.6 done. Moving this for 0.7.

[katajakasa]

Okay, i'm closing this issue as old, and opening up a new release issue for 0.7.