102 replies to this topic

[cc_julian]

hey

i came across the 0ad alpha 7 announcement today, was encouraged by the fat "Instructions for Mac OS" button, but as you all know it only leads only to an compilation instructions site instead of precompiled downloads.

i've therefore spent some time creating:
• a distributable binary version of 0ad alpha 7 for Mac OS X
• an xcode project and assorted support infrastructure for 0ad that makes creating distributable binary mac versions easy

1.) here is a very small patch for 0ad that fixes some compile errors (pyrogenesis.h is needed for the psLogDir declaration) and fixes up the runtime paths so that 0ad reads the data files from inside its application bundle (because we have a proper double clickable moveable app now) and also uses better paths for storing preferences. you could also change the ifdefs from __APPLE__ to something we define in _ad_Prefix.pch if you don't want these path changes to apply to mac versions built from the command line

http://dl.dropbox.co..._mac_patch.diff

http://dl.dropbox.co..._mac_patch.diff



2.) here is an zipped folder containing an xcode project for building 0ad and misc support files including pre-built libraries etc etc. this should be added to the build/ folder

http://dl.dropbox.co...d_mac_xcode.zip

3.) here is a pre-built deployable version of 0AD beta 7 - i've personally tested it on an NVIDIA equipped MacPro with 10.6.6 and an ATI equipped iMac with 10.7.1


0ad-r10288-alpha-mac.dmg
___

for building deployable binaries yourself you just need to open the build/xcode/0ad.xcodeproj in Xcode 3.2 (4.x may also work, but is untested), select the "Release" configuration and hit "Build" from the "Build" menu. this will create the "0 A.D." application. now just right click it, select "show package contents" and add the *complete* "data" folder into the application bundle, because without data the binary won't run ;-) now zip the result or make a DMG with Disk Utility.

EDIT: boost_1_47_0 must also be downloaded and decompressed into the xcode folder

__

the generated binary runs on Mac OS X 10.6 or later and only on 64-bit Macs. i don't consider the requirements problematic, 10.5 is unsupported by apple themselves by now, and apple only shipped very few 32-bit intel macs, most of which additionally only have sucky integrated GPUs like the GMA 950 and are barely able to run a game anyway. it would be easy to create a version that runs on 32 bit and 10.5 too, would just require a few hours creating updated version of the library dependencies, and a few changes to the xcode project

bye, julian

Edited by cc_julian, 26 September 2011 - 11:54 AM.

[cc_julian]

BTW:
i've completely ignored the existing build system (premake) and instead created an xcode version from scratch. using something other than xcode always has difficulties creating something that is actually deployable to end-users. of course i generated stand-alone versions of all dependent libraries too - again, using macports installed versions would lead to dependencies that make deployment impossible.

Edited by cc_julian, 18 September 2011 - 09:26 PM.

[historic_bruno]

Interesting, thanks for all the info and files, it's a very welcome contribution to the community (people have been begging recently for an Alpha 7 binary for OS X)

Quote

the generated binary runs on Mac OS X 10.6 or later and only on 64-bit Macs. i don't consider the requirements problematic, 10.5 is unsupported by apple themselves by now, and apple only shipped very few 32-bit intel macs, most of which additionally only have sucky integrated GPUs like the GMA 950 and are barely able to run a game anyway. it would be easy to create a version that runs on 32 bit and 10.5 too, would just require a few hours creating updated version of the library dependencies, and a few changes to the xcode project

I'll see if we can get some stats on how many OS X 10.5 or previous users we have and also how many 32-bit Macs (there are these semi-unrelated stats, which show 10.5 is at least as popular as 10.7 among browsers of that website, but I don't think we can assume 0A.D. players break down the same way). My feeling is that it's not a big deal, 0A.D. requires fairly good hardware to be enjoyed and Mac users seem to not mind spending out on new stuff, on an annual basis

cc_julian, on 18 September 2011 - 09:25 PM, said:

BTW:
i've completely ignored the existing build system (premake) and instead created an xcode version from scratch. using something other than xcode always has difficulties creating something that is actually deployable to end-users. of course i generated stand-alone versions of all dependent libraries too - again, using macports installed versions would lead to dependencies that make deployment impossible.

