Am 12.06.19 um 12:45 schrieb Christian Gagneraud: > 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.
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 _______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
