please make new binaries

[Favkis]

I am too dumb to compile myself but enjoying making a game with this module a lot, however I need new signal to code loading modified terrain, but this signal is only in new version and there are no binaries for that

[Zylann]

I only know how to make binaries for Windows atm. The current binaries were made by @tinmanjuggernaut . Would be nice to be able to setup CI to have master builds but I don't know well how to set this up.

[TokisanGames]

@Favkis You aren't too dumb to compile Godot yourself. It isn't difficult to build on your own system. Don't let impatience ruin a good learning opportunity. The directions that Godot has provided are very good, and the instructions we have provided are fine.

@Zylann Building a complete cross-platform build environment for Godot is quite cumbersome and time consuming, even using the dockers. I don't recommend it. However I do recommend setting up a Linux dual boot or VM just so you can build for linux using GCC on your system.

I've been very busy for a while, working on a game. When that's done, I'll probably make one more binary release. Maybe they'll finally approve my noise patches.

[Favkis]

@tinmanjuggernaut you're right, I compiled godot both 3.2.2 and 4.0 and it wasn't hard. However compiling godot 3.2.2 with godot_voxel module gives me errors:

[  6%] Compiling ==> modules\register_module_types.gen.cpp
[  6%] register_module_types.gen.cpp
[  7%] modules\register_module_types.gen.cpp(159): error C3861: register_voxel_tool_types: идентификатор не найден
modules\register_module_types.gen.cpp(289): error C3861: unregister_voxel_tool_types: идентификатор не найден
[ 41%] Compiling ==> modules\voxel_tool\voxel_string_names.cpp
voxel_string_names.cpp
[ 41%] Compiling ==> modules\voxel_tool\meshers\blocky\voxel.cpp
[ 41%] Compiling ==> modules\voxel_tool\meshers\blocky\voxel_library.cpp
[ 41%] voxel.cpp
[ 41%] Compiling ==> modules\voxel_tool\meshers\blocky\voxel_mesher_blocky.cpp
voxel_library.cpp
[ 41%] 
[ 41%] scons: *** [modules\register_module_types.gen.windows.tools.64.obj] Error 2
Compiling ==> modules\voxel_tool\meshers\transvoxel\transvoxel_tables.cpp
voxel_mesher_blocky.cpp
transvoxel_tables.cpp
scons: building terminated because of errors.

идентификатор не найден is identifier not found.

[Zylann]

Looks like you didn't do step 4 as explained here https://github.com/Zylann/godot_voxel/blob/master/doc/02_build-voxel-tools.md#add-voxel-tools The module's folder must be voxel.

[Favkis]

@Zylann yes, my bad, as I said too dumb, I couldn't even find these instructions

[Zylann]

Maybe we could use Github actions and use something like this https://github.com/GodotExplorer/ECMAScript/blob/master/.github/workflows/build.yml Or this https://github.com/touilleMan/godot-python/blob/master/.azure-pipelines.yml It probably won't be signed like the official distro though. Still no much time to dedicate to this

[TokisanGames]

The challenge isn't just a couple builds. Binaries aren't completely useful without export templates.

There are scripts that setup the build environment. That means building a system that cross compiles Godot for windows 32/64, windows mono 32/64, osx/64, osx mono/64, Linux 32/64, Linux mono 32/64. And that's just the editor. Then all those again plus 4x android, ios, and Javascript for both release and debug export templates.

If it works perfectly, it takes about 7-10 hours of compiling and downloading, 50gb of working space, 25+ of storage just to setup the environment. And it rarely works perfectly so requires tons of tinkering on each platform just to get it setup. And windows/mono on Linux doesn't even reliably produce working executables, even with the official build scripts, and have to be specially handled.

The actual building of Godot is easy. But then packaging up all of the export templates and binaries to match the official releases is another time consuming ordeal. I spent a month just setting up my build environment, build scripts, and improving the official build scripts.

Unfortunately the build environment is a moving target. So even this setup breaks every so often as the devs turn the build scripts upside down.

So that's why I don't recommend it. You could try some automated setup, but it's going to need a lot of options to produce three desktop platforms, plus mono options, plus export templates.

I think the best solution is for individuals to build the platforms they need, themselves. I could probably make one more 3.2 release in a while, assuming my build environment still works. But I doubt I will do much with 4.0.

[Zylann]

This is one of the reasons I would like to switch everything to GDNative, unfortunately there are more reasons not to atm.

[Zylann]

FYI, I enabled artifacts on CI scripts, so "nightly builds" of the editor are available for Windows and Linux (see README.md).

[Zylann]

Closing this because it's quite old. Dev builds are available on Github Actions, and I started adding Github Releases.