Document the Unification of tools/target build type configuration

Introduced in godotengine/godot#66242 the
`tools=yes/no` option was removed and merged into the `target` preset.

Replace the `tools=yes/no` calls in the documentation to the new
template target presets `editor`, `template_release` and
`template_debug`.

development/compiling/compiling_for_android.rst

@@ -94,8 +94,8 @@ root directory with the following arguments:
 
 ::
 
-    scons platform=android target=release android_arch=armv7
-    scons platform=android target=release android_arch=arm64v8
+    scons platform=android target=template_release android_arch=armv7
+    scons platform=android target=template_release android_arch=arm64v8
     cd platform/android/java
     # On Windows
     .\gradlew generateGodotTemplates
@@ -109,8 +109,8 @@ The resulting APK will be located at ``bin/android_release.apk``.
 
 ::
 
-    scons platform=android target=release_debug android_arch=armv7
-    scons platform=android target=release_debug android_arch=arm64v8
+    scons platform=android target=template_debug android_arch=armv7
+    scons platform=android target=template_debug android_arch=arm64v8
     cd platform/android/java
     # On Windows
     .\gradlew generateGodotTemplates
@@ -136,10 +136,10 @@ example, for the release template:
 
 ::
 
-    scons platform=android target=release android_arch=armv7
-    scons platform=android target=release android_arch=arm64v8
-    scons platform=android target=release android_arch=x86
-    scons platform=android target=release android_arch=x86_64
+    scons platform=android target=template_release android_arch=armv7
+    scons platform=android target=template_release android_arch=arm64v8
+    scons platform=android target=template_release android_arch=x86
+    scons platform=android target=template_release android_arch=x86_64
     cd platform/android/java
     # On Windows
     .\gradlew generateGodotTemplates
@@ -214,10 +214,10 @@ root directory with the following arguments:
 
 ::
 
-   scons platform=android android_arch=armv7 production=yes tools=yes target=release_debug
-   scons platform=android android_arch=arm64v8 production=yes tools=yes target=release_debug
-   scons platform=android android_arch=x86 production=yes tools=yes target=release_debug
-   scons platform=android android_arch=x86_64 production=yes tools=yes target=release_debug
+   scons platform=android android_arch=armv7 production=yes target=editor
+   scons platform=android android_arch=arm64v8 production=yes target=editor
+   scons platform=android android_arch=x86 production=yes target=editor
+   scons platform=android android_arch=x86_64 production=yes target=editor
    cd platform/android/java
    # On Windows
    .\gradlew generateGodotEditor

development/compiling/compiling_for_linuxbsd.rst

@@ -149,7 +149,7 @@ manager.
 
 .. note:: If you are compiling Godot for production use, then you can
           make the final executable smaller and faster by adding the
-          SCons option ``target=release_debug``.
+          SCons option ``target=template_release``.
 
           If you are compiling Godot with GCC, you can make the binary
           even smaller and faster by adding the SCons option ``use_lto=yes``.
@@ -167,17 +167,17 @@ Compiling a headless/server build
 To compile a *headless* build which provides editor functionality to export
 projects in an automated manner, use::
 
-    scons -j8 platform=server tools=yes target=release_debug
+    scons -j8 platform=server target=editor
 
 To compile a debug *server* build which can be used with
 :ref:`remote debugging tools <doc_command_line_tutorial>`, use::
 
-    scons -j8 platform=server tools=no target=release_debug
+    scons -j8 platform=server target=template_debug
 
 To compile a *server* build which is optimized to run dedicated game servers,
 use::
 
-    scons -j8 platform=server tools=no target=release
+    scons -j8 platform=server target=template_release
 
 Building export templates
 -------------------------
@@ -197,15 +197,15 @@ following parameters:
 
 ::
 
-    scons platform=linuxbsd tools=no target=release bits=32
-    scons platform=linuxbsd tools=no target=release_debug bits=32
+    scons platform=linuxbsd target=template_release bits=32
+    scons platform=linuxbsd target=template_debug bits=32
 
 -  (64 bits)
 
 ::
 
