Development Environment Setup

This page will describe how to set a dev env for several OSes. The android build is described on a dedicated page.

=Third-Party Libraries and Tools=


 * OpenMW currently uses the following libraries:
 * OpenSceneGraph 3.4 - OpenGL rendering toolkit
 * SDL2 - input and windowing
 * MyGUI 3.2.1 - GUI toolkit
 * Bullet ≥ 2.86 - the physics engine
 * OpenAL or OpenAL soft - for sound playback
 * FFmpeg For sound decoding and BINK video playback
 * LZ4 Extremely fast de-compression algorithm
 * SQLite - Persistent storage, cache
 * LuaJIT - Sandboxed scripting using Sol


 * OpenMW additionally uses the following tools:
 * CMake - used to manage the build process
 * Git - used as the source control management system

For those unfamiliar with Git, the Sphere RPG Engine group has a fairly useful short wiki page entitled "Git for the lazy". Make sure to also check out the GitLab FAQ.

MyGUI
By default, MyGUI will build with the Ogre3D platform enabled, but Ogre3D is not a hard dependency. If you do not want to have Ogre installed, then configure MyGUI with the dummy platform, and disable tools & demos:

OpenSceneGraph
It is recommended to use the OpenMW/osg fork of OpenSceneGraph. OpenMW still works with "vanilla" OpenSceneGraph, but may run at slightly lower frame rate.

Keep in mind the official OpenSceneGraph 3.6.3 release has a critical regression which causes major instabilities in OpenMW. It appears that 3.6.4 release may have severe issues as well. Even if you don't want to use our fork, make sure to use a build linked against an older or a newer stable release (e.g. 3.4.1 or 3.6.5).

OSG plugins
OSG comes with numerous plugins, most of which are not required by OpenMW. If you install OSG from a package manager, then you will have tons of bloat on your system that OpenMW does not need (another reason to build your own).

Only the following plugins are required for OpenMW to function properly:

Texture formats:
 * osgdb_dds
 * osgdb_tga
 * osgdb_bmp
 * osgdb_jpeg
 * osgdb_png

TrueType fonts support (used for profiler):


 * osgdb_freetype

.osg format support:
 * osgdb_osg
 * osgdb_serializers_osg

.dae (Collada) format support:


 * osgdb_dae

Notes: - the jpeg/png plugins will not be built unless you have 'libpng' and 'libjpeg' headers installed on your system. - the Collada (dae) plugin requires libcollada library/headers installed on your system.

If you are creating a release package, the library files for the plugins need to go in  /osgPlugins-.

When using the OSG git master (to be 3.6), or the OpenMW OSG fork, you can use the following cmake arguments to avoid unneeded plugins from being built:

-DBUILD_OSG_PLUGINS_BY_DEFAULT=0 -DBUILD_OSG_PLUGIN_OSG=1 -DBUILD_OSG_PLUGIN_DAE=1 -DBUILD_OSG_PLUGIN_DDS=1 -DBUILD_OSG_PLUGIN_TGA=1 -DBUILD_OSG_PLUGIN_BMP=1 -DBUILD_OSG_PLUGIN_JPEG=1 -DBUILD_OSG_PLUGIN_PNG=1 -DBUILD_OSG_PLUGIN_FREETYPE=1 -DBUILD_OSG_DEPRECATED_SERIALIZERS=0

S3TC texture compression support
OpenMW requires S3TC texture compression support. If you are using a proprietary video driver, you will usually have S3TC support out of the box. With open-source drivers on Linux, you may need to install S3TC support separately. An indicator for missing S3TC support are completely white or pink textures.

On Ubuntu: sudo apt-get install libtxc-dxtn-s2tc0

=Windows=

MSVC 2019-2022
While it's theoretically possible to do everything manually, very, very few people have succeeded, usually due to nonsensical linker errors. Instead, it's recommended that you use our prebuild script. It's what our team members do.

Make sure you're aware of different Build Configurations before being surprised that a Debug build is slower than an official release.

OpenMW currently supports MSVC via three build systems, namely Visual Studio Solutions, NMake Makefiles, and Ninja build files.


 * Solution files have the best integration into Visual Studio.
 * NMake doesn't support parallel builds, so are pointlessly slow if you've got more than one core, and have no particular other benefits. It doesn't support multiple build configurations, so uses much more disk space if you use several.
 * Ninja is theoretically faster than MSBuild/DevEnv (which build solution files) but has less reliable integration with Visual Studio. It only supports multiple build configurations with CMake 3.17 and later.

