maxmustermann/godot
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity
godot/modules/mono/SCsub

58 lines
1.8 KiB
Plaintext
Raw Normal View History

Added mono module
2017-10-02 23:24:00 +02:00
#!/usr/bin/env python
Re-write mono module editor code in C# Make the build system automatically build the C# Api assemblies to be shipped with the editor. Make the editor, editor player and debug export templates use Api assemblies built with debug symbols. Always run MSBuild to build the editor tools and Api assemblies when building Godot. Several bugs fixed related to assembly hot reloading and restoring state. Fix StringExtensions internal calls not being registered correctly, resulting in MissingMethodException.
2019-07-03 09:44:53 +02:00
import build_scripts.tls_configure as tls_configure
import build_scripts.mono_configure as mono_configure
Added mono module
2017-10-02 23:24:00 +02:00
Import('env')
Mono: Build in cloned env. Use a cloned env, so that toggling glue_enabled doesn't force a full rebuild as mentioned in #14584.
2017-12-12 16:18:55 +01:00
Import('env_modules')
env_mono = env_modules.Clone()
Added mono module
2017-10-02 23:24:00 +02:00
Mono/C#: Re-structure API solution and GodotTools post-build target Previously we had a placeholder solution called 'Managed' to benefit from tooling while editing the a part of the C# API. Later the bindings generator would create the final 'GodotSharp' solution including these C# files as well as the auto-generated C# API. Now we replaced the 'Managed' solution with the final 'GodotSharp' solution which is no longer auto-generated, and the bindings generator only takes care of the auto-generated C# API. This has the following benefits: - It's less confusing as there will no longer be two versions of the same file (the original and a generated copy of it). Now there's only one. - We no longer need placeholder for auto-generated API classes, like Node or Resource. We used them for benefiting from tooling. Now we can just use the auto-generated API itself. - Simplifies the build system and bindings generator. Removed lot of code that is not needed anymore. Also added a post-build target to the GodotTools project to copy the output to the data dir. This makes it easy to iterate when doing changes to GodotTools, as SCons doesn't have to be executed anymore just to copy these new files.
2019-12-28 19:12:32 +01:00
if env_mono['tools']:
Allow special characters in C# glue files Fixes #21139 - Surround the generated file modules/mono/glue/cs_compressed.gen.h with ifdef TOOLS_ENABLED
2018-09-04 22:13:47 +02:00
# NOTE: It is safe to generate this file here, since this is still executed serially
Mono/C#: Re-structure API solution and GodotTools post-build target Previously we had a placeholder solution called 'Managed' to benefit from tooling while editing the a part of the C# API. Later the bindings generator would create the final 'GodotSharp' solution including these C# files as well as the auto-generated C# API. Now we replaced the 'Managed' solution with the final 'GodotSharp' solution which is no longer auto-generated, and the bindings generator only takes care of the auto-generated C# API. This has the following benefits: - It's less confusing as there will no longer be two versions of the same file (the original and a generated copy of it). Now there's only one. - We no longer need placeholder for auto-generated API classes, like Node or Resource. We used them for benefiting from tooling. Now we can just use the auto-generated API itself. - Simplifies the build system and bindings generator. Removed lot of code that is not needed anymore. Also added a post-build target to the GodotTools project to copy the output to the data dir. This makes it easy to iterate when doing changes to GodotTools, as SCons doesn't have to be executed anymore just to copy these new files.
2019-12-28 19:12:32 +01:00
import build_scripts.gen_cs_glue_version as gen_cs_glue_version
gen_cs_glue_version.generate_header('glue/GodotSharp', 'glue/cs_glue_version.gen.h')
Added mono module
2017-10-02 23:24:00 +02:00
# Glue sources
Add and use mono build variables with cloned environment.
2018-02-11 04:48:46 +01:00
if env_mono['mono_glue']:
Cleanup of c# api files and bindings generator - We no longer generate RID and NodePath C# classes. Both will be maintained manually. - We no longer generate C# declarations and runtime registration of internal calls for the following classes: RID, NodePath, String, GD, SignalAwaiter and Godot.Object (partial base). - We no longer auto-generate the base members of Godot.Object. They will be maintained manually as a partial class. This makes it easier to maintain these C# classes and their internal calls, as well as the bindings generator which no longer generates C# classes that don't derive from Godot Object, and it no longer generates the Godot.Object base members (which where unreadable in the bindings generator code). - Added missing 'RID(Object from)' constructor to the RID C# class. - Replaced MONO_GLUE_DISABLED constant macro with MONO_GLUE_ENABLED. - Add sources in module/mono/glue even if glue is disabled, but surround glue files with ifdef MONO_GLUE_ENABLED.
2018-09-04 05:40:41 +02:00
env_mono.Append(CPPDEFINES=['MONO_GLUE_ENABLED'])
Added mono module
2017-10-02 23:24:00 +02:00
Mono: Reorganize build scripts All build scripts, other than config.py and SCSub, are now located in the build_scripts subdirectory.
2019-03-01 21:51:20 +01:00
import os.path
if not os.path.isfile('glue/mono_glue.gen.cpp'):
Re-write mono module editor code in C# Make the build system automatically build the C# Api assemblies to be shipped with the editor. Make the editor, editor player and debug export templates use Api assemblies built with debug symbols. Always run MSBuild to build the editor tools and Api assemblies when building Godot. Several bugs fixed related to assembly hot reloading and restoring state. Fix StringExtensions internal calls not being registered correctly, resulting in MissingMethodException.
2019-07-03 09:44:53 +02:00
raise RuntimeError("Mono glue sources not found. Did you forget to run '--generate-mono-glue'?")
Mono: Reorganize build scripts All build scripts, other than config.py and SCSub, are now located in the build_scripts subdirectory.
2019-03-01 21:51:20 +01:00
# Configure Thread Local Storage
Mono: Pending exceptions and cleanup
2018-06-26 21:03:42 +02:00
conf = Configure(env_mono)
tls_configure.configure(conf)
env_mono = conf.Finish()
Mono: Reorganize build scripts All build scripts, other than config.py and SCSub, are now located in the build_scripts subdirectory.
2019-03-01 21:51:20 +01:00
# Configure Mono
Added mono module
2017-10-02 23:24:00 +02:00
Mono: Add compiler flags to env_mono instead of env This way we avoid possible conflicts with other modules. Specially with include paths.
2019-03-01 22:00:39 +01:00
mono_configure.configure(env, env_mono)
Buildsystem improvements for the Mono module - Make sure to search the mono installation directory for the right architecture in the windows registry. - Do not build GodotSharpTools directly to #bin dir. Instead build to the default output path and copy it. This way we avoid MSBuild adding files we don't want to #bin. - Add hint path for MSBuild in OSX. - Copy shared library on Unix if not statically linking. - Use vswhere to search MSBuild and search for 14.0 tools version in the registry instead of 4.0. - SCons will only fallback xbuild when msbuild is not found if 'xbuild_fallback=yes' is passed to the command. - Use mono's assembly path as FrameworkPathOverride if using with system's MSBuild (not mono's fork). - Cleanup.
2017-10-24 22:47:27 +02:00
Add SCons option to not build C# solutions
2020-05-22 03:12:54 +02:00
if env_mono['tools'] and env_mono['mono_glue'] and env_mono['build_cil']:
Mono/C#: Re-structure API solution and GodotTools post-build target Previously we had a placeholder solution called 'Managed' to benefit from tooling while editing the a part of the C# API. Later the bindings generator would create the final 'GodotSharp' solution including these C# files as well as the auto-generated C# API. Now we replaced the 'Managed' solution with the final 'GodotSharp' solution which is no longer auto-generated, and the bindings generator only takes care of the auto-generated C# API. This has the following benefits: - It's less confusing as there will no longer be two versions of the same file (the original and a generated copy of it). Now there's only one. - We no longer need placeholder for auto-generated API classes, like Node or Resource. We used them for benefiting from tooling. Now we can just use the auto-generated API itself. - Simplifies the build system and bindings generator. Removed lot of code that is not needed anymore. Also added a post-build target to the GodotTools project to copy the output to the data dir. This makes it easy to iterate when doing changes to GodotTools, as SCons doesn't have to be executed anymore just to copy these new files.
2019-12-28 19:12:32 +01:00
# Build Godot API solution
Re-write mono module editor code in C# Make the build system automatically build the C# Api assemblies to be shipped with the editor. Make the editor, editor player and debug export templates use Api assemblies built with debug symbols. Always run MSBuild to build the editor tools and Api assemblies when building Godot. Several bugs fixed related to assembly hot reloading and restoring state. Fix StringExtensions internal calls not being registered correctly, resulting in MissingMethodException.
2019-07-03 09:44:53 +02:00
import build_scripts.api_solution_build as api_solution_build
Mono/C#: Prevent SCons from building API solutions in parallel
2019-11-22 23:42:24 +01:00
api_sln_cmd = api_solution_build.build(env_mono)
Buildsystem improvements for the Mono module - Make sure to search the mono installation directory for the right architecture in the windows registry. - Do not build GodotSharpTools directly to #bin dir. Instead build to the default output path and copy it. This way we avoid MSBuild adding files we don't want to #bin. - Add hint path for MSBuild in OSX. - Copy shared library on Unix if not statically linking. - Use vswhere to search MSBuild and search for 14.0 tools version in the registry instead of 4.0. - SCons will only fallback xbuild when msbuild is not found if 'xbuild_fallback=yes' is passed to the command. - Use mono's assembly path as FrameworkPathOverride if using with system's MSBuild (not mono's fork). - Cleanup.
2017-10-24 22:47:27 +02:00
Mono/C#: Re-structure API solution and GodotTools post-build target Previously we had a placeholder solution called 'Managed' to benefit from tooling while editing the a part of the C# API. Later the bindings generator would create the final 'GodotSharp' solution including these C# files as well as the auto-generated C# API. Now we replaced the 'Managed' solution with the final 'GodotSharp' solution which is no longer auto-generated, and the bindings generator only takes care of the auto-generated C# API. This has the following benefits: - It's less confusing as there will no longer be two versions of the same file (the original and a generated copy of it). Now there's only one. - We no longer need placeholder for auto-generated API classes, like Node or Resource. We used them for benefiting from tooling. Now we can just use the auto-generated API itself. - Simplifies the build system and bindings generator. Removed lot of code that is not needed anymore. Also added a post-build target to the GodotTools project to copy the output to the data dir. This makes it easy to iterate when doing changes to GodotTools, as SCons doesn't have to be executed anymore just to copy these new files.
2019-12-28 19:12:32 +01:00
# Build GodotTools
Re-write mono module editor code in C# Make the build system automatically build the C# Api assemblies to be shipped with the editor. Make the editor, editor player and debug export templates use Api assemblies built with debug symbols. Always run MSBuild to build the editor tools and Api assemblies when building Godot. Several bugs fixed related to assembly hot reloading and restoring state. Fix StringExtensions internal calls not being registered correctly, resulting in MissingMethodException.
2019-07-03 09:44:53 +02:00
import build_scripts.godot_tools_build as godot_tools_build
Mono/C#: Re-structure API solution and GodotTools post-build target Previously we had a placeholder solution called 'Managed' to benefit from tooling while editing the a part of the C# API. Later the bindings generator would create the final 'GodotSharp' solution including these C# files as well as the auto-generated C# API. Now we replaced the 'Managed' solution with the final 'GodotSharp' solution which is no longer auto-generated, and the bindings generator only takes care of the auto-generated C# API. This has the following benefits: - It's less confusing as there will no longer be two versions of the same file (the original and a generated copy of it). Now there's only one. - We no longer need placeholder for auto-generated API classes, like Node or Resource. We used them for benefiting from tooling. Now we can just use the auto-generated API itself. - Simplifies the build system and bindings generator. Removed lot of code that is not needed anymore. Also added a post-build target to the GodotTools project to copy the output to the data dir. This makes it easy to iterate when doing changes to GodotTools, as SCons doesn't have to be executed anymore just to copy these new files.
2019-12-28 19:12:32 +01:00
godot_tools_build.build(env_mono, api_sln_cmd)
Fix 'android_mono_config.gen.cpp' not compiled first time it's generated
2019-08-26 17:46:57 +02:00
# Add sources
env_mono.add_source_files(env.modules_sources, '*.cpp')
env_mono.add_source_files(env.modules_sources, 'glue/*.cpp')
env_mono.add_source_files(env.modules_sources, 'mono_gd/*.cpp')
env_mono.add_source_files(env.modules_sources, 'utils/*.cpp')
Mono/C#: Add iOS support Right now, games only work on devices when exported with FullAOT+Interpreter. There are some issues left that need to addressed for FullAOT alone. Right now, it's giving issues with the Godot.NativeCalls static constructor.
2020-03-11 01:34:10 +01:00
env_mono.add_source_files(env.modules_sources, 'mono_gd/support/*.cpp')
if env['platform'] in ['osx', 'iphone']:
env_mono.add_source_files(env.modules_sources, 'mono_gd/support/*.mm')
env_mono.add_source_files(env.modules_sources, 'mono_gd/support/*.m')
Fix 'android_mono_config.gen.cpp' not compiled first time it's generated
2019-08-26 17:46:57 +02:00
if env['tools']:
env_mono.add_source_files(env.modules_sources, 'editor/*.cpp')
Reference in a new issue Copy permalink