Consider moving the buildsystem to Meson or another build system #16014
Comments
|
For what I understand, the buildsystem tooling must provide:
I don't know Meson, but if it provides everything above it should be fine (if I didn't forget something). Of course, someone has to go the excruciating pain of rewriting the buildsystem in Meson and then show the tooling and build times are effectively better for Godot than SCons. Note that a few third-party dependencies requires a patch to be compiled with Godot. I noticed Wrap has a patch support, but it looks like the patch must be available somewhere to download, while I think it's easier to manage if they are still part of the repository. Also, some of them require special compilation flags that should not be applied to the whole build. |
|
I think such a proof-of-concept would be very valuable because
For the second point, this means we can see the difference in build speed for Godot, we can see how much easier (or more complex) our build scripts become, and we can compare the differences more easily to make a choice instead of making educated guesses based on what whe think it could offer. -- Now, personally, I have to say I'm neither for nor against this, but I think there are more low-hanging fruit to chase instead of (or before?) changing the entire build system. Especially at this critical point in time, where as many hands as possible are needed to make sure 3.0 and the first patches are in the best shape possible. But if we want to improve the build system, I'd look at the CI build times and the hassle of the Mono build situation. (I think these are on akien's TODO/list of aggrievances?) Also, the bugged parallel builds on Windows suck, but that is more on a personal would-be-nice-if-it-was-fixed basis. TL;DR:
My opinions. :) |
|
I absolutely do believe that getting 3.0 out there and focusing on the following releases (3.0.1, 3.1) should take priority over this, for the record. And ultimately, SCons really does "just work" which for most developers out there will probably be good enough, so while this is something that I hope does eventually happen, I'm not holding out my breath for it for 3.1 or even 3.2, if it even garners enough support to actually end up being worked on to begin with. All this said, I might kickstart the POC later this week in my fork, for those who are willing to follow the progress on that (and likely help me out, as I don't have a huge amount of experience writing build systems), but I won't be opening a pull request for this for a while most likely. |
|
I dont really find SCons to be slow, and its flexibility (which we take a ton of advantage of) is probably unmatched by anything else. SCons is also extremely proven, i find it that it never screws up a build. Honestly, unless someone volunteers to rewrite the whole build system (not just a proof of concept), and shows that it's either simpler (a lot less code) or much faster, I would not even consider anything else, not even a bit. |
That's not really detrimental for this change. I mean, most of Godot contributors work on free time and work on what they want. For @NullConstant's case it seems is either "do this or do nothing" (not saying you don't want to fix things, just that it's harder to work with the actual C++ code base and bug hunt on something unfamiliar), so doing this is a good thing in general. Also, the "there are better things to do" argument is the way to have nothing done IMO. Of course nothing will be merged until we are confident that it won't break stuff and won't be done close to a release. I agree there are more important stuff, but it doesn't mean this can't be started. The thing is that someone working on this will likely have to do this alone. Of course specific questions can be answered by the core devs, but anymore than that won't happen. That's why SCons was never considered to be replaced: no one so far wanted to get the hands dirty. Like I said about Bullet before: someone has to get it to work and prove it's possible and better, otherwise we will stay with the status quo. |
|
I do think SCons is slow though. Not much slow, but things like the progress status and the cache make it slower for rebuilds (using disk I/O to read from the cache makes it slow), so I disable those when rebuilding. It does take a bit to start doing stuff, after that it's quite fast. Don't know if Meson will be significantly faster, but if someone is willing to try I'm not against it. |
|
Oh sure, if someone takes the time to do it and shows that its an improvement big enough to warrant switching, I'm all for it :) |
|
Like I said, I'm not really equipped to deal with hunting C++ bugs or adding new features on that front, so I'm okay with doing this instead. I suppose that this gives me (and/or anyone else working on this in the future) a pretty clean, two-fold goal to reach for:
And I suppose that SCons' speed is not terrible-terrible (the bulk of the time of the build process is from the actual linking and compiling anyway, so the slowdown from the overhead of the build system is likely somewhat negligible), but it certainly could be improved, and offering Meson as an alternative might just be that improvement. We'll see. |
|
The biggest issue is probably replacing the python build scripts for autogenerating code like the shaders, it doesn't seem like meson has a feature like that. |
It should not be an alternative, either we move to it if it's clearly better, or we don't even offer it. Having to support two build systems is crazy. |
|
Right, that's fair. I'm gonna start hacking away at it over the next few days/weeks, see if this goes anywhere and whether it's an effort truly worth pursuing (even if I end up being the only person working on it that whole time). I'll report back if I get anything presentable (like a benchmark). |
|
Although, not meson, I'll make a test in the coming weeks to see what it takes to build godot under bazel for windows 64 bit under msvc. Bazel is another system whose advantage is a shorter build description and faster builds. Also it's maintained by Google so it's not going anywhere. |
|
Anyway, I can't verify that, but it's very likely that 99% of the computational time spend to build Godot is spent in the compiler. So even if the overhead of the building software was none, this would lead to a 1% decrease of the build time. Even a 5% decrease would not be worth, unless it allows less code and more reliability (or if I'm proven wrong :) ). |
|
For raw build speed of a clean clone, I doubt it'll have any significant difference. But it can be significant if you consider rebuild speeds. SCons always rebuilds a lot of stuff that weren't changed when I pull a new commit (especially OpenSSL and Bullet, which are both big libraries and take a while to build). As I said before, SCons is slow to start (takes a few seconds before really start compiling). If you're building the whole source that's negligible, but if you only changed a line and are compiling to test, it can significantly improve the workflow (which IMO is what most matter in the buildsystem: help the people who work with the code). So 5s decreased in a 10min build is irrelevant, but 5s decreased in a 10s rebuild is a major improvement. But I agree that any change in this regard should be tested a lot to prove it works. As @reduz stated, SCons never messed up a build, and that's something to consider. |
There is even a growing Wikipedia category of "things Google discontinued". :) |
|
@mhilbrunner Nope it is still maintained https://github.com/bazelbuild/bazel |
|
Their point was that just because google made it, doesn't mean it'll be around for a long time. |
|
Since we have embraced C# for game development, we might as well try something like Cake. I haven't tried it myself though, so I'm interested in what are your thoughts on that one. For one thing, at least, scripts wold run faster than with Python. |
I'm not sure if requiring a Mono installation to compile Godot is a good idea, considering that Godot is mostly a C++ project and can be compiled without C# support. The level of performance offered by Meson or CMake (with the Ninja generator) should be more than enough for Godot's purposes. |
|
@Calinou you are probably right, although it seems everybody has jumped on the C# bandwagon, personally I'm using it for game scripting with Godot and productivity apps with Xamarin.Forms, also if I really want to squeeze performance I can try something like an IL2cpp converter or jump right into C++. I'm also thinking to use the mono/csharp REPL and ASP.net for things that I'd normally use JavaScript, Python or PHP for, like for instance web development related stuff or shell scripting. The thing is that I wouldn't mind to have a build system based on C# either, since I'd be already using it for pretty much everything. At least for my it would be the end of "dammit... another language I need to learn... why don't they stick with C++ and -insert decent dynamic/managed language here-" Edit: To clarify, requiring the Mono Framework to be installed in order to build Godot doesn't sound as bad to me, since the so called AAA game engines require way more disk space:
Besides, we could hardcode Mono support in the editor by default and have some logic to detect whether to support C# scripting or not at runtime, and ask for the Mono framework or the appropriate export templates. |
|
I love CMake, and meson looks cool, but I tend to agree with this article: http://www.rojtberg.net/1481/do-not-use-meson. |
|
I'm very interested in doing the footwork to move Godot to Meson. The only thing currently stopping me from contributing to Godot (and using it) is Scons. I had to use it years ago, and I've never had a more painful incremental development experience in my entire life. The article linked above has a lot of strawman arguments, arguing that CMake already exists and we should just use that. Meson's build files are extremely easy to read, and use a syntax close to that of Python. Conversion can be quick. What I'm posting in this thread for is, if the footwork was done, would a pull request even be considered for merging? |
It will be considered, but it has to be proven advantageous over SCons. |
|
Once you consider CMake just another build system and not the de facto standard, you end up with too many options. Why meson over SCons? Or bazel/buck are decent tools as well? But the biggest argument I have in favor of CMake is the tooling built to support that ecosystem. Clang compilation databases, support for packaging to multiple operating systems, etc. The only valid downsides I have heard is bad syntax and docs, but that isn't really strong enough for me to change my position on this. |
Meson generates ninja files, which is much faster for incremental development. Additionally, on windows, you don't need to do any sort of visual studio path manipulation. Meson works out of the box. Using meson over scons would reduce a lot of the overhead of targeting windows, especially for those wanting to use visual studio (of which, I should note, meson can generate projects just as CMake)
Given that bazel and buck are both written in Java (a dependency godot has only if you'll be targeting android, and even then one could technically use just the NDK), I would argue they're right out as a primary dependency for all users. Python is already in the dependency list, and you can easily install meson (and ninja) through a quick
Meson supports this by default, as this is a default feature built into ninja
Meson also has support for this, and relies heavily on pkg-config where appropriate
Meson has a very python-like syntax, relying on variables, objects, and builtin functions. In my opinion, writing my_meson_list = ['x', 'y', 'z']
message(my_meson_list)vs set(MY_CMAKE_LIST "x;y;z")
message(STATUS ${MY_CMAKE_LIST})is a lot easier, especially given how cmake is sometimes case sensitive, and other times not. When you start to get into generator expressions, it can get extremely hairy. # In one file
set(USE_STD_CXX11 "-std=c++11")
set(USE_STDLIB_LIBCXX "-stdlib=libc++")
# Possibly elsewhere
set(LIBCXX $<BOOL:${CAN_USE_STDLIB_LIBCXX}>,$<BOOL:${BUILD_WITH_LIBCXX}>)
set(NO_RTTI $<BOOL:${CAN_USE_NO_RTTI}>,$<BOOL:${DISABLE_RTTI}>)
# Later on...
target_compile_options(my-exe
PUBLIC
$<$<BOOL:${CAN_USE_STD_CXX11}>:${USE_STD_CXX11}>
$<$<AND:${LIBCXX}>:${USE_STDLIB_LIBCXX}>
$<$<AND:${NO_RTTI}>:${USE_NO_RTTI}>
# Oh yeah, you're gonna want more of these, because you can't trust compiler interfaces
)
# Generator expressions mean you can't follow the flow of the build to see what is called and defined where. This is a completely valid use of CMake.
check_cxx_compiler_flag(${USE_STDLIB_LIBCXX} CAN_USE_STDLIB_LIBCXX)
check_cxx_compiler_flag(${USE_NO_RTTI} CAN_USE_NO_RTTI)The equivalent meson looks like: cxx = meson.get_compiler('cpp')
# This is an extremely simplified approach. One can do a different option when dealing with MSVC and gcc support.
args = compiler.get_supported_arguments('-std=c++11', '-stdlib=libc++')
add_project_arguments(args)I think I should note, by the way, that of all the C++ build systems out there, Meson is the least terrible. Arguments against its use tend to be a picture of a web comic, some hand waving about how CMake is the most used, so you should just deal with it, and "hey at least CMake isn't autotools". But above all (and I think this is a really important thing, especially for those using godot as for gdnative), Meson supports precompiled headers natively. CMake does not (and using cotire to hack the build can cause more problems than its worth). I cannot tell you how much this could speed up the build for gdnative users, but it will be a significant boost on gcc and msvc (at the very least, a performance increase on msvc is inevitable). Add in the use of |
Note that CMake can also generate Ninja build files instead of traditional Makefiles; this is done by passing Meson still wins in the raw performance comparisons I've seen, but this definitely helps close the gap between Meson and CMake performance. |
|
Yes, however, CMake does not automatically install ninja for you, and it is not the default generator. Most of CMake's time is spent configuring the project, in my experience, and while recent versions of CMake have vastly improved performance, not everyone will have the latest CMake. |
|
Just wanted to add that the latest version of CMake is adding some of the missing features people mentioned earlier as reasons to not use it. |
|
@Nosliwnayr Both of those have been supported by addons for many years, they are well tested and wanted enough now to be included. Those were never reasons not to use CMake as you've been able to do both in CMake for a very long time. |
|
@bdbaddog i hope the compile times can be optimized further, being able to compile c++ code near instantly with no tricks would be a god send - after seeing how fast godot compiles, i'm really struggling to go back to the unreal engine 4 (compiling it, took me 45 minutes, but now the engine somehow got more bloated, and it takes up to 60 minutes, which is fucking insane) i mean i think godot has the potential to compile even faster, and i would replace the build system myself, but i have 0 experience, so i literally would have no idea as to what to do @Nosliwnayr they also making sharing projects, way more annoying, and it's just never ending bloat, with too many downsides in my mind - but hey, if someone used them effectively, i'm cool, but to me they seem like a dirty trick, instead of a true optimization, and i don't like cheap tricks to be honest after using the unreal engine 4, i'm tired of 20 GBs worth of pre compiled bullshit, i just don't think they are worth it, there has to be a less stupid system (the unreal engine 4, took up to 60 - 80 GBs for me, not cool) if godot heads into that direction, i'll asume that the developers have lost their god damn minds hell, fuck it, i'd rather have them stick to scons, if it avoids the unreal engine 4's ball of insanity, i think the smarter approach, would be to improve scons, instead of outright replacing it, with a whole new broken ass compiling system, when the current one works... more or less i think the mental effort required, in order to shove in a brand new system, is way higher, than just improving on what we already have, and the new compiler, might end up being functionally broken for months i sure as hell am not going to complain if it gets done though, but with such a critical engine component, you pretty much have to go all in, there's no turning back once this changes |
|
@RaTcHeT302 - The command line specified is if you wanted to explicitly only compile a single target (in this case an object file) (and of course the files it depends on) Indeed if all the folks complaining about issues with SCons would contribute to helping fix them rather than suggesting switching a complicated build system to another newer shinier one.. well many of such concerns would be fixed.. |
|
@bdbaddog Scons does not generate intermediate stage build files. It does the "project dependency" step in the same step as it does compile, and they cannot be separated. Its like telling CMake to generate the project files everytime before you hit your build tool, whether it be MSVC, ninja-build, make, llvm, pick your poison. If I switch git branches, I cannot update visual studio without performing a scons command line build to regenerate the proper .vsproj and .sln files - and I almost always clean build branch changes since I have ran into issues in the past. Those intermediate files arent just for building, they can be used by static analyzers and other projects as well. While I agree that cmake isn't perfect (I don't like it as much myself), and I would prefer the flexibility of python, cmake has the best integration and support of all the build tools on the table. |
|
When converting my fork to CMake most of the complexity was in the code generation files. The idea that the build is complicated is a fallacy. The build doesn't need scons because its complex. It's complex because it uses scons. With that said, the reason I halted work is because I met with the lead devs at GDC in 2019 (at the GitHub meetup) and they said they have absolutely no intention of switching to something more usable, citing that they'd prefer to do the build entirely on linux and indeed from what I've seen they're violating the EULA that Apple requires acceptance of to install build tools for cross compiling. The mentality of those in charge is very much "ends justify the means" and there doesn't seem to be any care about treating the build as software, and instead godot treats it as a series of scripts that happens to produce a build. I will not be contributing the changes I made to the code generation to godot (despite it being more readable and faster), and I've given up on this engine entirely and moved on with my life. I'm much happier if I'm being honest. The engine already has considerable tech debt and I see it being an issue in about 3 years, especially as the C++ standard committee is working on a tooling technical report (I'm involved in this and have been pushing for things like options files being standardized to a degree, but it's just a technical report so some folks will diverge from it). It's a shame too. My CMake build was able to catch a bunch of static analysis errors that have led to tons of issues and are easily solvable, but I'm too burned out from having argued with the devs about this at GDC to file bugs or even attempt to fix them. My energy and my mental health are better spent elsewhere. There is no world where scons will be able to handle the upcoming C++20 modules design, as much as I have shouted how it will break many tools. It can't handle the dependency tracking for that, and would require it to have a pre-scan step, which will slow the dependency tracking down even further. Lastly, I'm going to suggest people not try to improve a tool that can only accept minor changes. Scons would need a complete rewrite from the ground up and a large number of breaking changes to get the improvements people here seek. I suggest this issue be closed as the discussion of changing the build system was answered at GDC 2019, but the leads don't even think its worth wasting their time to comment on this issue, which I think shows how much they care about the ergonomics of development. |
|
I feel as though if the existing build system were 100% converted in a plug and play fashion there would be no reason from the devs not to switch. Building only on Linux is useless. Having a game engine that doesn't run on windows will deter any serious game developers. I would like to be under the impression that the game developers care enough to change the build system to satisfy its users. One of the reasons I left Unreal is that the engine is tailored primarily for Blueprint/front end game creation. Creating tooling in c++ modules is extremely painful and complex in Unreal. So far, in Godot it has been decently pleasant. Making C++ builds faster would be a big plus for the community. |
|
IIRC they use Wine to run the MSVC build tools. Still doesn't change your point, and I agree. |
Godot has always been buildable on many platforms, not just Linux…
Official Windows builds are compiled using MinGW; we don't use WINE to run MSVC on Linux. |
|
@marstaik - if you switch builds and run scons just to generate the MSVS Project files, you should be able to specify those files as the target and not have to do a full build. so try: SCons should be able to do this without doing a complete build and also it should do it correctly without you needing to do a clean first. |
|
@bdbaddog I had to add vsproj=True to that command, but it seems to have worked From the godot src: Edit: For some reason you need to add the -j flag also... |
A lot of such flags aren't vanilla SCons, but part of the way various packages (Godot in this case) implement their build system with SCons. |
|
Why use SConstruct and insist on not switching to other build system??? |
|
@tjysdsg The discussion above sums that up very well 🙂 |
|
I'll close this because we've made it clear over the years that we have no intention a priori to change the buildsystem. We're happy with SCons and any of its shortcomings can and should be assessed individually, both within our own SCons usage and upstream if it's due to the tooling itself. Switching to a "cooler" buildsystem for the sake of it will not happen. The vast majority of core contributors is happy using SCons and it's the one we now know best. Switching to a new buildsystem has both an implementation and a learning cost, and it hasn't been proven so far that those would be worth the trouble. All in all, a buildsystem change is not something that we'd accept from new contributors. It has to come from the inside, and all core contributors must see it as a positive change for it to make any sense. We won't change the buildsystem just to please new users who attempt to build Godot from source and somehow don't like that they have to type Of course we're open to changing our minds if clear gains can be listed (and shown with a working proof of concept) that outweigh the costs of changing the buildsystem, but as of today and after two years of discussion here, I personally don't see the incentive. |
|
@slurps-mad-rips said it well.
and
Flat out disgusting that CMake isn't given serious consideration, I can think of many reasons to ditch SCons, but SPECIFICALLY that CMake finds errors Scons does not find makes it "worth it" to use something else.
CMake isn't "cooler", it's the standard. If you actually used it you would immediately understand why.
I'm not convinced that anyone is open to changing their minds. Again, @slurps-mad-rips showed clear gains, and she even did all the work... It's already done. It is shameful, representing the official stance of the Godot team, to completely disregard her efforts improving the development process. |
|
I quite understand your pain but I still agree with others - all the build
systems have their
pros and cons and generally the same. There is rarely any technical reason
to change it.
As for political reasons they will not do you anything good in the long
run. Everybody
prefers something different. Anyway nobody stops anyone from doing forks
for whatever
reasons, so I guess this one is as good as any.
…On Fri, Feb 21, 2020 at 1:38 PM dorkbox ***@***.***> wrote:
@slurps-mad-rips <https://github.com/slurps-mad-rips> said it well.
It's complex because it uses scons.
and
My CMake build was able to catch a bunch of static analysis errors that
have led to tons of issues and are easily solvable
Flat out disgusting that CMake isn't given serious consideration, I can
think of many reasons to ditch SCons, but *SPECIFICALLY* that CMake finds
errors Scons does not find makes it's "worth it" to use something else.
Switching to a "cooler" buildsystem for the sake of it will not happen
CMake isn't "cooler", it's the standard. If you actually used it you would
immediately understand why.
Of course we're open to changing our minds if clear gains can be listed
(and shown with a working proof of concept) that outweigh the costs of
changing the buildsystem
I'm not convinced that anyone is open to changing their minds. Again,
@slurps-mad-rips <https://github.com/slurps-mad-rips> showed clear gains,
and she even did all the work... *It's already done.*
It is shameful, representing the official stance of the Godot team, to
completely disregard her efforts improving the development process.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#16014?email_source=notifications&email_token=AAABPU2PBIEK6PFKQ2LDTHLRD6VKVA5CNFSM4ENJ6NN2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMSI4JY#issuecomment-589598247>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAABPU746R4YFHAI73Z57RTRD6VKVANCNFSM4ENJ6NNQ>
.
|
|
@dorkbox - cmake found static analysis errors? or was it the compilation database output from cmake run through llvm's static analysis tools which found them? |
|
@bdbaddog, @slurps-mad-rips did the work on this, and it would be best to ask her. (I think it would be the output from llvm's static analysis, but I'm not the one who did the work to build via cmake) |
How about static analysis tools and modern language features support? |
|
@bdbaddog @dorkbox I simply turned on clang-tidy to look for things like "returning references to non-static locals" and "buffer overflows" via CMake. I also ran clang-check on a few things and got a few more results. I was able to get That said, I didn't actually "finish" the cmake port. The part that never got ported was all the work I did with trying to change the current python scripts that simply call However I had hoped to keep parity with the scons build and at the very least get my changes to the code generation merged in. This didn't happen because the python scripts used to generate source files are constantly changing, and keeping those changes in sync with my jinja2 templatization was an exercise in frustration. Given the very emphatic and hard "no" I got from the lead developers at the GDC GitHub meetup, I decided I no longer wanted to contribute to godot. My changes were unwanted, are not desired, and they are apathetic to anyone else's opinion on this matter. I won't be contributing to godot, nor to any forks of godot. I wish you all luck in trying to convince the lead devs in the matter but it's like talking to a brick wall. Unyielding, immovable, and apathetic to the plight of everyone in this thread. |
|
So if SCons can spit out the compilation database which is input to the llvm tools then this would also be able to be done from SCons. |
It looks like there is the sunk-cost fallacy going on with SCons. Why not use something that is easier, streamlined, and already part of existing build tools, like cmake? From the scons website:
|
|
@dorkbox - I'm the SCons project co-manager. I'm just keeping an eye on desired functionality. The last few releases and the forthcoming one have had performance improvements. Additionally we have PR's for ninja file generation and some community members have compilation database tools. So some of the issues are likely to be addressed (at least partially, if not fully) in the next release. I'm not aware of any stability issues affecting the godot project which we haven't addressed. If there are any outstanding please let us know. I'm not sure cmake really requires less code for common tasks, I'd be interested in reasonable comparison. |
|
Well, what mostly annjoys me with scons is inability to generate plain old
GNU make makefile. Lack of ninja - I can live with it.
Also handling of cross-compile utility like CMake toolchains and autotools
cross-compiling capabilities is strong cmake weak point.
The rest is ok as I'm not IDE person. My IDE is UNIX environment.
…On Sun, Feb 23, 2020 at 10:05 PM William Deegan ***@***.***> wrote:
@dorkbox <https://github.com/dorkbox> - I'm the SCons project co-manager.
I'm just keeping an eye on desired functionality.
The last few releases and the forthcoming one have had performance
improvements.
Additionally we have PR's for ninja file generation and some community
members have compilation database tools. So some of the issues are likely
to be addressed (at least partially, if not fully) in the next release.
I'm not aware of any stability issues affecting the godot project which we
haven't addressed. If there are any outstanding please let us know.
(Reach us via: https://scons.org/contact.html)
I'm not sure cmake really requires less code for common tasks, I'd be
interested in reasonable comparison.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#16014?email_source=notifications&email_token=AAABPU5TQQFET5RS2JDRY7TRELCHDA5CNFSM4ENJ6NN2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMWEOMI#issuecomment-590104369>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAABPU6UHPX3HJTWPAFTPATRELCHDANCNFSM4ENJ6NNQ>
.
|
and others
Meson's website
I know, this is a bit of a hot topic, or at least a "nobody really wants to discuss it because nobody wants to actually do it" topic, so I'm putting massive emphasis here on the "consider" part. If the end result of this discussion is that Godot's build system shall stay the way it is, so be it.
So currently, Godot uses SCons, and I get why that is - it's a very powerful build system (since it's basically using Python to write build scripts), and the way it's setup in Godot makes it extremely easy to use. However, it's not without its downsides - primarily, that it's quite slow (being basically that SCons build files are Python scripts, and most Python interpreters do not particularly excel at execution speed), and because of its relative lack of popularity, difficult to find many resources or documentation about it.
Plus, I don't personally know how maintainable or easy-to-work-with the buildsystem code, but in my opinion it shouldn't be the sort of situation of "don't touch this code ever, or you risk breaking it and having to do boring and painful work just to get the project working again".
Now, I realize that Godot's project structure is not simple and that's a huge reason why SCons is what was chosen as the build system (and why there has been massive reluctance to move to another system), but I don't really believe that it's the only build system that can possibly satisify Godot's requirements. Feel free to prove me wrong, though.
So what could a migration to Meson offer?
Better baseline build speeds (and potentially that much better if unity or threaded builds are taken advantage of) [Some sample benchmarks]
The use of Meson's dependency system,
wrap, would help reduce the repository size (third party dependencies would no longer have to be included with the project, and would certainly also help when said dependencies need to be updated to new versions. Use of wrap would even allow for modules (both official and custom) to be simply included as 'subprojects' (and offloaded to their own repositories), further reducing the main repo's size. [Onwrap]I don't know where SCons stands regarding this, but it seems like Meson is designed to play nicely with CI tools such as Travis and AppVeyor, which might be of note. [CI]
Meson also appears to some degree of support for localization, but it appears to be
gettextbased which I believe differs from the way Godot handles this, so I'm not sure how compatible this is here. [Localisation]Right now Godot does not seem to make much use of unit tests (the godot-tests repo seems to be rather low-activity), but Meson has full support for performing such tests, which may be valuable. [Unit tests]
In addition to providing a way to generate the relevant files for both Visual Studio and XCode, Meson comes with an API that allows for integration with IDEs and other build tools, which again seems like something of value for those who don't use VS or XCode. [IDE integration]
This is all in addition to supporting (almost?) everything that Godot already uses and requires - cross-compilation support, source generation, running external commands, et cetera.
It's evidently a buildsystem that is capable of handling both small and big and complex projects - complex projects like systemd, GNOME, elementaryOS, Xorg, Mesa.
No promises, but I may be able to try and work on a proof-of-concept of this, to see how it fares. Also if there are any Meson experts/enthusiasts reading this, please feel free to chime in, as I probably got a few things wrong (both wrt Meson and SCons).
Cheers!
The text was updated successfully, but these errors were encountered: