Consider moving the buildsystem to Meson or another build system

[RiverMesa]

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. [On wrap]

• 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 gettext based 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!

[bruxisma]

@dorkbox if I can get these changes I'm working on in, you'd definitely be able to work in a CLion (cmake + ninja) workflow.

@germandiago

I'm actually friends now (more or less 😛), with the author of meson as of CppCon 2018. We both ended up on the same paper for the upcoming meeting regarding modules titled "Remember the Fortran", and I'll be presenting his paper at said meeting (It's next week, actually!), and we also were on the same build systems panel at CppCon.

I would love to use Meson. If you read further up in the thread, I had tried a meson port, but things were too integrated with Scons at the time. I'm still pulling out the current code generation scripts to be separate 'executable' scripts so that if, in the future, a move to Meson would not be out of the question. However it's slow work, and I have taken to writing a few jinja templates to help with the code generation so scons can be dropped entirely. That said, while my public fork is out of date, the one I have at home is a bit further ahead (and synced to a private fork). Work has unfortunately gotten in the way, and San Diego is unfortunately going to be 'stealing' more of my time. After that, however, I should be free to remove some of the local experiments I have on my private fork and finally get back on the godot cmake train. I am committed to making sure a full pull request can go in without also having a massive disruption in the current workflow process.

(As an aside: thanks everyone for the patience you've had while I work on this. I know it's been a while since I started it, but I represent my employer for the US National Body for the C++ standards committee now so my schedule has been a bit more full lately, especially as we hit important topics like modules, coroutines, and ranges)

[wberrier]

Yeah most modern IDE's are either CMake-only, and/or some Custom Build System, and/or 'raw calls' that lose a lot of features. CMake really has become standard, whether it is merited or not.

A possible useful tool for using meson with IDEs:

https://github.com/prozum/meson-cmake-wrapper

It makes the IDE think it's using CMake, but is really using meson under the hood.

Some background: I was a huge proponent of CMake for many (10?) years, but fell in love with meson this last year or so. Meson seems to be written with the intent of having CMake's useful features while fixing/preventing many of CMake's annoyances. One roadblock I'm currently facing for adopting meson in a project is the IDE support. I just discovered the above tool, so maybe that will help.

[slapin]

All and every build system have its major flaws, more than that, there is no reason to change that from technical point of vew, be it scons, autotools, cmake, meson, or whatever make vs ninja your religion is. I think it would be great to close all other build system change bugs as duplicate of this one.

[fire]

<reduz> iFire: no, you did not, all you did was build it but did not port any of the dozens of custom scripts that generate code
<iFire> reduz: the other person worked on the little python script generation on her branch
<iFire> so they directly imported the python env
<iFire> it's workable
<reduz> iFire: that is what everyone said that attempted it, and failed :P
<reduz> there are too many things in there

Prove reduz wrong @slurps-mad-rips :).

[lazybullfrog]

800lb gorilla in the room that hasn't been mentioned yet. One of Godot's claims to fame is cross platform compatibility. It should follow that whatever build system that is a potential for migrating to should be available and tested on all platforms that Godot targets. Whoever is behind such a migration should be inclined to test the migration on all supported platforms, or at least be part of a team that is doing so. Otherwise I would see such a move as contrary to Godot philosophy and generally just a bad idea.

[bruxisma]

@lazybullfrog I have access to about 5 separate machines for desktop, and several mobile devices. Part of my port to cmake is making sure there are cmake toolchains available for all the current platforms.

[lazybullfrog]

@slurps-mad-rips Is one of those Haiku? If not, I'd be willing to help test. Thanks.

[OvermindDL1]

Part of my port to cmake is making sure there are cmake toolchains available for all the current platforms.

Don't forget as well that if you need cmake toolchains for a platform then there is probably a prebuilt one at https://github.com/ruslo/polly and if there is not then you should PR it. :-)

[fire]

@slurps-mad-rips How has it been going? I noticed you updated the code on Jan 14th. I tried compiling on Windows but it didn't find pkgconfig.

[bruxisma]