With Alpha 7 we include a new build system (not default yet) that generates an Xcode project on OS X (you'll see it using the normal build instructions but substitute update-workspaces-new.sh). Some effort has been spent getting this far, but it's not perfect. What we would prefer is to get that working correctly as it does on other platforms, instead of having to construct the Xcode project by hand (since we might refactor/restructure the code, add new files and folders, and we want that handled automatically to make the process as painless as possible, which it's not currently). Probably that involves fixing small bugs and deficiencies in Premake. I think it's close but I'm not that knowledgeable about app bundles and the OS X build process. It would benefit from an expert opinion

MacPorts is annoying and I wouldn't mind finding an alternative, but it doesn't really fit in with our build process to require manually downloading and compiling a bunch of libraries from source. I seem to recall reading somewhere that Xcode can manage these dependencies, I may be mistaken.

The paths patch will definitely need to be more specific, we want the standard Unix path scheme for SVN builds. That code is due for changes anyway, even Windows builds need more reasonable data paths.

[Ykkrosh]

historic_bruno, on 18 September 2011 - 10:24 PM, said:

I'll see if we can get some stats on how many OS X 10.5 or previous users we have and also how many 32-bit Macs

Some old stats indicate very few OS X users at all, so detailed breakdowns would probably be meaningless.

Quote

MacPorts is annoying and I wouldn't mind finding an alternative, but it doesn't really fit in with our build process to require manually downloading and compiling a bunch of libraries from source.

Something like a shell script that downloads and builds and installs the libraries might be sufficient. I think the important thing is that we can easily update and rebuild everything consistently and reliably, when there's important updates to those libraries (security fixes etc), rather than it requiring manual effort (since then we probably would be too lazy to update libraries).

[cc_julian]

historic_bruno, on 18 September 2011 - 10:24 PM, said:

Interesting, thanks for all the info and files, it's a very welcome contribution to the community (people have been begging recently for an Alpha 7 binary for OS X)

i am glad if its of use

historic_bruno, on 18 September 2011 - 10:24 PM, said:

I'll see if we can get some stats on how many OS X 10.5 or previous users we have and also how many 32-bit Macs (there are these semi-unrelated stats, which show 10.5 is at least as popular as 10.7 among browsers of that website, but I don't think we can assume 0A.D. players break down the same way). My feeling is that it's not a big deal, 0A.D. requires fairly good hardware to be enjoyed and Mac users seem to not mind spending out on new stuff, on an annual basis

if someone provides prebuilt versions of the dependencies (boost, enet, collada, libjpeg, mozjs, nvtt), i'd be happy to update the project to support 32 bit and 10.5

historic_bruno, on 18 September 2011 - 10:24 PM, said:

With Alpha 7 we include a new build system (not default yet) that generates an Xcode project on OS X (you'll see it using the normal build instructions but substitute update-workspaces-new.sh). Some effort has been spent getting this far, but it's not perfect. What we would prefer is to get that working correctly as it does on other platforms, instead of having to construct the Xcode project by hand (since we might refactor/restructure the code, add new files and folders, and we want that handled automatically to make the process as painless as possible, which it's not currently). Probably that involves fixing small bugs and deficiencies in Premake. I think it's close but I'm not that knowledgeable about app bundles and the OS X build process. It would benefit from an expert opinion

i know generating project files is popular right now, but in my opinion it just doesnt work and i don't have an interest to spend a single minute on using premake/cmake/whatever or even messing with sucky generated projects
you can of course continue using premake, and just use my xcode project if you want to create deployable DMGs, that would be the least effort

historic_bruno, on 18 September 2011 - 10:24 PM, said:

MacPorts is annoying and I wouldn't mind finding an alternative, but it doesn't really fit in with our build process to require manually downloading and compiling a bunch of libraries from source. I seem to recall reading somewhere that Xcode can manage these dependencies, I may be mistaken.

the solution here is just to pre-build the dependencies once and include the pre-built libraries, so its easy to build for everyone

historic_bruno, on 18 September 2011 - 10:24 PM, said:

The paths patch will definitely need to be more specific, we want the standard Unix path scheme for SVN builds. That code is due for changes anyway, even Windows builds need more reasonable data paths.

hm ok but storing files in ~./local/ on Mac OS X is just wrong, regardless how the binary is being built ;-)
i suggest making the data path change only for the xcode build, but the location of the folder where files are being written to should be changed for all Mac OS X builds.
i've done just that in the linked patch and xcode folder.
if you want the other path change to be only for the xcode builds too, just change __APPLE__ to MAC_NATIVE

Edited by cc_julian, 18 September 2011 - 11:05 PM.

[cc_julian]

Ykkrosh, on 18 September 2011 - 10:47 PM, said:

Something like a shell script that downloads and builds and installs the libraries might be sufficient.

might be difficult, since even just installing macports might make built libraries "silently" dependent on in and therefore non-deployable.

libpng is included with macosx anyway, enet didnt update in the last 5 years, boost isn't security relevant, and probably nvtt neither. leaves us with libjpeg and mozjs.

i bet i can build those libraries 50 times in the time it takes to build a system that automatically generates deployable binaries from their latest versions.

[General Octavian]

Do you have instructions on what to do with the files

[fcxSanya]

Ykkrosh, on 18 September 2011 - 10:47 PM, said:

Some old stats indicate very few OS X users at all, so detailed breakdowns would probably be meaningless.

Is not this stat indicate users who somehow managed to compile/get compiled version of game and enabled feedback? In this case there can be few OS X users, because it is currently hard to get corresponding version of 0ad.

[Sebovzeoueb]

Thank you so much for this. Am currently downloading!

[cc_julian]

General Octavian, on 19 September 2011 - 12:11 AM, said:

Do you have instructions on what to do with the files

doesn't my first post contain detailed instructions, what else do you need?

Sebovzeoueb said:

Thank you so much for this. Am currently downloading!

actually the binary is meant to be mirrored by the powers-that-be and not to be downloaded directly by users dropbox doesn't like much bandwidth.

[JuliusColtranePille]

i have the problem that the carthaginian buildings are on the small map but can't be seen nor controlled. there is nothing on the screen!

got anyone this sort of problem too?

EDIT:

doesn't matter what map... the game doesn't show nor creat ANY units or buildings of a faction. seems there's an error on loading these structures and entities.

what to do?

thx a lot

Edited by JuliusColtranePille, 19 September 2011 - 01:32 PM.

[cc_julian]

must be a problem with the collada plugin, works here, what system are u on?

[JuliusColtranePille]

cc_julian, on 19 September 2011 - 01:35 PM, said:

must be a problem with the collada plugin, works here, what system are u on?

Snow Leopard 10.6.8.

2.5ghz intel core i5 iMac 2011...


i've tried to compile it, but it fails (xcode) what means choose the release-mode?

kind regards and thx for support

EDIT:

ok, i found the release-config... but somehow it still does not work. a lot of files in the xcode list are red.

Edited by JuliusColtranePille, 19 September 2011 - 01:44 PM.

[cc_julian]

JuliusColtranePille, on 19 September 2011 - 01:41 PM, said:

Snow Leopard 10.6.8.

2.5ghz intel core i5 iMac 2011...

i'll have a look
EDIT: found the problem, this was already working, will fix it soon.

JuliusColtranePille, on 19 September 2011 - 01:41 PM, said:

i've tried to compile it, but it fails (xcode) what means choose the release-mode?

just FYI, saying something like "it fails" is completely useless at it doesn't give any information on what the actual problem is

JuliusColtranePille, on 19 September 2011 - 01:41 PM, said:

ok, i found the release-config... but somehow it still does not work. a lot of files in the xcode list are red.

means the files couldnt be found, means you didn't put the xcode folder into the build folder of the 0ad sources. the xcode project is meant for *developers*

Edited by cc_julian, 19 September 2011 - 01:52 PM.

[JuliusColtranePille]

cc_julian, on 19 September 2011 - 01:48 PM, said:

i'll have a look
EDIT: found the problem, this was already working, will fix it soon.





just FYI, saying something like "it fails" is completely useless at it doesn't give any information on what the actual problem is




means the files couldnt be found, means you didn't put the xcode folder into the build folder of the 0ad sources. the xcode project is meant for *developers*

wow, thx a lot. yeah your'e right. it's just hard if someone is totally clueless and doesn't find the problem nor he knows exactly WHAT he is doing

[Sebovzeoueb]

cc_julian, on 19 September 2011 - 09:42 AM, said:

actually the binary is meant to be mirrored by the powers-that-be and not to be downloaded directly by users dropbox doesn't like much bandwidth.

Sorry, this wasn't specified, so I figured I was free to download it.

I am having the same probleme as JuliusColtranePille: No buildings or units are visible, and there are a load of error messages

Could not load collada dll conversion or words to that effect, and failure to load various meshes.

I hope this can be fixed.

Thank you.

[cc_julian]

Sebovzeoueb, on 19 September 2011 - 02:14 PM, said:

I hope this can be fixed.

yes, just a few minutes.

[Ykkrosh]

cc_julian, on 18 September 2011 - 11:08 PM, said:

i bet i can build those libraries 50 times in the time it takes to build a system that automatically generates deployable binaries from their latest versions.

I'd hope it would mostly just involve running configure/make/make install (probably with some prefix) to make the libraries available, which doesn't sound like it should be quite that much work (though I'm unfamiliar with the quirks of building on OS X). It's okay if we state it has to be a clean installation of some specific version of OS X to avoid it getting confused by MacPorts etc (like how the Windows executables are built on a dedicated VM to avoid unexpected environment changes that might break things).

I think my general concern is that we ought to have a build process, not just a build. (Having any OS X build is definitely better than having none, though - I don't mean to be just complaining, more looking for further improvements ) When we want to do a new release (which may have changes to game code and libraries and build system etc), it ought to be available on all platforms simultaneously, and if part of the process requires manual work then it's more likely to introduce a delay and more likely to introduce bugs due to human error and more likely to stop working in the future when people disappear. The Windows and Linux builds are largely automated to avoid those problems and to make everything more predictable. It takes more effort to set up at first but I think it's a good thing to strive for.

cc_julian, on 19 September 2011 - 09:42 AM, said:

actually the binary is meant to be mirrored by the powers-that-be and not to be downloaded directly by users dropbox doesn't like much bandwidth.

I suppose I be the power in this case, so I copied your version (from earlier today) here which ought to provide enough bandwidth for now

[cc_julian]

Ykkrosh, on 19 September 2011 - 02:54 PM, said:

I suppose I be the power in this case, so I copied your version (from earlier today) here which ought to provide enough bandwidth for now

ok thanks, but the version has the collada problem, i will have an fixed version in a few minutes.

[JuliusColtranePille]

cc_julian, on 19 September 2011 - 03:00 PM, said:

ok thanks, but the version has the collada problem, i will have an fixed version in a few minutes.

sounds good. thumbs up.
thx