Jump to content

Building on OS X


Recommended Posts

I just got my first complete build done, and finally have the game running on OS X. It took a while, figuring out dependencies and correcting issues, so I thought I'd document what I did, and invite others to share their own workarounds. These changes were applied to revision 7008.

The first thing I did was use MacPorts to install the following packages: libsdl, boost, spidermonkey, libvorbis, jpeg, libpng, libdevil, libxml2, i.e.,

sudo port install libsdl, boost, spidermonkey, libvorbis, jpeg, libpng, libdevil, libxml2

Next, I downloaded, built, and installed the stable 1.2 release of enet.

Then, I checked out, built, and installed valgrind. The 3.4.1 release does not work, you must get the repository version.

Now to the changes to the source...

I deleted the directory libraries/fcollada/include/LibXML because it overrides my libxml headers (my drive is formatted case insensitive, so LibXML matches libxml). There might be a better way to work around this, but it's only there for Windows users anyway.

I deleted the two library files in libraries/fcollada/lib, called libFColladaSD.a and libFColladaSR.a, because these are files that need to be rebuilt.

Then I these changes (pastebin): http://pastebin.ca/1498286

Link to comment
Share on other sites

Wow, your patch set's quite bigger than mine.

I'll do a write-up tomorrow afternoon along with macports portfiles and binaries (It's a bad idea to install things without package management, and I patched spidermonkey and libDevIL instead of working around them)

Oh, and somebody start a ticket regarding valgrind. It should be optional.

Edited by espes
Link to comment
Share on other sites

I tried my best to avoid patching anything outside the 0 A.D. source code, since I don't have control over those and it increases the complexity for a new person to get the source working.

There are a few changes in there to reduce warnings from the compiler, and I use the wxWidgets included with Leopard, which doesn't have wxRE_ADVANCED, so I had to include a patch for that sa well.

Link to comment
Share on other sites

Been through the patch and merged all the stuff that corresponded to compile errors I could reproduce.

(strike-through means I've committed fixes for it - but adding it to the list just to jot down that it was in the patch, the rest is todo)

  • premake config: collada and boost
  • fcollada: stringbuilder fixes
  • fcollada: pragmas (I didn't see any issues with this when compiling on my mac - was this only warnings?)
  • fcollada: use of snprintf (should be fixed, especially if long is more than 32 bits, but didn't cause any compile errors)
  • fcollada: ifdefs in filemanager (fixed by changes in the fcollada makefile - it shouldn't define Linux when on mac)
  • fcollada: makefile changes
  • openal: string type, should be fixed as trac issue #268
  • lib: timer type, debug_DumpStack, secure_crt functions
  • wxWidgets regexp stuff: I assume that passing the "advanced" argument enables some regexp extensions - but do these regexpes really mean the same thing if we use default rather than advanced regexpes? If so, we should change them to actually use the default-flag for everyone, else we should probably rewrite the regexpes to only use "default"-features.
  • wxUSE_DEBUG_REPORT: looks trivial enough, should be merged I guess
  • atlas/ScenarioEditor: Apple-ifdeffed _UINTxx defines. I didn't see any related compile errors on my mac, but if it's a problem with another version of something (os x, for instance) it looks like we would like to find a cleaner solution for the problem anyway.

Since the patch was a lot of small changes, I might have missed something, but what's in SVN now actually compiles (and runs!) on my macbook :)

(Well, the collada integration still doesn't compile for me, due to changed api:s in libxml2 and general confusion between the four separate sets of libxml2 headers that are reachable - but I think that's a slightly larger problem and I'll leave it to tomorrow and/or someone else to sort that out :D)

In other news, valgrind is now optional and support must be explicitly enabled by passing --with-valgrind to update-workspaces.sh.

Link to comment
Share on other sites

Thanks olsner, I am glad to see the changes made it in.

  • fcollada: pragmas (I didn't see any issues with this when compiling on my mac - was this only warnings?)
  • fcollada: use of snprintf (should be fixed, especially if long is more than 32 bits, but didn't cause any compile errors)

Both of these only caused warnings. In the case of snprintf, I don't know why it issued a warning (long is 32 bits on both 32-bit and 64-bit Macs, as far as I can tell), but changing from %ul to %u eliminates the warning.

  • wxWidgets regexp stuff: I assume that passing the "advanced" argument enables some regexp extensions - but do these regexpes really mean the same thing if we use default rather than advanced regexpes? If so, we should change them to actually use the default-flag for everyone, else we should probably rewrite the regexpes to only use "default"-features.

I had thought both the affected regexps were extended, but on reading the docs, it looks like the \d character class has to be written as [[:digit:]] instead. Other than that, it looks like it's okay, but I suppose they should be tested to make sure they still work.

  • atlas/ScenarioEditor: Apple-ifdeffed _UINTxx defines. I didn't see any related compile errors on my mac, but if it's a problem with another version of something (os x, for instance) it looks like we would like to find a cleaner solution for the problem anyway.

I ran into a conflict between SpiderMonkey (jsotypes.h) and Security.framework (cssmconfig.h), which are both included by ScenarioEditor.cpp, because they both provide typedefs for uint32 and the like. This might be specific to the version of SpiderMonkey (I've got the MacPorts 1.7 version).

Thanks again for going through that change set, it's great to see such a quick response.

Link to comment
Share on other sites

Hi all !

I've posted a topic about make errors on my mac today ... and then saw your post, sorry :)

So I guess it could help me compiling on my MBP, but I want to ask you before two questions :

1) I have Tiger unfortunately, do the changes made need Leopard as you seem to have or do they run on Tiger ?

2) not beeing a developper, I don't know how apply the patch you wrote. Could you tell me more about it ? I guess I have to save the text as a script file and execute it in a console. Am I right ?

TIA

Arnaud

Link to comment
Share on other sites

Hi Arnaud,

The patch has since been checked into the Subversion repository, so you shouldn't need to apply it yourself.

I don't know if there are differences that will affect compiling on Tiger versus Leopard, but you can always post any errors you get here, and we can try to help figure them out.

Link to comment
Share on other sites

apple's gcc is 4.0.1 : it gave me tons of warnings and errors. After changing to gcc 4.3 (from macports), the compilation is nicer, but I get this error. Do you have an idea where it comes from ? And what I could do to make it work ?

I'll try to update svn and see if latest version goes better ... (althought the one I have is just three days old :) )

Edited by arn34
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...