What Build System Should Qt 6 Use?

[hoohoo]

First off, all build systems suck in some way. <snip>

Therefore we should have as few of them as possible, in order to minimize the suck.

[swizzler]

Meson doesn't fit the requirements. 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.

Mesa builds with meson. Moving to meson was a enthusiastically welcomed by most Mesa developers. It provided a big speedup in compile times. Mesa devs are generally happy on meson.

[lowflyer]

The discussion over here is equally heated as on the mailing list. And it is heading down the wrong path again. The question on build systems cannot be decided in the same way you would do any other software engineering decision. You cannot pile up a list of "requirements" and then conclude that you need to invent your own. The Qt guys are very experienced on that well trodden path. Does anybody remember the Qt build system? (the one before qmake) Instead of fixing it they went on to create qmake. I do not despise qmake at all. I'm working with it since years. It sucks, has rough edges and bugs. But mostly it works. Then the Qt guys did it again. "We won't fix the bugs in qmake, we'll invent Qbs." And here we are: a build system that mostly works, has rough edges and bugs and it sucks too. And yet again we hear the Qt wise guys saying "we need another build system".

Dear Qt guys, can you please stop that nonsense and just treat make, autotools and cmake as primary citizens in your creator? If you must, you are welcome to throw in Qbs and meson too. But everything else is anti C++ developers.

[johanb]

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.

Fair enough, but it is still don't see this as something critical.
It's good convention to split your build for each architecture/toolchain into separate build directories and you rarely have to modify your cross file once it's correctly set up.

[Nth_man]

As it was already written:

> Why a new build system and not CMake?

When not using CMake on a daily basis, you will likely forget everything very soon. Not so with Qbs.
Qbs uses a very elegant and easy-to-remember declarative DSL (QML) where users can focus on WHAT they want to build rather than HOW. That’s really an innovation.

[brrrrttttt]

Fair enough, but it is still don't see this as something critical.
It's good convention to split your build for each architecture/toolchain into separate build directories and you rarely have to modify your cross file once it's correctly set up.

It's a great way to have weird behaviour that's only reproducible for a subset of developers (e.g. arch specific FPU flag changed). That's exactly the worst type of bug.

[JoeTennies]

I worked on a commercial project that used Qt for the GUI. My team was in charge of switching it from Motif to Qt 4 (Qt5.x was out at the time). We started by using qmake. qmake had some functionality that meant that we couldn't use it at all. I think it had something to do with generating multiple outputs. Anyways, we eventually switched to CMake, and it did what we needed. That stated, I don't think anyone really knew how to maintain the file after the first person left. It was a "necessary evil" to complete the job.

Now, I do a lot more C than C++, but there's a lot of people I've heard say good things about switching to Meson. The GTK+/GNOME people are switching in droves. MESA is switching. Xorg is switching. I've actually heard about people liking Meson.

So, I'd say CMake is the safe pick. It can definitely do whatever Qt needs. CMake is likely the best pick today. We're talking about 2 years from now. Spend some effort right now, and Meson might be what you need. If you aren't going to put time into the build system (which is a fair decision), then choose CMake. I'm unsure why anything else other than just not changing is being considered.

[kpedersen]

Can they perhaps just simplify Qt enough that any build system is easy to fit. Something so I can just do:

$ c++ `find -name '*.cpp'`

and it just does a full compile. Then I can hook it up to our internal build systems that does the dependency tracking.

basically... Get rid of that MOC shit. Cut out the pointless superfluous dependencies and just write the whole system correctly so that it will guarantee that a Qt 4 project is actually build-able in 20 years time

It is a GUI library... not an OS. Why is it so sloppy?

[Nth_man]

> basically... Get rid of that MOC shit.

This information is partially fetched from <https://www.angrycane.com.br/en/2018/06/21/the-day-kate-gregory-enjoyed-qt/>:

You can create complete Qt applications without the Meta-Object Compiler (moc):

- You don’t need to use moc-like code if you don’t inherit from QObject.

- If you inherit from QObject: you need to use moc-like code, but that can be done with:
* moc (easiest way);
* hand written if you feel like it (but why?);
* [Verdigris](https://woboq.com/blog/verdigris-qt-without-moc.html).

You can create something that’s unrelated to a widget, you can use QtNetwork, QtXML, threads (http://doc.qt.io/qt-5/qtconcurrent-index.html), and more that you can find in http://doc.qt.io/qt-5/qtmodules.html

[kpedersen]

Unfortunately it will be quite hard to take advantage of Qt as a GUI system without inheriting from its base object (QObject)

Another solution to Moc would be to use the Qt 4 fork (http://www.copperspice.com/) who have replaced the crap code that relies on it.