What Build System Should Qt 6 Use?

[Staffan]

The last thing the world needs is another build system. Just use CMake, it is already used successfully in tons of other projects.

[Staffan]

https://shakebuild.com/

Apparently Shake depends on Haskell so using it will introduce another dependency whereas CMake only requires C++ which QT already uses.

[johanb]

Try to build a current meson project (a real one, not hello world) with a meson build from two years ago and watch it burn.

Have you heard of backwards compatibility without forwards compatibility?

The maintainers of the projects you are using are building it with a newer version but have forgotten to specify the minimum required meson version in their meson.build file.
If they do that properly, meson will give you a clear error that your meson version is too old.
So this is not an issue with meson, this is the packagers fault.

However, a valid criticism would be that Meson is still adding lots of new functionality since it is not very mature yet. IMO some of these features which were added the past year are almost essential, so it's common that you cannot use your distros packaged meson version since it might still miss important features.

It's cross-compiling support is also really clunky to deal with (although that wasn't one of Thiago's requirements).

Was very straight forward for me with openembedded (x86, ARM and mips targets), what was the issue for you?

[makam]

Considering the latest development trends...
Why not a Javascript based build system?

[carewolf]

Considering the latest development trends...
Why not a Javascript based build system?

That's qbs.

[brrrrttttt]

Have you heard of backwards compatibility without forwards compatibility?

The maintainers of the projects you are using are building it with a newer version but have forgotten to specify the minimum required meson version in their meson.build file.
If they do that properly, meson will give you a clear error that your meson version is too old.
So this is not an issue with meson, this is the packagers fault.

Did you read the Qt project requirements?

Was very straight forward for me with openembedded (x86, ARM and mips targets), what was the issue for you?

One example (there are more): "Cross file settings are only read when the build directory is set up the first time." This is a pretty big problem for an embedded/uC project with multiple developers...

[johanb]

Did you read the Qt project requirements?

Yes I did, what's your point?

One example (there are more): "Cross file settings are only read when the build directory is set up the first time." This is a pretty big problem for an embedded/uC project with multiple developers...

What's the issue with this? The cross file points to build tools and configurations which are responsible for the resulting artifacts, if you would change any of these settings you should have to recompile everything no matter what build system you are using so it makes sense to make a new build tree after such a change. Can you explain what I'm missing?

[Ansla]

johanb The build system should recompile everything if that is needed, it shouldn't need manual intervention. I would hate it if I had to check after each pull from master if something changed that requires to delete the build dir.

[hoohoo]

OBVIOUSLY it should use something new, unheard of, difficult to understand, incompatible with past build systems, which introduces strange paradigms, which is bug ridden, which syntax is mashup of make and meson and ant, and is only compatible with Ubuntu 18.10.

[hoohoo]

https://shakebuild.com/

Haskel. You want Qt6 - a C++ toolkit - to depend on a Haskel interpetter & runtime JUST TO BUILD STUFF?

Are you by any chance invested in shake?