godot/editor/SCsub

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

148 lines
4.6 KiB
Text
Raw Normal View History

#!/usr/bin/env python
Import("env")
env.editor_sources = []
2014-02-10 01:10:30 +00: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 16:34:09 +00:00
import glob
import editor_builders
import methods
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 06:28:55 +00:00
if env.editor_build:
2024-05-03 14:44:57 +00:00
# Generate doc data paths
def doc_data_class_path_builder(target, source, env):
paths = dict(sorted(source[0].read().items()))
data = "\n".join([f'\t{{"{key}", "{value}"}},' for key, value in paths.items()])
with methods.generated_wrapper(target) as file:
file.write(
f"""\
static const int _doc_data_class_path_count = {len(paths)};
struct _DocDataClassPath {{
const char *name;
const char *path;
}};
static const _DocDataClassPath _doc_data_class_paths[{len(env.doc_class_path) + 1}] = {{
{data}
{{nullptr, nullptr}},
}};
"""
)
env.CommandNoCache("doc_data_class_path.gen.h", env.Value(env.doc_class_path), env.Run(doc_data_class_path_builder))
# Register exporters
2024-05-03 14:44:57 +00:00
def register_exporters_builder(target, source, env):
platforms = source[0].read()
exp_inc = "\n".join([f'#include "platform/{p}/export/export.h"' for p in platforms])
exp_reg = "\n".join([f"\tregister_{p}_exporter();" for p in platforms])
exp_type = "\n".join([f"\tregister_{p}_exporter_types();" for p in platforms])
with methods.generated_wrapper(target) as file:
file.write(
f"""\
#include "register_exporters.h"
{exp_inc}
void register_exporters() {{
{exp_reg}
}}
void register_exporter_types() {{
{exp_type}
}}
"""
)
gen_exporters = env.CommandNoCache(
"register_exporters.gen.cpp", env.Value(env.platform_exporters), env.Run(register_exporters_builder)
)
for e in env.platform_exporters:
# Add all .cpp files in export folder
2024-05-03 14:44:57 +00:00
env.add_source_files(env.editor_sources, f"../platform/{e}/export/*.cpp")
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 16:34:09 +00:00
# Core API documentation.
2017-10-21 17:31:23 +00: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 16:34:09 +00:00
docs += Glob("#doc/classes/*.xml")
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 16:34:09 +00:00
# Module API documentation.
module_dirs = []
for d in env.doc_class_path.values():
if d not in module_dirs:
module_dirs.append(d)
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 16:34:09 +00:00
for d in module_dirs:
if not os.path.isabs(d):
docs += Glob("#" + d + "/*.xml") # Built-in.
else:
docs += Glob(d + "/*.xml") # Custom.
docs = sorted(docs)
env.Depends("#editor/doc_data_compressed.gen.h", docs)
env.CommandNoCache(
"#editor/doc_data_compressed.gen.h",
docs,
env.Run(editor_builders.make_doc_header),
)
# 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
# ratio (20% for the editor UI, 10% for the class reference).
# Generated with `make include-list` for each resource.
# Editor translations
tlist = glob.glob(env.Dir("#editor/translations/editor").abspath + "/*.po")
env.Depends("#editor/editor_translations.gen.h", tlist)
env.CommandNoCache(
"#editor/editor_translations.gen.h",
tlist,
env.Run(editor_builders.make_editor_translations_header),
)
# Property translations
tlist = glob.glob(env.Dir("#editor/translations/properties").abspath + "/*.po")
env.Depends("#editor/property_translations.gen.h", tlist)
env.CommandNoCache(
"#editor/property_translations.gen.h",
tlist,
env.Run(editor_builders.make_property_translations_header),
)
# Documentation translations
tlist = glob.glob(env.Dir("#doc/translations").abspath + "/*.po")
env.Depends("#editor/doc_translations.gen.h", tlist)
env.CommandNoCache(
"#editor/doc_translations.gen.h",
tlist,
env.Run(editor_builders.make_doc_translations_header),
)
# Extractable translations
tlist = glob.glob(env.Dir("#editor/translations/extractable").abspath + "/*.po")
tlist.extend(glob.glob(env.Dir("#editor/translations/extractable").abspath + "/extractable.pot"))
env.Depends("#editor/extractable_translations.gen.h", tlist)
env.CommandNoCache(
"#editor/extractable_translations.gen.h",
tlist,
env.Run(editor_builders.make_extractable_translations_header),
)
env.add_source_files(env.editor_sources, "*.cpp")
2024-05-03 14:44:57 +00:00
env.add_source_files(env.editor_sources, gen_exporters)
SConscript("debugger/SCsub")
SConscript("export/SCsub")
SConscript("gui/SCsub")
SConscript("icons/SCsub")
SConscript("import/SCsub")
SConscript("plugins/SCsub")
SConscript("project_manager/SCsub")
SConscript("themes/SCsub")
lib = env.add_library("editor", env.editor_sources)
env.Prepend(LIBS=[lib])