There are different people who already worked on improvements of Mac support, but we're not yet where we want to be and there are still some missing bits before we can put everything together.
This involves different aspects and we will only be successful if we cover all of them or at least the important ones.
First let's give an overview for those who didn't look at our build-system in detail:
update-workspaces.sh / update-workspaces.bat:
The sh-script on Linux/*nix/OSX runs the compilation of some external dependencies and also premake.
On Windows the batchfile only executes premake because most of the dependencies are precompiled.
Premake creates our workspaces (also called solutions or projects) for the different platforms.
Currently we support Makefiles, VisualStudio (2005, 2008, 2010), Xcode3, Codeblocks.
The workspaces are used for building the code on different platform and also for development with different programs (IDE's).
For (alpha-)releases we make a special deployment for various reasons. The main reason is that we want to make it easier and more convenient for the user.
Everything is precompiled and distributed in appropriate containers for the different operating systems and platforms (e.g. .deb files for debian based linux systems and .exe files for windows etc.).
I don't know who exactly does that for which system.
OK now our current status:
Currently we have support for XCode3 but It's not particularly useful as far as I can tell and XCode 4 is already out quite a while.
The most current version of premake (4.4beta) supports XCode4, but we don't yet know how well.
We are using premake4.3 with quite a lot of customizations. Upgrading is a lot easier than from premake 3.x to 4.3, but I requires some efforts to reimplement the customizations that are still needed and to test everything.
Here's a list I made in a few minutes... but It's probably not complete.
- General: Customizations for using nasm assembler. It's not needed anymore, but the customizations are still in our code...
- General: PCHHeader as „path“ instead of „string“ in api.lua
- Windows: trimmprefix for removing the „source“-prefix
- Makefiles: Fix for parallel builds
- Makefiles: Test generation
- Linux+Makefiles, Codeblocks: --start-group and –end-group to work around circular referencing
- Codeblocks: Fix Codeblocks not relinking after static libraries change (changeset 10814)
- Workaround some linking problems for ActorEditor, ArchiveViewer and FileConverter (changeset 10749)
- ... maybe forgot some
Build-process on the Mac:
The build-process used during development generally works. There's one little problem because both the Makefiles and XCode generate a .app bundle that does not work.
You have to copy the binary inside the app-bundle to /binaries/system before it can be executed properly.
Deployment process on the Mac:
We currently don't have one. We just link to the development build-instructions and sometimes there are people on the forums who create a .app bundle.
There are currently at least two open tickets about this topic:
The patches in both tickets don't offer completed solutions yet.
Next steps / open questions
I think we must still stick to premake and should not use manually created XCode projects.
Changing one workspace manually is error-prone and time-consuming.
I've created a quick-and-dirty integration of the premake4.4beta and sent it to historic_bruno because he has XCode4 and knows what to check. He will test if it's worth the efforts of upgrading.
Build-process on the Mac:
Changing the kind of our WindowedApp-Projects to "ConsoleApp" in premake4.lua causes XCode and the Makefiles to generated simple binaries instead of the broken .app bundles on OSX. That's a quick fix and we just need to test if we can change this settings on all environments or if we should do it just for the Mac.
Deployment process on the Mac:
I've discussed this with historic_bruno and we both think that we should seperate the deployment from the build-system.
It's something that should come after everything is build and the build-process should stay as it is for development.
I've red some documentation about .app bundles and started creating a shell-script to but one together.
We aren't sure if we should put everything into a single .app bundle or if we should use more advanced packaging tools.
I think we have to do the .app bundle anyway, because those packages seem to be just some kind of container. If there are no important downsides of "simple" .app bundles, we should avoid the additional complexity added by the packager.
One important question that could make a decision obsolete is where we want to put the different resources like the data-directory.
We know about two potentially suitable locations:
1. The Resources directory of the .app bundle
2. Library/Application Support/0AD/
I tend to the first because of two reasons:
1. According to the Bundle Programming Guide a bundle should contain all resources required to run propperly.
2. Having anything outside the bundle forces us to use the packager.
Code for resource-paths:
We definitely have to make some changes to source/ps/GameSetup/Paths.cpp about the location where it tries to find the data-directory and other directories.
Echelon9 proposed something about that in his patch. I think we should do something like that for the default behaviour on the Mac (either for Library/Application Support/0AD/ or the bundle's Resources-folder) and in addition add some possibilities to override the default behaviour by command-line parameters or environment variables.
I don't know which libraries need to be prebuilt yet and it will require more work and more testing.
One important thing is that the libraries should be compatible for different versions of OSX (which?) and 32 and 64 bit.
The Bundle Programming Guide states
I'm not sure if that's something that can be done with the bundles or if it just means using universal binaries.
A bundle can support multiple chip architectures (PowerPC, Intel) and different address space requirements (32-bit/64-bit). It can also support the inclusion of specialized executables (for example, libraries optimized for a particular set of vector instructions).
What do you think?
Probably that's a topic we could also discuss on our team-meeting.