@fire life decided to throw a few curveballs my way and I had to take care of them. Personal stuff, unfortunately. I've been focusing on work and finishing the IXM library that I'm using to reduce the amount of work that would be copied into godot. Luckily I'm taking a vacation in a week (I'm heading to Kona for the WG21 ISO meeting for this quarter this weekend) so I'll have some spare time to work on this, and (hopefully!) I'll have a working build for macOS, Linux, and Windows soon™. Android and iOS, followed by FreeBSD and Haiku (sorry @lazybullfrog, though you're more than welcome to test early/often) will be my next priority after that.

The biggest chunk of work/blocker thus far has been extracting the python scripts into "installable" tools that are separate from Scons and executed like processes. The actual grabbing of dependencies, settings, etc. has been easier in comparison.

[lazybullfrog]

@slurps-mad-rips, life has thrown me a few curve balls too. Perhaps we should start a baseball team. 😂

Fortunately one of those curve balls since I last commented was a 8 core Xeon with 32gb ram with Haiku and FreeBSD installed. Perhaps soon I'll get some time to help test both.

I'm actually ecstatic that both of these platforms are getting attention. Look forward to testing soon.

[njlr]

I think it is reasonable to have multiple build-systems. Perhaps an official build-system that is well supported and the others provided on a "you figure it out" basis. Users will want to use their own build-system regardless, so why not pool their work into one place?

I would be willing to contribute a Bazel port if things go that way.

[akien-mga]

I think it is reasonable to have multiple build-systems. Perhaps an official build-system that is well supported and the others provided on a "you figure it out" basis. Users will want to use their own build-system regardless, so why not pool their work into one place?

As a Linux packager, I have seen hundreds of projects with various buildsystems. I've seen a few which did have several buildsystems available. I've never seen one where it was not a complete mess, especially when the alternative buildsystems were contributed by first-time "please add CMake it's so cool" contributors who then disappeared from the project, and maintainers didn't bother updating it.

There's no value at all in supporting several buildsystems, and I won't merge any PR going in that direction. I'm one of the main buildysytem maintainers, and I definitely don't want to have the burden of maintaining alternative ones whenever we need to change something.

We currently have a buildsystem that works for everyone and is well supported, and no intent to change. If someone really wants to investigate other options, feel free to, and if the final result also works for everyone, can be well supported and provides added value without big drawbacks, we'll consider it.

[bruxisma]

If someone really wants to investigate other options, feel free to, and if the final result also works for everyone, can be well supported and provides added value without big drawbacks, we'll consider it.

That's what I've been doing with my CMake port. Currently a no-op or single file change under scons takes upwards of 10 seconds on my current machine (which has 64GB of RAM, comparable processor, etc.) With ninja + cmake the entire configure + generate process takes less time, and the ninja build finishes in under 0.2 seconds in a no-op build (on windows, where launching a process is expensive). I'm also able to use the sccache tool from mozilla if its installed, and that's been extremely useful for editing the codegen parts/running a regenerated build from scratch to make sure nothing is depending on my local environment.

most of my time has been spent on extracting the code generation scripts into python scripts that could run on their own. If that was the only thing merged into godot, my time spent on this wouldn't have been a total waste. It also solves the run_in_subprocess hack that currently exists to solve issues on windows with parallelization.

I just returned from my trip and was able to get a bit of work done. Right now I still need to copy a few files over from a manual scons run, but I've been chipping away at the generated sources as time goes on. The license.gen.h and method_bind.inc headers are currently my biggest target, but I'm taking a few days to deal with jetlag + work before I'll tackle them.

(also just gonna cc @fire since he's been interested in this progress for a bit)

[Antonz0]

From my experience Meson is totally f*ed up when building Android on Windows, I just cannot get it work to compile one of third party libraries that uses it (libepoxy). And I think it's too much tied to concrete compiler stuff.

[marstaik]

All I desire is a build system that can generate project files and database files separately from the build command.

Every time I check out a new branch with major changes to files, I have to run Scons from the command-line to regenerate my vsproj files, which also causes a full build to occur anyways. In Scons from what I have seen, there is no project generation stage of any sorts. This is also why it doesn't support generating compilation databases out of the box for usage in clang-tools.

Currently, the only viable solution to coding Godot on windows (IDE-wise) is with Visual Studio, otherwise be prepared to just use a text-editor.

Scons is wonderful and all, but when I have a 12 core threadripper and 128gb of ram and I have to wait 12+ seconds on windows to compile a single line change (most of that is Scons thinking), it gets a bit annoying.

But the real downside to Scons (and this could be my laziness in searching) is that I cannot compile individual cpp files. Being able to compile individual cpp files without building the entire project is a huge productivity booster and sanity checker.

Its not just line changes that take time, even figuring out if there is anything to build takes time...

Running from git-bash:

$ time scons -j24 num_jobs=24 vsproj=true platform=windows
scons: Reading SConscript files ...
Configuring for Windows: target=debug, bits=default
 Found MSVC version 14.2, arch amd64, bits=64
YASM is necessary for WebM SIMD optimizations.
WebM SIMD optimizations are disabled. Check if your CPU architecture, CPU bits or platform are supported!
Checking for C header file mntent.h... no
scons: done reading SConscript files.
scons: Building targets ...
[Initial build] progress_finish(["progress_finish"], [])
[Initial build] scons: done building targets.

real    0m16.082s
user    0m0.000s
sys     0m0.030s

[bdbaddog]

If you want to build only a single target file, then specify that on the command line

scons -j24 num_jobs=24 vsproj=true platform=windows <path  to targetfile>/targetfile.obj

[Nosliwnayr]

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. Unity builds: https://cmake.org/cmake/help/latest/prop_tgt/UNITY_BUILD.html Precompiled headers: https://cmake.org/cmake/help/latest/command/target_precompile_headers.html

[OvermindDL1]

@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.

[ghost]

@bdbaddog i don't understand, do i have to specificy every single file manually? what does that .obj thing do? how do i apply it to the whole project? does it automatically recompile individual files?

---

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 can we please avoid pre compiled headers? i think they are complete garbage, just keep it simple

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

[bdbaddog]

@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..

[marstaik]

@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.

[bruxisma]

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.

[marstaik]

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.

[bruxisma]

IIRC they use Wine to run the MSVC build tools. Still doesn't change your point, and I agree.

[Calinou]

Building only on Linux is useless. Having a game engine that doesn't run on windows will deter any serious game developers.

Godot has always been buildable on many platforms, not just Linux…

IIRC they use Wine to run the MSVC build tools. Still doesn't change your point, and I agree.

Official Windows builds are compiled using MinGW; we don't use WINE to run MSVC on Linux.

[bdbaddog]

@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 <path to created MSVS project file>/VSPROJECTFILENAME (replace with actual paths and file name which are generated)

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. (BTW. I'm the SCons project maintainer)

[marstaik]

@bdbaddog I had to add vsproj=True to that command, but it seems to have worked

From the godot src: scons -j24 godot.vxcproj num_jobs=x vsproj=true

Edit: For some reason you need to add the -j flag also...

[bdbaddog]

@bdbaddog I had to add vsproj=True to that command, but it seems to have worked

From the godot src: scons -j24 godot.vxcproj num_jobs=x vsproj=true

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. Glad you found a way!

[tjysdsg]

Why use SConstruct and insist on not switching to other build system???

[Calinou]

@tjysdsg The discussion above sums that up very well :slightly_smiling_face:

[akien-mga]

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 scons instead of cmake or meson which they are used to. We also will not accept attempts to introduce an optional new buildsystem - from experience, I know that this can only lead to inconsistency, bugs and output differences.

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.

[dorkbox]

@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 "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 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.

[slapin]

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 notifications@github.com 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 https://github.com/godotengine/godot/issues/16014?email_source=notifications&email_token=AAABPU2PBIEK6PFKQ2LDTHLRD6VKVA5CNFSM4ENJ6NN2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMSI4JY#issuecomment-589598247, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAABPU746R4YFHAI73Z57RTRD6VKVANCNFSM4ENJ6NNQ .

[bdbaddog]

@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?

[dorkbox]

@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)

[dorkbox]

@slapin

There is rarely any technical reason to change it.

How about static analysis tools and modern language features support?

[bruxisma]

@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 include-what-you-use to run as well, and it found quite a few unnecessary header inclusions.

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 f.write on some file to generate a file from JSON. I was able to remove a lot of that logic and replace it with a generic jinja2 based template generator. This also solved a hack that the current scons build does on windows where it launches a script as an executable.

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.

[bdbaddog]

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.

[dorkbox]

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:

When compared to scons, CMake is :

• Faster
• Requires less code for common tasks
  • Arguably more stable
  • Supports outputting to projects like Code::Blocks, Xcode, etc. which scons does not

[bdbaddog]

@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.

[slapin]

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 notifications@github.com 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 https://github.com/godotengine/godot/issues/16014?email_source=notifications&email_token=AAABPU5TQQFET5RS2JDRY7TRELCHDA5CNFSM4ENJ6NN2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMWEOMI#issuecomment-590104369, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAABPU6UHPX3HJTWPAFTPATRELCHDANCNFSM4ENJ6NNQ .