The tools to build VS Solutions and NMake Makefiles are provided as part of both Visual Studio and the MSVC command-line build tools, but you'll need to install Ninja separately ( if you have Chocolatey).

What you need

 * Visual Studio 2019 or 2022 (Community edition is enough) or the command-line build tools for Visual Studio ( or   if you use Chocolatey).
 * Make sure you've got the C++ toolset installed, which isn't necessarily selected by default.
 * This can be chosen during or after installation from the Visual Studio Installer, where it's called Desktop development with C++ in the workloads tab. If you do add this to an existing installation, the Visual Studio Installer is available in the Start menu, and you'll want to choose to modify the existing installation.
 * Ninja if you're using Ninja ( if you have Chocolatey).
 * VSWhere in your path if you're using Ninja or NMake.
 * works if you have Chocolatey, but make sure you reload your shell or otherwise refresh your environment variables afterwards.
 * It also comes with Visual Studio and the command-line build tools, but isn't on the path by default, and isn't in a reliable location. Feel free to add that version to the path for the shell session you use instead of installing it again.
 * Git for Windows ( if you have Chocolatey).
 * Other Git implementations will be sufficient to clone the OpenMW repo, but Git for Windows also provides the Bash shell used to run the script. You might be able to use a full MSYS2 installation, as it should be the same, just configured slightly differently.
 * Note that WSL does not work for this as the script needs to execute windows executables.
 * Note that a full Cygwin install does not work for this as it tries to emulate Unix file permissions, and the script was not written with this in mind.
 * 7-zip in your path
 * works if you have Chocolatey, but make sure you reload your shell or otherwise refresh your environment variables afterwards.
 * If you don't use Chocolatey, install 7zip like any other application, then use the instructions in this guide to add it to your path.
 * CMake in your path
 * for Chocolatey, but make sure you reload your shell or otherwise refresh your environment variables afterwards. If you'd rather CMake was in the path for all users instead of just the current one, swap  for.
 * If you don't use Chocolatey, install CMake like any other application, making sure to choose Add CMake to the system PATH for all users or Add CMake to the system PATH for the current user when offered.
 * Python in your path
 * works if you have Chocolatey, but make sure you reload your shell or otherwise refresh your environment variables afterwards.
 * If you don't use Chocolatey, you can install Python like any other application, making sure to check the Add Python to PATH box in the installer.
 * Python from the Windows store is probably fine too, but no one's ever tested it.
 * If your Windows install is up-to-date, you might find you've already got  in your path without manually installing it. This isn't an actual Python interpreter, and just opens the Windows Store page for Python if you run it, or crashes with a permissions error. Fake Python is not sufficient to run the prebuild script.
 * You shouldn't be using Windows 7 any more anyway, but there are potential issues with its default version of PowerShell. You won't get helped if this causes problems.
 * ~10GB of free space per build platform (32/64-bit, different build tools etc.) for all the dependencies and build artefacts.
 * Time. A slowish machine will take about an hour, but obviously a faster one will take much less. If you're not using NMake, this should scale well with the number of cores available.

