On Fri, 7 Jun 2019 at 03:31, Alexandru Croitor <[email protected]> wrote: > On 6. Jun 2019, at 16:48, Christian Gagneraud <[email protected]> wrote: > On Fri, 7 Jun 2019 at 02:25, Simon Hausmann <[email protected]> wrote: > Am 06.06.19 um 16:17 schrieb Christian Gagneraud: > On Fri, 7 Jun 2019 at 02:08, Simon Hausmann <[email protected]> wrote: > Am 06.06.19 um 15:52 schrieb Christian Gagneraud: > On Fri, 7 Jun 2019 at 01:35, Bogdan Vatra via Development > <[email protected]> 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. Yes, qmake support is "hackish", but that is not a good reason to justify the near-zero support of cmake. 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. Chris _______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
