VCMI for macOS


Ok. Seems to be ready. Xcode project is generated. All features are supported. Packaging to .dmg is done. Looking forward to see changes in trunk.

osx.path -
osx.diff - -


Patch applied, rev 3018


I’ve made a dmg package (rev 3019) so it could be added to download section on main page -


Thank you for contribution!

By the way… How is that includes are platform specific? I see CBattleAnimations.h included in CBattleInterface.h — why is it needed?

I’m not sure if it belongs there, it is r3019, not the actual VCMI 0.9. Besides, I’m not sure how to label it or whether it needs some additional instructions.

How about creating a wiki page “Installation on OS X” with download link and instructions just like we have … n_on_Linux ? [Or, if there’s little difference, we could make it a single page for both Linux/OS X.]
You can edit vcmi wiki after signing in with your forum account. :slight_smile:


To tell the truth I don’t know myself :slight_smile: Maybe it’s a sign of Clang immaturity. Maybe something else. But in some places forward declarations haven’t worked so I replaced them with direct includes.

I’ve already have draft “Building VCMI on OS X” but I’m waiting for my new SSD to arrive soon. I’m going to install fresh system on it anyway so it would be a great possibility to check everything one more time on a clean system.

What about end-user installing it’s really dead simple. Every OS X user will do it. The only problem is game data which anyway should be obtained separately and placed to “~/.vcmi”. I’m a bit concerned about it because for myself I installed Heroes3 + WoG on Windows machine, compressed to zip archive and copied to Mac. Not sure it’s a good solution because some people don’t have second computer with Windows. We have the same problem on Linux so maybe we need shared “Preparing game data on non-Windows system” page. Any ideas? Because Wine based manual is not very best solution from my point of view.


Strange thing is that I use clang as well. And I don’t need those includes.
The only difference I can think of is standard library (libstdc++ for me, libc++ on Mac) but it shouldn’t affect includes either.

Yeah. I’ve been asked about this multiple times. Check my wiki update (vcmibuilder script): … aring_data

Will commit the script to svn today so you can check how it works on Mac. Shouldn’t be a problem - it requires bash itself + some optional utilites to extract data (wget, unzip, unshield, innoextract).

EDIT: done. Script uploaded, revision 3022 … cmibuilder


Yep, I’m using libc++ because libstdc++ on OS X is way outdated (from gcc 4.2). And I can’t use libstdc++ from newer gcc installed from MacPorts because of portability.

Yeah, unshield install seems to be working fine after some patches to unshield itself. Can anyone provide me iso with InnoSetup install to test innoextract?


Nevertheless vcmibuilder script seems to be working on OS X it’s probably not a best option because you still need to compile from source both unshiled and InnoExtract (for some reason there is no InnoExtract in MacPorts, and unshield in MacPorts is too outdated). So I’ve decided to create a nice gui version of vcmibuilder script with prebuilt unshield and innoextract for OS X to make things as simple as possible once again. Here is patch for it: … lder.patch


Don’t like increasing number of OS-specific files…
Will apply it tomorrow if there won’t be objections\better propositions.

List of files modified\added by patch:

 client/CMT.cpp                                     |    7 +
 client/CMakeLists.txt                              |    2 +-
 osx-vcmibuilder/innoextract                        |  Bin 0 -> 2407224 bytes
 osx-vcmibuilder/unshield                           |  Bin 0 -> 56252 bytes
 osx-vcmibuilder/vcmibuilder.icns                   |  Bin 0 -> 1399181 bytes
 .../vcmibuilder.xcodeproj/project.pbxproj          |  307 ++++++++
 osx-vcmibuilder/vcmibuilder/AppDelegate.h          |   48 ++
 osx-vcmibuilder/vcmibuilder/AppDelegate.m          |  310 ++++++++
 .../vcmibuilder/en.lproj/InfoPlist.strings         |    2 +
 osx-vcmibuilder/vcmibuilder/en.lproj/MainMenu.xib  |  772 ++++++++++++++++++++
 osx-vcmibuilder/vcmibuilder/main.m                 |    6 +
 osx-vcmibuilder/vcmibuilder/vcmibuilder-Info.plist |   34 +
 osx-vcmibuilder/vcmibuilder/vcmibuilder-Prefix.pch |    7 +


Another small patch for OS X: … _fix.patch

Install and Compile OS X manuals for wiki are coming soon!


It seems that I will eventually need more OS X specific files than just osx-vcmibuilder dir.
Taking this into account what about organizing all packaging folders like debian, rpm and osx into some packaging folder instead of placing everything on root level?


For debian name of directory is more-less hardcoded (usually added during uploading to Debian repositories). Can’t say for rpm though.

Keeping one “osx” directory in root with all OS X-specific files in it sound fine for me.

  1. So debian folder always should be on top level?
  2. Please upload to site OS X prebuilt dependency archive:


Yes. Note that in most cases package maintainer is not a part of development team so this directory is stored separately as a “patch”.
This is not true for VCMI so storing it directly in trunk is easier.


Now I get it. In such case just upload please. So I could insert working link into OS X Building wiki page.


Yet another OS X compatibility patch: … atch.patch
Please provide link once it is uploaded.


Done, sorry for delay. :slight_smile:


Finally I’m back. Can someone give me wiki access so I can start adding “How to build VCMI (OS X)” article?


You can login with your forum account.


Just wanted to say thank you to stopiccot for all the work he’s done with the OS Xbuild. Setting up the workspace was a breeze thanks to him. Now I am starting to hunt bugs.