godot

godot copied to clipboard

This is #45093 rebased to work against the current master. It also has some minor correctness fixes. I only tested this on Linux where the build completes and can be run, but the end result has broken text (all Unicode replacement squares).

The build definitions work, but could use some TLC. For example the way it uses system libtheora is fairly complicated as opposed to using Meson subprojects and dependency management. Here is an equivalent build file for SDL Mixer that uses Vorbis. It would probably also make more sense to move from config.py scripts that you run to doing the configuration and header generation with Meson builtins.

If there is genuine interest in getting this working, I can help with the work needed to get the rest of it working with equivalent or better level than the current SCons build.

Bugsquad edit: This closes https://github.com/godotengine/godot-proposals/issues/1797.

Can you re-enable at least Linux github workflow?

I am also around for support. I have contact with the pr creator originally and feel free to find me on discord for godot.

For me build fails with this message(clean build)

In file included from ../thirdparty/miniupnpc/miniupnpc/miniupnpcstrings.h:4,
                 from ../thirdparty/miniupnpc/miniupnpc/miniwget.c:52:
../core/version.h:34:10: fatal error: core/version_generated.gen.h: No such file or directory
   34 | #include "core/version_generated.gen.h"
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.

That's because it is missing a dependency on the generated target. This is one of the fixed dependency things I mentioned above. I fixed most of them but some still remain. I'll fix the rest as there is time. In the mean time you should be able to fix it by going in the build dir and running

ninja core/version_generated.gen.h

and then restarting the build with ninja (or meson compile if you were using that).

Linux workflows re-enabled. I did not re-enable the Mono one as I was not sure what it should do so it will fail.

Here are some instructions for others.

# Test on Popos! with meson and other deps installed
git clone https://github.com/jpakkane/godot.git -b meson --single-branch godot-meson
cd godot-meson
meson ./build -Dbuildtype=debugoptimized
cd build/
meson compile
./godot

Results in a unicode broken state where fonts aren't loaded.

Edited: Second update.

Pushed an update that works on Windows apart from the fact that it gives a compilation error in Icu for uchar.cpp because a constant is too wide. Maybe missing some compiler flags?

meson ./build -Dbuildtype=debug

You don't need to add -Dbuildtype=debug, that is the default. For an optimized build you can use -Dbuildtype=debugoptimized instead.

scene/resources/default_theme/default_theme_builders.py has not been converted. See https://github.com/godotengine/godot/commit/d211c05111eed90baa7e70cb4e818fd328e97770

It now compiles on macOS as well, but the binary crashes on launch. I don't have enough macOS experience to find out why.

scene/resources/default_theme/default_theme_builders.py has not been converted. See d211c05

Could you please clarify? FWICT the version in this is the same as in current trunk, just changed a bit to run standalone.

Sounds great! From my part if Meson can be proven to work as well as Scons, and it can result in a demostrably better build performance when everything works, I am all for it. I think our only requirement is that we want automatic source scanning like we have for the most part with Scons.

That is a bit problematic, because one of Meson's main design points has been to not do that. None of the backends we use have support for that and adding it in is is not really possible if you want it to be both always reliable and fast.

