[Development] Proposing CMake as build tool for Qt 6

Sat Jun 15 11:18:28 CEST 2019

Hello :)

> What makes you think that you can build Qt for any platform with cmake
found
in Ubuntu 16.04 (or any later version) ?

You can download a CMake static binary (https://cmake.org/download/) that
runs fine on Ubuntu 16.04 (or 12.04 or CentOS 6 for that matters) - and it
wouldn't be hard to have a bootstrap script that builds or fetches a
recenter CMake if the local version is not up-to-date - after all, you're
talking about building Qt 6 on a system that already ships with Qt 5.5 so
you're not that concerned with using your distro's packages. That's what
tools like vcpkg do for instance (and that's what Qt itself currently does
- if the status quo was kept, building Qt 6 would start by building Qt 6's
qmake anyways).

> It has the least features and it has the ugliest syntax than the
alternatives qmake and QBS.

It has enough features to be able to implement
https://bugreports.qt.io/browse/QTBUG-73925 and I think that we are all
pretty confident that https://bugreports.qt.io/browse/QTBUG-74612 will work
out. If there are other features request / missing features for the CMake
build system they should be added - so far, I think that the CMake people
have been responsive regarding patches that were needed to achieve the Qt
build system. If there's no one doing the same work for QBS, how can you
expect Qt to migrate to it ?

Also, it is much more maintained and active (
https://github.com/qbs/qbs/graphs/contributors?from=2018-06-15&to=2019-06-15&type=c
vs
https://github.com/Kitware/CMake/graphs/contributors?from=2018-06-15&to=2019-06-15&type=c)
which should be a prime concern for any software project leveraging another
software project - that is, will it be dead in 5 years. The odds for CMake
are I think much smaller than the odds for qbs.

Finally, CMake's main maintainer has historically be open to alternative
front-end languages for CMake if someone actually puts the work in :
https://cmake.org/pipermail/cmake-developers/2016-January/027379.html ;
what would the state of C++ build systems be if the work and energy that
was put towards QBS was instead put in contributing a similar declarative
frontend to CMake is left as a thought exercice to the reader :)

Best,
Jean-Michaël

On Sat, Jun 15, 2019 at 8:46 AM Bogdan Vatra via Development <
development at qt-project.org> wrote:

> Hi,
>
> În ziua de joi, 13 iunie 2019, la 18:22:14 EEST, Thiago Macieira a scris:
> > On Thursday, 13 June 2019 01:06:06 PDT Bogdan Vatra via Development
> wrote:
> > > Hi,
> > >
> > >   There is one more missing feature to add to your list: build & debug
> > >
> > > builds for msvc in one go (same as qmake does now, a single "make"
> command
> > > will build both targets).
> >
> > 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.
> >
> > 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.
> 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.
>
> > >   Also I wonder when do you plan to release Qt6? Because according to
> > >
> > > Thiago's "what a buildsystem must to have list" he mentioned that the
> > > buildsystem should be at least 2 years in the wild. If the needed cmake
> > > support is not implemented yet, are you going to delay Qt 6 release (I
> > > won't mid to use C++20 in Qt 6 :) ) just to give time to cmake to
> mature?
> > > Or that (part of the) list was just an excuse for TQC to ditch QBS ;-).
> >
> > 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) ?
>   According to https://code.qt.io/cgit/qt/qtbase.git/tree/CMakeLists.txt?
> h=wip/cmake#n1
> <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 :).
>
>   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.
>
> Cheers,
> BogDan.
>
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20190615/b12d1923/attachment.html>