-    scons platform=linuxbsd tools=no target=release bits=64
-    scons platform=linuxbsd tools=no target=release_debug bits=64
+    scons platform=linuxbsd target=template_release bits=64
+    scons platform=linuxbsd target=template_debug bits=64
 
 Note that cross-compiling for the opposite bits (64/32) as your host
 platform is not always straight-forward and might need a chroot environment.

development/compiling/compiling_for_macos.rst

@@ -100,38 +100,38 @@ Compiling a headless/server build
 To compile a *headless* build which provides editor functionality to export
 projects in an automated manner, use::
 
-    scons platform=server tools=yes target=release_debug --jobs=$(sysctl -n hw.logicalcpu)
+    scons platform=server target=editor --jobs=$(sysctl -n hw.logicalcpu)
 
 To compile a debug *server* build which can be used with
 :ref:`remote debugging tools <doc_command_line_tutorial>`, use::
 
-    scons platform=server tools=no target=release_debug --jobs=$(sysctl -n hw.logicalcpu)
+    scons platform=server target=template_debug --jobs=$(sysctl -n hw.logicalcpu)
 
 To compile a release *server* build which is optimized to run dedicated game servers,
 use::
 
-    scons platform=server tools=no target=release --jobs=$(sysctl -n hw.logicalcpu)
+    scons platform=server target=template_release --jobs=$(sysctl -n hw.logicalcpu)
 
 Building export templates
 -------------------------
 
-To build macOS export templates, you have to compile with ``tools=no`` (no
-editor) and respectively for ``target=release`` (release template) and
-``target=release_debug``.
+To build macOS export templates, you have to compile with the no
+editor targets ``target=template_release`` (release template) and
+``target=template_debug``.
 
 Official templates are universal binaries which support both Intel x86_64 and
 ARM64 architectures. You can also create export templates that support only one
 of those two architectures by leaving out the ``lipo`` step below.
 
 - For Intel x86_64::
 
-    scons platform=macos tools=no target=release arch=x86_64 --jobs=$(sysctl -n hw.logicalcpu)
-    scons platform=macos tools=no target=release_debug arch=x86_64 --jobs=$(sysctl -n hw.logicalcpu)
+    scons platform=macos target=template_release arch=x86_64 --jobs=$(sysctl -n hw.logicalcpu)
+    scons platform=macos target=template_debug arch=x86_64 --jobs=$(sysctl -n hw.logicalcpu)
 
 - For ARM64 (Apple M1)::
 
-    scons platform=macos tools=no target=release arch=arm64 --jobs=$(sysctl -n hw.logicalcpu)
-    scons platform=macos tools=no target=release_debug arch=arm64 --jobs=$(sysctl -n hw.logicalcpu)
+    scons platform=macos target=template_release arch=arm64 --jobs=$(sysctl -n hw.logicalcpu)
+    scons platform=macos target=template_debug arch=arm64 --jobs=$(sysctl -n hw.logicalcpu)
 
 To support both architectures in a single "Universal 2" binary, run the above
 two commands blocks and then use ``lipo`` to bundle them together::

development/compiling/compiling_for_uwp.rst

@@ -66,8 +66,8 @@ be able to export.
 Open the command prompt for one architecture and run SCons twice (once for
 each target)::
 
-    C:\godot>scons platform=uwp target=release_debug
-    C:\godot>scons platform=uwp target=release
+    C:\godot>scons platform=uwp target=template_debug
+    C:\godot>scons platform=uwp target=template_release
 
 Repeat for the other architectures.
 

development/compiling/compiling_for_web.rst

@@ -34,18 +34,18 @@ and ``source ./emsdk_env.sh``/``emsdk_env.bat``.
 
 Open a terminal and navigate to the root directory of the engine source code.
 Then instruct SCons to build the Web platform. Specify ``target`` as
-either ``release`` for a release build or ``release_debug`` for a debug build::
+either ``template_release`` for a release build or ``template_debug`` for a debug build::
 
