[pepijndevos]

I have in the past developed a fairly large (proprietary) Qt application that used the same codebase on Linux, Windows, and Android. I would say Windows and Android are tied for compile hell.

This update looks really neat, and may solve some problems for some people. But personally my biggest gripe with Qt is qmake.

When you are doing Android, lots of resources assume Gradle, and lots of Qt stuff assumes qmake. Neither is ideal if you're dealing with other libraries like gstreamer, or even worse: proprietary libraries compiled using an old NDK.

So I ended up writing my whole build system in cmake, which made builds on Windows and Linux a lot saner, but made Android a living hell. I'd love to see better support in Qt for actual sane build systems you can use with real world third-party libraries, because qmake is not it in my experience.

[ahartmetz]

There is already CMake support in Qt, and Qt itself is going to be compiled with CMake starting from version 6.

[scrollaway]

I read somewhere a few months back that qt is dropping qmake in favour of cmake in the medium term. And everyone rejoiced.

[detaro]

building Qt apps with CMake is already possible and supported. Building Qt itself with CMake is an active project, and the long-term plan is indeed to drop qmake completely.

[amelius]

That's a step in the right direction. The next thing would be to drop the compiler extensions (signal/slots macros) in favor of modern C++.

[jcelerier]

There is sadly no reflection nore code generation yet in C++ so that cannot work without lots of ugly macros.

[_fbpt]

Verdigris is a moc replacement (not a Qt fork like CopperSpice) which generates QMetaObject through macros using constexpr.

[kevin_thibedeau]

Already done by CopperSpice.

[joezydeco]

You didn't try iOS? =)

The XCode cross-compile is incredibly smooth, and the runtime is complete ass. Qt really messed up high-DPI support and it has no better example of this than iOS.

[mehhh]

Qt development using Python is similarly painful, I end up drafting things up in Qt Creator, taking that code and amending it to work in Python.

The tooling for Qt needs help, I feel like this is a huge reason why shovelware Electron apps are so common now.

Edit: Capitalization

[cocoa19]

I've been developing C++ for 10+ years.

I think the pain is unfairly attributed to Qt. A lot of the pain actually comes from the poor tooling in the C++ world.

Conan is supposed to come to the rescue, but after attempting to use it, it feels like it's still not as easy to use as any other package manager (npm, pypi, gems, etc). I love C++ and Qt, but It's extremely difficult to convince people to start any new projects in C++.

Common C/C++ questions and answers in stack overflow: how do I do x in C++ (e.g. trim whitespace), the usual responses: 1. It's trivial to implement, do it yourself. 2. Why would you want to do that.

Compare that to pulling up a library to do that, or it's already baked into the standard library (e.g. Java).

[mehhh]

I would not want to develop a new application in C++, both Google and Mozilla decided it was bad enough they had to write better languages (Go & Rust), and the speed at which I can write things in Python, Lua or another lanugage is much faster than C++.

That being said, my SO would love you! He is always trying to get me to write things in C :D

[ahartmetz]

QString::trimmed() ;)

std::string is laughably underpowered in comparison - it's basically a vector of bytes, missing a huge amount of convenience methods and all Unicode support.

[stef-13013]

It's Qt not QT

[mehhh]

Edited both comments, should be fixed now

[benibela]

I tried to cross compile my Qt project from Linux to Windows.

It started, but then it crashed. So I gave up on that, and let someone compile it directly on Windows. Then there are no issues.

I did not try Android there.

Then I have another app that runs on Linux, Windows and Android using FreePascal/Lazarus rather than Qt.

FreePascal is really great for building. You only need to set the search path, and then it finds all the files it needs (just sometimes it crashes when serializing the dependency graph, then you need to delete all object files and restart).

Cross compiling from Linux to Windows works perfectly. FreePascal has an internal linker, so you do not need any other software for Windows. You do not need to deal with proprietary libraries, because there basically are no FreePascal libraries, especially no proprietary.

Linux-Linux cross compilation is more complicated. I just got a new computer and my 32-bit build failed silently because I did not have 32-bit gtk dev files and crtbegin from gcc installed. Yesterday I tried to install them with apt, but the installation failed, because they were conflicting with the 64-bit gtk dev gir files. Then I set force override in apt, and the installation worked, and then FreePascal cross compiled correctly. However, today I noticed, apt had uninstalled Python, Mercurial, Tortoise-Hg and most TeXlive packages. There must be something very wrong with Ubuntu's multiarch support.

There are three ways to run a Lazarus GUI on Android. First LAMW which has created a lot of FreePascal JNI wrappers around Android Views (and is far too complex for my liking); secondly Lazarus Customdrawn which draws all controls directly in FreePascal (and looks like it was designed to be Windows 98 compatible and crashed) and thirdly Qt, because Lazarus supports Qt as GUI backend (which probably works on Desktop, but I do not know anyone using it on Android). Hence, I compile my app as .so, export the data through JNI, and wrote a completely new GUI in Android Studio without using anything of Lazarus. Gradle does not need to know anything about FreePascal, it just copies the .so to the apk. But theoretically Lazarus is all you need. (Then I tried to submit my app to F-Droid, but they cannot include FreePascal/Lazarus apps, too complex build process)

[UnFleshedOne]

Building Qt apps on windows is trivial if you use Visual Studio as a first class project with a few Qt specific msbuild targets, there are a few floating around. Then moc'in a header is as simple as using <MOC> element in vsxproj instead of <Include>, similar for UI and RCC, etc.

Does mean you have a platform specific build system though.