mirror/godot
2
0
Fork 0
mirror of https://github.com/godotengine/godot.git synced 2024-12-27 11:24:59 +08:00
Code Issues Packages Projects Releases Wiki Activity
c1e9842afb
godot/platform_methods.py

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

248 lines
8.1 KiB
Python
Raw Normal View History

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-18 06:23:55 +08:00
import os
import sys
import json
Unify bits, arch, and android_arch into env["arch"] Fully removes the `bits` option and adapts the code that relied on it. Co-authored-by: Rémi Verschelde <rverschelde@gmail.com>
2021-12-16 09:38:10 +08:00
import platform
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-18 06:23:55 +08:00
import uuid
import functools
import subprocess
# NOTE: The multiprocessing module is not compatible with SCons due to conflict on cPickle
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 21:36:03 +08:00
JSON_SERIALIZABLE_TYPES = (bool, int, float, str)
Fixed Mac build by running builders in subprocess only on Windows Also passing serializable SCons environment variables (env) for compatibility with debug builds (search for uses of env in make functions)
2018-07-31 05:35:35 +08: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-18 06:23:55 +08:00
def run_in_subprocess(builder_function):
@functools.wraps(builder_function)
def wrapper(target, source, env):
# Convert SCons Node instances to absolute paths
target = [node.srcnode().abspath for node in target]
source = [node.srcnode().abspath for node in source]
Fixed short circuiting on non-Windows platforms
2018-07-31 05:55:15 +08:00
# Short circuit on non-Windows platforms, no need to run in subprocess
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 14:28:32 +08:00
if sys.platform not in ("win32", "cygwin"):
Fixed short circuiting on non-Windows platforms
2018-07-31 05:55:15 +08:00
return builder_function(target, source, env)
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-18 06:23:55 +08:00
# Identify module
module_name = builder_function.__module__
function_name = builder_function.__name__
module_path = sys.modules[module_name].__file__
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 14:28:32 +08:00
if module_path.endswith(".pyc") or module_path.endswith(".pyo"):
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-18 06:23:55 +08:00
module_path = module_path[:-1]
# Subprocess environment
subprocess_env = os.environ.copy()
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 14:28:32 +08:00
subprocess_env["PYTHONPATH"] = os.pathsep.join([os.getcwd()] + sys.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-18 06:23:55 +08:00
Fixed Mac build by running builders in subprocess only on Windows Also passing serializable SCons environment variables (env) for compatibility with debug builds (search for uses of env in make functions)
2018-07-31 05:35:35 +08:00
# Keep only JSON serializable environment items
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 14:28:32 +08:00
filtered_env = dict((key, value) for key, value in env.items() if isinstance(value, JSON_SERIALIZABLE_TYPES))
Fixed Mac build by running builders in subprocess only on Windows Also passing serializable SCons environment variables (env) for compatibility with debug builds (search for uses of env in make functions)
2018-07-31 05:35:35 +08: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-18 06:23:55 +08:00
# Save parameters
Fixed Mac build by running builders in subprocess only on Windows Also passing serializable SCons environment variables (env) for compatibility with debug builds (search for uses of env in make functions)
2018-07-31 05:35:35 +08:00
args = (target, source, filtered_env)
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-18 06:23:55 +08:00
data = dict(fn=function_name, args=args)
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 14:28:32 +08:00
json_path = os.path.join(os.environ["TMP"], uuid.uuid4().hex + ".json")
Enforce `\n` eol for Python writes • Ensure utf-8 encoding if previously unspecified
2024-03-10 04:29:24 +08:00
with open(json_path, "wt", encoding="utf-8", newline="\n") as json_file:
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-18 06:23:55 +08:00
json.dump(data, json_file, indent=2)
Fixed Mac build by running builders in subprocess only on Windows Also passing serializable SCons environment variables (env) for compatibility with debug builds (search for uses of env in make functions)
2018-07-31 05:35:35 +08:00
json_file_size = os.stat(json_path).st_size
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-28 02:00:26 +08:00
if env["verbose"]:
print(
"Executing builder function in subprocess: "
"module_path=%r, parameter_file=%r, parameter_file_size=%r, target=%r, source=%r"
% (module_path, json_path, json_file_size, target, source)
)
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-18 06:23:55 +08:00
try:
exit_code = subprocess.call([sys.executable, module_path, json_path], env=subprocess_env)
finally:
try:
os.remove(json_path)
Merge python EnvironmentError, IOError and WindowsError into OSError.
2020-09-02 22:58:07 +08:00
except OSError as e:
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-18 06:23:55 +08:00
# Do not fail the entire build if it cannot delete a temporary file
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 14:28:32 +08:00
print(
"WARNING: Could not delete temporary file: path=%r; [%s] %s" % (json_path, e.__class__.__name__, e)
)
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-18 06:23:55 +08:00
# Must succeed
if exit_code:
raise RuntimeError(
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 14:28:32 +08:00
"Failed to run builder function in subprocess: module_path=%r; data=%r" % (module_path, data)
)
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-18 06:23:55 +08:00
return wrapper
def subprocess_main(namespace):
with open(sys.argv[1]) as json_file:
data = json.load(json_file)
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 14:28:32 +08:00
fn = namespace[data["fn"]]
fn(*data["args"])
Unify bits, arch, and android_arch into env["arch"] Fully removes the `bits` option and adapts the code that relied on it. Co-authored-by: Rémi Verschelde <rverschelde@gmail.com>
2021-12-16 09:38:10 +08:00
# CPU architecture options.
architectures = ["x86_32", "x86_64", "arm32", "arm64", "rv64", "ppc32", "ppc64", "wasm32"]
architecture_aliases = {
"x86": "x86_32",
"x64": "x86_64",
"amd64": "x86_64",
"armv7": "arm32",
"armv8": "arm64",
"arm64v8": "arm64",
"aarch64": "arm64",
"rv": "rv64",
"riscv": "rv64",
"riscv64": "rv64",
"ppcle": "ppc32",
"ppc": "ppc32",
"ppc64le": "ppc64",
}
def detect_arch():
host_machine = platform.machine().lower()
if host_machine in architectures:
return host_machine
elif host_machine in architecture_aliases.keys():
return architecture_aliases[host_machine]
elif "86" in host_machine:
# Catches x86, i386, i486, i586, i686, etc.
return "x86_32"
else:
print("Unsupported CPU architecture: " + host_machine)
print("Falling back to x86_64.")
return "x86_64"
SCons: Move platform logo/run icon to `export` folder Follow-up to #75932. Since these icons are only used by the export plugin, it makes sense to move them and generate the headers there. The whole `detect.is_active()` logic seems to be a leftover from before times, as far back as 1.0-stable it already wasn't used for anything. So I'm removing it and moving the export icon generation to `platform_methods`, where it makes more sense.
2023-06-19 17:28:22 +08:00
def generate_export_icons(platform_path, platform_name):
"""
Generate headers for logo and run icon for the export plugin.
"""
export_path = platform_path + "/export"
svg_names = []
if os.path.isfile(export_path + "/logo.svg"):
svg_names.append("logo")
if os.path.isfile(export_path + "/run_icon.svg"):
svg_names.append("run_icon")
for name in svg_names:
svgf = open(export_path + "/" + name + ".svg", "rb")
b = svgf.read(1)
svg_str = " /* AUTOGENERATED FILE, DO NOT EDIT */ \n"
svg_str += " static const char *_" + platform_name + "_" + name + '_svg = "'
while len(b) == 1:
svg_str += "\\" + hex(ord(b))[1:]
b = svgf.read(1)
svg_str += '";\n'
svgf.close()
# NOTE: It is safe to generate this file here, since this is still executed serially.
wf = export_path + "/" + name + "_svg.gen.h"
Enforce `\n` eol for Python writes • Ensure utf-8 encoding if previously unspecified
2024-03-10 04:29:24 +08:00
with open(wf, "w", encoding="utf-8", newline="\n") as svgw:
SCons: Move platform logo/run icon to `export` folder Follow-up to #75932. Since these icons are only used by the export plugin, it makes sense to move them and generate the headers there. The whole `detect.is_active()` logic seems to be a leftover from before times, as far back as 1.0-stable it already wasn't used for anything. So I'm removing it and moving the export icon generation to `platform_methods`, where it makes more sense.
2023-06-19 17:28:22 +08:00
svgw.write(svg_str)
[iOS/macOS] Add option to automatically build (and sign / archive) bundles.
2023-12-12 02:50:44 +08:00
def get_build_version(short):
import version
name = "custom_build"
if os.getenv("BUILD_NAME") != None:
name = os.getenv("BUILD_NAME")
v = "%d.%d" % (version.major, version.minor)
if version.patch > 0:
v += ".%d" % version.patch
status = version.status
if not short:
if os.getenv("GODOT_VERSION_STATUS") != None:
status = str(os.getenv("GODOT_VERSION_STATUS"))
v += ".%s.%s" % (status, name)
return v
def lipo(prefix, suffix):
from pathlib import Path
target_bin = ""
lipo_command = ["lipo", "-create"]
arch_found = 0
for arch in architectures:
bin_name = prefix + "." + arch + suffix
if Path(bin_name).is_file():
target_bin = bin_name
lipo_command += [bin_name]
arch_found += 1
if arch_found > 1:
target_bin = prefix + ".fat" + suffix
lipo_command += ["-output", target_bin]
subprocess.run(lipo_command)
return target_bin
def get_mvk_sdk_path(osname):
def int_or_zero(i):
try:
return int(i)
except:
return 0
def ver_parse(a):
return [int_or_zero(i) for i in a.split(".")]
dirname = os.path.expanduser("~/VulkanSDK")
if not os.path.exists(dirname):
return ""
ver_min = ver_parse("1.3.231.0")
ver_num = ver_parse("0.0.0.0")
files = os.listdir(dirname)
lib_name_out = dirname
for file in files:
if os.path.isdir(os.path.join(dirname, file)):
ver_comp = ver_parse(file)
if ver_comp > ver_num and ver_comp >= ver_min:
# Try new SDK location.
lib_name = os.path.join(os.path.join(dirname, file), "macOS/lib/MoltenVK.xcframework/" + osname + "/")
if os.path.isfile(os.path.join(lib_name, "libMoltenVK.a")):
ver_num = ver_comp
lib_name_out = os.path.join(os.path.join(dirname, file), "macOS/lib/MoltenVK.xcframework")
else:
# Try old SDK location.
lib_name = os.path.join(
os.path.join(dirname, file), "MoltenVK/MoltenVK.xcframework/" + osname + "/"
)
if os.path.isfile(os.path.join(lib_name, "libMoltenVK.a")):
ver_num = ver_comp
lib_name_out = os.path.join(os.path.join(dirname, file), "MoltenVK/MoltenVK.xcframework")
return lib_name_out
def detect_mvk(env, osname):
mvk_list = [
get_mvk_sdk_path(osname),
"/opt/homebrew/Frameworks/MoltenVK.xcframework",
"/usr/local/homebrew/Frameworks/MoltenVK.xcframework",
"/opt/local/Frameworks/MoltenVK.xcframework",
]
if env["vulkan_sdk_path"] != "":
mvk_list.insert(0, os.path.expanduser(env["vulkan_sdk_path"]))
mvk_list.insert(
0,
os.path.join(os.path.expanduser(env["vulkan_sdk_path"]), "macOS/lib/MoltenVK.xcframework"),
)
mvk_list.insert(
0,
os.path.join(os.path.expanduser(env["vulkan_sdk_path"]), "MoltenVK/MoltenVK.xcframework"),
)
for mvk_path in mvk_list:
if mvk_path and os.path.isfile(os.path.join(mvk_path, osname + "/libMoltenVK.a")):
mvk_found = True
print("MoltenVK found at: " + mvk_path)
return mvk_path
return ""
Reference in New Issue Copy Permalink