shadowm

Untitled

Apr 7th, 2015
286
0
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 8.93 KB | None | 0 0
  1. Contents
  2. ========
  3.  
  4. 1. Prerequisites
  5. 2. Build Environment
  6. 3. SCons Build
  7. 4. CMake Build
  8. 5. Build Options
  9.  
  10.  
  11. 1. Prerequisites
  12. ================
  13.  
  14. You'll need to have these libraries and their development headers installed in
  15. order to build Wesnoth:
  16.  
  17. * Boost libraries:
  18. * Filesystem >= 1.44.0
  19. * Locale >= 1.48.0
  20. * Iostreams >= 1.36.0
  21. * Multi-index >= 1.36.0 (header only)
  22. * Random >= 1.48.0
  23. * Regex >= 1.36.0
  24. * Serialization >= 1.36.0 (header only)
  25. * Asio >= 1.36.0 (header only)
  26. * Program Options >= 1.36.0
  27. * System >= 1.36.0
  28. * SDL libraries:
  29. * SDL >= 1.2.10
  30. * SDL_image >= 1.2.0 (with PNG and JPEG support)
  31. * SDL_mixer >= 1.2.12 (with Ogg Vorbis support)
  32. * SDL_ttf >= 2.0.8
  33. * SDL_net
  34. * Fontconfig >= 2.4.1
  35. * Pango >= 1.21.3 (with Cairo backend)
  36. * Vorbisfile
  37. * libbz2
  38. * libz
  39.  
  40. The following libraries are optional dependencies that enable additional
  41. features:
  42.  
  43. * libpng:
  44. PNG screenshots, otherwise only BMP is supported.
  45.  
  46. * D-Bus (libdbus-1):
  47. Desktop notifications on Linux, *BSD, etc.
  48.  
  49. * GNU history (libreadline):
  50. Command history and history expansion in the built-in Lua console.
  51.  
  52. Note that although different Boost version requirements are listed, individual
  53. libraries from different releases are generally incompatible with each other
  54. and you should not mix and match.
  55.  
  56. Also note that SDL 1.2.14 is known to have problems on Windows, so we advise
  57. you to use SDL 1.2.15 instead.
  58.  
  59. Although not recommended, you may use libintl on platforms other than Windows
  60. instead of Boost.Locale. For scons, set the `libintl` option to `true`.
  61.  
  62.  
  63. 2. Build Environment
  64. ====================
  65.  
  66. You can obtain the source code tarball for the latest version from
  67. <http://www.wesnoth.org/downloads>.
  68.  
  69. Before building, make sure to untar the package and change into the newly
  70. created directory:
  71.  
  72. $ tar xvJf wesnoth-<version>.tar.xz
  73. $ cd wesnoth-<version>
  74.  
  75. The following build systems are fully supported for compiling Wesnoth on Linux,
  76. *BSD, and other Unix-like platforms:
  77.  
  78. * SCons >= 0.98.3
  79. * CMake >= 2.6.0
  80.  
  81. You will also need to have a working installation of GNU gettext to build the
  82. translations.
  83.  
  84. While Wesnoth may be easily installed system-wide using SCons or CMake, it is
  85. also possible to run it directly from the source directory after building. This
  86. may be useful in situations where you don't have root access or need to
  87. rebuild Wesnoth frequently (i.e. for development and testing).
  88.  
  89. NOTE: It has been reported that using GCC 3.3.6 and earlier versions with
  90. optimizations enabled will result in a build that is incapable of using
  91. multiplayer. See <https://gna.org/bugs/?10326> for further details. We
  92. recommend using GCC 4.x to build Wesnoth.
  93.  
  94.  
  95. 3. SCons Build
  96. ==============
  97.  
  98. Unlike CMake or the classic "autotools" build-system (configure && make),
  99. configuration and building are done in the same step with SCons.
  100.  
  101. Simply type `scons` in the top-level directory to build the game client and
  102. MP server:
  103.  
  104. $ scons
  105.  
  106. It is possible to select individual targets to build by naming them in the
  107. command line separated by spaces.
  108.  
  109. To build the game client only:
  110.  
  111. $ scons wesnoth
  112.  
  113. Building the MP server only:
  114.  
  115. $ scons wesnothd
  116.  
  117. The `install` target will install any binaries that were previously compiled
  118. (use su or sudo if necessary to write files into the installation prefix):
  119.  
  120. # scons install
  121.  
  122. SCons takes a `prefix=` argument that specifies where to install the game and
  123. its resource files. The prefix defaults to `/usr/local`; for production builds,
  124. you may wish to use `/usr` instead:
  125.  
  126. $ scons prefix=/usr
  127.  
  128.  
  129. 4. CMake Build
  130. ==============
  131.  
  132. Unlike SCons, CMake has separate configuration and build steps. Configuration
  133. is done using CMake itself, and build is done using `make`.
  134.  
  135. There are two ways to build Wesnoth with CMake: inside the source tree or
  136. outside of it. Out-of-source builds have the advantage that you can have
  137. multiple builds with different options from one source directory.
  138.  
  139. To build Wesnoth out of source:
  140.  
  141. $ mkdir build && cd build
  142. $ cmake .. -DCMAKE_BUILD_TYPE=Release
  143. $ make
  144.  
  145. To build Wesnoth in the source directory:
  146.  
  147. $ cmake . -DCMAKE_BUILD_TYPE=Release
  148. $ make
  149.  
  150. To install Wesnoth after building (as root using su or sudo if necessary):
  151.  
  152. # make install
  153.  
  154. To change build options, you can either pass the options on the command line:
  155.  
  156. $ cmake .. -DOPTION_NAME=option_value
  157.  
  158. Or use either the `ccmake` or `cmake-gui` front-ends, which display all options
  159. and their cached values on a console and graphical UI, respectively.
  160.  
  161. $ ccmake ..
  162. $ cmake-gui ..
  163.  
  164.  
  165. 5. Build Options
  166. ================
  167.  
  168. A full list of options supported by SCons along with their descriptions and
  169. defaults is available by running `scons --help` from the Wesnoth source. For
  170. CMake, you may either run the `ccmake` or `cmake-gui` front-ends, or run
  171. `cmake` and open the generated CMakeCache.txt from the build directory in a
  172. text editor.
  173.  
  174. $ scons option_name1=option_value1 [option_name2=option_value2 [...]]
  175. $ cmake -DOPTION_NAME1=option_value1 [-DOPTION_NAME2=option_value2 [...]]
  176.  
  177. With SCons, boolean options take `yes` or `true` for a true value, and `no` or
  178. `false` for a false value. CMake uses `ON` for a true value, and `OFF` for a
  179. false value.
  180.  
  181. Some of the most important options follow.
  182.  
  183. * build=<build type> (SCons)
  184. CMAKE_BUILD_TYPE=<build type> (CMake)
  185.  
  186. Selects a specific build configuration when compiling. `release` produces
  187. the default, optimized (-O2) build for regular use. `debug` produces a
  188. slower and larger unoptimized (-O0) build with full debug symbols, which is
  189. often needed for obtaining detailed backtraces when reporting bugs.
  190.  
  191. NOTE: By default, CMake will produce `debug` builds unless a different
  192. configuration option is passed in the command line.
  193.  
  194. * ENABLE_GAME=<boolean> (CMake)
  195.  
  196. Whether to build the game client binary. Use command line target selection
  197. selection with SCons instead.
  198.  
  199. * ENABLE_SERVER=<boolean> (CMake)
  200.  
  201. Whether to build the MP server binary. Use command line target selection
  202. selection with SCons instead.
  203.  
  204. * prefix=<full path> (SCons)
  205. CMAKE_INSTALL_PREFIX=<full path> (CMake)
  206.  
  207. Installation prefix for binaries, resources, and documentation files.
  208.  
  209. * nls=<boolean> (SCons)
  210. ENABLE_NLS=<boolean> (CMake)
  211.  
  212. Whether to compile and install translations.
  213.  
  214. * strict=<boolean> (SCons)
  215. ENABLE_STRICT_COMPILATION=<boolean> (CMake)
  216.  
  217. Whether to treat compiler warnings as errors or not. Primarily intended for
  218. developers.
  219.  
  220. * prefsdir=<directory name> (SCons)
  221. PREFERENCES_DIR=<directory name> (CMake)
  222.  
  223. Hardcoded user preferences and user data directory. The default is to leave
  224. this unspecified so that Wesnoth will use separate XDG paths such as
  225. .config/wesnoth and .local/share/wesnoth/<version> for its user preferences
  226. and data, respectively.
  227.  
  228. * cxxtool=<program> (SCons)
  229. CMAKE_CXX_COMPILER=<program> (CMake)
  230.  
  231. Specifies which C++ compiler to use. By default, the system's default C++
  232. compiler will be automatically selected during configuration.
  233.  
  234. * ccache=<boolean> (SCons)
  235.  
  236. Whether to run the compiler through ccache first. Useful if the compiler
  237. executable is not a symbolic link to ccache. Requires ccache to be
  238. installed first.
  239.  
  240. If using CMake, use CMAKE_CXX_COMPILER instead.
  241.  
  242. * extra_flags_<buildtype>=<flags> (SCons)
  243. extra_flags_config=<flags> (SCons)
  244. CXX_FLAGS_USER=<flags> (CMake)
  245.  
  246. Additional compiler flags to use when compiling a specific build type
  247. (SCons-only). To apply the same flags to all builds, use extra_flags_config
  248. (SCons) or CXX_FLAGS_USER (CMake) without a build type suffix.
  249.  
  250. Alternatively, you may specify your flags in the CXXFLAGS environment
  251. variable.
  252.  
  253. * fifodir=<full path> (SCons)
  254. FIFO_DIR=<full path> (CMake)
  255.  
  256. server_uid=<UID> server_gid=<GID> (SCons)
  257. SERVER_UID=<UID> SERVER_GID=<GID> (CMake)
  258.  
  259. Directory and owner id for the wesnothd control FIFO file. This is relevant
  260. only if you wish to be able to communicate with a local wesnothd instance
  261. through a named pipe. You must run wesnothd with the same UID specified at
  262. build time for this to work.
Advertisement
Add Comment
Please, Sign In to add comment