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

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

26 lines
652 B
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
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 os
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_icons_builders
style: Fix PEP8 blank lines issues in Python files Done with `autopep8 --select=E3,W3`, fixes: - E301 - Add missing blank line. - E302 - Add missing 2 blank lines. - E303 - Remove extra blank lines. - E304 - Remove blank line following function decorator. - E309 - Add missing blank line. - W391 - Remove trailing blank lines.
2016-10-30 19:05:14 +01:00
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
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["BUILDERS"]["MakeEditorIconsBuilder"] = Builder(
action=env.Run(editor_icons_builders.make_editor_icons_action, "Generating editor icons header."),
suffix=".h",
src_suffix=".svg",
)
Add support for creating editor icons per module The functionality is similar to how `doc_classes` are retrieved per module. The build system will search for custom icons path defined per module via `get_icons_path()` method in `config.py` or default icons path. If such paths don't exist, only the editor's own icons will be built. Most module icons were moved from editor/icons to respective modules.
2019-06-28 22:42:26 +02:00
# Editor's own icons
icon_sources = Glob("*.svg")
# Module icons
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 path in env.module_icons_paths:
if not os.path.isabs(path):
icon_sources += Glob("#" + path + "/*.svg") # Built-in.
else:
icon_sources += Glob(path + "/*.svg") # Custom.
Add support for creating editor icons per module The functionality is similar to how `doc_classes` are retrieved per module. The build system will search for custom icons path defined per module via `get_icons_path()` method in `config.py` or default icons path. If such paths don't exist, only the editor's own icons will be built. Most module icons were moved from editor/icons to respective modules.
2019-06-28 22:42:26 +02:00
Reorganize code related to editor theming This change introduces a new EditorThemeManager class to abstract theme generatio and its subroutines. Logic related to EditorTheme, EditorColorMap, and editor icons has been extracted into their respective files with includes cleaned up. All related files have been moved to a separate folder to better scope them in the project. This includes relevant generated files as well.
2024-01-15 13:14:55 +01:00
env.Alias("editor_icons", [env.MakeEditorIconsBuilder("#editor/themes/editor_icons.gen.h", icon_sources)])
Reference in a new issue Copy permalink