edit Compiling Wesnoth
This page covers compilation on a Unix-like system. See also:
- Compiling Wesnoth on Windows
- Compiling Wesnoth on FreeBSD
- Compiling Wesnoth on Mac OS X
- Compiling Wesnoth on Syllable
- Wesnoth on Linux PDAs
- Compiling Wesnoth on SuSE -For install on SuSE 10.0
Forcemstr has cross compiled for Windows using the free mingw32 tools, running under Linux.
Here's documentation of another cross compilation attempt: CompilingWesnoth/CrossCompiling
For detailed instructions and full prerequisites, please consult the current INSTALL file in the source code.
You need a C++ compiler (such as gcc).
You must have the following libraries installed on your system. Many Linux distributions split development packages from libraries. If so, you need to have the development packages to build Wesnoth (the -dev packages include the header files which are required to build packages from source). You will also need the runtime packages to actually run Wesnoth.
- libsdl >= 1.2.7 (http://www.libsdl.org/)
- Note that there is a known bug with SDL 1.2.14 that can be solved by downgrading to 1.2.13.
- sdl-image-1.2 >= (with PNG support) (http://www.libsdl.org/projects/SDL_image)
- sdl-mixer >= 1.2 (with Vorbis support) (http://www.libsdl.org/projects/SDL_mixer)
- sdl-net (http://www.libsdl.org/projects/SDL_net)
- sdl-ttf >= 2.0.8 (http://www.libsdl.org/projects/SDL_ttf)
- libintl (and other libraries found in gettext package) (http://www.gnu.org/software/gettext/gettext.html)
- libboost >= 1.36.0 (http://www.boost.org/)
- If your distro splits boost, you need: boost_iostreams, boost_regex, boost_serialization, boost_asio, boost_program_options, boost_system, boost_thread.
- You need gzip support in boost_iostreams.
- zlib (in theory already needed for libsdl-image, http://www.zlib.org/)
- pangocairo >= 1.14.8 (http://www.pango.org/)
- libfontconfig >= 2.4.1 (http://fontconfig.org/wiki/)
The following libraries are optional.
- libdbus-1 (only required desktop notifications, http://www.freedesktop.org/wiki/Software/dbus)
- fribidi >= 0.10.9 (only required for RTL languages)
To be able to build things, you will need a build tool, either
- scons >=0.98.3 (http://www.scons.org/)
- cmake >=2.6 (http://www.cmake.org/)
On all linux distributions that are based on Debian (like eg Ubuntu) it should be enough to use this command (if your distribution ships a recent version of Wesnoth, otherwise dependencies might be outdated and you have to install the respective dependencies by hand, i.e. if your distribution does only ship wesnoth-1.6 you won't get the build dependencies for 1.8 with the following command):
sudo apt-get build-dep wesnoth
To make sure Wesnoth 1.10 builds, you might need this:
sudo apt-get install libboost1.40-all-dev
The following command will install most prerequisites for openSuSE 12.1, wesnoth 1.10.1. All dependencies are in the standard OSS repository.
zypper install libSDL-devel gettext-runtime zlib-devel cairo-devel fontconfig-devel cmake make libSDL_mixer-devel libSDL_image-devel libSDL_net-devel libSDL_ttf-devel gettext-tools boost-devel libSDL_Pango-devel lua-devel dbus-1-devel
You can get it here:
If any config checks fail, look in the respective log files (eg in build/config.log when using scons) for details. When using scons, a check can spuriously fail due to caching. If this happens, please use --config=force to force its rerun.
Building with SCons
To build using SCons, simply type
in the Wesnoth top-level directory. This will perform the equivalent of "configure --enable-editor --enable-tools; make" under autotools, buiding all client-side tools. To find out more about build options, type
$ scons --help
Equivalents of many configure options will be available, and you can easily build individual targets such as wesnothd.
Because scons checks for out-of-dateness with MD5 checksums of a target's ancestors and its build environment (including compiler and linker flags), the "make clean" and "make uninstall" preliminaries that you need for safety under autotools won't be necessary.
Building with CMake
CMake supports so called "out of tree" builds. That is you compile in a place completely different from the folder where your checkout is in. To do so, simply create a folder to compile in and call cmake with the path to your checkout. Of course you can also just call cmake from the checkout folder with a plain cmake ., but this is boring, isn't it?
To have cmake build wesnoth in a new dir called cmake_build_dir, just use these commands (PATH/TO/WESNOTH/TOPLEVEL-DIR means the base of your repository checkout or the folder where you extracted the tarball to, not src/ in there!):
$ mkdir cmake_build_dir $ cd cmake_build_dir $ cmake PATH/TO/WESNOTH/TOPLEVEL-DIR
This will perform the equivalent of "configure --enable-editor --enable-server" under autotools. To get an interface for editing settings, just type
$ ccmake .
in the cmake_build_dir. When done with your changes hit 'c' to configure and 'g' to generate the files and exit. In general you can either add commands to your cmake PATH/TO/WESNOTH/TOPLEVEL-DIR call, or change the parameters later on via ccmake or a cmake gui. Equivalents of many configure options are be available.
In the 2nd step you just have to build the game. This is done as with autotools using
This by default builds all the targets you activated. If you want to you can also just build specific targets like wesnothd.
Because CMake checks for out-of-dateness, the "make clean" and "make uninstall" preliminaries that you need for safety under autotools won't be necessary.
Become superuser, so that you have permission to install.
$ su Password: /*doesn't show*/
Now that you have permission, install it.
Installing using SCons
If you are using SCons:
# scons install
Installing using CMake
If you are using CMake, installing basically happens the same way as when using autotools. When authorized as admin (see above), just type this:
# make install
Running the game without installing
After compiling it is also possible to just run the game without installing it. All you have to do is execute the compiled binary and provide the path to the data location as argument. This looks eg like this:
$ ./wesnoth .
or, if you compiled outside the place where you have your repository checkout or the extracted tarball (lets assume this content lies in ../wesnoth-1.8):
$ ./wesnoth ../wesnoth-1.8/