[Development] Proposing CMake as build tool for Qt 6

[Thiago Macieira]

On Friday, 14 June 2019 23:45:47 PDT Bogdan Vatra via Development wrote:
> > I wouldn't call that a hard requirement. Separate builds for debug and for
> > release are acceptable, the same way that we've ostensibly had support for
> > shared-and-release builds but in practice they're always built separately.

I meant "shared-and-static".

> > The only difficult part I see is enforcing the suffix. On Mac we've had
> > problems with this, since a debug-only build is un-suffixed. Maybe it's
> > time to rethink the strategy and make the suffix optional altogether
> > (using the lib infix feature). On Windows, we should stop enforcing that
> > unoptimised builds be -MDd and make it easy for people to debug into -MD
> > libraries. Hardly anyone ever debugs into Microsoft's libraries...
> 
> I think libs built with -MDd are a must to enable debug builds for your
> application. AFAIK (if I'm wrong I apologize) you can't mix debug apps with
> release libs.

You can't mix -MD with -MDd libs, that's true. But the thing is: that's not 
the switch that controls whether you can debug or not. The true control is the 
optimisation level (-O0) and presence of debug symbols (-Z7). So, is there any 
reason we can't have -MD -O0 -Z7?

And especially for MinGW, since there is no -MD or -MDd switch, the control is 
really artificial.

> So, as long as we need to provide libs, (qml) plugins  for debug & release I
> think building them in one go is a must have feature.

Why must they be built in one go? Why can't they be separate builds stitched 
together? Or even completely separate builds as on Linux and all the other 
Unix?

> > 2 years in the wild was not for all features, it was for the buildsystem
> > itself and the major features. But we need to build with the version that
> > comes with the host systems that we are targetting (if they ship tools
> > like this in the first place; Windows doesn't).
> > 
> > That means that the iOS support only needs to be present in whatever
> > version of CMake that Homebrew installs. Since Homebrew always has the
> > latest, this is not an impediment.
> > 
> > But if we want to build on Ubuntu 16.04, then that three year old
> > version's
> > CMake needs to be sufficient for a native build of Qt and whatever cross-
> > builds get targeted from Linux (Android and QNX, I'd guess). For Qt 6, I'd
> > just recommend raising the minimum to 18.04...
> 
>   What makes you think that you can build Qt for any platform with cmake
> found in Ubuntu 16.04 (or any later version) ?

Nothing. I just chose a version number of Ubuntu out of the blue as an 
example.

>   According to https://code.qt.io/cgit/qt/qtbase.git/tree/CMakeLists.txt?
> h=wip/cmake#n1 Qt needs CMake *3.15.0* which is not even released. This
> means you'll need *NEXT* Ubuntu LTS (20.04?) to build Qt, this means we
> should put Qt6 on pause until 2022 :).

That's concerning.

>   Just to be clear, I don't want to change TQC mind again, but I don't like
> people hiding or twisting the true. The true is that in this moment CMake is
> not the best option but, arguably, the worst one. It has the least features
> and it has the ugliest syntax than the alternatives qmake and QBS.

But it has the most support base and the most experience out there, which was 
ostensibly the reason I posted. If users and packagers have problems, the pool 
of people who can help is much bigger.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products