introduction_to_the_buildsystem.rst 8.0 KB

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