asgardius/virtualx-engine
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
virtualx-engine/editor/SCsub

124 lines
4.5 KiB
Text
Raw Normal View History

SCsub: Add python shebang as a hint for syntax highlighting Also switch existing shebangs to "better" /usr/bin/env python.
2016-10-17 08:50:25 +02:00
#!/usr/bin/env python
SCons: Format buildsystem files with psf/black Configured for a max line length of 120 characters. psf/black is very opinionated and purposely doesn't leave much room for configuration. The output is mostly OK so that should be fine for us, but some things worth noting: - Manually wrapped strings will be reflowed, so by using a line length of 120 for the sake of preserving readability for our long command calls, it also means that some manually wrapped strings are back on the same line and should be manually merged again. - Code generators using string concatenation extensively look awful, since black puts each operand on a single line. We need to refactor these generators to use more pythonic string formatting, for which many options are available (`%`, `format` or f-strings). - CI checks and a pre-commit hook will be added to ensure that future buildsystem changes are well-formatted.
2020-03-30 08:28:32 +02:00
Import("env")
SCons: Build thirdparty code in own env, disable warnings Also remove unnecessary `Export('env')` in other SCsubs, Export should only be used when exporting *new* objects.
2018-09-28 13:29:52 +02:00
Reorder the folders in tools to prepare moving tools/editor - `certs` and `editor_fonts` go to `thirdparty` - `dist` and `scripts` go to a new `misc` folder - `collada` and `doc` go to `tools/editor` The next step will be to rename `tools/editor` to `editor` directly, but this will be done at the right time to avoid breaking too many PRs.
2017-02-09 00:07:44 +01:00
env.editor_sources = []
GODOT IS OPEN SOURCE
2014-02-10 02:10:30 +01:00
Implements modules documents Editor can generate documents for modules in thier own xml files
2016-12-16 12:12:22 +01:00
import os
Add `custom_modules` build option to compile external user modules This patch adds ability to include external, user-defined C++ modules to be compiled as part of Godot via `custom_modules` build option which can be passed to `scons`. ``` scons platform=x11 tools=yes custom_modules="../project/modules" ``` Features: - detects all available modules under `custom_modules` directory the same way as it does for built-in modules (not recursive); - works with both relative and absolute paths on the filesystem; - multiple search paths can be specified as a comma-separated list. Module custom documentation and editor icons collection and generation process is adapted to work with absolute paths needed by such modules. Also fixed doctool bug mixing absolute and relative paths respectively. Implementation details: - `env.module_list` is a dictionary now, which holds both module name as key and either a relative or absolute path to a module as a value. - `methods.detect_modules` is run twice: once for built-in modules, and second for external modules, all combined later. - `methods.detect_modules` was not doing what it says on the tin. It is split into `detect_modules` which collects a list of available modules and `write_modules` which generates `register_types` sources for each. - whether a module is built-in or external is distinguished by relative or absolute paths respectively. `custom_modules` scons converter ensures that the path is absolute even if relative path is supplied, including expanding user paths and symbolic links. - treats the parent directory as if it was Godot's base directory, so that there's no need to change include paths in cases where custom modules are included as dependencies in other modules.
2020-03-08 17:34:09 +01:00
import glob
Running builder (content generator) functions in subprocesses on Windows - Refactored all builder (make_*) functions into separate Python modules along to the build tree - Introduced utility function to wrap all invocations on Windows, but does not change it elsewhere - Introduced stub to use the builders module as a stand alone script and invoke a selected function There is a problem with file handles related to writing generated content (*.gen.h and *.gen.cpp) on Windows, which randomly causes a SHARING VIOLATION error to the compiler resulting in flaky builds. Running all such content generators in a new subprocess instead of directly inside the build script works around the issue. Yes, I tried the multiprocessing module. It did not work due to conflict with SCons on cPickle. Suggested workaround did not fully work either. Using the run_in_subprocess wrapper on osx and x11 platforms as well for consistency. In case of running a cross-compilation on Windows they would still be used, but likely it will not happen in practice. What counts is that the build itself is running on which platform, not the target platform. Some generated files are written directly in an SConstruct or SCsub file, before the parallel build starts. They don't need to be written in a subprocess, apparently, so I left them as is.
2018-03-17 23:23:55 +01:00
import editor_builders
Reorder the folders in tools to prepare moving tools/editor - `certs` and `editor_fonts` go to `thirdparty` - `dist` and `scripts` go to a new `misc` folder - `collada` and `doc` go to `tools/editor` The next step will be to rename `tools/editor` to `editor` directly, but this will be done at the right time to avoid breaking too many PRs.
2017-02-09 00:07:44 +01:00
Properly closing all files in Python code
2018-03-10 18:37:33 +01:00
Changed the doc class generation to individual files per class. It is also possible to save module files in module directories and the build system will recognize them.
2017-09-12 22:42:36 +02:00
def _make_doc_data_class_path(to_path):
Running builder (content generator) functions in subprocesses on Windows - Refactored all builder (make_*) functions into separate Python modules along to the build tree - Introduced utility function to wrap all invocations on Windows, but does not change it elsewhere - Introduced stub to use the builders module as a stand alone script and invoke a selected function There is a problem with file handles related to writing generated content (*.gen.h and *.gen.cpp) on Windows, which randomly causes a SHARING VIOLATION error to the compiler resulting in flaky builds. Running all such content generators in a new subprocess instead of directly inside the build script works around the issue. Yes, I tried the multiprocessing module. It did not work due to conflict with SCons on cPickle. Suggested workaround did not fully work either. Using the run_in_subprocess wrapper on osx and x11 platforms as well for consistency. In case of running a cross-compilation on Windows they would still be used, but likely it will not happen in practice. What counts is that the build itself is running on which platform, not the target platform. Some generated files are written directly in an SConstruct or SCsub file, before the parallel build starts. They don't need to be written in a subprocess, apparently, so I left them as is.
2018-03-17 23:23:55 +01:00
# NOTE: It is safe to generate this file here, since this is still executed serially
SCons: Drop support for Python 2 We now require SCons 3.0+ (first version with Python 3 support), and we set min required Python 3 version to 3.5 (3.4 and earlier are EOL).
2020-03-25 14:36:03 +01:00
g = open(os.path.join(to_path, "doc_data_class_path.gen.h"), "w", encoding="utf-8")
Properly closing all files in Python code
2018-03-10 18:37:33 +01:00
g.write("static const int _doc_data_class_path_count = " + str(len(env.doc_class_path)) + ";\n")
g.write("struct _DocDataClassPath { const char* name; const char* path; };\n")
SCons: Format buildsystem files with psf/black Configured for a max line length of 120 characters. psf/black is very opinionated and purposely doesn't leave much room for configuration. The output is mostly OK so that should be fine for us, but some things worth noting: - Manually wrapped strings will be reflowed, so by using a line length of 120 for the sake of preserving readability for our long command calls, it also means that some manually wrapped strings are back on the same line and should be manually merged again. - Code generators using string concatenation extensively look awful, since black puts each operand on a single line. We need to refactor these generators to use more pythonic string formatting, for which many options are available (`%`, `format` or f-strings). - CI checks and a pre-commit hook will be added to ensure that future buildsystem changes are well-formatted.
2020-03-30 08:28:32 +02:00
g.write("static const _DocDataClassPath _doc_data_class_paths[" + str(len(env.doc_class_path) + 1) + "] = {\n")
Properly closing all files in Python code
2018-03-10 18:37:33 +01:00
for c in sorted(env.doc_class_path):
SCons: Format buildsystem files with psf/black Configured for a max line length of 120 characters. psf/black is very opinionated and purposely doesn't leave much room for configuration. The output is mostly OK so that should be fine for us, but some things worth noting: - Manually wrapped strings will be reflowed, so by using a line length of 120 for the sake of preserving readability for our long command calls, it also means that some manually wrapped strings are back on the same line and should be manually merged again. - Code generators using string concatenation extensively look awful, since black puts each operand on a single line. We need to refactor these generators to use more pythonic string formatting, for which many options are available (`%`, `format` or f-strings). - CI checks and a pre-commit hook will be added to ensure that future buildsystem changes are well-formatted.
2020-03-30 08:28:32 +02:00
g.write('\t{"' + c + '", "' + env.doc_class_path[c] + '"},\n')
Replace NULL with nullptr
2020-04-02 01:20:12 +02:00
g.write("\t{nullptr, nullptr}\n")
Properly closing all files in Python code
2018-03-10 18:37:33 +01:00
g.write("};\n")
Changed the doc class generation to individual files per class. It is also possible to save module files in module directories and the build system will recognize them.
2017-09-12 22:42:36 +02:00
Properly closing all files in Python code
2018-03-10 18:37:33 +01:00
g.close()
Changed the doc class generation to individual files per class. It is also possible to save module files in module directories and the build system will recognize them.
2017-09-12 22:42:36 +02:00
GODOT IS OPEN SOURCE
2014-02-10 02:10:30 +01:00
SCons: Unify tools/target build type configuration Implements https://github.com/godotengine/godot-proposals/issues/3371. New `target` presets ==================== The `tools` option is removed and `target` changes to use three new presets, which match the builds users are familiar with. These targets control the default optimization level and enable editor-specific and debugging code: - `editor`: Replaces `tools=yes target=release_debug`. * Defines: `TOOLS_ENABLED`, `DEBUG_ENABLED`, `-O2`/`/O2` - `template_debug`: Replaces `tools=no target=release_debug`. * Defines: `DEBUG_ENABLED`, `-O2`/`/O2` - `template_release`: Replaces `tools=no target=release`. * Defines: `-O3`/`/O2` New `dev_build` option ====================== The previous `target=debug` is now replaced by a separate `dev_build=yes` option, which can be used in combination with either of the three targets, and changes the following: - `dev_build`: Defines `DEV_ENABLED`, disables optimization (`-O0`/`/0d`), enables generating debug symbols, does not define `NDEBUG` so `assert()` works in thirdparty libraries, adds a `.dev` suffix to the binary name. Note: Unlike previously, `dev_build` defaults to off so that users who compile Godot from source get an optimized and small build by default. Engine contributors should now set `dev_build=yes` in their build scripts or IDE configuration manually. Changed binary names ==================== The name of generated binaries and object files are changed too, to follow this format: `godot.<platform>.<target>[.dev][.double].<arch>[.<extra_suffix>][.<ext>]` For example: - `godot.linuxbsd.editor.dev.arm64` - `godot.windows.template_release.double.x86_64.mono.exe` Be sure to update your links/scripts/IDE config accordingly. More flexible `optimize` and `debug_symbols` options ==================================================== The optimization level and whether to generate debug symbols can be further specified with the `optimize` and `debug_symbols` options. So the default values listed above for the various `target` and `dev_build` combinations are indicative and can be replaced when compiling, e.g.: `scons p=linuxbsd target=template_debug dev_build=yes optimize=debug` will make a "debug" export template with dev-only code enabled, `-Og` optimization level for GCC/Clang, and debug symbols. Perfect for debugging complex crashes at runtime in an exported project.
2022-09-22 08:28:55 +02:00
if env.editor_build:
Reorder the folders in tools to prepare moving tools/editor - `certs` and `editor_fonts` go to `thirdparty` - `dist` and `scripts` go to a new `misc` folder - `collada` and `doc` go to `tools/editor` The next step will be to rename `tools/editor` to `editor` directly, but this will be done at the right time to avoid breaking too many PRs.
2017-02-09 00:07:44 +01:00
# Register exporters
style: Fix PEP8 whitespace issues in Python files Done with `autopep8 --select=E2,W2`, fixes: - E201 - Remove extraneous whitespace. - E202 - Remove extraneous whitespace. - E203 - Remove extraneous whitespace. - E211 - Remove extraneous whitespace. - E221 - Fix extraneous whitespace around keywords. - E222 - Fix extraneous whitespace around keywords. - E223 - Fix extraneous whitespace around keywords. - E224 - Remove extraneous whitespace around operator. - E225 - Fix missing whitespace around operator. - E226 - Fix missing whitespace around operator. - E227 - Fix missing whitespace around operator. - E228 - Fix missing whitespace around operator. - E231 - Add missing whitespace. - E231 - Fix various deprecated code (via lib2to3). - E241 - Fix extraneous whitespace around keywords. - E242 - Remove extraneous whitespace around operator. - E251 - Remove whitespace around parameter '=' sign. - E261 - Fix spacing after comment hash. - E262 - Fix spacing after comment hash. - E265 - Format block comments. - E271 - Fix extraneous whitespace around keywords. - E272 - Fix extraneous whitespace around keywords. - E273 - Fix extraneous whitespace around keywords. - E274 - Fix extraneous whitespace around keywords. - W291 - Remove trailing whitespace. - W293 - Remove trailing whitespace.
2016-10-30 18:57:40 +01:00
reg_exporters_inc = '#include "register_exporters.h"\n'
SCons: Format buildsystem files with psf/black Configured for a max line length of 120 characters. psf/black is very opinionated and purposely doesn't leave much room for configuration. The output is mostly OK so that should be fine for us, but some things worth noting: - Manually wrapped strings will be reflowed, so by using a line length of 120 for the sake of preserving readability for our long command calls, it also means that some manually wrapped strings are back on the same line and should be manually merged again. - Code generators using string concatenation extensively look awful, since black puts each operand on a single line. We need to refactor these generators to use more pythonic string formatting, for which many options are available (`%`, `format` or f-strings). - CI checks and a pre-commit hook will be added to ensure that future buildsystem changes are well-formatted.
2020-03-30 08:28:32 +02:00
reg_exporters = "void register_exporters() {\n"
style: Start applying PEP8 to Python files, indentation issues Done with `autopep8 --select=E1`, fixes: - E101 - Reindent all lines. - E112 - Fix under-indented comments. - E113 - Fix over-indented comments. - E115 - Fix under-indented comments. - E116 - Fix over-indented comments. - E121 - Fix a badly indented line. - E122 - Fix a badly indented line. - E123 - Fix a badly indented line. - E124 - Fix a badly indented line. - E125 - Fix indentation undistinguish from the next logical line. - E126 - Fix a badly indented line. - E127 - Fix a badly indented line. - E128 - Fix a badly indented line. - E129 - Fix a badly indented line.
2016-10-30 18:44:57 +01:00
for e in env.platform_exporters:
Allow additional cpp files to be added for export template
2021-07-13 21:17:17 +02:00
# Glob all .cpp files in export folder
files = Glob("#platform/" + e + "/export/" + "*.cpp")
env.add_source_files(env.editor_sources, files)
SCons: Format buildsystem files with psf/black Configured for a max line length of 120 characters. psf/black is very opinionated and purposely doesn't leave much room for configuration. The output is mostly OK so that should be fine for us, but some things worth noting: - Manually wrapped strings will be reflowed, so by using a line length of 120 for the sake of preserving readability for our long command calls, it also means that some manually wrapped strings are back on the same line and should be manually merged again. - Code generators using string concatenation extensively look awful, since black puts each operand on a single line. We need to refactor these generators to use more pythonic string formatting, for which many options are available (`%`, `format` or f-strings). - CI checks and a pre-commit hook will be added to ensure that future buildsystem changes are well-formatted.
2020-03-30 08:28:32 +02:00
reg_exporters += "\tregister_" + e + "_exporter();\n"
style: Fix PEP8 whitespace issues in Python files Done with `autopep8 --select=E2,W2`, fixes: - E201 - Remove extraneous whitespace. - E202 - Remove extraneous whitespace. - E203 - Remove extraneous whitespace. - E211 - Remove extraneous whitespace. - E221 - Fix extraneous whitespace around keywords. - E222 - Fix extraneous whitespace around keywords. - E223 - Fix extraneous whitespace around keywords. - E224 - Remove extraneous whitespace around operator. - E225 - Fix missing whitespace around operator. - E226 - Fix missing whitespace around operator. - E227 - Fix missing whitespace around operator. - E228 - Fix missing whitespace around operator. - E231 - Add missing whitespace. - E231 - Fix various deprecated code (via lib2to3). - E241 - Fix extraneous whitespace around keywords. - E242 - Remove extraneous whitespace around operator. - E251 - Remove whitespace around parameter '=' sign. - E261 - Fix spacing after comment hash. - E262 - Fix spacing after comment hash. - E265 - Format block comments. - E271 - Fix extraneous whitespace around keywords. - E272 - Fix extraneous whitespace around keywords. - E273 - Fix extraneous whitespace around keywords. - E274 - Fix extraneous whitespace around keywords. - W291 - Remove trailing whitespace. - W293 - Remove trailing whitespace.
2016-10-30 18:57:40 +01:00
reg_exporters_inc += '#include "platform/' + e + '/export/export.h"\n'
SCons: Format buildsystem files with psf/black Configured for a max line length of 120 characters. psf/black is very opinionated and purposely doesn't leave much room for configuration. The output is mostly OK so that should be fine for us, but some things worth noting: - Manually wrapped strings will be reflowed, so by using a line length of 120 for the sake of preserving readability for our long command calls, it also means that some manually wrapped strings are back on the same line and should be manually merged again. - Code generators using string concatenation extensively look awful, since black puts each operand on a single line. We need to refactor these generators to use more pythonic string formatting, for which many options are available (`%`, `format` or f-strings). - CI checks and a pre-commit hook will be added to ensure that future buildsystem changes are well-formatted.
2020-03-30 08:28:32 +02:00
reg_exporters += "}\n"
Running builder (content generator) functions in subprocesses on Windows - Refactored all builder (make_*) functions into separate Python modules along to the build tree - Introduced utility function to wrap all invocations on Windows, but does not change it elsewhere - Introduced stub to use the builders module as a stand alone script and invoke a selected function There is a problem with file handles related to writing generated content (*.gen.h and *.gen.cpp) on Windows, which randomly causes a SHARING VIOLATION error to the compiler resulting in flaky builds. Running all such content generators in a new subprocess instead of directly inside the build script works around the issue. Yes, I tried the multiprocessing module. It did not work due to conflict with SCons on cPickle. Suggested workaround did not fully work either. Using the run_in_subprocess wrapper on osx and x11 platforms as well for consistency. In case of running a cross-compilation on Windows they would still be used, but likely it will not happen in practice. What counts is that the build itself is running on which platform, not the target platform. Some generated files are written directly in an SConstruct or SCsub file, before the parallel build starts. They don't need to be written in a subprocess, apparently, so I left them as is.
2018-03-17 23:23:55 +01:00
# NOTE: It is safe to generate this file here, since this is still executed serially
SCons: Drop support for Python 2 We now require SCons 3.0+ (first version with Python 3 support), and we set min required Python 3 version to 3.5 (3.4 and earlier are EOL).
2020-03-25 14:36:03 +01:00
with open("register_exporters.gen.cpp", "w", encoding="utf-8") as f:
Properly closing all files in Python code
2018-03-10 18:37:33 +01:00
f.write(reg_exporters_inc)
f.write(reg_exporters)
style: Start applying PEP8 to Python files, indentation issues Done with `autopep8 --select=E1`, fixes: - E101 - Reindent all lines. - E112 - Fix under-indented comments. - E113 - Fix over-indented comments. - E115 - Fix under-indented comments. - E116 - Fix over-indented comments. - E121 - Fix a badly indented line. - E122 - Fix a badly indented line. - E123 - Fix a badly indented line. - E124 - Fix a badly indented line. - E125 - Fix indentation undistinguish from the next logical line. - E126 - Fix a badly indented line. - E127 - Fix a badly indented line. - E128 - Fix a badly indented line. - E129 - Fix a badly indented line.
2016-10-30 18:44:57 +01:00
Add `custom_modules` build option to compile external user modules This patch adds ability to include external, user-defined C++ modules to be compiled as part of Godot via `custom_modules` build option which can be passed to `scons`. ``` scons platform=x11 tools=yes custom_modules="../project/modules" ``` Features: - detects all available modules under `custom_modules` directory the same way as it does for built-in modules (not recursive); - works with both relative and absolute paths on the filesystem; - multiple search paths can be specified as a comma-separated list. Module custom documentation and editor icons collection and generation process is adapted to work with absolute paths needed by such modules. Also fixed doctool bug mixing absolute and relative paths respectively. Implementation details: - `env.module_list` is a dictionary now, which holds both module name as key and either a relative or absolute path to a module as a value. - `methods.detect_modules` is run twice: once for built-in modules, and second for external modules, all combined later. - `methods.detect_modules` was not doing what it says on the tin. It is split into `detect_modules` which collects a list of available modules and `write_modules` which generates `register_types` sources for each. - whether a module is built-in or external is distinguished by relative or absolute paths respectively. `custom_modules` scons converter ensures that the path is absolute even if relative path is supplied, including expanding user paths and symbolic links. - treats the parent directory as if it was Godot's base directory, so that there's no need to change include paths in cases where custom modules are included as dependencies in other modules.
2020-03-08 17:34:09 +01:00
# Core API documentation.
Cleanup unnecessary debug prints
2017-10-21 19:31:23 +02:00
docs = []
Add `custom_modules` build option to compile external user modules This patch adds ability to include external, user-defined C++ modules to be compiled as part of Godot via `custom_modules` build option which can be passed to `scons`. ``` scons platform=x11 tools=yes custom_modules="../project/modules" ``` Features: - detects all available modules under `custom_modules` directory the same way as it does for built-in modules (not recursive); - works with both relative and absolute paths on the filesystem; - multiple search paths can be specified as a comma-separated list. Module custom documentation and editor icons collection and generation process is adapted to work with absolute paths needed by such modules. Also fixed doctool bug mixing absolute and relative paths respectively. Implementation details: - `env.module_list` is a dictionary now, which holds both module name as key and either a relative or absolute path to a module as a value. - `methods.detect_modules` is run twice: once for built-in modules, and second for external modules, all combined later. - `methods.detect_modules` was not doing what it says on the tin. It is split into `detect_modules` which collects a list of available modules and `write_modules` which generates `register_types` sources for each. - whether a module is built-in or external is distinguished by relative or absolute paths respectively. `custom_modules` scons converter ensures that the path is absolute even if relative path is supplied, including expanding user paths and symbolic links. - treats the parent directory as if it was Godot's base directory, so that there's no need to change include paths in cases where custom modules are included as dependencies in other modules.
2020-03-08 17:34:09 +01:00
docs += Glob("#doc/classes/*.xml")
Added modules' doc files to make_doc_header They were somehow never included. This fixes that.
2017-11-16 18:53:54 +01:00
Add `custom_modules` build option to compile external user modules This patch adds ability to include external, user-defined C++ modules to be compiled as part of Godot via `custom_modules` build option which can be passed to `scons`. ``` scons platform=x11 tools=yes custom_modules="../project/modules" ``` Features: - detects all available modules under `custom_modules` directory the same way as it does for built-in modules (not recursive); - works with both relative and absolute paths on the filesystem; - multiple search paths can be specified as a comma-separated list. Module custom documentation and editor icons collection and generation process is adapted to work with absolute paths needed by such modules. Also fixed doctool bug mixing absolute and relative paths respectively. Implementation details: - `env.module_list` is a dictionary now, which holds both module name as key and either a relative or absolute path to a module as a value. - `methods.detect_modules` is run twice: once for built-in modules, and second for external modules, all combined later. - `methods.detect_modules` was not doing what it says on the tin. It is split into `detect_modules` which collects a list of available modules and `write_modules` which generates `register_types` sources for each. - whether a module is built-in or external is distinguished by relative or absolute paths respectively. `custom_modules` scons converter ensures that the path is absolute even if relative path is supplied, including expanding user paths and symbolic links. - treats the parent directory as if it was Godot's base directory, so that there's no need to change include paths in cases where custom modules are included as dependencies in other modules.
2020-03-08 17:34:09 +01:00
# Module API documentation.
module_dirs = []
for d in env.doc_class_path.values():
if d not in module_dirs:
module_dirs.append(d)
Added modules' doc files to make_doc_header They were somehow never included. This fixes that.
2017-11-16 18:53:54 +01:00
Add `custom_modules` build option to compile external user modules This patch adds ability to include external, user-defined C++ modules to be compiled as part of Godot via `custom_modules` build option which can be passed to `scons`. ``` scons platform=x11 tools=yes custom_modules="../project/modules" ``` Features: - detects all available modules under `custom_modules` directory the same way as it does for built-in modules (not recursive); - works with both relative and absolute paths on the filesystem; - multiple search paths can be specified as a comma-separated list. Module custom documentation and editor icons collection and generation process is adapted to work with absolute paths needed by such modules. Also fixed doctool bug mixing absolute and relative paths respectively. Implementation details: - `env.module_list` is a dictionary now, which holds both module name as key and either a relative or absolute path to a module as a value. - `methods.detect_modules` is run twice: once for built-in modules, and second for external modules, all combined later. - `methods.detect_modules` was not doing what it says on the tin. It is split into `detect_modules` which collects a list of available modules and `write_modules` which generates `register_types` sources for each. - whether a module is built-in or external is distinguished by relative or absolute paths respectively. `custom_modules` scons converter ensures that the path is absolute even if relative path is supplied, including expanding user paths and symbolic links. - treats the parent directory as if it was Godot's base directory, so that there's no need to change include paths in cases where custom modules are included as dependencies in other modules.
2020-03-08 17:34:09 +01:00
for d in module_dirs:
if not os.path.isabs(d):
docs += Glob("#" + d + "/*.xml") # Built-in.
else:
docs += Glob(d + "/*.xml") # Custom.
Changed the doc class generation to individual files per class. It is also possible to save module files in module directories and the build system will recognize them.
2017-09-12 22:42:36 +02:00
i18n: Only include editor translations above a threshold This reduces the size of the editor binaries significantly, as we otherwise embed all WIP translations, including ones with very low completion ratios, and end up paying for the size of all `msgid`s for each locale. Cf. https://github.com/godotengine/godot-proposals/issues/3421 for details. The thresholds used are: - 30% for the editor interface (should already include most common strings while more obscure ones like UndoRedo action names might be untranslated). - 10% for the class reference: this is a HUGE resource and 10% is already a lot of useful content, especially if focused on the most used APIs. This currently reduces the size of the editor binary by 17% on Linux. The list will be synced manually every now and then. (cherry picked from commit 8425c589911f8ffc006990f4149859e175ae93a9)
2021-10-20 13:47:50 +02:00
_make_doc_data_class_path(env.Dir("#editor").abspath)
Changed the doc class generation to individual files per class. It is also possible to save module files in module directories and the build system will recognize them.
2017-09-12 22:42:36 +02:00
Improve code style of generated headers
2017-11-15 20:16:51 +01:00
docs = sorted(docs)
BuildSystem: generated files have .gen.extension
2017-06-23 17:03:41 +02:00
env.Depends("#editor/doc_data_compressed.gen.h", docs)
SCons: Refactor running commands through builders A new `env.Run` method is added which allows to control the verbosity of builders output automatically depending on whether the "verbose" option is set. It also allows to optionally run any SCons commands in a subprocess using the existing `run_in_subprocess` method, unifying the interface. `Action` objects wrap all builder functions to include a short build message associated with any action. Notably, this removes quite verbose output generated by `make_doc_header` and `make_editor_icons_action` builders.
2020-07-27 20:00:26 +02:00
env.CommandNoCache(
"#editor/doc_data_compressed.gen.h",
docs,
env.Run(editor_builders.make_doc_header, "Generating documentation header."),
)
Running builder (content generator) functions in subprocesses on Windows - Refactored all builder (make_*) functions into separate Python modules along to the build tree - Introduced utility function to wrap all invocations on Windows, but does not change it elsewhere - Introduced stub to use the builders module as a stand alone script and invoke a selected function There is a problem with file handles related to writing generated content (*.gen.h and *.gen.cpp) on Windows, which randomly causes a SHARING VIOLATION error to the compiler resulting in flaky builds. Running all such content generators in a new subprocess instead of directly inside the build script works around the issue. Yes, I tried the multiprocessing module. It did not work due to conflict with SCons on cPickle. Suggested workaround did not fully work either. Using the run_in_subprocess wrapper on osx and x11 platforms as well for consistency. In case of running a cross-compilation on Windows they would still be used, but likely it will not happen in practice. What counts is that the build itself is running on which platform, not the target platform. Some generated files are written directly in an SConstruct or SCsub file, before the parallel build starts. They don't need to be written in a subprocess, apparently, so I left them as is.
2018-03-17 23:23:55 +01:00
i18n: Only include editor translations above a threshold This reduces the size of the editor binaries significantly, as we otherwise embed all WIP translations, including ones with very low completion ratios, and end up paying for the size of all `msgid`s for each locale. Cf. https://github.com/godotengine/godot-proposals/issues/3421 for details. The thresholds used are: - 30% for the editor interface (should already include most common strings while more obscure ones like UndoRedo action names might be untranslated). - 10% for the class reference: this is a HUGE resource and 10% is already a lot of useful content, especially if focused on the most used APIs. This currently reduces the size of the editor binary by 17% on Linux. The list will be synced manually every now and then. (cherry picked from commit 8425c589911f8ffc006990f4149859e175ae93a9)
2021-10-20 13:47:50 +02:00
# Editor interface and class reference translations incur a significant size
# cost for the editor binary (see godot-proposals#3421).
# To limit it, we only include translations with a high enough completion
i18n: Sync editor translations with Weblate (cherry picked from commit 1e61fb1e37c537179e3d50ad21ff26776a3ebb7e)
2022-04-25 17:14:49 +02:00
# ratio (20% for the editor UI, 10% for the class reference).
i18n: Only include editor translations above a threshold This reduces the size of the editor binaries significantly, as we otherwise embed all WIP translations, including ones with very low completion ratios, and end up paying for the size of all `msgid`s for each locale. Cf. https://github.com/godotengine/godot-proposals/issues/3421 for details. The thresholds used are: - 30% for the editor interface (should already include most common strings while more obscure ones like UndoRedo action names might be untranslated). - 10% for the class reference: this is a HUGE resource and 10% is already a lot of useful content, especially if focused on the most used APIs. This currently reduces the size of the editor binary by 17% on Linux. The list will be synced manually every now and then. (cherry picked from commit 8425c589911f8ffc006990f4149859e175ae93a9)
2021-10-20 13:47:50 +02:00
# Generated with `make include-list` for each resource.
style: Start applying PEP8 to Python files, indentation issues Done with `autopep8 --select=E1`, fixes: - E101 - Reindent all lines. - E112 - Fix under-indented comments. - E113 - Fix over-indented comments. - E115 - Fix under-indented comments. - E116 - Fix over-indented comments. - E121 - Fix a badly indented line. - E122 - Fix a badly indented line. - E123 - Fix a badly indented line. - E124 - Fix a badly indented line. - E125 - Fix indentation undistinguish from the next logical line. - E126 - Fix a badly indented line. - E127 - Fix a badly indented line. - E128 - Fix a badly indented line. - E129 - Fix a badly indented line.
2016-10-30 18:44:57 +01:00
i18n: Add support for translating the class reference - Parse `.po` files from `doc/translations/*.po` like already done with `editor/translations/*.po`. - Add logic to register a doc translation mapping in `TranslationServer` and `EditorSettings`. - Add `DTR()` to lookup the doc translation mapping (similar to `TTR()`). Strings are automatically dedented and stripped of whitespace to ensure that they would match the translation catalog. - Use `DTR()` to translate relevant strings in `EditorHelp`, `EditorInspector`, `CreateDialog`, `ConnectionsDialog`. - Small simplification to `TranslationLoaderPO`, the path argument was not really meaningful.
2020-03-18 18:34:36 +01:00
# Editor translations
i18n: Only include editor translations above a threshold This reduces the size of the editor binaries significantly, as we otherwise embed all WIP translations, including ones with very low completion ratios, and end up paying for the size of all `msgid`s for each locale. Cf. https://github.com/godotengine/godot-proposals/issues/3421 for details. The thresholds used are: - 30% for the editor interface (should already include most common strings while more obscure ones like UndoRedo action names might be untranslated). - 10% for the class reference: this is a HUGE resource and 10% is already a lot of useful content, especially if focused on the most used APIs. This currently reduces the size of the editor binary by 17% on Linux. The list will be synced manually every now and then. (cherry picked from commit 8425c589911f8ffc006990f4149859e175ae93a9)
2021-10-20 13:47:50 +02:00
to_include = (
i18n: Sync editor translations with Weblate (cherry picked from commit 5e66d2e2c4103ba4c7d178409da2a721bcb6d842)
2022-07-27 15:31:01 +02:00
"ar,bg,ca,cs,de,el,eo,es_AR,es,fi,fr,gl,he,hu,id,it,ja,ko,lv,ms,nb,nl,pl,pt_BR,pt,ro,ru,sk,sv,th,tr,uk,vi,zh_CN,zh_TW"
i18n: Only include editor translations above a threshold This reduces the size of the editor binaries significantly, as we otherwise embed all WIP translations, including ones with very low completion ratios, and end up paying for the size of all `msgid`s for each locale. Cf. https://github.com/godotengine/godot-proposals/issues/3421 for details. The thresholds used are: - 30% for the editor interface (should already include most common strings while more obscure ones like UndoRedo action names might be untranslated). - 10% for the class reference: this is a HUGE resource and 10% is already a lot of useful content, especially if focused on the most used APIs. This currently reduces the size of the editor binary by 17% on Linux. The list will be synced manually every now and then. (cherry picked from commit 8425c589911f8ffc006990f4149859e175ae93a9)
2021-10-20 13:47:50 +02:00
).split(",")
tlist = [env.Dir("#editor/translations").abspath + "/" + f + ".po" for f in to_include]
SCons: Format buildsystem files with psf/black Configured for a max line length of 120 characters. psf/black is very opinionated and purposely doesn't leave much room for configuration. The output is mostly OK so that should be fine for us, but some things worth noting: - Manually wrapped strings will be reflowed, so by using a line length of 120 for the sake of preserving readability for our long command calls, it also means that some manually wrapped strings are back on the same line and should be manually merged again. - Code generators using string concatenation extensively look awful, since black puts each operand on a single line. We need to refactor these generators to use more pythonic string formatting, for which many options are available (`%`, `format` or f-strings). - CI checks and a pre-commit hook will be added to ensure that future buildsystem changes are well-formatted.
2020-03-30 08:28:32 +02:00
env.Depends("#editor/editor_translations.gen.h", tlist)
env.CommandNoCache(
SCons: Refactor running commands through builders A new `env.Run` method is added which allows to control the verbosity of builders output automatically depending on whether the "verbose" option is set. It also allows to optionally run any SCons commands in a subprocess using the existing `run_in_subprocess` method, unifying the interface. `Action` objects wrap all builder functions to include a short build message associated with any action. Notably, this removes quite verbose output generated by `make_doc_header` and `make_editor_icons_action` builders.
2020-07-27 20:00:26 +02:00
"#editor/editor_translations.gen.h",
tlist,
env.Run(editor_builders.make_editor_translations_header, "Generating editor translations header."),
SCons: Format buildsystem files with psf/black Configured for a max line length of 120 characters. psf/black is very opinionated and purposely doesn't leave much room for configuration. The output is mostly OK so that should be fine for us, but some things worth noting: - Manually wrapped strings will be reflowed, so by using a line length of 120 for the sake of preserving readability for our long command calls, it also means that some manually wrapped strings are back on the same line and should be manually merged again. - Code generators using string concatenation extensively look awful, since black puts each operand on a single line. We need to refactor these generators to use more pythonic string formatting, for which many options are available (`%`, `format` or f-strings). - CI checks and a pre-commit hook will be added to ensure that future buildsystem changes are well-formatted.
2020-03-30 08:28:32 +02:00
)
i18n: Add support for translating the class reference - Parse `.po` files from `doc/translations/*.po` like already done with `editor/translations/*.po`. - Add logic to register a doc translation mapping in `TranslationServer` and `EditorSettings`. - Add `DTR()` to lookup the doc translation mapping (similar to `TTR()`). Strings are automatically dedented and stripped of whitespace to ensure that they would match the translation catalog. - Use `DTR()` to translate relevant strings in `EditorHelp`, `EditorInspector`, `CreateDialog`, `ConnectionsDialog`. - Small simplification to `TranslationLoaderPO`, the path argument was not really meaningful.
2020-03-18 18:34:36 +01:00
# Documentation translations
i18n: Sync classref translations with Weblate German (de) is now above the threshold for inclusion. (cherry picked from commit 0b694eb8e711b6cfdc3d398254692ed9cbb6f8c9)
2021-11-03 15:00:43 +01:00
to_include = "de,es,fr,ja,zh_CN".split(",")
i18n: Only include editor translations above a threshold This reduces the size of the editor binaries significantly, as we otherwise embed all WIP translations, including ones with very low completion ratios, and end up paying for the size of all `msgid`s for each locale. Cf. https://github.com/godotengine/godot-proposals/issues/3421 for details. The thresholds used are: - 30% for the editor interface (should already include most common strings while more obscure ones like UndoRedo action names might be untranslated). - 10% for the class reference: this is a HUGE resource and 10% is already a lot of useful content, especially if focused on the most used APIs. This currently reduces the size of the editor binary by 17% on Linux. The list will be synced manually every now and then. (cherry picked from commit 8425c589911f8ffc006990f4149859e175ae93a9)
2021-10-20 13:47:50 +02:00
tlist = [env.Dir("#doc/translations").abspath + "/" + f + ".po" for f in to_include]
SCons: Format buildsystem files with psf/black Configured for a max line length of 120 characters. psf/black is very opinionated and purposely doesn't leave much room for configuration. The output is mostly OK so that should be fine for us, but some things worth noting: - Manually wrapped strings will be reflowed, so by using a line length of 120 for the sake of preserving readability for our long command calls, it also means that some manually wrapped strings are back on the same line and should be manually merged again. - Code generators using string concatenation extensively look awful, since black puts each operand on a single line. We need to refactor these generators to use more pythonic string formatting, for which many options are available (`%`, `format` or f-strings). - CI checks and a pre-commit hook will be added to ensure that future buildsystem changes are well-formatted.
2020-03-30 08:28:32 +02:00
env.Depends("#editor/doc_translations.gen.h", tlist)
env.CommandNoCache(
SCons: Refactor running commands through builders A new `env.Run` method is added which allows to control the verbosity of builders output automatically depending on whether the "verbose" option is set. It also allows to optionally run any SCons commands in a subprocess using the existing `run_in_subprocess` method, unifying the interface. `Action` objects wrap all builder functions to include a short build message associated with any action. Notably, this removes quite verbose output generated by `make_doc_header` and `make_editor_icons_action` builders.
2020-07-27 20:00:26 +02:00
"#editor/doc_translations.gen.h",
tlist,
env.Run(editor_builders.make_doc_translations_header, "Generating translations header."),
SCons: Format buildsystem files with psf/black Configured for a max line length of 120 characters. psf/black is very opinionated and purposely doesn't leave much room for configuration. The output is mostly OK so that should be fine for us, but some things worth noting: - Manually wrapped strings will be reflowed, so by using a line length of 120 for the sake of preserving readability for our long command calls, it also means that some manually wrapped strings are back on the same line and should be manually merged again. - Code generators using string concatenation extensively look awful, since black puts each operand on a single line. We need to refactor these generators to use more pythonic string formatting, for which many options are available (`%`, `format` or f-strings). - CI checks and a pre-commit hook will be added to ensure that future buildsystem changes are well-formatted.
2020-03-30 08:28:32 +02:00
)
style: Start applying PEP8 to Python files, indentation issues Done with `autopep8 --select=E1`, fixes: - E101 - Reindent all lines. - E112 - Fix under-indented comments. - E113 - Fix over-indented comments. - E115 - Fix under-indented comments. - E116 - Fix over-indented comments. - E121 - Fix a badly indented line. - E122 - Fix a badly indented line. - E123 - Fix a badly indented line. - E124 - Fix a badly indented line. - E125 - Fix indentation undistinguish from the next logical line. - E126 - Fix a badly indented line. - E127 - Fix a badly indented line. - E128 - Fix a badly indented line. - E129 - Fix a badly indented line.
2016-10-30 18:44:57 +01:00
Reorder the folders in tools to prepare moving tools/editor - `certs` and `editor_fonts` go to `thirdparty` - `dist` and `scripts` go to a new `misc` folder - `collada` and `doc` go to `tools/editor` The next step will be to rename `tools/editor` to `editor` directly, but this will be done at the right time to avoid breaking too many PRs.
2017-02-09 00:07:44 +01:00
# Fonts
i18n: Only include editor translations above a threshold This reduces the size of the editor binaries significantly, as we otherwise embed all WIP translations, including ones with very low completion ratios, and end up paying for the size of all `msgid`s for each locale. Cf. https://github.com/godotengine/godot-proposals/issues/3421 for details. The thresholds used are: - 30% for the editor interface (should already include most common strings while more obscure ones like UndoRedo action names might be untranslated). - 10% for the class reference: this is a HUGE resource and 10% is already a lot of useful content, especially if focused on the most used APIs. This currently reduces the size of the editor binary by 17% on Linux. The list will be synced manually every now and then. (cherry picked from commit 8425c589911f8ffc006990f4149859e175ae93a9)
2021-10-20 13:47:50 +02:00
flist = glob.glob(env.Dir("#thirdparty").abspath + "/fonts/*.ttf")
flist.extend(glob.glob(env.Dir("#thirdparty").abspath + "/fonts/*.otf"))
Convert the editor and default theme fonts to WOFF2 format to save space.
2022-03-25 09:54:32 +01:00
flist.extend(glob.glob(env.Dir("#thirdparty").abspath + "/fonts/*.woff"))
flist.extend(glob.glob(env.Dir("#thirdparty").abspath + "/fonts/*.woff2"))
BuildSystem: Sort input file lists so that godot package builds reproducibly in spite of indeterministic filesystem readdir order and http://bugs.python.org/issue30461 See https://reproducible-builds.org/ for why this is good. Sort font input file list, so that builtin_fonts.gen.h is created in a reproducible way Sort list of platforms, so that editor/register_exporters.gen.cpp is created in a reproducible way Sort list of source files, so that .a files and resulting godot binaries are created in a reproducible way
2018-08-28 20:40:51 +02:00
flist.sort()
SCons: Format buildsystem files with psf/black Configured for a max line length of 120 characters. psf/black is very opinionated and purposely doesn't leave much room for configuration. The output is mostly OK so that should be fine for us, but some things worth noting: - Manually wrapped strings will be reflowed, so by using a line length of 120 for the sake of preserving readability for our long command calls, it also means that some manually wrapped strings are back on the same line and should be manually merged again. - Code generators using string concatenation extensively look awful, since black puts each operand on a single line. We need to refactor these generators to use more pythonic string formatting, for which many options are available (`%`, `format` or f-strings). - CI checks and a pre-commit hook will be added to ensure that future buildsystem changes are well-formatted.
2020-03-30 08:28:32 +02:00
env.Depends("#editor/builtin_fonts.gen.h", flist)
SCons: Refactor running commands through builders A new `env.Run` method is added which allows to control the verbosity of builders output automatically depending on whether the "verbose" option is set. It also allows to optionally run any SCons commands in a subprocess using the existing `run_in_subprocess` method, unifying the interface. `Action` objects wrap all builder functions to include a short build message associated with any action. Notably, this removes quite verbose output generated by `make_doc_header` and `make_editor_icons_action` builders.
2020-07-27 20:00:26 +02:00
env.CommandNoCache(
"#editor/builtin_fonts.gen.h",
flist,
env.Run(editor_builders.make_fonts_header, "Generating builtin fonts header."),
)
Running builder (content generator) functions in subprocesses on Windows - Refactored all builder (make_*) functions into separate Python modules along to the build tree - Introduced utility function to wrap all invocations on Windows, but does not change it elsewhere - Introduced stub to use the builders module as a stand alone script and invoke a selected function There is a problem with file handles related to writing generated content (*.gen.h and *.gen.cpp) on Windows, which randomly causes a SHARING VIOLATION error to the compiler resulting in flaky builds. Running all such content generators in a new subprocess instead of directly inside the build script works around the issue. Yes, I tried the multiprocessing module. It did not work due to conflict with SCons on cPickle. Suggested workaround did not fully work either. Using the run_in_subprocess wrapper on osx and x11 platforms as well for consistency. In case of running a cross-compilation on Windows they would still be used, but likely it will not happen in practice. What counts is that the build itself is running on which platform, not the target platform. Some generated files are written directly in an SConstruct or SCsub file, before the parallel build starts. They don't need to be written in a subprocess, apparently, so I left them as is.
2018-03-17 23:23:55 +01:00
Reorder the folders in tools to prepare moving tools/editor - `certs` and `editor_fonts` go to `thirdparty` - `dist` and `scripts` go to a new `misc` folder - `collada` and `doc` go to `tools/editor` The next step will be to rename `tools/editor` to `editor` directly, but this will be done at the right time to avoid breaking too many PRs.
2017-02-09 00:07:44 +01:00
env.add_source_files(env.editor_sources, "*.cpp")
SCons: List `.gen.cpp` sources explicitly to avoid globbing errors Whenever we change the name (or remove) generated cpp files with the `.gen.cpp` extension, users run into build issues when switching between branches (i.e. switching before and after the name change/removal). This is because we glob `*.cpp` so if a now-obsolete file from a previous build is present, we'll include it too, potentially leading to bugs or compilation failure (due to missing headers or invalid code). So globbing patterns in `add_source_files` will now skip files ending with `.gen.cpp`, which should instead be passed explicitly where they're used.
2021-10-15 21:59:11 +02:00
env.add_source_files(env.editor_sources, "register_exporters.gen.cpp")
Reorder the folders in tools to prepare moving tools/editor - `certs` and `editor_fonts` go to `thirdparty` - `dist` and `scripts` go to a new `misc` folder - `collada` and `doc` go to `tools/editor` The next step will be to rename `tools/editor` to `editor` directly, but this will be done at the right time to avoid breaking too many PRs.
2017-02-09 00:07:44 +01:00
SCons: Format buildsystem files with psf/black Configured for a max line length of 120 characters. psf/black is very opinionated and purposely doesn't leave much room for configuration. The output is mostly OK so that should be fine for us, but some things worth noting: - Manually wrapped strings will be reflowed, so by using a line length of 120 for the sake of preserving readability for our long command calls, it also means that some manually wrapped strings are back on the same line and should be manually merged again. - Code generators using string concatenation extensively look awful, since black puts each operand on a single line. We need to refactor these generators to use more pythonic string formatting, for which many options are available (`%`, `format` or f-strings). - CI checks and a pre-commit hook will be added to ensure that future buildsystem changes are well-formatted.
2020-03-30 08:28:32 +02:00
SConscript("debugger/SCsub")
Split up editor export code into multiple files
2022-07-17 19:24:37 +02:00
SConscript("export/SCsub")
SCons: Format buildsystem files with psf/black Configured for a max line length of 120 characters. psf/black is very opinionated and purposely doesn't leave much room for configuration. The output is mostly OK so that should be fine for us, but some things worth noting: - Manually wrapped strings will be reflowed, so by using a line length of 120 for the sake of preserving readability for our long command calls, it also means that some manually wrapped strings are back on the same line and should be manually merged again. - Code generators using string concatenation extensively look awful, since black puts each operand on a single line. We need to refactor these generators to use more pythonic string formatting, for which many options are available (`%`, `format` or f-strings). - CI checks and a pre-commit hook will be added to ensure that future buildsystem changes are well-formatted.
2020-03-30 08:28:32 +02:00
SConscript("fileserver/SCsub")
SConscript("icons/SCsub")
SConscript("import/SCsub")
SConscript("plugins/SCsub")
Reorder the folders in tools to prepare moving tools/editor - `certs` and `editor_fonts` go to `thirdparty` - `dist` and `scripts` go to a new `misc` folder - `collada` and `doc` go to `tools/editor` The next step will be to rename `tools/editor` to `editor` directly, but this will be done at the right time to avoid breaking too many PRs.
2017-02-09 00:07:44 +01:00
disable caching for targets using helper functions
2017-11-28 21:27:57 +01:00
lib = env.add_library("editor", env.editor_sources)
Reorder the folders in tools to prepare moving tools/editor - `certs` and `editor_fonts` go to `thirdparty` - `dist` and `scripts` go to a new `misc` folder - `collada` and `doc` go to `tools/editor` The next step will be to rename `tools/editor` to `editor` directly, but this will be done at the right time to avoid breaking too many PRs.
2017-02-09 00:07:44 +01:00
env.Prepend(LIBS=[lib])
Reference in a new issue Copy permalink