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

36 lines
1.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
GODOT IS OPEN SOURCE
2014-02-10 02:10:30 +01: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
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
from platform_methods import run_in_subprocess
import main_builders
Restored (And auto-generated) splash image
2017-04-10 01:02:04 +02:00
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
env.main_sources = []
SCons: Fix uses of [].append instead of env.add_source_files() Also added support for SCons project-absolute paths (starting with #) and warning about duplicates in add_source_files(), and fixed default_controller_mappings.gen.cpp being included twice after first build due to *.cpp globbing. Part of #30270.
2019-07-22 13:57:39 +02:00
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
env.add_source_files(env.main_sources, "*.cpp")
GODOT IS OPEN SOURCE
2014-02-10 02:10:30 +01:00
Gamepad: Fix parsing order for SDL2 controller databases We were overriding values from `gamecontrollerdb.txt` (current, updated upstream) with `gamecontrollerdb_205.txt` (legacy, SDL 2.0.5) and then `gamecontrollerdb_204.txt` (legacy, SDL 2.0.4). There was a comment to warn about this but it seems it did not prevent using the wrong order for all this time... Now `gamecontrollerdb.txt` mappings will properly override outdated ones present in the `204` and `205` variants.
2020-01-08 12:23:37 +01:00
# Order matters here. Higher index controller database files write on top of lower index database files.
Input: Drop obsolete versions of SDL gamecontrollerdb The 204 and 205 are the older, SDL 2.0.4 and 2.0.5 compatible mappings, but since all new mappings have only been added to the main gamecontrollerdb.txt which overrides the older entries, it doesn't make much sense for us to keep the old databases. We do not support the SDL2 half axes and inverted axes features from gamecontrollerdb.txt, but this only impacts the specific controllers which can use those features, the rest are parsed and used properly. As for godotcontrollerdb.txt, it doesn't make sense for us to maintain our own custom mappings instead of submitting them upstream. The only exception is the Javascript and UWP platforms for which no bindings are available upstream, so we keep those entries. (cherry picked from commit 510e83498e768ffbec8177f18a50180de828b844)
2020-04-28 14:42:00 +02:00
controller_databases = ["#main/gamecontrollerdb.txt", "#main/godotcontrollerdb.txt"]
Generate controller mapping class from one or more SDL2 database files
2018-03-06 04:10:17 +01:00
env.Depends("#main/default_controller_mappings.gen.cpp", controller_databases)
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
env.CommandNoCache("#main/default_controller_mappings.gen.cpp", controller_databases, run_in_subprocess(main_builders.make_default_controller_mappings))
Generate controller mapping class from one or more SDL2 database files
2018-03-06 04:10:17 +01:00
SCons: Fix uses of [].append instead of env.add_source_files() Also added support for SCons project-absolute paths (starting with #) and warning about duplicates in add_source_files(), and fixed default_controller_mappings.gen.cpp being included twice after first build due to *.cpp globbing. Part of #30270.
2019-07-22 13:57:39 +02:00
# Don't warn about duplicate entry here, we need it registered manually for first build,
# even if later builds will pick it up twice due to above *.cpp globbing.
env.add_source_files(env.main_sources, "#main/default_controller_mappings.gen.cpp", warn_duplicates=False)
Generate controller mapping class from one or more SDL2 database files
2018-03-06 04:10:17 +01:00
BuildSystem: generated files have .gen.extension
2017-06-23 17:03:41 +02:00
env.Depends("#main/splash.gen.h", "#main/splash.png")
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
env.CommandNoCache("#main/splash.gen.h", "#main/splash.png", run_in_subprocess(main_builders.make_splash))
Restored (And auto-generated) splash image
2017-04-10 01:02:04 +02:00
fixed reference to splash file
2017-12-16 20:20:36 +01:00
env.Depends("#main/splash_editor.gen.h", "#main/splash_editor.png")
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
env.CommandNoCache("#main/splash_editor.gen.h", "#main/splash_editor.png", run_in_subprocess(main_builders.make_splash_editor))
Added custom editor splash (including sponsor logo).
2017-12-16 20:11:13 +01:00
BuildSystem: generated files have .gen.extension
2017-06-23 17:03:41 +02:00
env.Depends("#main/app_icon.gen.h", "#main/app_icon.png")
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
env.CommandNoCache("#main/app_icon.gen.h", "#main/app_icon.png", run_in_subprocess(main_builders.make_app_icon))
Restored (And auto-generated) splash image
2017-04-10 01:02:04 +02:00
SCons: do not build tests with tools=no This doesn't affect the resulting binary size, but allows to save a phew seconds during compilation if building export templates.
2019-09-26 13:56:27 +02:00
if env["tools"]:
SConscript('tests/SCsub')
Move tests again from core to main As advised by @reduz, as tests depend on other libs.
2017-01-08 21:33:23 +01:00
disable caching for targets using helper functions
2017-11-28 21:27:57 +01:00
lib = env.add_library("main", env.main_sources)
GODOT IS OPEN SOURCE
2014-02-10 02:10:30 +01:00
env.Prepend(LIBS=[lib])
Reference in a new issue Copy permalink