-    scons platform=web tools=no target=release
-    scons platform=web tools=no target=release_debug
+    scons platform=web target=template_release
+    scons platform=web target=template_debug
 
 By default, the :ref:`JavaScript singleton <doc_javascript_eval>` will be built
 into the engine. Official export templates also have the JavaScript singleton
 enabled. Since ``eval()`` calls can be a security concern, the
 ``javascript_eval`` option can be used to build without the singleton::
 
-    scons platform=web tools=no target=release javascript_eval=no
-    scons platform=web tools=no target=release_debug javascript_eval=no
+    scons platform=web target=template_release javascript_eval=no
+    scons platform=web target=template_debug javascript_eval=no
 
 The engine will now be compiled to WebAssembly by Emscripten. Once finished,
 the resulting file will be placed in the ``bin`` subdirectory. Its name is
@@ -71,8 +71,8 @@ performance and compatibility reasons. See the
 You can build the export templates using the option ``dlink_enabled=yes``
 to enable GDExtension support::
 
-    scons platform=web tools=no dlink_enabled=yes target=release
-    scons platform=web tools=no dlink_enabled=yes target=release_debug
+    scons platform=web dlink_enabled=yes target=template_release
+    scons platform=web dlink_enabled=yes target=template_debug
 
 Once finished, the resulting file will be placed in the ``bin`` subdirectory.
 Its name will have ``_dlink`` added.
@@ -90,7 +90,7 @@ It is also possible to build a version of the Godot editor that can run in the
 browser. The editor version is not recommended
 over the native build. You can build the editor with::
 
-    scons platform=web tools=yes target=release_debug
+    scons platform=web target=editor
 
 Once finished, the resulting file will be placed in the ``bin`` subdirectory.
 Its name will be ``godot.web.opt.tools.wasm32.zip``. You can upload the

development/compiling/compiling_for_windows.rst

@@ -157,7 +157,7 @@ dependencies. Running it will bring up the Project Manager.
 
 .. note:: If you are compiling Godot for production use, then you can
           make the final executable smaller and faster by adding the
-          SCons option ``target=release_debug``.
+          SCons option ``target=template_release``.
 
           If you are compiling Godot with MinGW, you can make the binary
           even smaller and faster by adding the SCons option ``use_lto=yes``.
@@ -269,10 +269,10 @@ Creating Windows export templates
 Windows export templates are created by compiling Godot without the editor,
 with the following flags::
 
-    C:\godot> scons platform=windows tools=no target=release_debug bits=32
-    C:\godot> scons platform=windows tools=no target=release bits=32
-    C:\godot> scons platform=windows tools=no target=release_debug bits=64
-    C:\godot> scons platform=windows tools=no target=release bits=64
+    C:\godot> scons platform=windows target=template_debug bits=32
+    C:\godot> scons platform=windows target=template_release bits=32
+    C:\godot> scons platform=windows target=template_debug bits=64
+    C:\godot> scons platform=windows target=template_release bits=64
 
 If you plan on replacing the standard export templates, copy these to the
 following location, replacing ``<version>`` with the version identifier

development/compiling/compiling_with_mono.rst

@@ -58,9 +58,9 @@ Generate the glue
 Glue sources are the wrapper functions that will be called by managed methods.
 These source files must be generated before building your final binaries. In
 order to generate them, first, you must build a temporary Godot binary with the
-options ``tools=yes`` and ``mono_glue=no``::
+options ``target=editor`` and ``mono_glue=no``::
 
-    scons p=<platform> tools=yes module_mono_enabled=yes mono_glue=no
+    scons p=<platform> target=editor module_mono_enabled=yes mono_glue=no
 
 After the build finishes, you need to run the compiled executable with the
 parameter ``--generate-mono-glue`` followed by the path to an output directory.
@@ -77,8 +77,8 @@ without having to repeat this process.
 ``<godot_binary>`` refers to the tools binary you compiled above with the Mono
 module enabled. Its exact name will differ based on your system and
 configuration, but should be of the form
