For quite some time I want to have ability to make Windows builds of VCMI, but I’m don’t really want to use games firmware for anything except games. So only option is using cross-compilation using MinGW, but every time I attempted to at least build Boost it’s didn’t I was bored long before process was anywhere near to complete.
Though this time after I’m partially built Boost I’m find out about project called MXE and it’s likely have everything VCMI need. Building process is quite simple and there is very few changes needed to achieve successful compilation.
With few changes to bypass conflicts with Windows headers and case sensitivity it’s able to compile everything, but launcher and client linking failing: gist.github.com/ArseniyShestako … 3b63c0ddf6
This is likely related to fact that by default MXE use static linking and looks like client can’t be easily statically linked this way.
Attempted to link everything, but failed. Possible MXE does have some feature so find all dependencies recursively, but not sure how to integrate it with Cmake. So decide to build it with support for shared libraries.
With shared libraries client compilation looks more real, but there is still errors related to SD_ttf: gist.github.com/ArseniyShestako … 2905ebc204
Looks like freetype can be built as dynamic library, but SDL_ttf for some reason can’t and as result client not linking.
So for some reason SDL2_ttf (“src/sdl2_ttf.mk”) in MXE have “–disable-shared” option. When removed it’s can be built as DLL just fine. Then I patched already generated makefile and it’s actually built and it’s working on Windows 8.1
MXE put tons of rubbish on “make install” because it’s linked everything statically, but it’s not a big issue.
So I found solution for all my problems with conflicts. It’s end up that MXE for some reason contain patch for Boost that set BOOST_USE_WINDOWS_H by default. This of course cause conflicts with constants and explain why @AVS don’t have such problems even if he use MinGW on Windows.
So with this part fixed VCMI compile just fine.
Thinking about setting up daily builds or something like that.
PS: Cross-compilation manual also updated of course.
So thanks to Tony Theodore MXE now using Boost 1.60 by default and it’s don’t use windows headers so no conflicts there. Still there is some issue that VCMI have “using std::make_shared” that end up in conflict with boost.
Thanks to Ivan it’s now known that happen because VCMI have “using namespace boost;” in few files.
Already pulled them from codebase. Still I’m not sure what to do with these in Global.h:
using std::shared_ptr;
using std::unique_ptr;
using std::make_shared;
This code originally appear back when VCMI was using boost variants so switch to std is easier, but now it’s doesn’t make sense. Considering VCMI is using “std::” prefix everywhere it’s would be better to remove these too.
So here is link to fully automated daily builds via MXE: vcmi.arseniyshestakov.com/windows/
Build script run 3 times a day and create new build whatever it’s see latest commit changed. Once there 15 or more files on server all files that created 7 days ago or earlier are removed. So please do not hotlink files! (hotlinks won’t work anyway)
Use on your own risk, builds are untested, not supported, not include launcher and not include extra resolutions mod as it’s not hosted in VCMI repository. So if you want to play please stick to versioned Warmonger development builds.
PS: Script for creating builds is available on gist.
Just restored daily build creation. Also I now compile launcher as well and as far as I know it’s might be compatible with Windows XP, but testing needed.
So before my MXE used GCC 4.9.4 and there was few really weird desyncs in saves for no reason. Today I switched to GCC 6.2 for testing on both my development environment and MXE.
So for now builds since “dba58e5eb1a8c15e4e92fe2cf0642ec59c994c29” is using gcc 6.2 which might cause some glitches. If they’ll have too many problems another option would be using GCC 5.3 which also available.
DMGs are actual MacOS builds, just little bit broken for now since more work needed in order to put all dependencies there.
Also you can extract NSIS installer exe with any archive manager. If you think separate achieves are necessary I’ll work on them. Though I want to find way to create them by CPack as well since I’m really think it’s better to use CMake rater than add extra Bash scripts that duplicate it’s functionality.
