Open CristianoBarone opened 1 month ago
I'm not entirely familiar with SConstruct aside from building Redot a couple of times on my machine, so I have a few questions that might also help steer the discussion here
CMake/XMake are not capable to support this kinda project, alternative build systems are not a trivial thing to integrate either.
How easy would it be to construct builders for all desired platforms with a replacement like CMake/XMake? (Windows, macOS, Linux, Android)
In my experience, xmake is pretty versatile and show be able to support Android too (I know from experience it does support all the major OSs already)
Do we need to add anything to replace SCons' built-in language support or do we not use them?
I guess we don't use them? I'm not very familiar with SCons either, my issue stems from the fact that it's not trivial to setup for windows compilation and it isn't free from its caveats
Visual Studio project support seems to also be a part of SCons, would we need to find a solution to that?
Isn't it just a bunch of JSONs? I think that's the least problematic thing about it
CMake/XMake are not capable to support this kinda project
May I ask why is that?
CMake/XMake are not capable to support this kinda project, alternative build systems are not a trivial thing to integrate either.
Why?
CMake/XMake by themselves are not capable to support all the infrastructure involved, the buildsystem with SCons does not just rely upon building the binaries, (or building things alone, it also provides and extracts information and embeds data) and the python scripts are too intrinsic to how the engine's buildsystem works, (and rely heavily on Python and SCons behavior) if you tried to actually completely replace everything that SCons does with CMake or XMake, you'd find that it is wholly incapable and not designed to do the things that SCons is doing here. This is why the only viable alternative proposed for Godot was Meson because its a python written buildsystem too, maintaining the buildsystem with this complexity in CMake/XMake, a limited DSL cannot cope and it would mostly devolve into using python scripts like SCons already does, (only worse because it would not be able to properly extract the necessary information from those scripts) this ends up more complex because you're working around limitations that they were not designed to account for. There is a reason the CMake files that are in Godot are so limited and only do the barest of things. CMake can do many things, (it could feasibly even do this eventually) but when the buildsystem becomes complex enough there are a lot of cases where it simply does not cut it. (and I'm not saying it can't conceivable do so with enough eventual work, but that I'm not sure is worth it as it be too wasteful and lacking in benefits to justify)
I will also say I absolutely despise CMake, it has caused me enough headaches compared to most other buildsystems before that I really am not in the mood either to maintain a buildsystem on CMake, also GDExtensions rely on the continued use of SCons so swapping it out creates its own issues with anything that relies on redot-cpp or relied on godot-cpp, alongside the fact replacing it would constantly cause merge conflicts when we merge changes to the buildsystem from upstream.
I dont have an issue using scons it may not be as easy to setup within an ide if you arent used to it but it isnt overly complex. Ive been able to use scons reliably from vs code, visual studios, and clion. Windows platforms may be slightly harder but it isnt the fault of scons. Its that windows doesn't include a compiler or the windows sdk when installed. Nor does it have python installed initially. This is a drawback of how Windows is shipped and not a limitation of the scons buildsystem. No matter what buildsystem you use it will be just as convoluted to setup on windows. You will still need to install the windows sdk and compiler then you will have to install the buildsystem of choice and ensure that its been added correctly to the windows PATH environment variable.
The proposal to switch buildsystems seems to overlook the main issue on windows. The issue of setup could be addressed by a powershell script.
Don't. I am engineering builds, from my minimal interactions with C/C++ scons is fine for Godot's needs. One of the better options to be honest.
The proposal to switch buildsystems seems to overlook the main issue on windows. The issue of setup could be addressed by a powershell script.
This is the solution. Probably the limit of what can be done on windows.
@CristianoBarone would a windows powershell script that automates the installation of scons and windows compiler pipeline adequately address your concerns
Here is a script i made tested on a vm. https://github.com/RadenTheFolf/SCons-Install-Script
The vm was a fresh install of windows. Downloaded a zip of redot master. Placed the script in the directory withe the scons files and ran it.
it installs everything and immediately tests the build system by completing a first time build of the engine.
Describe the project you are working on
Build system
Describe the problem or limitation you are having in your project
The current build system, SCons, is not the best. For one, it's tricky to install for someone that has never used it and it does not provide pre-built binaries on Windows, not to mention that SCons is often rightfully regarded as slow.
Describe the feature / enhancement and how it helps to overcome the problem or limitation
Remove the old SCons configurations and replace them with a faster and more straightforward build system (like xmake, CMake or something else)
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
The SConstruct, version.py, scu_builders.py, gles3_builders.py, glsl_builders.py, .scons_env.json must be removed
If this enhancement will not be used often, can it be worked around with a few lines of script?
This enhancement is, at least in my opinion, critical to simplify the build progress and we cannot do otherwise if we don't want to use SCons.
Is there a reason why this should be core and not an add-on in the asset library?
It cannot be an asset