What you do

 * Decide if you're using Solution files, Ninja , or NMake . Solution files are recommended if you're unsure.
 * Pick a directory to do this in.
 * Its path cannot contain spaces. (We can't change this until Qt can be installed with a path containing spaces.)
 * Its path should either be short (e.g. ) or you should enable long file paths in your registry (for example by following this guide).
 * Clone the OpenMW repo.  (or your own fork of it).
 * Open a Git Bash shell in the repo.
 * Remember that other Bash implementations such as WSL or Cygwin won't work.
 * Run the following command:.
 * If you're using Ninja, add  to the command.
 * If you're using NMake, add  to the command.
 * Substitute  with   if doing a 32-bit build. This is no longer supported, but you might be able to bodge it if you build deps yourself.
 * can also be substituted with  for MSVC/VS 2019
 * For Solution files and Ninja with recent versions of CMake this will set up and install runtime resources for all build configurations, so all will be buildable and will run. For NMake (or Ninja if your CMake version is below 3.17) it will only set up the Debug configuration. The differences between the configurations are discussed here
 * To set up Release, add  to the command.
 * To set up RelWithDebInfo, add  to the command.
 * If we ever change the default, adding  will set up the Debug configuration.
 * For NMake (or Ninja if your CMake version is below 3.17) you can still set up multiple configurations at once by specifying several on the command line, but this will use significantly more disk space.
 * If you want debug symbols for dependency libraries (e.g. if you want to investigate a bug in one of them), add.
 * If you want to build the unit tests, add.
 * Other, more niche, options exist, and are documented in the script's help text, available by running


 * Wait for the build environment to be set up.


 * For Solution files:
 * Go to the build folder that was just created ( if you've used VS 2022 and specified 64-bit) and open.
 * Make sure the Configuration dropdown at the top of Visual Studio is set to the one you want to use.
 * If you want to use Visual Studio's debugger, make sure you've set a startup project in the Solution Explorer by right clicking one and choosing Set as Startup Project. (The default startup project is  which doesn't have an executable as it's a meta project used to build all other OpenMW projects at once, so cannot be started.)
 * Press F5 to build the current startup project and launch it with the debugger, or Ctrl+Shift+B to build all projects.


 * For Ninja:
 * into the build folder that was just created ( if you've used MSVC 2022, specified 64-bit and are using a recent CMake version) either in the Bash shell you just used, or another of your choosing.
 * Activate the correct MSVC environment in the current shell. Helper scripts are provided to make it easy to match the build you just configured:
 * For Bash, use.
 * For PowerShell, use.
 * For CMD, use.
 * Run  to build all targets, or add target names to build specific targets, e.g..
 * With CMake older than 3.17.0, different build configurations need to be built by calling  in different folders. With newer CMake versions, they're all available in the same folder and you can build a specific configuration by adding   to the command, e.g.   to build just the CS in the RelWithDebInfo configuration.


 * For NMake:
 * into the build folder that was just created ( if you've used MSVC 2022, specified 64-bit either specified the Debug configuration or left it with the default) either in the Bash shell you just used, or another of your choosing.
 * Activate the correct MSVC environment in the current shell. Helper scripts are provided to make it easy to match the build you just configured:
 * For Bash, use.
 * For PowerShell, use.
 * For CMD, use.
 * Run  to build all targets, or add target names to build specific targets, e.g..

If this doesn't work
First, double check that you've followed the instructions properly. Some common problems are in bold. If you still have issues, make sure to report them somewhere official, such as the OpenMW forums, as otherwise we won't know anything needs fixing.

Updating dependencies
Once in a while, the versions of dependencies listed in the script will be updated. For some of these, they can be updated just by running the script again. However, for some others, the process has not been automated yet. The rough steps to do so manually are as follows:


 * If you don't have any particular reason to keep the existing build directory (the  directory), simply delete it and use the script to regenerate it. You will get a new build environment using updated dependencies.
 * If you need to keep the build directory, the process is more involved:
 * Delete the directory the dependency was extracted to
 * Remove any lines mentioning the dependency from
 * Run the script again.

Build Configurations

 * Debug builds are slow, but the easiest to use with a debugger.
 * Release builds are fast, but cannot be effectively used with a debugger.
 * RelWithDebInfo builds are fast, and can be used with a debugger, but some lines may be executed in a different order to how they appear in the source code, and some may be skipped altogether, making debugging more difficult.

None of these are quite the same as official release builds - they have a different setting called Link Time Optimization (LTO)/Interprocedural Optimisation turned on. As it's a time-costly option, automatic builds and the instructions above do not have LTO enabled. It may affect performance, but we have no credible reports of the effect being significant.

Enabling LTO can be done by ticking a checkbox in the CMake GUI, or passing  on the command line when configuring with CMake.

NOTE: This can take a release build from half an hour to two hours, potentially trash debugability if using RelWithDebInfo, and definitely if actually using Debug.

To enable LTO for an existing build:
 * Open the CMake GUI. This should show up if you type cmake gui into the Start menu.
 * Set the build directory to the one with your OpenMW solution file, Ninja build files, or NMake makefiles. It should pick up all the settings the build script set.
 * Tick the OPENMW_LTO_BUILD option (it might be fastest to type LTO into the filter bar).
 * Press Generate.
 * If using Visual Studio, it will then ask to reload the solution.
 * Build again.

Visual Studio 2017-2019 scripted way
This is the recommended method to build OpenMW on Windows. This script is kept updated and has fewer ways of going wrong than setting up your development environment manually. If you have issues, make sure to report them somewhere official, such as the OpenMW forums, as otherwise we won't know anything needs fixing.

What you need

 * Visual Studio 2017 or 2019 (Community edition is enough)
 * Make sure you've got the C++ toolset installed, which isn't necessarily installed by default.
 * In VS 2017/2019, this is called "Desktop development with C++" and is available under the workloads tab in the Visual Studio installer. This can be added during initial installation or alternatively afterwards by typing "Visual Studio Installer" into the start menu search and choosing to modify Visual Studio 2017.
 * MSYSGit or Git for Windows as it's also called ( if you have Chocolatey)
 * Other Git implementations will be sufficient to clone the OpenMW repo, but MSYSGit also provides the bash shell used to run the script.
 * Note that WSL does not work for this as the script needs to execute windows executables.
 * Note that a full Cygwin install does not work for this as it tries to emulate Unix file permissions, and the script was not written with this in mind.
 * 7-zip in your path
 * works if you have Chocolatey, but make sure you reload your shell or otherwise refresh your environment variables afterwards.
 * If you don't use Chocolatey, install 7zip like any other application, then use the instructions in this guide to add it to your path.
 * CMake in your path
 * for Chocolatey, but make sure you reload your shell or otherwise refresh your environment variables afterwards. If you'd rather CMake was in the path for all users instead of just the current one, swap  for.
 * If you don't use Chocolatey, install CMake like any other application, making sure to choose "Add CMake to the system PATH for all users" or "Add CMake to the system PATH for the current user" when offered.
 * There might be an issue with the version of PowerShell bundled with Windows 7, so if you're using Windows 7 and the script hangs, consider updating PowerShell. If this helps, please tell someone, as we're not sure if this affects everyone or just one person.
 * ~10GB of free space per build platform (32/64-bit), for all the build artefacts.
 * Time. Around an hour most likely for a full release or debug build.

What you do

 * Pick a directory to do this in.
 * Its path cannot contain spaces (this can't change until Qt can be installed with a path containing spaces).
 * Its path should either be short (e.g. ) or you should enable long file paths in your registry (for example by following this guide).
 * Clone the OpenMW repo.  (or your own fork of it).
 * Open a Git Bash shell in the repo.
 * Remember that other Bash implementations such as WSL or Cygwin won't work.
 * Run the following command:.
 * Substitute Win64 with Win32 if doing a 32-bit build.
 * 2019 can also be substituted with 2017 for VS2017
 * This will only install the runtime resources for the Debug configuration, so while others will be available in Visual Studio, they won't run.
 * To install them for Release instead, add  to the command. (see Release Optimization )
 * To install them for RelWithDebInfo instead, add  to the command.
 * If we ever change the default, adding  will set up the Debug configuration.
 * Only one configuration can be set up per command invocation, so feel free to run it again with another configuration specified to get all the ones you need.
 * Wait for the build environment to be set up.
 * Go to the build folder that was just created ( if you've used VS 2019 and specified 64-bit) and open.
 * If this Visual Studio bug hasn't been fixed yet, there's an extra step to work around it. If you skip this before it's fixed, you'll get an error saying Unable to start debugging. Check your debugger settings by opening project properties... when you launch something through VS, e.g. to debug it.
 * In Visual Studio, for each executable target you intend to use (e.g.,  ,   etc.), right click on it in the Solution Explorer and choose Properties to open its Property Pages.
 * At the top left of the popup, you'll see that Configuration is set to something. Changing this to All Configurations ensures that you won't have to repeat this for every single build type later.
 * In the left hand list, under Configuration Properties, there'll be a Debugging category. Select it.
 * In the right hand list, you'll see that Working Directory is set to . Change this to something else, then press Apply at the bottom right of the popup.
 * Change it back to  and then press Apply again.
 * Make sure the Configuration dropdown at the top of Visual Studio is set to the one you want to use.
 * Debug builds are slow, but the easiest to use with a debugger.
 * Release builds are fast, but cannot be effectively used with a debugger.
 * RelWithDebInfo builds are fast, and can be used with a debugger, but some lines may be executed in a different order to how they appear in the source code, and some may be skipped altogether, making debugging more difficult.
 * If you want to use Visual Studio's debugger, make sure you've set a startup project in the Solution Explorer by right clicking one and choosing Set as Startup Project. (The default startup project is  which doesn't have an executable as it's a meta project used to build all other OpenMW projects at once, so cannot be started.)
 * Develop.

If this doesn't work
First, double check that you've followed the instructions properly. Some common problems are in bold. If you still have issues, make sure to report them somewhere official, such as the OpenMW forums, as otherwise we won't know anything needs fixing.

Updating dependencies
Once in a while, the versions of dependencies listed in the script will be updated. For some of these, they can be updated just by running the script again. However, for some others, the process has not been automated yet. The rough steps to do so manually are as follows:


 * If you don't have any particular reason to keep the existing build directory (the  directory), simply delete it and use the script to regenerate it. You will get a new build environment using updated dependencies.
 * If you need to keep the build directory, the process is more involved:
 * Delete the directory the dependency was extracted to
 * Remove any lines mentioning the dependency from
 * Run the script again.

Release Optimization
Official builds are done with Link Time Optimization (LTO) turned on. As it is time-costly option, automatic builds and the instructions above do not have LTO enabled. It may affect performance. One PC user testing in Seyda Neen saw ~50fps without and ~150fps with LTO. Android might required different instructions to see performance increase.

Enabling LTO can be done by ticking a checkbox in the CMake GUI, or passing -DOPENMW_LTO_BUILD=1 on the command line.

NOTE: This can take a release build from half an hour to two hours, potentially trash debugability if using RelWithDebInfo, and definitely if actually using Debug.


 * Open the CMake GUI. This should show up if you type cmake gui into the Start menu.
 * Set the build directory to the one with your OpenMW solution file. It should pick up all the settings the build script set.
 * Tick the OPENMW_LTO_BUILD option (might be fastest to type LTO into the filter bar).
 * Press Generate.
 * VS will then ask to reload the solution.

From Discord #development Jan-2020 with AnyOldName3 and Capo

Previous versions of this guide
https://forum.openmw.org/viewtopic.php?f=6&t=4074 quick placeholder

https://gist.github.com/ananace/de7f30454e99b3952405

NMake 2017-2019 scripted way
This method is basically the same as the one above, but produces NMake Makefiles for those who want a more Unix-like development setup. You will need to choose and set up your own editor and debugger etc.

What you need

 * Everything required for the above method, except you can optionally exclude the Visual Studio GUI and only install the build tools.

What you do

 * Pick a directory to do this in.
 * Its path cannot contain spaces (this can't change until Qt can be installed with a path containing spaces).
 * Its path should either be short (e.g. ) or you should enable long file paths in your registry (for example by following this guide).
 * Clone the OpenMW repo.  (or your own fork of it).
 * Open a console capable of command-line C++ development in the Git repo.
 * The simplest way of achieving this is to open the start menu, locate the folder for your chosen Visual Studio release, and open a Development Command Prompt for your chosen architecture (e.g. x64 Native Tools Command Prompt to build 64-bit OpenMW on a 64-bit machine). You can then use  to navigate to the cloned repo.
 * Microsoft recommend against permanently setting up the necessary environment variables to have access to C++ tools as updates to those tools may break many things if you do.
 * Open a Git Bash shell from within the development console. If Git Bash is the only Bash shell you have installed, the command  should suffice.
 * Remember that other Bash implementations such as WSL or Cygwin won't work.
 * Remember that if you don't open Bash from within the development console, the necessary environment variables for tools to access NMake and the compiler won't be set.
 * Run the following command:.
 * Substitute Win64 with Win32 if doing a 32-bit build.
 * 2019 can also be substituted with 2017 for the build tools provided with VS2017
 * This will only set up the Debug configuration. NMake is a single-configuration build system, so you only get one build type per set of Makefiles.
 * To set up Release instead, add  to the command.
 * To set up RelWithDebInfo instead, add  to the command.
 * If we ever change the default, adding  will set up the Debug configuration.
 * Even though only one configuration can be set up per command invocation, you can feel free to run it again with another configuration specified to get all the ones you need.
 * Use  to navigate to the build folder that was just created (  if you've used the build tools from VS 2019 and specified 64-bit and the Debug configuration).
 * Develop
 * Use  build a target. If no target name is specified, all will be built.

Manual setup
Setting up a Windows development environment manually is not recommended. If one were to follow these instructions, it would not lead to a working OpenMW build. If you have experience setting up the required libraries (including the ones not listed here), you may be able to work around any issues, but it's also possible that you won't be able to. It is unlikely that trying is worth your time.

Tools

 * Visual Studio - normal or free (C++) express versions. Note that you will have to build Qt yourself.
 * CMake: CMake at least v2.8, but grab the latest stable release.
 * Git - Our version control software: Git at least v1.8.x, but grab the latest stable release.

Libraries
(Needs updating, +osg)
 * Boost: Use the installer for your Visual Studio version and set the environment variable BOOST_ROOT to the .
 * Bullet Download bullet and build the BulletCollision, BulletDynamics and LinearMath projects. Make sure the Runtime library is set to "Multi-threaded Debug DLL (/MDd)" or "Multi-threaded DLL (/MD)" for the debug and the release configuration, respectively. Also "Enable Run-Time Type Information" has to be set to "Yes (/GR)". Afterwards put the libraries into the  folder, strip the ending off (like _vs2010) and set the environment variable BULLET_ROOT to the .
 * Freetype: Freetype2, and set the environment variable FREETYPE_DIR to the .
 * MyGUI: Download and build following compilation instructions and set the MYGUI_HOME environment variable.
 * OpenAL: Download OpenAL11CoreSDK and set the environment variable OPENALDIR.
 * Qt. Download the latest Qt4 version for your Visual Studio version and install the environment variable QTDIR. Example: qt-win-opensource-4.8.4-vs2010.exe
 * FFmpeg Download and extract the dev and shared of ffmpeg. The latest builds don't work. A known working version is commit 1eabd71, available in the "previous versions" links on that page. The environment variable is FFMPEG_HOME. (Note: A later build ffmpeg-20120914-git-8bdba0b-win64 appears to work ok with openmw-0.30 without crashing)
 * SDL2 Download and extract the SDL2 VS "Development Libraries". SDL2-devel-2.0.1-VC.zip Then set the SDL2_LIBRARY variable to the location of the SDL2.dll file.

Once this is done, you're ready to get the source code.


 * Get the OpenMW Source code using GIT or Tortoise Git

Download and install all of these and make sure the environment (the system and Cmake) knows where they are. If you develop under a non-admin account, use System variables rather than User variables (in Control Panel->System and Security->System->System Properties->Advanced (tab)->Environment Variables). Add the following, adjusted to the paths in your system:

Check that PATH includes the path to git.exe for CMakeGUI to find it.

Bullet libraries won't be found by CMake if you didn't put the built libraries manually into \lib\Release\ as indicated above. Alternatively modify cmake\FindBullet.cmake to look for ${BULLET_ROOT}/lib.

Similarly, either set MYGUI_INCLUDE_DIRS and MYGUI_PLATFORM_INCLUDE_DIRS manually in CMakeGUI or modify cmake\FindMyGUI.cmake to look for ${MYGUISDK}/include/MYGUI.

Need to remove SDL2main.lib from VS->Properties->Configuration Properties->Linker->Additional Dependencies if you run into linking errors building owmlauncher. One way is to edit CMakeLists.txt so that SDL2_BUILDING_LIBRARY is set before running CMakeGUI. Another way is to set the SDL2_LIBRARY env variable instead of SDL2DIR as indicated above.

Running and using CMake
First, before opening Cmake, create a sibling directory called "OpenMW - build" next to the root "openmw" so that an out-of-source build can be done. This step is not needed if you're using CMakeGUI, as a separate build directory can be specified at the start.

This will create a Visual Studio solution which you can use to compile OpenMW. (Hint: If you are building a debug version, add /bigobj to openmw project in VS->Properties->Configuration Properties->C/C++->Command Line->Additional Options)

via Cygwin
Git is available on Windows via cygwin. Git can be used directly on Windows instead of grabbing source zip files from Gihub. The cygwin environment will allow you to use the same git command line commands as are recommended for the Linux environment. Note however that the cygwin version of CMake does not appear to support VS2008 as a valid target; therefore, cygwin can only be used for Git commands and a standard Windows command prompt should be used for invoking CMake.

via msysGit
There is also a stand-alone compiled package called msysgit. This will give you a Cygwin-like console with the git command, which you may find easier than via Cygwin.

via TortoiseGit
There is also a GUI git client for the one used to TortoiseSVN or TortoiseCVS which is called TortoiseGIT. It will give you a nice GUI inside the Windows explorer. This is the easy way.

via Eclipse
First of all, you need the egit plugin. Install it, restart eclipse, "file -> import -> git -> clone"

=Linux=

Arch
There is a development package available for OpenMW on the AUR. It can be found at.

Information about building packages from the Arch User Repository (AUR) can be found at the Arch wiki.

Key requirements
Because some dependencies of OpenMW are not in the Ubuntu repositories we made a development repository on Launchpad which provides packages for the missing dependencies.

To be able to install these packages you need to add the openmw Launchpad PPA by running:

and to make sure that the ppa will be used run:

Packages
You will need g++ in order to compile OpenMW.

To setup a build environment and install all dependencies type:

Key requirements
Because some dependencies of OpenMW are not in the Fedora Workstation repositories, you need to enable RPMFusion free and non-free repositories which provide packages for the missing dependencies.

Packages
You will need g++ in order to compile OpenMW.

To setup a build environment and install most of the dependencies type:

While this list of packages is technically up-to-date, you'll run into problems if you don't get MyGUI and unshield libraries.

First try doing that:

This will probably fail.

If you're reading this in 2090 and it doesn't fail as expected, please bother someone to update these instructions!

But if you're reading this circa 2022, you are probably using Fedora 36 or Fedora 37 and these will have trouble.

The issue is that the official Fedora repositories don't include MyGUI and unshield anymore at the time this is being written.

Fortunately, as a temporary measure, you should be able to build their libraries from the source code and either install them to your system - bypassing the package management system, which is not recommended - or point OpenMW's CMake environment to their location.

unshield and MyGUI
unshield adds no new dependencies. MyGUI's only relevant dependency is FreeType. Get it:

and then you can follow the fetching source and building instructions from below for both.

Keep the notes regarding not building MyGUI against Ogre in the beginning of this article in mind.

While configuring OpenMW's CMake, you will now need to manually point it to the brand-new libraries and the source code in your system. Have fun.

Bullet
This isn't where the fun ends, though: remember installing Bullet libraries? Well, there wasn't any particular reason to install them, since - at the moment - the ones in Fedora repositories are not built with double-precision support enabled.

You'll have to build Bullet from source as well. Make sure to enable double-precision in Bullet's CMake (USE_DOUBLE_PRECISION).

Once again, you can tinker with its other build settings to your liking as OpenMW currently only needs BulletCollision library.

After building Bullet, you should get back to OpenMW's CMake settings.

Once again, have some fun configuring it by pointing CMake to Bullet libraries and source code. By this point you should be able to finish Makefile generation successfully.

Packages
You will need g++ in order to compile OpenMW.

To setup a build environment and install all dependencies type:

openSUSE also supports installing packages from their cmake BuildRequires. For example, one can enter `sudo zypper in 'cmake(yaml-cpp)'` to install `yaml-cpp-devel`.

Fetching the source
Download the source from the main downloads page:, or get the latest git snapshot:

With make
Note that this is an out-of-source build. Generally, this is the preferred method when working with cmake. This creates a regular makefile.

Now we can start compiling. Normally you can just run

but if you have multiple cores, you can decrease your compile time by doing this:

Note** If you are having undefined reference errors while compiling, its possible that you have previously installed a different openscenegraph version than what openMW depends on.

To remove it, you can use

If this doesn't work, it might be necessary to manually remove the libraries installed by the package.

You can usually find them in one of these:

= macOS =

Prerequisites
OpenMW requires C++20 in order to compile. If you've got macOS 11.0 or later, you can use the Xcode provided compiler (clang) You will also need the Xcode comand line tools.

CMake & pkg-config are required. You can install these via Homebrew:

$ brew install cmake $ brew install pkg-config

Dependencies
The easiest way to handle OpenMW dependencies is to use openmw-dep, which is what is used for official release builds. Either follow the instructions in that repository to build from source, or download the prebuilt dependencies here.

Qt
Supported Qt version for macOS builds is 5.15.2.

Note that you can install Qt from homebrew too but we previously had some issues with deployment of OpenMW binaries built against homebrewed Qt. It's completely fine if you don't intend to deploy to other machines, though. Also note that we currently support Qt5, not Qt6 which is the latest version provided by homebrew. The following command can be used to obtain the supported version.

$ brew install qt@5

It's recommended, however, to use package from Qt Project site if you're planning to deploy your builds to other machines.

liblz4
This can be installed via brew

$ brew install lz4

ICU
This can be installed via brew

$ brew install icu4c

yaml-cpp
This can be installed via rew

$ brew install yaml-cpp

On macOS 10.15, you should also ensure that the compiler will use the Homebrew version. This will be done with the cmake parameters (see below).

Build
First of all you'll need to clone OpenMW source code, either from our main repository or from your fork:

$ git clone https://gitlab.com/OpenMW/openmw/

Then you can cd into source directory and look around. Please note that out-of-source build is recommended:

$ mkdir build $ cd build I assume that openmw & build directories are siblings. Call CMake:

$ cmake \ -D CMAKE_PREFIX_PATH="$PATH_TO_DEPENDENCIES_DIR;$PATH_TO_QT_INSTALLATION" \ -D CMAKE_BUILD_TYPE=Debug \ -G"Unix Makefiles" \ ../openmw/

Where $PATH_TO_DEPENDENCIES_DIR and $PATH_TO_QT_INSTALLATION are directories listed earlier in this guide. $PATH_TO_DEPENDENCIES_DIR</tt> is a directory like "openmw-deps" containing "lib" and "include" sub-directories, and $PATH_TO_QT_INSTALLATION</tt> is a path to a Qt 5.15.2 installation (for example ~/Qt/Qt5.15.2/5.15/clang_64/lib/cmake</tt>). Note that these paths must be absolute; if they are relative paths then the correct files will not be found.

You may need to include this line in the `cmake` arguements: -D CMAKE_OSX_SYSROOT="$MAC_OS_VERSION" \</tt> where $MAC_OS_VERSION</tt> is the version of macOS in the format macosx10.##</tt>. For instance, if you are running macOS 10.13 (High Sierra), $MAC_OS_VERSION</tt> would need to be set to macosx10.13</tt>.

You may need to include this line in the `cmake` arguments: -D SDL2_INCLUDE_DIR="$PATH_TO_DEPENDENCIES_DIR/include/SDL2" \</tt>.

You may need to brew install bullet</tt>.

Then build:

$ make

And try:

$ open OpenMW.app $ open OpenMW-CS.app

Or run binaries directly to see the output:

$ OpenMW.app/Contents/MacOS/openmw-launcher $ OpenMW.app/Contents/MacOS/openmw $ OpenMW-CS.app/Contents/MacOS/OpenMW-CS

Deployment
If you want to make a release build and deploy it, you must set CMake variable OPENMW_OSX_DEPLOYMENT</tt> to TRUE</tt>:

$ cmake \ -D CMAKE_PREFIX_PATH="$PATH_TO_DEPENDENCIES_DIR;$PATH_TO_QT_INSTALLATION" \ -D CMAKE_OSX_DEPLOYMENT_TARGET="10.15" \ -D CMAKE_BUILD_TYPE=Release \ -D OPENMW_OSX_DEPLOYMENT=TRUE \ -G"Unix Makefiles" ../openmw/

If these instructions aren't up to date, refer to the CI scripts in the repo.

Build & package:

$ make package After this command completes, you'll have a *.dmg file in current directory. You can publish this file as OpenMW release, send it to your friend, etc.

Note that if you'll try to launch release versions of OpenMW.app or OpenMW-CS.app directrly from build directory they won't work, because they're built in deployment configuration when all dependencies are expected to be inside application bundle, but they're not until everything is packed in *.dmg.

Troubleshooting
If you experiencing configuration or build errors, or just in doubt, please refer to our Travis CI build script, it's proven to be working and should help you setup build environment on almost any compatible Mac with OS X 10.15 or higher (older versions could work too, but we're unable to test on them).

Umbrella script: https://gitlab.com/OpenMW/openmw/blob/master/.travis.yml

Dependency setup: https://gitlab.com/OpenMW/openmw/blob/master/CI/before_install.osx.sh

Build: https://gitlab.com/OpenMW/openmw/blob/master/CI/before_script.osx.sh

macOS 10.15
The clang compiler provided by Xcode on macOS 10.15 do not support C++20 features, but the one provided by brew support them. Before compiling OpenMW, you should install llvm via brew:

$ brew install llvm

Then specify to cmake that you want it to use brew llvm via export:

$ export CC="/usr/local/opt/llvm/bin/clang" $ export CCX="/usr/local/opt/llvm/bin/clang++" $ export CPPFLAGS="-I/usr/local/opt/llvm/include"

or via cmake parameters. In such case, make sure that you apply the CPPFLAGS after the "stdlib=libc++" one i.e.,

-D CMAKE_CXX_FLAGS="-stdlib=libc++ -I/usr/local/opt/llvm/include"

You also have to make sure to use the ICU version provided by brew

-D ICU_ROOT="/usr/local/opt/icu4c"

=Data=

For a detailed description of how to obtain the data files check Installation_Instructions.