[Development] Proposing CMake as build tool for Qt 6

[Simon Hausmann]

Am 12.06.19 um 12:45 schrieb Christian Gagneraud:
> On Fri, 7 Jun 2019 at 03:31, Alexandru Croitor <alexandru.croitor at qt.io> wrote:
>> On 6. Jun 2019, at 16:48, Christian Gagneraud <chgans at gmail.com> wrote:
>> On Fri, 7 Jun 2019 at 02:25, Simon Hausmann <Simon.Hausmann at qt.io> wrote:
>> Am 06.06.19 um 16:17 schrieb Christian Gagneraud:
>> On Fri, 7 Jun 2019 at 02:08, Simon Hausmann <Simon.Hausmann at qt.io> wrote:
>> Am 06.06.19 um 15:52 schrieb Christian Gagneraud:
>> On Fri, 7 Jun 2019 at 01:35, Bogdan Vatra via Development
>> <development at qt-project.org> wrote:
> [what a beautiful thread, flatten by HTML top posting where no one can
> understand the history of this discussion]
>
>> What metrics do you expect?
>> With the time I had available, I discovered some issues regarding iOS + CMake, but nothing insurmountable.
>> I gave my analysis. We (people working on the CMake port) feel it's possible to do.
>> Now it's just a matter of getting to do it. But we still have other things to do first.
> BTW, can cmake "out of the box" deal with:
> https://doc.qt.io/qt-5/qtremoteobjects-repc.html
> https://doc.qt.io/QtQuickCompiler/
> https://doc.qt.io/qtforpython/shiboken2/shibokenmodule.html
>
> Last time i checked none of these were supported.


QtRemoteObjects has come with CMake support since its initial release 
with Qt 5.9.0. According to git log, Kevin Funk implemented it.

The QtQuickCompiler has come with CMake support since version 2.0 
released in 2014. The git history for that is not public, but I know it 
because I wrote it myself.

Qt For Python uses CMake as its build system and it supports running 
shiboken from your project to generate type information and bindings. 
It's not very convenient from what I can tell, but it works. The docs 
are referring to it here


https://doc.qt.io/qtforpython/shiboken2/samplebinding.html#building


and the actual code is located in the pyside-setup repository under 
examples.


> Yes, qmake support is "hackish", but that is not a good reason to
> justify the near-zero support of cmake.


The above at least is certainly not "near-zero".


> And let me diverge a little bit, whatever the build system chosen by
> Qt *developers*,  Qt *users* should still be free to choose their own
> build system. I'm including both open source users and paid customers.
> That is: however *you* (qt developers) decide to use as your build
> system shouldn't impact what *I* (as a Qt user) decide to use as my
> own build system.
> For example, you'll have to support qmake for years to come... You
> like it or not.


I tend to agree with that. At the moment this is primarily a decision 
for Qt development itself.


Simon