MG/Windows Compiling

From MegaGlest
Jump to navigation Jump to search

This page explains how to compile MegaGlest for Windows.

Introduction[edit]

Generally, there are two approaches to get your work done:

  • CLI: the automatable and fast one, using command line utilities and batch files
  • GUI: the slow and shiny one, using graphical user interfaces

You have to choose one of them. The MegaGlest developers prefer the first approach, and this is also the most tested and recommended approach. You can of course choose the GUI approach, which should work, but please do not expect us to support you with setting up your VC++ build environment or GUI GIT client since this is hard to support and eats a lot of time. So if you choose this approach, please do not ask for support unless you do know how this is done properly and that the issues you are running into are clearly due to a bug in the solution files or this documentation.

Compilation[edit]

Prepare

Important note: Since version "2015" microsoft decided to (annoy people &) "make C++ optional" and hide it during installation so you should choose 'Custom' type of installation and then set check marks next to “Common Tools for Visual C++ 2015” and “Microsoft Foundation Classes for C++”.

  • Install 7-Zip or other compatible file archiving utility. 7-Zip is recommended.
  • Install and use Git to check out the MegaGlest source code.
  • Choose one approach.

The CLI approach[edit]

(recommended)

  • Locate and run the batch file:
    MegaGlest batch file
    mk\windoze\build-mg-2015.bat (or build-mg32bit-2015.bat for 32 bit build) (Note: that it may be necessary to run this as an administrator, then right click on it and choose "run as administrator")
  • Note: On Windows 10 with Visual Studio 2017, running build-mg-2015.bat produces the following error: 'msbuild' is not recognized as an internal or external command. To make the script work, it needs to be executed in the developer command prompt.
  • If nothing goes wrong you will see megaglest.exe (and other binaries) in mk\windoze\

The GUI approach[edit]

  • Read the above Introduction paragraph since it provides important information on the limits of this aproach
  • Update the branch you are working in with the latest GIT code
  • If it is first compilation download the build dependencies archive (which one and from where you can find out in the "code" of build-...bat script from CLI approach, some line with "wget.exe") and unpack it into the source subdirectory of your GIT working copy. You should then see a source\windows_deps...\ directory with many files inside; ... then also run the mk\windoze\CopyWindowsRuntimeDlls_2015.bat batch file to copy runtime dependency DLL's to the runtime binary folder
  • Start Visual C++ 2015 and open the main solution, located in mk\windoze\Glest_vc2015.sln
  • Perform a rebuild project (choose release mode or release with debug info)
  • If nothing goes wrong you will see megaglest.exe (and other binaries) in mk\windoze

Trouble shooting[edit]

First compilation[edit]

(The CLI approach)

In the CLI approach a script mk\windoze\build-mg32bit-2015.bat should performs/ automates the following steps (listed on below list) for you:

  • Download and extract the build dependencies archive to source\windows_deps...\ directory unless you already have it
  • On the first run, also run the mk\windoze\CopyWindowsRuntimeDlls_2015.bat batch file to copy runtime dependency DLL's to the runtime binary folder.
  • Update the branch you are working in with the latest GIT code
  • Update the timestamp and revision number on source\glest_game\facilities\game_util.cpp
  • Compile all projects from command line

When you know that steps and the error message then you can quite easy diagnose what is wrong, e.g. error during downloading may mean "broken internet connection" or "not enough disk space".

If error is related with 7-zip then you should e.g. ensure that the 7-zip command is available globally (add it to your PATH). If the installer did not automatically add the installation directory to the system path, instructions are available here).

Not first compilation[edit]

If your build fails, and you have not been building for a while, this is usually due to outdated build dependencies. Check them (which one archive and from where you should have you can find out in the "code" of build-...bat script from CLI approach, some line with "wget.exe") for windows_deps...7z when it was last updated, and if it's more recent than the one you have in source\ (or if you are unsure), then recursively delete both source\windows_deps...\ and source\windows_deps...7z. Deleting files recursively on Windows GUI can take ages, so to quickly delete recursively, do it on your command line after changing to the correct directory and choosing correct names:

rd /Q /S source\windows_deps...\
del /Q source\windows_deps...7z

When using the GUI approach, you also need to manually download the updated build dependencies archive and extract it into the source\ directory in your GIT repository. With the CLI approach, this will be done automatically on next build.

Running[edit]

If MegaGlest crashes you should do a full rebuild. To do so with the CLI approach, instead of just running mk\windoze\build-mg32bit-2015.bat, to trigger a full rebuild run:

mk\windoze\build-mg32bit-2015.bat n rebuild

If you run into dependency errors when starting the game, be sure to re-run the mk\windoze\CopyWindowsRuntimeDlls_2015.bat batch file to copy possibly updated runtime dependency DLL's to the runtime binary folder.

Reporting bugs[edit]

If you think you have run into a bug in MegaGlest, and neither reading the README and FAQ nor searching for it at http://bugs.megaglest.org helps, then please report a new bug at http://bugs.megaglest.org/ (one-time registration is neccessary to post).

When filing a bug, please provide a log of the build process of a full rebuild. With the CLI approach, run the build batch file and redirect all output to a log file, such as by using:

cd mk\windoze\
build-mg32bit-2015.bat n rebuild 1>%Temp%\build-mg-2015.log 2>&1
@echo The build log was written to: %Temp%\build-mg-2015.log

The GUI approach will always do a full rebuild if you do it as described above.

See also[edit]