-``bin/godot.<platform>.tools.<bits>.mono``, e.g. ``bin/godot.linuxbsd.tools.64.mono``
-or ``bin/godot.windows.tools.64.mono.exe``. Be especially aware of the **.mono**
+``bin/godot.<platform>.editor.<bits>.mono``, e.g. ``bin/godot.linuxbsd.editor.64.mono``
+or ``bin/godot.windows.editor.64.mono.exe``. Be especially aware of the **.mono**
 suffix! If you've previously compiled Godot without Mono support, you might have
 similarly named binaries without this suffix. These binaries can't be used to
 generate the Mono glue.
@@ -104,11 +104,11 @@ Once you have generated the Mono glue, you can build the final binary with
 ``mono_glue=yes``. This is the default value for ``mono_glue``, so you can also
 omit it. To build a Mono-enabled editor::
 
-    scons p=<platform> tools=yes module_mono_enabled=yes mono_glue=yes
+    scons p=<platform> target=editor module_mono_enabled=yes mono_glue=yes
 
 And Mono-enabled export templates::
 
-    scons p=<platform> tools=no module_mono_enabled=yes mono_glue=yes
+    scons p=<platform> target=template_release module_mono_enabled=yes mono_glue=yes
 
 If everything went well, apart from the normal output, SCons should have created
 the following files in the ``bin`` directory:
@@ -136,33 +136,33 @@ Example (Windows)
 ::
 
     # Build temporary binary
-    scons p=windows tools=yes module_mono_enabled=yes mono_glue=no
+    scons p=windows target=editor module_mono_enabled=yes mono_glue=no
     # Generate glue sources
     bin\godot.windows.tools.64.mono --generate-mono-glue modules/mono/glue
 
     ### Build binaries normally
     # Editor
-    scons p=windows target=release_debug tools=yes module_mono_enabled=yes
+    scons p=windows target=editor module_mono_enabled=yes
     # Export templates
-    scons p=windows target=release_debug tools=no module_mono_enabled=yes
-    scons p=windows target=release tools=no module_mono_enabled=yes
+    scons p=windows target=template_debug module_mono_enabled=yes
+    scons p=windows target=template_release module_mono_enabled=yes
 
 Example (Linux, \*BSD)
 ^^^^^^^^^^^^^^^^^^^^^^
 
 ::
 
     # Build temporary binary
-    scons p=linuxbsd tools=yes module_mono_enabled=yes mono_glue=no
+    scons p=linuxbsd target=editor module_mono_enabled=yes mono_glue=no
     # Generate glue sources
-    bin/godot.linuxbsd.tools.64.mono --generate-mono-glue modules/mono/glue
+    bin/godot.linuxbsd.editor.64.mono --generate-mono-glue modules/mono/glue
 
     ### Build binaries normally
     # Editor
-    scons p=linuxbsd target=release_debug tools=yes module_mono_enabled=yes
+    scons p=linuxbsd target=editor module_mono_enabled=yes
     # Export templates
-    scons p=linuxbsd target=release_debug tools=no module_mono_enabled=yes
-    scons p=linuxbsd target=release tools=no module_mono_enabled=yes
+    scons p=linuxbsd target=template_debug module_mono_enabled=yes
+    scons p=linuxbsd target=template_release module_mono_enabled=yes
 
 .. _compiling_with_mono_data_directory:
 

development/compiling/cross-compiling_for_ios_on_linux.rst

@@ -141,4 +141,4 @@ way, with some additional arguments to provide the correct paths:
 
 ::
 
-    $ scons -j 4 platform=ios arch=arm64 target=release_debug IOS_SDK_PATH="/path/to/iPhoneSDK" IOS_TOOLCHAIN_PATH="/path/to/iostoolchain" ios_triple="arm-apple-darwin11-"
+    $ scons -j 4 platform=ios arch=arm64 target=template_release IOS_SDK_PATH="/path/to/iPhoneSDK" IOS_TOOLCHAIN_PATH="/path/to/iostoolchain" ios_triple="arm-apple-darwin11-"