introduction_to_the_buildsystem.rst 8.4 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235
  1. .. _doc_introduction_to_the_buildsystem:
  2. Introduction to the buildsystem
  3. ===============================
  4. .. highlight:: none
  5. SCons
  6. -----
  7. Godot uses `SCons <https://www.scons.org/>`__ to build. We love it, we are
  8. not changing it for anything else. We are not even sure other build
  9. systems are up to the task of building Godot. We constantly get requests
  10. to move the build system to CMake, or Visual Studio, but this is not
  11. going to happen. There are many reasons why we have chosen SCons over
  12. other alternatives, for example:
  13. - Godot can be compiled for a dozen different platforms: all PC
  14. platforms, all mobile platforms, many consoles, and WebAssembly.
  15. - Developers often need to compile for several of the platforms **at
  16. the same time**, or even different targets of the same platform. They
  17. can't afford reconfiguring and rebuilding the project each time.
  18. SCons can do this with no sweat, without breaking the builds.
  19. - SCons will *never* break a build no matter how many changes,
  20. configurations, additions, removals etc. You have more chances to die
  21. struck by lightning than needing to clean and rebuild in SCons.
  22. - Godot build process is not simple. Several files are generated by
  23. code (binders), others are parsed (shaders), and others need to offer
  24. customization (plugins). This requires complex logic which is easier
  25. to write in an actual programming language (like Python) rather than
  26. using a mostly macro-based language only meant for building.
  27. - Godot build process makes heavy use of cross-compiling tools. Each
  28. platform has a specific detection process, and all these must be
  29. handled as specific cases with special code written for each.
  30. So, please try to keep an open mind and get at least a little familiar with it
  31. if you are planning to build Godot yourself.
  32. Setup
  33. -----
  34. Please refer to the documentation for :ref:`doc_compiling_for_android`,
  35. :ref:`doc_compiling_for_ios`, :ref:`doc_compiling_for_osx`,
  36. :ref:`doc_compiling_for_uwp`, :ref:`doc_compiling_for_web`,
  37. :ref:`doc_compiling_for_windows` and :ref:`doc_compiling_for_x11`.
  38. Note that for **Windows/Visual Studio**, you need to use ``x86_x64 Cross Tools
  39. Command Prompt for VS 2017`` or similar, depending on your install, instead of
  40. the standard Windows command prompt to enter the commands below.
  41. Platform selection
  42. ------------------
  43. Godot's build system will begin by detecting the platforms it can build
  44. for. If not detected, the platform will simply not appear on the list of
  45. available platforms. The build requirements for each platform are
  46. described in the rest of this tutorial section.
  47. SCons is invoked by just calling ``scons``. If no platform is specified,
  48. SCons will detect the target platform automatically based on the host platform.
  49. It will then start building for the target platform right away.
  50. To list the available target platforms, use ``scons platform=list``::
  51. user@host:~/godot$ scons platform=list
  52. scons: Reading SConscript files ...
  53. The following platforms are available:
  54. android
  55. javascript
  56. server
  57. windows
  58. x11
  59. Please run SCons again and select a valid platform: platform=<string>
  60. To build for a platform (for example, x11), run with the ``platform=`` (or
  61. ``p=`` to make it short) argument:
  62. ::
  63. user@host:~/godot$ scons platform=x11
  64. This will start the build process, which will take a while. If you want
  65. SCons to build faster, use the ``-j <cores>`` parameter to specify how many
  66. cores will be used for the build. Or leave it using one core, so you
  67. can use your computer for something else :)
  68. Example for using 4 cores:
  69. ::
  70. user@host:~/godot$ scons platform=x11 -j 4
  71. Resulting binary
  72. ----------------
  73. The resulting binaries will be placed in the ``bin/`` subdirectory,
  74. generally with this naming convention::
  75. godot.<platform>.[opt].[tools/debug].<architecture>[extension]
  76. For the previous build attempt, the result would look like this::
  77. user@host:~/godot$ ls bin
  78. bin/godot.x11.tools.64
  79. This means that the binary is for X11, is not optimized, has tools (the
  80. whole editor) compiled in, and is meant for 64 bits.
  81. A Windows binary with the same configuration will look like this::
  82. C:\godot> dir bin/
  83. godot.windows.tools.64.exe
  84. Copy that binary to any location you like, as it contains the project manager,
  85. editor and all means to execute the game. However, it lacks the data to export
  86. it to the different platforms. For that the export templates are needed (which
  87. can be either downloaded from `godotengine.org <https://godotengine.org/>`__, or
  88. you can build them yourself).
  89. Aside from that, there are a few standard options that can be set in all
  90. build targets, and which will be explained below.
  91. Tools
  92. -----
  93. Tools are enabled by default in all PC targets (Linux, Windows, macOS),
  94. disabled for everything else. Disabling tools produces a binary that can
  95. run projects but that does not include the editor or the project
  96. manager.
  97. ::
  98. scons platform=<platform> tools=yes/no
  99. Target
  100. ------
  101. Target controls optimization and debug flags. Each mode means:
  102. - **debug**: Build with C++ debugging symbols, runtime checks (performs
  103. checks and reports error) and none to little optimization.
  104. - **release_debug**: Build without C++ debugging symbols and
  105. optimization, but keep the runtime checks (performs checks and
  106. reports errors). Official editor binaries use this configuration.
  107. - **release**: Build without symbols, with optimization and with little
  108. to no runtime checks. This target can't be used together with
  109. ``tools=yes``, as the editor requires some debug functionality and run-time
  110. checks to run.
  111. ::
  112. scons platform=<platform> target=debug/release_debug/release
  113. This flag appends the ``.debug`` suffix (for debug), or ``.tools`` (for debug
  114. with tools enabled). When optimization is enabled (release), it appends
  115. the ``.opt`` suffix.
  116. Bits
  117. ----
  118. Bits is meant to control the CPU or OS version intended to run the
  119. binaries. It is focused mostly on desktop platforms and ignored everywhere
  120. else.
  121. - **32**: Build binaries for 32-bit platforms.
  122. - **64**: Build binaries for 64-bit platforms.
  123. - **default**: Build for the architecture that matches the host platform.
  124. ::
  125. scons platform=<platform> bits=default/32/64
  126. This flag appends ``.32`` or ``.64`` suffixes to resulting binaries when
  127. relevant. If ``bits=default`` is used, the suffix will match the detected
  128. architecture.
  129. Other build options
  130. -------------------
  131. There are several other build options that you can use to configure the
  132. way Godot should be built (compiler, debug options, etc.) as well as the
  133. features to include/disable.
  134. Check the output of ``scons --help`` for details about each option for
  135. the version you are willing to compile.
  136. Export templates
  137. ----------------
  138. Official export templates are downloaded from the Godot Engine site:
  139. `godotengine.org <https://godotengine.org/>`__. However, you might want
  140. to build them yourself (in case you want newer ones, you are using custom
  141. modules, or simply don't trust your own shadow).
  142. If you download the official export templates package and unzip it, you
  143. will notice that most files are optimized binaries or packages for each
  144. platform:
  145. ::
  146. android_debug.apk
  147. android_release.apk
  148. javascript_debug.zip
  149. javascript_release.zip
  150. linux_server_32
  151. linux_server_64
  152. linux_x11_32_debug
  153. linux_x11_32_release
  154. linux_x11_64_debug
  155. linux_x11_64_release
  156. osx.zip
  157. version.txt
  158. windows_32_debug.exe
  159. windows_32_release.exe
  160. windows_64_debug.exe
  161. windows_64_release.exe
  162. To create those yourself, follow the instructions detailed for each
  163. platform in this same tutorial section. Each platform explains how to
  164. create its own template.
  165. The ``version.txt`` file should contain the corresponding Godot version
  166. identifier. This file is used to install export templates in a version-specific
  167. directory to avoid conflicts. For instance, if you are building export templates
  168. for Godot 3.1.1, ``version.txt`` should contain ``3.1.1.stable`` on the first
  169. line (and nothing else). This version identifier is based on the ``major``,
  170. ``minor``, ``patch`` (if present) and ``status`` lines of the
  171. `version.py file in the Godot Git repository <https://github.com/godotengine/godot/blob/master/version.py>`__.
  172. If you are developing for multiple platforms, macOS is definitely the most
  173. convenient host platform for cross-compilation, since you can cross-compile for
  174. almost every target (except for UWP). Linux and Windows come in second place,
  175. but Linux has the advantage of being the easier platform to set this up.