Development Environment Setup: Difference between revisions

From OpenMW Wiki
Jump to navigation Jump to search
(→‎Windows: NMake guide)
m (Add qttools5-dev for Ubuntu)
 
(67 intermediate revisions by 15 users not shown)
Line 1: Line 1:
This page will describe how to set a dev env for several OSes.
This page will describe how to set a dev env for several OSes.
The android build is described on a [[Android build|dedicated page]].


=Third-Party Libraries and Tools=
=Third-Party Libraries and Tools=


* OpenMW currently uses the following libraries:
* OpenMW currently uses the following libraries:
** [http://www.openscenegraph.org/ OpenSceneGraph 3.4] - OpenGL rendering toolkit
** [http://www.openscenegraph.org/ OpenSceneGraph 3.6] - OpenGL rendering toolkit
** [http://www.libsdl.org/ SDL2] - input and windowing
** [http://www.libsdl.org/ SDL2] - input and windowing
** [http://mygui.info/ MyGUI 3.2.1] - GUI toolkit
** [http://mygui.info/ MyGUI 3.4.1] - GUI toolkit
** [http://www.bulletphysics.com/ Bullet 2.86] - the physics engine
** [http://www.bulletphysics.com/ Bullet 2.86] - the physics engine
** [http://connect.creativelabs.com/openal/default.aspx OpenAL] or [http://kcat.strangesoft.net/openal.html#download OpenAL soft] - for sound playback
** [http://connect.creativelabs.com/openal/default.aspx OpenAL] or [http://kcat.strangesoft.net/openal.html#download OpenAL soft] - for sound playback
** [http://www.ffmpeg.org/ FFmpeg] For sound decoding and BINK video playback.
** [http://www.ffmpeg.org/ FFmpeg] For sound decoding and BINK video playback
** [https://github.com/lz4/lz4 LZ4] Extremely fast de-compression algorithm
** [https://www.sqlite.org/index.html SQLite] - Persistent storage, cache
** [https://luajit.org/ LuaJIT] - Sandboxed scripting using Sol


* OpenMW additionally uses the following tools:
* OpenMW additionally uses the following tools:
Line 27: Line 31:
cmake .. -DMYGUI_RENDERSYSTEM=1 -DMYGUI_BUILD_DEMOS=OFF -DMYGUI_BUILD_TOOLS=OFF -DMYGUI_BUILD_PLUGINS=OFF
cmake .. -DMYGUI_RENDERSYSTEM=1 -DMYGUI_BUILD_DEMOS=OFF -DMYGUI_BUILD_TOOLS=OFF -DMYGUI_BUILD_PLUGINS=OFF
</syntaxhighlight>
</syntaxhighlight>
As of 0.49.0, the minimum MyGUI version requirement has been bumped to 3.4.3 and linking MyGUI requires it to have been built with MYGUI_DONT_USE_OBSOLETE=ON.


=== OpenSceneGraph ===
=== OpenSceneGraph ===


It is recommended to use the [https://github.com/OpenMW/osg OpenMW/osg] fork of OpenSceneGraph. OpenMW still works with "vanilla" OpenSceneGraph, but may run at slightly lower frame rate.
It is recommended to use the [https://github.com/OpenMW/osg 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 3.6.5 or newer.


==== OSG plugins ====
==== OSG plugins ====
Line 44: Line 52:
* osgdb_jpeg
* osgdb_jpeg
* osgdb_png
* osgdb_png
TrueType fonts support (used for profiler):
* osgdb_freetype


[[Native_Mesh_Format|.osg format]] support:
[[Native_Mesh_Format|.osg format]] support:
* osgdb_osg.so
* osgdb_osg
* osgdb_serializers_osg.so
* 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.


Note, the jpeg/png plugins will not be built unless you have 'libpng' and 'libjpeg' headers installed on your system.


If you are creating a release package, the library files for the plugins need to go in ''<library path>/osgPlugins-<OSG_VERSION>''.
If you are creating a release package, the library files for the plugins need to go in ''<library path>/osgPlugins-<OSG_VERSION>''.
Line 55: Line 74:
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:
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_DDS=1 -DBUILD_OSG_PLUGIN_TGA=1 -DBUILD_OSG_PLUGIN_BMP=1 -DBUILD_OSG_PLUGIN_JPEG=1 -DBUILD_OSG_PLUGIN_PNG=1 -DBUILD_OSG_DEPRECATED_SERIALIZERS=0
  -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 ===
=== S3TC texture compression support ===
Line 68: Line 87:
=Windows=
=Windows=


==Visual Studio 2013/2015/2017 scripted way==
== MSVC 2019-2022 ==
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.
 
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 [[Development_Environment_Setup#Build_Configurations|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 (<code>cinst ninja</code> if you have Chocolatey).


=== What you need ===
=== What you need ===


* Visual Studio 2013, 2015 or 2017 (Community edition is enough)
* Visual Studio 2019 or 2022 (Community edition is enough) ''or'' the command-line build tools for Visual Studio (<code>cinst visualstudio2022buildtools</code> or <code>cinst visualstudio2019buildtools</code> if you use Chocolatey).
** Make sure you've got the C++ toolset installed, which isn't necessarily installed by default.
** Make sure you've got the C++ toolset installed, which isn't necessarily selected by default.
*** In VS 2017, 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.
*** 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.
*** In VS 2015, a similarly-named package is available and can be added during initial installation or afterwards by choosing to repair then modify your VS installation from the Windows Programs and Features menu.
* Ninja if you're using Ninja (<code>cinst ninja</code> if you have Chocolatey).
*** VS 2013 should always come with C++ support.
* VSWhere '''in your path''' if you're using Ninja or NMake.
* MSYSGit or Git for Windows as it's also called (<code>cinst git.install</code> if you have Chocolatey)
** <code>cinst vswhere</code> works if you have Chocolatey, but make sure you reload your shell or otherwise refresh your environment variables afterwards.
** Other Git implementations will be sufficient to clone the OpenMW repo, but MSYSGit also provides the bash shell used to run the script.
** 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 (<code>cinst git.install</code> 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 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.
*** 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'''
* 7-zip '''in your path'''
**<code>cinst 7zip.install</code> works if you have Chocolatey, but make sure you reload your shell or otherwise refresh your environment variables afterwards.
** <code>cinst 7zip.install</code> 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 [https://www.howtogeek.com/118594/how-to-edit-your-system-path-for-easy-command-line-access/ this guide] to add it to your path.
** If you don't use Chocolatey, install 7zip like any other application, then use the instructions in [https://www.howtogeek.com/118594/how-to-edit-your-system-path-for-easy-command-line-access/ this guide] to add it to your path.
* CMake '''in your path'''
* CMake '''in your path'''
**<code>cinst cmake.install --installargs 'ADD_CMAKE_TO_PATH=User'</code> for Chocolatey, but make sure you reload your shell or otherwise refresh your environment variables afterwards.
** <code>cinst cmake.install --installargs 'ADD_CMAKE_TO_PATH=User'</code> 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 <code>ADD_CMAKE_TO_PATH=User</code> for <code>ADD_CMAKE_TO_PATH=System</code>.
**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.
** 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.
* ~10GB of free space per build platform (32/64-bit), for all the build artefacts.
* Python '''in your path'''
* Time. Around an hour most likely for a full release or debug build.
** <code>cinst python</code> 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 <version> 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 <code>python.exe</code> 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 ===
=== What you do ===


* Decide if you're using <span style="color:purple">Solution files</span>, <span style="color:green">Ninja</span>, or <span style="color:maroon">NMake</span>. Solution files are recommended if you're unsure.
* Pick a directory to do this in.
* 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 '''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. <code>C:\OpenMW-dev\</code>) or you should enable long file paths in your registry (for example by following [https://www.howtogeek.com/266621/how-to-make-windows-10-accept-file-paths-over-260-characters/ this guide]).
** Its path should either be short (e.g. <code>C:\OpenMW-dev\</code>) or you should enable long file paths in your registry (for example by following [https://www.howtogeek.com/266621/how-to-make-windows-10-accept-file-paths-over-260-characters/ this guide]).
* Clone the OpenMW repo. <code>git clone https://gitlab.com/OpenMW/openmw/</code> (or your own fork of it).
* Clone the OpenMW repo. <code>git clone https://gitlab.com/OpenMW/openmw/</code> (or your own fork of it).
* Open a Git Bash shell in the repo.
* Open a Git Bash shell in the repo.
** Remember that other Bash implementations such as WSL or Cygwin won't work.
** Remember that other Bash implementations such as WSL or Cygwin won't work.
* Run the following command: <code>CI/before_script.msvc.sh -k -p Win64 -v 2017</code>.
* Run the following command: <code>CI/before_script.msvc.sh -k -p Win64 -v 2022</code>.
** Substitute Win64 with Win32 if doing a 32-bit build.
** <span style="color:green">If you're using Ninja, add <code> -N</code> to the command.</span>
** 2017 can also be substituted with 2013 for VS2013 or 2015 for VS2015
** <span style="color:maroon">If you're using NMake, add <code> -n</code> to the command.</span>
** '''This will only install the runtime resources for the Debug configuration, so while others will be available in Visual Studio, they won't run.'''
** Substitute <code>Win64</code> with <code>Win32</code> if doing a 32-bit build. This is no longer supported, but you might be able to bodge it if you build deps yourself.
*** To install them for Release instead, add <code> -c Release</code> to the command.
** <code>2022</code> can also be substituted with <code>2019</code> for MSVC/VS 2019
*** To install them for RelWithDebInfo instead, add <code> -c RelWithDebInfo</code> to the command.
** '''For <span style="color:purple">Solution files</span> and <span style="color:green">Ninja with recent versions of CMake</span> this will set up and install runtime resources for all build configurations, so all will be buildable and will run. <span style="color:maroon">For NMake <span style="color:green">(or Ninja if your CMake version is below 3.17)</span> it will only set up the Debug configuration.</span> The differences between the configurations are discussed [[Development_Environment_Setup#Build_Configurations|here]]'''
*** To set up Release, add <code> -c Release</code> to the command.
*** To set up RelWithDebInfo, add <code> -c RelWithDebInfo</code> to the command.
*** If we ever change the default, adding <code> -c Debug</code> will set up the Debug configuration.
*** If we ever change the default, adding <code> -c Debug</code> 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.
*** <span style="color:maroon">For NMake <span style="color:green">(or Ninja if your CMake version is below 3.17)</span> you can still set up multiple configurations at once by specifying several on the command line, but this will use significantly more disk space.</span>
** If you want debug symbols for dependency libraries (e.g. if you want to investigate a bug in one of them), add <code> -P</code>. Alternatively, you can tell your debugger to use <code>https://openmw-sym.rgw.ctrl-c.liu.se</code> as a symbol server, and they'll be fetched on demand.
** If you want to build the unit tests, add <code> -t</code>.
** Other, more niche, options exist, and are documented in the script's help text, available by running <code>CI/before_script.msvc.sh -h</code>
 
* Wait for the build environment to be set up.
* Wait for the build environment to be set up.
* Go to the build folder that was just created (<code>MSVC2017_64</code> if you've used VS 2017 and specified 64-bit) and open <code>OpenMW.sln</code>.
 
* If you're using VS 2017 and [https://developercommunity.visualstudio.com/content/problem/268817/debugger-no-longer-respects-localdebuggerworkingdi.html this Visual Studio bug hasn't been fixed yet], there's an extra step to work around it.
* <span style="color:purple">For Solution files:</span>
** In Visual Studio, for each executable target you intend to use (e.g. <code>openmw</code>, <code>openmw-cs</code>, <code>openmw-launcher</code> etc.), right click on it in the Solution Explorer and choose Properties to open its Property Pages.
** Go to the build folder that was just created (<code>MSVC2022_64</code> if you've used VS 2022 and specified 64-bit) and open <code>OpenMW.sln</code>.
** 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.
** Make sure the Configuration dropdown at the top of Visual Studio is set to the one you want to use.
** In the left hand list, under Configuration Properties, there'll be a Debugging category. Select it.
** 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 <code>ALL_BUILD</code> 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.)
** In the right hand list, you'll see that Working Directory is set to <code>$(TargetDir)</code>. Change this to something else, then press Apply at the bottom right of the popup.
** Press F5 to build the current startup project and launch it with the debugger, or Ctrl+Shift+B to build all projects.
** Change it back to <code>$(TargetDir)</code> 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.
* <span style="color:green">For Ninja:</span>
** Debug builds are slow, but the easiest to use with a debugger.
** <code>cd</code> into the build folder that was just created (<code>MSVC2022_64_Ninja</code> 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.
** Release builds are fast, but cannot be effectively used with a debugger.
** Activate the correct MSVC environment in the current shell. Helper scripts are provided to make it easy to match the build you just configured:
** 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.
*** For Bash, use <code>source activate_msvc.sh</code>.
* 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 <code>ALL_BUILD</code> 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.)
*** For PowerShell, use <code>.\ActivateMSVC.ps1</code>.
* Develop.
*** For CMD, use <code>ActivateMSVC.bat</code>.
** Run <code>ninja</code> to build all targets, or add target names to build specific targets, e.g. <code>ninja openmw-cs</code>.
** With CMake older than 3.17.0, different build configurations need to be built by calling <code>ninja</code> in different folders. With newer CMake versions, they're all available in the same folder and you can build a specific configuration by adding <code> -f build-<configuration>.ninja</code> to the command, e.g. <code>ninja -f build-RelWithDebInfo.ninja openmw-cs</code> to build just the CS in the RelWithDebInfo configuration.
 
* <span style="color:maroon">For NMake:</span>
** <code>cd</code> into the build folder that was just created (<code>MSVC2022_64_NMake_Debug</code> 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 <code>source activate_msvc.sh</code>.
*** For PowerShell, use <code>.\ActivateMSVC.ps1</code>.
*** For CMD, use <code>ActivateMSVC.bat</code>.
** Run <code>nmake</code> to build all targets, or add target names to build specific targets, e.g. <code>nmake openmw-cs</code>.


=== If this doesn't work ===
=== If this doesn't work ===
Line 128: Line 183:
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:
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 <code>MSVC<year><_64></code> directory), simply delete it and use the script to regenerate it. You will get a new build environment using updated dependencies.
* If you don't have any particular reason to keep the existing build directory (the <code>MSVC<year><_64?><build system><configuration></code> 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:
* If you need to keep the build directory, the process is more involved:
** Delete the directory the dependency was extracted to (<code>MSVC<year><_64>/deps/<dependency name></code>)
** Delete the directory the dependency was extracted to (<code>build directory/deps/<dependency name></code>)
** Remove any lines mentioning the dependency from <code>MSVC<year><_64>/CMakeCache.txt</code>
** Remove any lines mentioning the dependency from <code>build directory/CMakeCache.txt</code>
** Run the script again.
** 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.


=== Previous versions of this guide ===
None of these are quite the same as official release builds - they have a different setting called [https://www.google.com/search?q=Link%20Time%20Optimization 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.


https://forum.openmw.org/viewtopic.php?f=6&t=4074 quick placeholder
Enabling LTO can be done by ticking a checkbox in the CMake GUI, or passing <code>-DOPENMW_LTO_BUILD=1</code> on the command line when configuring with CMake.


https://gist.github.com/ananace/de7f30454e99b3952405
''NOTE'': This setting only affects Release builds - it would hurt debuggability for RelWithDebInfo and Debug builds, undermining their whole purpose, so we keep it off for them.


==NMake 2013/2015/2017 scripted way==
To enable LTO for an existing build:
 
* Open the CMake GUI. This should show up if you type ''cmake gui'' into the Start menu.
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.
* 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).
=== What you need ===
* Press Generate.
 
* If using Visual Studio, it will then ask to reload the solution.
* Everything required for the above method, except you can optionally exclude the Visual Studio GUI and only install the build tools.
* Build again.
 
=== 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. <code>C:\OpenMW-dev\</code>) or you should enable long file paths in your registry (for example by following [https://www.howtogeek.com/266621/how-to-make-windows-10-accept-file-paths-over-260-characters/ this guide]).
* Clone the OpenMW repo. <code>git clone https://gitlab.com/OpenMW/openmw/</code> (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 <code>cd <directory path></code> 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 <code>bash</code> 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: <code>CI/before_script.msvc.sh -k -p Win64 -v 2017 -n</code>.
** Substitute Win64 with Win32 if doing a 32-bit build.
** 2017 can also be substituted with 2013 for the build tools provided with VS2013 or 2015 for those from VS2015
** '''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 <code> -c Release</code> to the command.
*** To set up RelWithDebInfo instead, add <code> -c RelWithDebInfo</code> to the command.
*** If we ever change the default, adding <code> -c Debug</code> 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 <code>cd</code> to navigate to the build folder that was just created (<code>MSVC2017_64_NMake_Debug</code> if you've used the build tools from VS 2017 and specified 64-bit and the Debug configuration).
* Develop
* Use <code>nmake <target name></code> build a target. If no target name is specified, all will be built.
 
 
==Visual Studio 2008/2010/2012/2013==
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 2008/2010/2012/2013 - normal or free (C++) express versions. Note that if you use Visual Studio 2012 or newer you will have to build Qt yourself.
* CMake: [http://www.cmake.org/cmake/resources/software.html CMake] at least v2.8, but grab the latest stable release.
* Git - Our version control software: [http://code.google.com/p/msysgit/downloads/list Git] at least v1.8.x, but grab the latest stable release.
 
===Libraries===
 
<i>(Needs updating, +osg)</i>
* [http://sourceforge.net/projects/boost/files/boost-binaries/ Boost]: Use the installer for your Visual Studio version and set the environment variable '''BOOST_ROOT''' to the <install_path>.
* [http://www.bulletphysics.com/ 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 <install_path\lib\Release> folder, strip the ending off (like _vs2010) and set the environment variable '''BULLET_ROOT''' to the <install_path>.
* [http://gnuwin32.sourceforge.net/downlinks/freetype.php Freetype]:  Freetype2, and set the environment variable '''FREETYPE_DIR''' to the <install_path>.
* [http://www.ogre3d.org/tikiwiki/MyGUI MyGUI]: Download and build following compilation instructions and set the '''MYGUI_HOME''' environment variable.
* [http://kcat.strangesoft.net/misc-downloads/ OpenAL]: Download OpenAL11CoreSDK and set the environment variable '''OPENALDIR'''.
* [http://qt-project.org/downloads 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
* [https://code.google.com/p/msinttypes/ msinttypes] Download and extract to your visual studio 'install_root\VC\include' directory and overwrite the files there. This will give you C99 compliant inttypes.  This is only required for building FFmpeg and not required for Visual Studio 2012 or later.
* [http://ffmpeg.zeranoe.com/builds/ 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)
* [http://www.libsdl.org/download-2.0.php SDL2] Download and extract the SDL2 VS "Development Libraries". [http://www.libsdl.org/release/SDL2-devel-2.0.1-VC.zip 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:
 
<syntaxhighlight lang="dos">
BOOST_ROOT  D:\sdk\boost-1.55
BULLET_ROOT D:\sdk\bullet
FFMPEG_HOME D:\sdk\ffmpeg
MYGUI_HOME  D:\sdk\MyGUI_3.2.0
OPENALDIR  D:\sdk\OpenAL
QTDIR      D:\build\qt-4.8
SDL2DIR    D:\sdk\SDL2
</syntaxhighlight>
 
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 <BULLET_ROOT>\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.
 
<syntaxhighlight lang="dos">
set(SDL2_BUILDING_LIBRARY ON)
find_package(SDL2 REQUIRED)
</syntaxhighlight>
 
===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.
 
<syntaxhighlight lang="dos">
"<Cmake's Install Directory>\bin\cmake.exe" ..\openmw -G "Visual Studio 9 2008"
</syntaxhighlight>
 
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)
 
===Git on Windows===
 
====via Cygwin====
 
Git is available on Windows via [http://www.cygwin.com/ 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 [http://code.google.com/p/msysgit/ 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 [http://code.google.com/p/tortoisegit/ 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 [http://www.eclipse.org/egit/ egit plugin]. Install it, restart eclipse, "file -> import -> git -> clone"


=Linux=
=Linux=
Line 269: Line 218:
Information about building packages from the Arch User Repository (AUR) can be found at the [http://wiki.archlinux.org/index.php/Arch_User_Repository Arch wiki].
Information about building packages from the Arch User Repository (AUR) can be found at the [http://wiki.archlinux.org/index.php/Arch_User_Repository Arch wiki].


===Ubuntu===
===Debian and Ubuntu===


====Key requirements====
====Key requirements====
Line 291: Line 240:
<syntaxhighlight lang="bash">
<syntaxhighlight lang="bash">


  sudo apt-get install git libopenal-dev libopenscenegraph-3.4-dev \
  sudo apt-get install git build-essential cmake \
  libsdl2-dev libqt4-dev libboost-filesystem-dev libboost-thread-dev \
libopenal-dev libopenscenegraph-dev libbullet-dev libsdl2-dev \
  libboost-program-options-dev libboost-system-dev \
  libmygui-dev libunshield-dev liblz4-dev libtinyxml-dev libqt5opengl5-dev \
  libboost-filesystem-dev libboost-program-options-dev libboost-iostreams-dev \
  libavcodec-dev libavformat-dev libavutil-dev libswscale-dev libswresample-dev \
  libavcodec-dev libavformat-dev libavutil-dev libswscale-dev libswresample-dev \
  libbullet-dev libmygui-dev libunshield-dev cmake build-essential \
  librecast-dev libluajit-5.1-dev libsqlite3-dev libyaml-cpp-dev libcollada-dom-dev \
  libqt4-opengl-dev
  qttools5-dev


</syntaxhighlight>
</syntaxhighlight>
===Debian Stretch===
Debian Stretch has all the packages necessary to build OpenMW.
====Install OpenMW dependencies====
sudo apt-get install git libopenal-dev libopenscenegraph-3.4-dev \
libsdl2-dev libqt4-dev libboost-filesystem-dev libboost-thread-dev \
libboost-program-options-dev libboost-system-dev \
libavcodec-dev libavformat-dev libavutil-dev libswscale-dev libswresample-dev \
libbullet-dev libmygui-dev libunshield-dev cmake build-essential \
libqt4-opengl-dev


<!-- TODO UPDATE
<!-- TODO UPDATE
Line 356: Line 295:


Because some dependencies of OpenMW are not in the Fedora Workstation repositories, you need to [http://rpmfusion.org/Configuration/ enable RPMFusion] free and non-free repositories which provide packages for the missing dependencies.
Because some dependencies of OpenMW are not in the Fedora Workstation repositories, you need to [http://rpmfusion.org/Configuration/ 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:
<syntaxhighlight lang="bash">
sudo dnf groupinstall development-tools
sudo dnf install openal-devel OpenSceneGraph-devel OpenSceneGraph-Collada SDL2-devel \
qt6-qtbase-devel qt6-linguist boost-devel boost-filesystem boost-thread boost-program-options \
boost-system boost-iostreams ffmpeg-devel ffmpeg-libs bullet-devel tinyxml-devel lz4-devel \
cmake luajit-devel sqlite-devel gtest-devel gmock-devel yaml-cpp-devel libXt-devel
</syntaxhighlight>
While this list of packages is technically up-to-date, you'll run into problems if you don't get [https://github.com/MyGUI/mygui MyGUI]
and [https://github.com/twogood/unshield unshield] libraries.
First try doing that:
<syntaxhighlight lang="bash">
sudo dnf install mygui-devel unshield-devel
</syntaxhighlight>
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 2024, you are probably using Fedora 38 or newer and it 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:
<syntaxhighlight lang="bash">
sudo dnf install freetype-devel
</syntaxhighlight>
and then you can follow the fetching source and building instructions from below for both.
You must keep the MyGUI notes 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 [https://github.com/bulletphysics/bullet3 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.
===openSUSE Tumbleweed===


====Packages====
====Packages====
Line 361: Line 368:


To setup a build environment and install all dependencies type:
To setup a build environment and install all dependencies type:
<!-- Haven't tested this on a clean install. There's probably more packages to add. -->
<!-- Change to ffmpeg-5-* when 0.48 releases -->
<syntaxhighlight lang="bash">
<syntaxhighlight lang="bash">
sudo zypper in git cmake \
ffmpeg-6-lib{avcodec,avformat,avutil,swscale,swresample}-devel \
libbullet-devel unshield-devel libOpenSceneGraph-devel OpenSceneGraph-plugins \
libboost_{filesystem,program_options,iostreams}-devel \
libXt-devel \
MyGUI-devel SDL2-devel luajit-devel \
qt6-base-devel qt6-wayland \
doxygen sqlite3-devel yaml-cpp-devel


sudo dnf groupinstall development-tools;
</syntaxhighlight>
sudo dnf install openal-devel OpenSceneGraph-qt-devel SDL2-devel qt4-devel \
boost-filesystem git boost-thread boost-program-options boost-system ffmpeg-devel \
ffmpeg-libs bullet-devel gcc-c++ mygui-devel unshield-devel tinyxml-devel cmake


</syntaxhighlight>
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==
==Fetching the source==
Line 404: Line 418:
<syntaxhighlight lang="bash">
<syntaxhighlight lang="bash">
make -j`getconf _NPROCESSORS_ONLN`
make -j`getconf _NPROCESSORS_ONLN`
</syntaxhighlight>
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
<syntaxhighlight>
#removes just package
apt-get remove <yourOSGversion>
#or
#removes configurations as well
apt-get remove --purge <yourOSGversion>
</syntaxhighlight>
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:
<syntaxhighlight>
/usr/lib
/usr/local/library
/usr/lib/<cpu_architecture>-linux-gnu
</syntaxhighlight>
</syntaxhighlight>


Line 410: Line 449:
== Prerequisites ==
== Prerequisites ==


You must have recent version (7.0 or higher) of [https://itunes.apple.com/us/app/xcode/id497799835?mt=12 Xcode] & Xcode command line tools.
OpenMW requires C++20 in order to compile. If you've got macOS 11.0 or later, you can use the [https://itunes.apple.com/us/app/xcode/id497799835 Xcode] provided compiler (clang) You will also need the Xcode comand line tools.  
 
Miminal macOS version is determined by minimal Xcode version. Supported deployment target is 10.8.


CMake & pkg-config are required. You can install these via [https://brew.sh Homebrew]:
CMake & pkg-config are required. You can install these via [https://brew.sh Homebrew]:
Line 423: Line 460:
== Dependencies ==
== Dependencies ==


The easiest way to handle OpenMW dependencies is to use [https://github.com/OpenMW/openmw-deps-mac OpenMW-deps-Mac], 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 [https://downloads.openmw.org/osx/dependencies/ here].
The easiest way to handle OpenMW dependencies is to use [https://gitlab.com/OpenMW/openmw-dep 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 [https://downloads.openmw.org/osx/dependencies/?C=M&O=D here].


=== Qt ===
=== Qt ===


Supported Qt version for macOS builds is 5.5.1. Newer versions require C++11 to be enabled.
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.
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.
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.


<pre>
<pre>
$ brew install qt@5.5
$ brew install qt@5
</pre>
</pre>


It's recommended, however, to use [https://download.qt.io/archive/qt/5.5/5.5.1/qt-opensource-mac-x64-clang-5.5.1.dmg package] from Qt Project site if you're planning to deploy your builds to other machines.
It's recommended, however, to use [https://download.qt.io/archive/qt package] from Qt Project site if you're planning to deploy your builds to other machines.
 
=== liblz4 ===
 
This can be installed via brew
 
<pre>
$ brew install lz4
</pre>
 
=== ICU ===
 
This can be installed via brew
 
<pre>
$ brew install icu4c
</pre>
 
=== yaml-cpp ===
 
This can be installed via rew
 
<pre>
$ brew install yaml-cpp
</pre>
 
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).
 
=== Bullet ===
 
As of macOS 14.3 and circa 2024, <tt>brew install bullet</tt> provides a build of bullet that does not include double-precision support enabled.
 
You'll have to build [https://github.com/bulletphysics/bullet3 Bullet] from source. Make sure to enable double-precision in Bullet's CMake (USE_DOUBLE_PRECISION). As of February 2024, the Bullet repo includes a handy <tt>./build_cmake_pybullet_double.sh</tt> which will build Bullet with the proper CMake flag for 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.


== Build ==
== Build ==
Line 452: Line 527:
<pre>$ cmake \
<pre>$ cmake \
     -D CMAKE_PREFIX_PATH="$PATH_TO_DEPENDENCIES_DIR;$PATH_TO_QT_INSTALLATION" \
     -D CMAKE_PREFIX_PATH="$PATH_TO_DEPENDENCIES_DIR;$PATH_TO_QT_INSTALLATION" \
    -D CMAKE_OSX_SYSROOT="$MAC_OS_VERSION" \
    -D DESIRED_QT_VERSION=5 \
     -D CMAKE_BUILD_TYPE=Debug \
     -D CMAKE_BUILD_TYPE=Debug \
    -D BUILD_MYGUI_PLUGIN=FALSE \
     -G"Unix Makefiles" \
     -G"Unix Makefiles" \
     ../openmw/</pre>
     ../openmw/</pre>


Where <tt>$PATH_TO_DEPENDENCIES_DIR</tt> and <tt>$PATH_TO_QT_INSTALLATION</tt> are directories listed earlier in this guide. <tt>$PATH_TO_DEPENDENCIES_DIR</tt> is a directory like "openmw-deps" containing "lib" and "include" sub-directories, and <tt>$PATH_TO_QT_INSTALLATION</tt> is a path to a Qt 5.5.1 installation (for example <tt>~/Qt/Qt5.5.1/5.5/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.
Where <tt>$PATH_TO_DEPENDENCIES_DIR</tt> and <tt>$PATH_TO_QT_INSTALLATION</tt> are directories listed earlier in this guide. <tt>$PATH_TO_DEPENDENCIES_DIR</tt> is a directory like "openmw-deps" containing "lib" and "include" sub-directories, and <tt>$PATH_TO_QT_INSTALLATION</tt> is a path to a Qt 5.15.2 installation (for example <tt>~/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.


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


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


Then build:
Then build:
Line 487: Line 557:
<pre>$ cmake \
<pre>$ cmake \
     -D CMAKE_PREFIX_PATH="$PATH_TO_DEPENDENCIES_DIR;$PATH_TO_QT_INSTALLATION" \
     -D CMAKE_PREFIX_PATH="$PATH_TO_DEPENDENCIES_DIR;$PATH_TO_QT_INSTALLATION" \
    -D CMAKE_OSX_SYSROOT="$MAC_OS_VERSION" \
     -D CMAKE_OSX_DEPLOYMENT_TARGET="10.15" \
     -D CMAKE_OSX_DEPLOYMENT_TARGET="10.9" \
    -D DESIRED_QT_VERSION=5 \
     -D CMAKE_BUILD_TYPE=Release \
     -D CMAKE_BUILD_TYPE=Release \
    -D BUILD_ESMTOOL=FALSE \
    -D BUILD_MYGUI_PLUGIN=FALSE \
     -D OPENMW_OSX_DEPLOYMENT=TRUE \
     -D OPENMW_OSX_DEPLOYMENT=TRUE \
     -G"Unix Makefiles" ../openmw/</pre>
     -G"Unix Makefiles" ../openmw/</pre>
Line 506: Line 572:


== Troubleshooting ==
== 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.9 or higher (older versions could work too, but we're unable to test on them).
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
Umbrella script: https://gitlab.com/OpenMW/openmw/blob/master/.travis.yml
Line 513: Line 579:


Build: https://gitlab.com/OpenMW/openmw/blob/master/CI/before_script.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:
<pre>
  $ brew install llvm
</pre>
Then specify to cmake that you want it to use brew llvm via export:
<pre>
$ export CC="/usr/local/opt/llvm/bin/clang"
$ export CCX="/usr/local/opt/llvm/bin/clang++"
$ export CPPFLAGS="-I/usr/local/opt/llvm/include"
</pre>
or via cmake parameters. In such case, make sure that you apply the CPPFLAGS after the "stdlib=libc++" one i.e.,
<pre>
  -D CMAKE_CXX_FLAGS="-stdlib=libc++ -I/usr/local/opt/llvm/include"
</pre>
You also have to make sure to use the ICU version provided by brew
<pre>
-D ICU_ROOT="/usr/local/opt/icu4c"
</pre>


=Data=
=Data=


For a detailed description of how to obtain the data files check [[Installation_Instructions#Install_Game_Files]].
For a detailed description of how to obtain the data files check [[Installation_Instructions#Install_Game_Files]].

Latest revision as of 00:04, 7 March 2024

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 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.

General notes on dependencies

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:

cmake .. -DMYGUI_RENDERSYSTEM=1 -DMYGUI_BUILD_DEMOS=OFF -DMYGUI_BUILD_TOOLS=OFF -DMYGUI_BUILD_PLUGINS=OFF

As of 0.49.0, the minimum MyGUI version requirement has been bumped to 3.4.3 and linking MyGUI requires it to have been built with MYGUI_DONT_USE_OBSOLETE=ON.

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 3.6.5 or newer.

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 <library path>/osgPlugins-<OSG_VERSION>.

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 (cinst ninja 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 (cinst visualstudio2022buildtools or cinst visualstudio2019buildtools 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 (cinst ninja if you have Chocolatey).
  • VSWhere in your path if you're using Ninja or NMake.
    • cinst vswhere 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 (cinst git.install 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
    • cinst 7zip.install 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
    • cinst cmake.install --installargs 'ADD_CMAKE_TO_PATH=User' 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 ADD_CMAKE_TO_PATH=User for ADD_CMAKE_TO_PATH=System.
    • 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
    • cinst python 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 <version> 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 python.exe 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. C:\OpenMW-dev\) or you should enable long file paths in your registry (for example by following this guide).
  • Clone the OpenMW repo. git clone https://gitlab.com/OpenMW/openmw/ (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: CI/before_script.msvc.sh -k -p Win64 -v 2022.
    • If you're using Ninja, add -N to the command.
    • If you're using NMake, add -n to the command.
    • Substitute Win64 with Win32 if doing a 32-bit build. This is no longer supported, but you might be able to bodge it if you build deps yourself.
    • 2022 can also be substituted with 2019 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 -c Release to the command.
      • To set up RelWithDebInfo, add -c RelWithDebInfo to the command.
      • If we ever change the default, adding -c Debug 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 -P. Alternatively, you can tell your debugger to use https://openmw-sym.rgw.ctrl-c.liu.se as a symbol server, and they'll be fetched on demand.
    • If you want to build the unit tests, add -t.
    • Other, more niche, options exist, and are documented in the script's help text, available by running CI/before_script.msvc.sh -h
  • Wait for the build environment to be set up.
  • For Solution files:
    • Go to the build folder that was just created (MSVC2022_64 if you've used VS 2022 and specified 64-bit) and open OpenMW.sln.
    • 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 ALL_BUILD 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:
    • cd into the build folder that was just created (MSVC2022_64_Ninja 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 source activate_msvc.sh.
      • For PowerShell, use .\ActivateMSVC.ps1.
      • For CMD, use ActivateMSVC.bat.
    • Run ninja to build all targets, or add target names to build specific targets, e.g. ninja openmw-cs.
    • With CMake older than 3.17.0, different build configurations need to be built by calling ninja in different folders. With newer CMake versions, they're all available in the same folder and you can build a specific configuration by adding -f build-<configuration>.ninja to the command, e.g. ninja -f build-RelWithDebInfo.ninja openmw-cs to build just the CS in the RelWithDebInfo configuration.
  • For NMake:
    • cd into the build folder that was just created (MSVC2022_64_NMake_Debug 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 source activate_msvc.sh.
      • For PowerShell, use .\ActivateMSVC.ps1.
      • For CMD, use ActivateMSVC.bat.
    • Run nmake to build all targets, or add target names to build specific targets, e.g. nmake openmw-cs.

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 MSVC<year><_64?><build system><configuration> 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 (build directory/deps/<dependency name>)
    • Remove any lines mentioning the dependency from build directory/CMakeCache.txt
    • 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 -DOPENMW_LTO_BUILD=1 on the command line when configuring with CMake.

NOTE: This setting only affects Release builds - it would hurt debuggability for RelWithDebInfo and Debug builds, undermining their whole purpose, so we keep it off for them.

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.

Linux

Installing Dependencies

Arch

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

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

Debian and Ubuntu

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:

sudo add-apt-repository ppa:openmw/openmw

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

sudo apt-get update

Packages

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

To setup a build environment and install all dependencies type:

 sudo apt-get install git build-essential cmake \
 libopenal-dev libopenscenegraph-dev libbullet-dev libsdl2-dev \
 libmygui-dev libunshield-dev liblz4-dev libtinyxml-dev libqt5opengl5-dev \
 libboost-filesystem-dev libboost-program-options-dev libboost-iostreams-dev \
 libavcodec-dev libavformat-dev libavutil-dev libswscale-dev libswresample-dev \
 librecast-dev libluajit-5.1-dev libsqlite3-dev libyaml-cpp-dev libcollada-dom-dev \
 qttools5-dev


Fedora Workstation

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:

sudo dnf groupinstall development-tools
sudo dnf install openal-devel OpenSceneGraph-devel OpenSceneGraph-Collada SDL2-devel \
qt6-qtbase-devel qt6-linguist boost-devel boost-filesystem boost-thread boost-program-options \
boost-system boost-iostreams ffmpeg-devel ffmpeg-libs bullet-devel tinyxml-devel lz4-devel \
cmake luajit-devel sqlite-devel gtest-devel gmock-devel yaml-cpp-devel libXt-devel

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:

sudo dnf install mygui-devel unshield-devel

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 2024, you are probably using Fedora 38 or newer and it 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:

sudo dnf install freetype-devel

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

You must keep the MyGUI notes 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.

openSUSE Tumbleweed

Packages

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

To setup a build environment and install all dependencies type:

sudo zypper in git cmake \
ffmpeg-6-lib{avcodec,avformat,avutil,swscale,swresample}-devel \
libbullet-devel unshield-devel libOpenSceneGraph-devel OpenSceneGraph-plugins \
libboost_{filesystem,program_options,iostreams}-devel \
libXt-devel \
MyGUI-devel SDL2-devel luajit-devel \
qt6-base-devel qt6-wayland \
doxygen sqlite3-devel yaml-cpp-devel

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: [2], or get the latest git snapshot:

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

 cd openmw

Building

With make

Note that this is an out-of-source build. Generally, this is the preferred method when working with cmake.

 mkdir build
 cd build
 cmake ../

This creates a regular makefile.

Now we can start compiling. Normally you can just run

make

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

make -j`getconf _NPROCESSORS_ONLN`

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

#removes just package
apt-get remove <yourOSGversion>

#or 

#removes configurations as well
apt-get remove --purge <yourOSGversion>


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:

/usr/lib
/usr/local/library
/usr/lib/<cpu_architecture>-linux-gnu

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).

Bullet

As of macOS 14.3 and circa 2024, brew install bullet provides a build of bullet that does not include double-precision support enabled.

You'll have to build Bullet from source. Make sure to enable double-precision in Bullet's CMake (USE_DOUBLE_PRECISION). As of February 2024, the Bullet repo includes a handy ./build_cmake_pybullet_double.sh which will build Bullet with the proper CMake flag for 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.

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 is a directory like "openmw-deps" containing "lib" and "include" sub-directories, and $PATH_TO_QT_INSTALLATION is a path to a Qt 5.15.2 installation (for example ~/Qt/Qt5.15.2/5.15/clang_64/lib/cmake). 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" \ where $MAC_OS_VERSION is the version of macOS in the format macosx10.##. For instance, if you are running macOS 10.13 (High Sierra), $MAC_OS_VERSION would need to be set to macosx10.13.

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

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 to TRUE:

$ 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#Install_Game_Files.