Build environment and deployment on the Mac

[historic_bruno]

Today there was an avalanche of OS X related commits, the SDL-Mavericks build error should be fixed. gloox has been added to the lib build script, so the lobby can be built and tested. Kieran (k776) has reported the build currently fails on Mavericks, if anyone else has upgraded, I would be interested in hearing if the game builds successfully or not using latest SVN. Building against 10.9 SDK on Mountain Lion works for me now.

Please note: OS X devs will need to run ./build-osx-libs.sh again to build the new dependencies, and if you've recently upgraded to Mavericks, it is advised that you run ./build-osx-libs.sh --force-rebuild, and later ./clean-workspaces.sh to perform a clean build.

[wraitii]

Gave it a shot.

Can't run ./build-osx-libs.sh directly because the 10.7 SDK is removed in the latest Xcode. Changed to 10.8 and ran the script fine until the game compilation, which failed.

Started XCode, had to re-switch all the schemes to Release (this is annoying, if it could be changed it'd be great). Tried to compile. Seemed to go fine but I've got an error on every project, "Command /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool failed with exit code 1", which is somewhat odd.

[historic_bruno]

Can't run ./build-osx-libs.sh directly because the 10.7 SDK is removed in the latest Xcode.

Do you mean the bundle build? The lib build script doesn't have an SDK hardcoded, you would need to set the SYSROOT env variable, which shouldn't happen by accident (and it's not necessary unless you want the binaries to run on multiple computers).

Changed to 10.8 and ran the script fine until the game compilation, which failed.

Started XCode, had to re-switch all the schemes to Release (this is annoying, if it could be changed it'd be great). Tried to compile. Seemed to go fine but I've got an error on every project, "Command /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool failed with exit code 1", which is somewhat odd.

Which version of Xcode? Which version of the command line tools? (the results of gcc --version could be informative) Have you upgraded Xcode/command line tools recently?

Premake doesn't generate Xcode workspaces the way it should be done (using the "new" 4.x+ schemes concept), that is a known problem and one reason why I never use Xcode to build the game

BTW I don't know if it's documented anywhere or not, but it's not a good idea to mix the command line build scripts with SDK and Xcode, since Xcode has its own ways of doing SDK / targeting that might conflict. That's a completely untested scenario but I know there are many ways it could go wrong.

[dvangennip]

I tried compiling today on a fresh install of OS X 10.9 (Mavericks), with only the Xcode command line tools installed and cmake (no Xcode installed). I put back a copy of the 0ad svn from my earlier 1.6.8 (Snow Leopard) install, and updated svn to the most recent revision (#14154). As a first step, I cleaned the workspaces and tried build-osx-libs.sh with the --force-rebuild flag. All goes well until it gets to FCollada, at which point the compiling fails.

Building FCollada...
~/0ad/trunk/libraries/source/fcollada/src ~/0ad/trunk/libraries/source/fcollada ~/0ad/trunk/libraries/osx
FCollada/FCollada.cpp
error: unable to open output file 'output/debug/FCollada/FCollada.o': 'Error
opening output file 'output/debug/FCollada/FCollada.o''
1 error generated.
make: *** [output/debug/FCollada/FCollada.o] Error 1
make: *** Waiting for unfinished jobs....
ERROR: FCollada build failed

Of course, I never got to compiling the actual game. Trying the build-osx-libs.sh again, simply reports that it skips building FCollada, as it would be already built (it seems wrong to flag a lib as built when it failed to do so). As far as I can see, the other libraries were built successfully (FCollada is the last one in the list). The 'unopenable file' from the error message does exist though.

If you know anything I could try to get it going, let me know

[historic_bruno]

I tried compiling today on a fresh install of OS X 10.9 (Mavericks), with only the Xcode command line tools installed and cmake (no Xcode installed). I put back a copy of the 0ad svn from my earlier 1.6.8 (Snow Leopard) install, and updated svn to the most recent revision (#14154). As a first step, I cleaned the workspaces and tried build-osx-libs.sh with the --force-rebuild flag. All goes well until it gets to FCollada, at which point the compiling fails.

Building FCollada...

~/0ad/trunk/libraries/source/fcollada/src ~/0ad/trunk/libraries/source/fcollada ~/0ad/trunk/libraries/osx

FCollada/FCollada.cpp

error: unable to open output file 'output/debug/FCollada/FCollada.o': 'Error

opening output file 'output/debug/FCollada/FCollada.o''

1 error generated.

make: *** [output/debug/FCollada/FCollada.o] Error 1

make: *** Waiting for unfinished jobs....

ERROR: FCollada build failed

Are you having permissions issues? If you simply copied files from one computer to another, that is something that comes to mind. Make sure your account has read/write permissions on all the 0 AD sub-directories.

Of course, I never got to compiling the actual game. Trying the build-osx-libs.sh again, simply reports that it skips building FCollada, as it would be already built (it seems wrong to flag a lib as built when it failed to do so)

Indeed that's a bug in the build script, it should remove .already-built when --force-rebuild is used.

[dvangennip]

Adjusting the folder permissions seems to get the libraries to build. Thanks for the tip Building FCollada on Mavericks does generate a lot of warnings about deprecated stuff though. If you are interested, I saved a log of the terminal output. For now, I assume that will be amended upstream at some point..

However, the game still won't build. Now, I run into a similar issue with some other file. Again, the file exists. The permissions also appear fine, but I have to check and try some more. The permissions might still be a little wonky, although that shouldn't be an issue for new folders generated by the library compilation (?). This tr1/unordered_map file is part of the boost lib, btw. Compiling that library did not seem to give any errors.

$ make
==== Building mocks_real (release) ====
==== Building network (release) ====
precompiled.h
In file included from ../../../source/pch/network/precompiled.h:19:
In file included from ../../../source/lib/precompiled.h:107:
../../../source/lib/pch/pch_stdlib.h:74:11: fatal error: 'tr1/unordered_map'
file not found
# include <tr1/unordered_map>
^
1 error generated.
make[1]: *** [obj/network_Release/precompiled.h.gch] Error 1
make: *** [network] Error 2

Edited November 14, 2013 by dvangennip

[Ykkrosh]

The tr1/unordered_map includes are not used anywhere, so r14177 deletes them.

[historic_bruno]

Building FCollada on Mavericks does generate a lot of warnings about deprecated stuff though. If you are interested, I saved a log of the terminal output. For now, I assume that will be amended upstream at some point..

I don't believe FCollada is actively maintained, so any changes will have to come from us (#562 is relevant if anyone is interested)

I would prefer to ignore the warnings, unless they cause noticeable bugs in the game - nobody here understands all of FCollada, or what could break on one platform by "fixing" harmless warnings on another.

[dvangennip]

The tr1/unordered_map includes are not used anywhere, so r14177 deletes them.

Thanks, that helps me get past the problem

I keep running into things though, which makes me wonder if I'm the only one using a clean Mavericks install with just the (late October 2013 version of OS X Mavericks' specific) Command Line Tools, and having trouble? If I am the only one, sorry for bothering you all with my issues.. But I hope it is of help for other people on Mavericks.

Currently the build process fails at ModelRenderer.cpp with 20 errors that seem to relate to the command line tools. See the example (the first error encountered) below, and the error log attached.

In file included from ../../../source/renderer/ModelRenderer.cpp:1:

In file included from /Users/vangennip/0ad/trunk/build/workspaces/gcc/../../../source/pch/graphics/precompiled.h:18:

In file included from /Users/vangennip/0ad/trunk/build/workspaces/gcc/../../../source/lib/precompiled.h:76:

In file included from /Users/vangennip/0ad/trunk/build/workspaces/gcc/../../../source/lib/pch/pch_boost.h:35:

In file included from /Users/vangennip/0ad/trunk/build/workspaces/gcc/../../../libraries/osx/boost/include/boost/filesystem.hpp:16:

In file included from /Users/vangennip/0ad/trunk/build/workspaces/gcc/../../../libraries/osx/boost/include/boost/filesystem/path.hpp:25:

In file included from /Users/vangennip/0ad/trunk/build/workspaces/gcc/../../../libraries/osx/boost/include/boost/filesystem/path_traits.hpp:26:

/Library/Developer/CommandLineTools/usr/bin/../lib/c++/v1/vector:661:16: error:

non-const lvalue reference to type 'value_type' (aka

'boost::shared_ptr<CShaderTechnique>') cannot bind to a value of unrelated

type 'void *'

return *(this->__end_ - 1);

^~~~~~~~~~~~~~~~~~~

../../../source/renderer/ModelRenderer.cpp:505:52: note: in instantiation of

member function 'std::__1::vector<boost::shared_ptr<CShaderTechnique>,

ProxyAllocator<void *, Allocators::DynamicArena> >::back' requested here

...if (sortByDistTechs.empty() || sortByDistTechs.back() != tech)

^

ModelRenderer-errors.txt

Edited November 15, 2013 by dvangennip

[historic_bruno]

You're certainly not the only one having problems with Mavericks, but they are all slightly different. I may have to get a Mavericks install locally and spend some time working through this. Thanks Apple...

[wraitii]

Some more reports:

I run it fine in Xcode usually by rebuilding the workspaces after running the "build osx bundle" script. However in both cases I get a ""GL/glx.h" file not found" error in HWDetect.cpp.

[historic_bruno]

So I upgraded and now have a Mavericks test system, and got the command line build working on there after some tinkering. Apple only includes clang in their latest command line tools, so gcc and llvm-gcc are merely symlinks to clang, which is a confusing hack. More relevant is that as of Mavericks, clang uses libc++ as the default C++ library, before it was always libstdc++. It's likely that some libraries (e.g. Boost) are detecting that change and configuring to use libc++ and possibly C++11, which causes errors later in the game build.

One workaround is to use clang explicitly instead of "gcc", and tell clang to use libstdc++ via flags (-stdlib=libstdc++). That seems best for backward compatibility, clang actually gives an error if a deployment target < 10.7 is used with -stdlib=libc++. I think for this to work properly in Xcode as well, Premake will need to be modified to add those flags and use clang instead of gcc on OS X. clang is available even back to Xcode 3.x on Snow Leopard, so I'm not worried about losing compatibility there.

Another problem is that even with the above workaround, I was unable to build with a target < 10.7, since SDL fails to build when using some formerly deprecated functions and types (distinct from the errors mentioned and fixed previously). I don't really care to fix SDL's OS X SDK compatibility at the moment, so instead I will look into the best way to support 10.5-10.9 with our release bundles if possible.

[wraitii]

Interesting development.

Do you have any statistics on OSX version usage? I believe it's mostly a few reluctant users on 10.6 and the rest basically on 10.8/10.9

[historic_bruno]

Premake will need to be modified to add those flags and use clang instead of gcc on OS X

Looks like a hack for clang support was added to premake-dev earlier this year: https://bitbucket.org/premake/premake-dev/commits/6f77b0d18774eec7440d4f621c701b47fb8cbae8

It's not yet merged into the stable branch, and it's probably not usable as-is due to API differences from our old version of Premake. I haven't confirmed that. But needless to say it's more complicated than I had hoped

Do you have any statistics on OSX version usage? I believe it's mostly a few reluctant users on 10.6 and the rest basically on 10.8/10.9

We would need updated stats from Philip to know that. It's not impossible to support OS X as far back as 10.5, like we've been doing, it means continuing to release two separate bundles and keeping a build machine with an old SDK on it.

[dvangennip]

One workaround is to use clang explicitly instead of "gcc", and tell clang to use libstdc++ via flags (-stdlib=libstdc++). That seems best for backward compatibility, clang actually gives an error if a deployment target < 10.7 is used with -stdlib=libc++. I think for this to work properly in Xcode as well, Premake will need to be modified to add those flags and use clang instead of gcc on OS X. clang is available even back to Xcode 3.x on Snow Leopard, so I'm not worried about losing compatibility there.

What would be the best way to set clang with libstdc++? I suspect doing that may help me to get 0 AD built, but I'm not really an expert on compilers and premake. As far as I can see this is not yet the default setting (?), so I made this change to build-osx-libs.sh which compiles without issue:

#export CC=${CC:="gcc"} CXX=${CXX:="g++"} # commented out for nowexport CC=${CC:="/usr/bin/clang"} CXX=${CXX:="/usr/bin/clang++"} # added additional flagCPPFLAGS="$CPPFLAGS -stdlib=libstdc++"

A similar adjustment needs to be made to the premake file, but this is less clear to me. I'm not sure how to set CC and CXX here to clang. The generated makefiles list gcc and g++ (although the terminal window title shows it is using clang). So far I've tried this to set the stdlib:

(this is around line 345)if not _OPTIONS["minimal-flags"] then  buildoptions {    -- Added the stdlib part    "-fvisibility=hidden", "-stdlib=libstdc++"}end

I accidentally submitted my post while this change is still compiling...... Aaand, it failed Most stuff compiled nicely, it seems to get wrong at the final step. I guess that's progress

This is the error from the build process:

==== Building pyrogenesis (release) ====Creating obj/pyrogenesis_Releasemain.cppLinking pyrogenesisld: '_SDL_main' in obj/pyrogenesis_Release/main.o contains undefined reference for architecture x86_64clang: error: linker command failed with exit code 1 (use -v to see invocation)make[1]: *** [../../../binaries/system/pyrogenesis] Error 1make: *** [pyrogenesis] Error 2

Slight edit: manually updating the generated makefiles to use clang/clang++ makes no difference. The generated pyrogenesis.make reads as follows. I'm not entirely sure the compiler flags are set correctly, or would some other issue be bothering me?

# GNU Make project makefile autogenerated by Premake

ifndef config

config=release

endif

ifndef verbose

SILENT = @

endif

ifndef CC

CC = clang

endif

ifndef CXX

CXX = clang++

endif

ifndef AR

AR = ar

endif

ifeq ($(config),release)

OBJDIR = obj/pyrogenesis_Release

TARGETDIR = ../../../binaries/system

TARGET = $(TARGETDIR)/pyrogenesis

DEFINES += -DNDEBUG -DCONFIG_FINAL=1 -DLIB_STATIC_LINK -D_REENTRANT -DNVTT_SHARED=1

INCLUDES += -I../../../source/pch/pyrogenesis -I../../../source -I../../../libraries/osx/libjpg/include -I../../../libraries/osx/libpng/include -I../../../libraries/osx/zlib/include -I../../../libraries/source/spidermonkey/include -I../../../libraries/source/cxxtest/include -I../../../libraries/source/enet/include -I../../../libraries/osx/libcurl/include -I../../../libraries/source/valgrind/include -I../../../libraries/osx/libogg/include -I../../../libraries/osx/vorbis/include -I../../../libraries/source/nvtt/include -I../../../libraries/source/miniupnpc/include

CPPFLAGS += -MMD -MP $(DEFINES) $(INCLUDES)

CFLAGS += $(CPPFLAGS) -g -Wall -O3 -Wno-switch -Wno-reorder -Wno-invalid-offsetof -Wextra -Wno-missing-field-initializers -Wunused-parameter -Wredundant-decls -Wnon-virtual-dtor -Wundef -fstack-protector-all -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fstrict-aliasing -fno-omit-frame-pointer -fpch-preprocess -msse -msse2 -fvisibility=hidden -stdlib=libstdc++ `/Users/vangennip/0ad/trunk/build/workspaces/../../libraries/osx/sdl/bin/sdl-config --cflags` `/Users/vangennip/0ad/trunk/build/workspaces/../../libraries/osx/libxml2/bin/xml2-config --cflags` -isystem../../../libraries/osx/boost/include `/Users/vangennip/0ad/trunk/build/workspaces/../../libraries/osx/gloox/bin/gloox-config --cflags`

CXXFLAGS += $(CPPFLAGS) -g -Wall -O3 -Wno-switch -Wno-reorder -Wno-invalid-offsetof -Wextra -Wno-missing-field-initializers -Wunused-parameter -Wredundant-decls -Wnon-virtual-dtor -Wundef -fstack-protector-all -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fstrict-aliasing -fno-omit-frame-pointer -fpch-preprocess -msse -msse2 -fvisibility=hidden -stdlib=libstdc++ `/Users/vangennip/0ad/trunk/build/workspaces/../../libraries/osx/sdl/bin/sdl-config --cflags` `/Users/vangennip/0ad/trunk/build/workspaces/../../libraries/osx/libxml2/bin/xml2-config --cflags` -isystem../../../libraries/osx/boost/include `/Users/vangennip/0ad/trunk/build/workspaces/../../libraries/osx/gloox/bin/gloox-config --cflags`

LDFLAGS += -framework OpenGL -framework OpenAL -framework ApplicationServices -framework Cocoa -framework CoreFoundation -L../../../binaries/system -L../../../libraries/osx/libjpg/lib -L../../../libraries/osx/libpng/lib -L../../../libraries/osx/zlib/lib -L../../../libraries/source/spidermonkey/lib -L../../../libraries/osx/boost/lib -L../../../libraries/source/cxxtest/lib -L../../../libraries/source/enet/lib -L../../../libraries/osx/libcurl/lib -L../../../libraries/source/valgrind/lib -L../../../libraries/osx/libogg/lib -L../../../libraries/osx/vorbis/lib -L../../../libraries/source/nvtt/lib -L../../../libraries/source/miniupnpc/lib

LIBS += -lmocks_real -ljpeg -lpng15 -lz -lmozjs185-ps-release -lboost_filesystem-mt -lboost_system-mt -lenet -lcurl -lvorbis -lvorbisenc -lvorbisfile -logg -lnvcore -lnvmath -lnvimage -lnvtt -lsquish -lminiupnpc -lpthread -lnetwork -llobby -lglooxwrapper -lsimulation2 -lscriptinterface -lengine -lgraphics -latlas -lgui -llowlevel -lmongoose `/Users/vangennip/0ad/trunk/build/workspaces/../../libraries/osx/sdl/bin/sdl-config --libs` `/Users/vangennip/0ad/trunk/build/workspaces/../../libraries/osx/libxml2/bin/xml2-config --libs` `/Users/vangennip/0ad/trunk/build/workspaces/../../libraries/osx/gloox/bin/gloox-config --libs`

RESFLAGS += $(DEFINES) $(INCLUDES)

LDDEPS += ../../../binaries/system/libmocks_real.a ../../../binaries/system/libnetwork.a ../../../binaries/system/liblobby.a ../../../binaries/system/libglooxwrapper.a ../../../binaries/system/libsimulation2.a ../../../binaries/system/libscriptinterface.a ../../../binaries/system/libengine.a ../../../binaries/system/libgraphics.a ../../../binaries/system/libatlas.a ../../../binaries/system/libgui.a ../../../binaries/system/liblowlevel.a ../../../binaries/system/libmongoose.a

LINKCMD = $(CXX) -o $(TARGET) $(OBJECTS) $(LDFLAGS) $(RESOURCES) $(LDDEPS) $(LIBS)

define PREBUILDCMDS

endef

define PRELINKCMDS

endef

define POSTBUILDCMDS

endef

endif

(I omitted the rest, as it is not so relevant)

Edited December 27, 2013 by dvangennip

[dvangennip]

Ok, I got the game to compile now. Specifiying the c++ libraries is probably doing the trick, as may indicating a OS X version minimum target lower than 10.9. For those interested, I commented on the relevant trac ticket #2304.

[Echelon9]

The patches to source/renderer/ModelRenderer.cpp and source/tools/atlas/AtlasObject/AtlasObjectImpl.h found in http://trac.wildfiregames.com/ticket/2304#comment:9 worked for me in drastically reducing the number of Clang compiler errors on Mavericks OS X 10.9.

This improvement is without having to manually edit premake files or makefiles per some posts above, nor set the stdlib being utilised.

However, there are still a number of wxwidgets related compiler errrors in libAtlasUI.dylib.

Edited January 19, 2014 by Echelon9

[Echelon9]

Okay, I've narrowed down the wxWidgets C++11 MacOSX Clang++ linking issue.

Linking AtlasUIUndefined symbols for architecture x86_64:  "std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::find_last_of(wchar_t const*, unsigned long, unsigned long) const", referenced from:      wxFileName::SplitPath(wxString const&, wxString*, wxString*, wxString*, wxString*, bool*, wxPathFormat) in libwx_baseu-3.0.a(baselib_filename.o)

At the time of report I was using a tip-of-trunk LLVM/Clang build.

See this thread on the wxWidgets for reported and resolved case of the linker issue in this external library. http://forums.wxwidgets.org/viewtopic.php?f=19&t=37432

[Echelon9]

As a test of the new Mavericks builds utilising the latest patches on Trac ticket #2304, I've run unit tests successfully over the resultant binaries with only one failing test report.

$ ./test Running 289 tests.........................................................................................................................................................In TestCStr::test_parse:../../../source/ps/tests/../../../source/ps/tests/test_CStr.h:136: Error: Expected (str3.ToFloat() == 3.0f), found (0.0000 != 3.0000)../../../source/ps/tests/../../../source/ps/tests/test_CStr.h:137: Error: Expected (str3.ToDouble() == 3.0), found (0.0000 != 3.0000).......................................................................................................................................Failed 1 of 289 testsSuccess rate: 99%

Edited February 6, 2014 by Echelon9

[historic_bruno]

Normally I build the OS X release bundles, but my dev computer has been down for a while and I'm stuck on an old XP laptop. wraitii has kindly volunteered to assist in building the OS X bundle for A16. Since I realized there hasn't ever been a really authoritative document on how to do this, I'm going to post my thoughts here.

-----

There's an outline of the process on ReleaseProcess.

You should update BUNDLE_VERSION to "0.0.16". Most of the work is done by running build-osx-bundle.sh. When it's done, if it works, you'll get a 0ad.app bundle in the workspaces directory.

My suggestion for A16 and maybe indefinitely, is to build against the 10.7 SDK (already default in build-osx-bundle.sh) assuming your Xcode version includes it, and 10.7 API using MIN_OSX_VERSION="10.7" (sets the earliest OS X version the game will run on). You could also try the 10.6 API, but as of the SM upgrade it's no longer possible to build on 10.6, and I don't know if you will encounter issues if you go down that route. For now, I'm thinking we've lost compatibility with older OS X and it's probably not a big deal. We can forget about a 32-bit bundle.

General recommendations: don't have Homebrew/MacPorts/whatever installed if you can help it, they will only break things. If you find errors, there's probably no quick and dirty solution, it's better to fix each error. config.log's are your friend if a library configure script fails. Commenting out bits of build-osx-bundle.sh can save a lot of time during troubleshooting, if they already worked (like the forced library rebuild, or the clean game build, or the archive builder).

The new SpiderMonkey doesn't support GCC 4.2, so it won't work with llvm-gcc bundled previously with Xcode, it now requires clang. Depending on your Xcode version, "gcc" might already be clang, if not, you'll need to set CC=clang and CXX=clang++ in build-osx-bundle.sh. I would almost recommend that anyway, so stupid configure scripts don't assume "gcc" really is GCC. Mavericks will require even more massaging to get it working.

Atlas is broken due to a runtime error (see #2356). A couple of options: 1) use an experimental dev version of wxWidgets but it's risky, it may have other bugs, 2) extract the patch(es) that fix that and apply to 3.0.0, 3) downgrade to 2.9 (but config options have changed so that's a pain too), 4) don't build Atlas...

Another special OS X release blocker is #2338. You could try commenting out the offending UPnPc free lines (even better put them in #if OS_MACOSX ... #endif wrappers), or disable UPnP in the build as a last resort (--without-miniupnpc?). Since A15, multiplayer hosting is broken on OS X due to this bug. leper and I agreed a small memory leak is better than a crash.

With A16, we have internationalization/localization support, some modification of build-osx-bundle.sh will be required so it copies the necessary files from binaries\data\l10n into the bundle (hopefully only one line). Also, only approved+reviewed translations should be included, sanderd17 and Gallaecio would know more about that.

Check the binaries (0ad.app/Contents/MacOS/pyrogenesis, and AtlasUI/Collada dylibs in the shared frameworks directory) for the correct architecture using the "file" command (should be x86_64), check which dylibs they link with "otool -L" (none of those built in libraries/osx should be listed there, they are static libs, look for weird ones that would break the bundle, like /opt/* or /usr/local/*). Check that the game runs, Atlas runs, and tests pass

You need to put 0ad.app into a bzip2-compressed disk image (DMG) or it will be a huge download: 1) create an uncompressed DMG big enough to hold the bundle, 2) make a shortcut to /Applications so people can "install" the game in the Mac fashion, 3) copy 0ad.app into the folder, 4) set the icon positions and background image as desired, 5) convert the uncompressed DMG into a compressed read-only DMG with hdiutil. Again that's outlined on ReleaseProcess with additional references.

When you have the compressed DMG, you'll need to let Philip know, and host it somewhere so he can download it remotely into http://releases.wildfiregames.com/rc. I usually turn on the OS X web server and host it directly, long enough for him to download it - you might have another web server you can use. I would recommend testing the DMG first, on another machine if possible, to verify it opens properly, and that it works on as many versions of OS X as you can access. If you only have one, then round up as many OS X volunteers for testing as you can, the more the merrier

[GunChleoc]

I have no clue how packaging works and I am always when I see what you are doing.

Just one note on the translations:

With A16, we have internationalization/localization support, some modification of build-osx-bundle.sh will be required so it copies the necessary files from binaries\data\l10n into the bundle (hopefully only one line). Also, only approved+reviewed translations should be included, sanderd17 and Gallaecio would know more about that.

Since I'm not sure what you mean by "approved+reviewed", I hope you dont mean set to "reviewed" on Transifex, because we would lose a couple of languages right now.

Use whatever the i18n team has committed to SVN, all those translated strings should be good enough. If I understand correctly, they have only added the languages that have hit the 90% mark and everything has been submitted to a quick check to see that there are no problems.

[sanderd17]

I have no clue how packaging works and I am always when I see what you are doing.

Just one note on the translations:

Since I'm not sure what you mean by "approved+reviewed", I hope you dont mean set to "reviewed" on Transifex, because we would lose a couple of languages right now.

Use whatever the i18n team has committed to SVN, all those translated strings should be good enough. If I understand correctly, they have only added the languages that have hit the 90% mark and everything has been submitted to a quick check to see that there are no problems.

It's not reviewed on Transifex, but reviewed by us. As changes on Transifex are hard to track, and some teams are pretty big, we have reviewed the translations against vandalism, but also against code breakage (like someone translating the wrong printf style var in the text), and for the languages we know, also a small quality review. As you're not supposed to review your own language, we're not going to have the "reviewed" flag in Transifex as a criterium. It would lock out small teams like Gaelic or Galician.

[GunChleoc]

This makes sense, thanks

[wraitii]

I'll give this a try tomorrow during the day, it'll likely fail so I'll try to fix the issues.

[wraitii]

Okay. I don't have the 10.7SDK anywhere anymore, apparently, my Xcode is too up-to-date. So I can make the bundle, but for 10.8. 10.7 is the least used version though (less so than 10.6 afaik) so it's likely not too bad.

I'm giving this a go on Mavericks on my MBA because my iMac is really outdated. I'll update this post later.

Edit: getting this error:

../../../source/scriptinterface/ScriptTypes.h:71:10: fatal error: 'jspubtd.h'      file not found#include "jspubtd.h"