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

24 lines
530 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
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
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
from platform_methods import run_in_subprocess
import platform_osx_builders
Create separate debug info files by default Now that we have a built-in stacktrace on a segfault it would be useful to have debug information on debug_release builds so that bugreports can include this information. Without this debug info we will still get function names in the backtrace but not file location. This commit will by default build all targets with minimal debug info and then strip the information into separate files. On MacOS this is a .dSYM file, on Linux/MingW this is a .debug file. MacOSX will automatically load a dSYM file if it exists in its debugger. On Linux/MingW we create a 'gnu debuglink' meaning that gdb and friends will automatically find the debug symbols if they exist. Existing workflow for developers does not change at all, except that we now create two instead of one build artifact by default. This commit also adds a 'debug_symbols' option to X11, MacOS, and MingW targets. The default is 'yes' which corresponds to -g1. The alternatives are 'no' (don't generate debug infos at all) or 'full' which runs with -g2. A target=debug build will now build with -g3.
2017-09-13 19:32:24 +02:00
GODOT IS OPEN SOURCE
2014-02-10 02:10:30 +01:00
files = [
Added a crash handler to dump the backtrace on Windows, Linux and OS X
2017-09-08 03:01:49 +02:00
'crash_handler_osx.mm',
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
'os_osx.mm',
'godot_main_osx.mm',
'sem_osx.cpp',
'dir_access_osx.mm',
Finish replacement of joystick by joypad Some parts were forgotten in 547a577.
2017-01-08 21:29:57 +01:00
'joypad_osx.cpp',
Add API to access battery power state Done: - X11, server (tested) - Windows (developed, would be nice to retest) - OSX (not tested) Prepared (not developed): - Android (code is here, but may not compile) - iphone - winrt - bb10 - haiku - javascript
2016-07-23 13:15:55 +02:00
'power_osx.cpp',
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
]
GODOT IS OPEN SOURCE
2014-02-10 02:10:30 +01:00
disable caching for targets using helper functions
2017-11-28 21:27:57 +01:00
prog = env.add_program('#bin/godot', files)
use the same cache for all branches for appveyor
2017-11-27 14:39:05 +01:00
Make separate debug symbols opt-in This adds a separate_debug_symbols option to the x11, windows, and osx targets. This will default to adding normal debugging symbols to the artifacts and only splits them when separate_debug_symbols=yes on the Scons command line.
2018-01-26 20:46:56 +01:00
if (env["debug_symbols"] == "full" or env["debug_symbols"] == "yes") and env["separate_debug_symbols"]:
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.AddPostAction(prog, run_in_subprocess(platform_osx_builders.make_debug_osx))
Create separate debug info files by default Now that we have a built-in stacktrace on a segfault it would be useful to have debug information on debug_release builds so that bugreports can include this information. Without this debug info we will still get function names in the backtrace but not file location. This commit will by default build all targets with minimal debug info and then strip the information into separate files. On MacOS this is a .dSYM file, on Linux/MingW this is a .debug file. MacOSX will automatically load a dSYM file if it exists in its debugger. On Linux/MingW we create a 'gnu debuglink' meaning that gdb and friends will automatically find the debug symbols if they exist. Existing workflow for developers does not change at all, except that we now create two instead of one build artifact by default. This commit also adds a 'debug_symbols' option to X11, MacOS, and MingW targets. The default is 'yes' which corresponds to -g1. The alternatives are 'no' (don't generate debug infos at all) or 'full' which runs with -g2. A target=debug build will now build with -g3.
2017-09-13 19:32:24 +02:00
Reference in a new issue Copy permalink