There are ways to work around with with a script, as mentioned in the FAQ, but it has known downsides (specifically if you add a file, it won't get autodetected).

It looks to me that switching to Meson will lead to situation that we'll both have a new build system and Python stuff used to generate stuff, while SCons is more tightly integrated in this regard since SCons itself is written in Python, the way I see it.

I'd like to repeat the importance of having custom_modules feature to be implemented with Meson. 🙂

There are a few different ways to implement custom modules like that in Meson. The first that comes to mind is to use Meson subprojects. Basically each external module would be its own simple Meson project inside the subprojects directory (for example via Git submodules). It would have a declaration like:

sp_dep = declare_dependency(sources: 'MyModuleSource.cpp',
    include_directories: '.')

Then the main Godot project would have an option of said external extensions to use and it would do something like:

external_mods = []
foreach sp : get_option('custom_modules')
    external_mods += subproject(sp).get_variable('sp_dep')
endforeach

external_mods would then be passed to the main build target.

Rebased to fix the build issue. Things to note:

• I don't have experience with mobile development, so it would be great if someone who knows Android and iOS could try it out. I do know there are projects built with Meson on both app stores, so it should be possible.
• Ditto for WASM
• moving external dependencies to subprojects would help custom modules, too, as it would make all thirdparty deps immediately accessible

Ditto for WASM

@jpakkane I've added the WASM build here: https://github.com/Faless/godot/tree/meson_web

You need a recent emsdk, and you should be able to build:

meson ./build --cross-file cross/emscripten -Dbuildtype=plain -Dbuiltin_pcre2_with_jit=false -Dtools=false -Ddisabled_modules=upnp,text_server_adv
meson compile -C build

But I need figuring out some things:

• Avanced Text Server is broken (meson seems to force a werror and ignore my setting).
• UPNP is broken (not sure what's missing, the module should compile to provide API compatibility, but it has some undefined types).
• Object files suffix seems ignored. They should be .bc but instead it uses .o (maybe I used the wrong option in the cross file?).
• The scons version used to generate a zip template, are there facilities for that in meson?

@jpakkane

That is a bit problematic, because one of Meson's main design points has been to not do that. None of the backends we use have support for that and adding it in is is not really possible if you want it to be both always reliable and fast.

I understand this, but we largely prefer source scanning. It is a big plus in usability and version control. We already discussed how it could be implemented in Meson and it should really not be a problem (It can be done in the generator). It should also not have a performance impact given scanning for filesystem changes is very fast.

I understand this, but we largely prefer source scanning. It is a big plus in usability and version control.

Wildcards have a problem when it comes to version control and generated files. If a generated file is removed from scripts but still on disk, SCons still builds it because of wildcards. This often results in #include errors when building Godot after pulling changes, forcing you to manually delete the file from disk. Who knows, could be even worse if the build succeeded. Albeit I'm not sure if the same problem would be present with Meson as I think it auto-detect changes to build files to re-configure.

We already discussed how it could be implemented in Meson and it should really not be a problem (It can be done in the generator). It should also not have a performance impact given scanning for filesystem changes is very fast.

In my experience filesystem scanning with wildcards is very slow specially on large projects. SCons empty builds are a good example of this. Doing this when configuring Meson may be ok, but it won't really be the same thing as you would have to manually re-configure after adding a new file.

Is it really that much of a problem to add the files to the build system?

+1 for globbing. It's already annoying enough having to run the reconfigure every time you add a (or remove) a file, having to also add the file name to the build file, before reconfiguring is even more annoying.

It's already annoying enough having to run the reconfigure every time you add a (or remove) a file,

When you run make or ninja to compile, Meson will automatically run the configuration step again if its build files were modified. You don't have to worry about manually running the configuration step again.

I agree that having to modify the build files when you add a new source file is an annoyance, but your IDE can do it automatically using a plugin.

I still think there are valuable performance improvements to get by not relying on globbing, on top of having more reliable behavior when switching branches.

but your IDE can do it automatically using a plugin.

I don't use an IDE. Designing a build system around IDEs plugins is bad.

I don't use an IDE.

I suppose we could commit a shell/Python script that updates the build files automatically then :slightly_smiling_face:

It would be similar to the globbing approach, except that it would be run manually by the user when needed. (And if you really want to run it before every build, you can still do that!)

It would be similar to the globbing approach

Then use the globbing approach instead of forcing developers to use extra scripts or force IDEs on them

Then use the globbing approach instead of forcing developers to use extra scripts or force IDEs on them

I'd be OK with using globbing by default actually, but opting out should be made possible somehow (e.g. using a build option or environment variable).

I'd be OK with using globbing by default actually, but opting out should be made possible somehow (e.g. using a build option or environment variable).

Yeah, I guess we can have the globbing script generate meson build files (.gitignored), which are then sourced. So you can disable the globbing script with a flag after the first configure, and edit the file manually if you prefer.

I went through the Wasm branch and there are a bunch of things that are plain weird or need fixing in Meson.

meson seems to force a werror and ignore my setting

I got errors in Harfbuzz. This seems to be an issue in Emscripten instead. Meson does not add any ´-Werror` flags, emcc does that by itself. I tried disabling those checks and flags by hand but it ignored my args (even though they were definitely there in the command line).

The way the current code does library linkage needs fixing, probably in Meson itself. The files should be usable either by adding the .js files in the list of sources or using cc.find_library. One of our design goals is that end users should never need to build paths to files by hand (or mcgyber things by adding random compiler/linker flags either).

You should not add USE_PTHREADS flag by hand, Meson's threads dependency does the correct thing on all platforms. It even adds an option for pool size automatically.

This seems to be an issue in Emscripten instead. Meson does not add any ´-Werror` flags,

Well, that flag is not added in the current scons build. So it sounds like a flag added by meson (directly or indirectly).

The way the current code does library linkage needs fixing, probably in Meson itself. The files should be usable either by adding the .js files in the list of sources or using cc.find_library

Okay, I have very little knowledge of meson, we don't want it to include all .js files. We want to select specific files in platform and in modules.

EDIT: They are not to be treated as sources, but as linkable libraries for the final executable.

So it sounds like a flag added by meson (directly or indirectly).

That's the thing, it is not. This is easy to verify yourself with grep -i werror build.ninja (or plain error, though you have to manually ignore things in the error directory). The flag is not there and I don't know where it could come from which would imply that it's internal to emcc somehow.

@jpakkane I see.

It seems that the current meson implementation does not disable warnings for third-party libraries like we do in scons. Do you know how to do that in meson? See: https://github.com/godotengine/godot/blob/master/methods.py#L41

Overriding the warning level is the common solution (the best one is, of course, submitting patches upstream to get the warnings fixed).

library(..., override_options: 'warning_level=0')