Unable to build Godot with C# support and Godex #187
Comments
AndreaCatania
added
bug
|
I'm looking into this now out of interest, and I'm pretty sure it's because the mono glue generates a file called I haven't yet got the whole thing compiled and working, but you can fix the syntax errors in the glue manually (there are only a few) by using aliased imports for the relevant types, e.g. in
To the using directives, and then replace instances of However, I'm expecting this might cause further effects when trying to write C# scripts in Godot, so it may be better to somehow change how the glue is generated for the Godex classes so that the types don't clash. Alternatively I suspect if you build the initial binary without the Godex module, then generate the glue, then compile the final binary with Godex, it should build successfully (haven't tried it, but I'm 99% sure). Of course, you wouldn't then have a native mapping for Godex in C# which I guess is kinda the point of building it with Mono, though you could build a facade or adaptor or something manually. Going to continue playing with it and see what comes up. |
|
Btw, here is a git patch that you can apply to the generated glue to fix the syntax, so it should at least build. |
|
Note: We chatted about this in discord and we contacted the Godot team to have support for that, here the discord chat link: https://discord.com/channels/797456114404163625/797456114404163630/852560754611322930 |
Great! FWIW, Godot 4 is in the process of moving off of mono, onto dotnet6. It still uses a similar "generated glue" approach, but it could be different enough/more modern such that it avoids this issue. I've been testing out the dotnet6 branch recently but haven't tried to build godex on it. I've no idea if it'll make a difference, but I'll give it a go when I can. |
|
This is great!! Thx for the update, really appreciated 🙂🤙
…On Thu, 28 Apr 2022 at 21:20, Lewis James ***@***.***> wrote:
Note: We chatted about this in discord and we contacted the Godot team to
have support for that, here the discord chat link:
https://discord.com/channels/797456114404163625/797456114404163630/852560754611322930
Great!
FWIW, Godot 4 is in the process of moving off of mono, onto dotnet6. It
still uses a similar "generated glue" approach, but it could be different
enough/more modern such that it avoids this issue. I've been testing out
the dotnet6 branch recently but haven't tried to build godex on it. I've no
idea if it'll make a difference, but I'll give it a go when I can.
—
Reply to this email directly, view it on GitHub
<#187 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB7UYRZZQOCFOEJQ2VAUVCDVHLQIVANCNFSM46OOZS4A>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
Since |
|
I've 0 experience with C# but it seems that it's possible to use the C# namespace to fix it. In case case: What's the correct steps to fix this issue @neikeq? |
|
We definitely don't want to generate a class named One option is for the bindings' generator to just rename The other option is to generate a class named |
|
@AndreaCatania I think that's fine, since C# users will be using an ide that'll autocomplete anyway, so it's unlikely to cause confusion. Though the cleanest solution imo would be to prefix any Godex generated classes with Godex, to prevent any other clashes/potential future clashes of namespace. Some C++ libraries use this kind of system already in godot, for example the libicu library allows a flag to add a custom prefix to statically linked functions to prevent clashes, which was recently used to prevent a clash with the dotnet bundled icu. But I'm uncertain how simple it'd be for a module to implement it on their "side" of the build, rather than having to patch the C# bindings generator itself. Classdb metadata would be best in that case as @neikeq said, but I guess would take some work to get setup to have the bindings gen detect it and output the prefixed names. But overall I agree that simply having the generator rename with some kind of generic suffix/prefix is the simplest way and prevents any need for specific custom handling. |
|
I'll look into this next Saturday after I'm done with other tasks, and I need to make sure not to break code that assumes class names. |
|
This diff is a working update where I changed https://discordapp.com/channels/797456114404163625/865464299681349662/969402587340226570 |
|
@neikeq Nice, thx a lot! |
|
@FieldStudios If you managed to get it working already, you may submit a PR directly if you have some free time 🙌 |
|
I tried to write the "System_" solution by changing https://github.com/godotengine/godot/blob/master/modules/mono/editor/bindings_generator.h#L507 to This does generally work, but there are 2 problems:
|
|
This should be fixed in Godot 4.0+. Classes named |
|
You are right, it is. |
|
Does Godex work with 4.x ? |
From looking at the Setup and the Compiling with Mono Godot docs page, I ran the following commands to hopefully enable C# support along with Godex:
scons -j8 p=windows target=release_debug tools=yes module_mono_enabled=yes mono_glue=no custom_modules="../godex" mono_prefix="C:\Program Files\Mono"Glue generation:
.\bin\godot.windows.opt.tools.64.mono.exe --generate-mono-glue .\modules\mono\glueI receive the following errors when attempting to build with the glue:
scons -j8 p=windows target=release_debug tools=yes module_mono_enabled=yes mono_glue=yes custom_modules="../godex" mono_prefix="C:\Program Files\Mono"The text was updated successfully, but these errors were encountered: