[Development] Proposing CMake as build tool for Qt 6

Konstantin Tokarev annulen at yandex.ru
Sat Jun 15 23:25:33 CEST 2019



16.06.2019, 00:22, "Thiago Macieira" <thiago.macieira at intel.com>:
> On Saturday, 15 June 2019 12:22:34 PDT Bogdan Vatra via Development wrote:
>>  > 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?
>>
>>    Because qmake can build them in one go and last but not least is very
>>  convenient. Because a "new" buildsystem should do more than the existing
>>  one, not less :).
>
> That only means a "nice to have", not "must have", feature. Sure it's
> convenient, but how often do you really need both and can't simply build
> twice? My Windows build is slow enough as is[*], I'd probably welcome the
> separation.
>
> Note: with qmake's NMake generator, you *can* type "make debug" and it'll only
> compile the debug sub-targets. That doesn't work with the Unix Makefile one,
> so it won't work for macOS.
>
> [* because I build on my IT-provided dual-core laptop, which comes loaded with
> IT-provided virus scanners, data-loss prevention tools, etc.]
>
>>  > 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.
>>
>>    IMHO "the most support base and the most experience out there" it's just
>>  an appearance, or at least all these "support" and "experience" doesn't
>>  apply to Qt,
>
> Sorry, I disagree. There being more users, more posts on StackOverflow, more.
> I projects using it is not an appearance. It's a fact. Usually, that has a
> strong correlation with quality and the ability to obtain help.

CMake is well-known for its ability to create artifical difficulties, so there is no wonder
that there are more posts on StackOverflow :)

>
>>  I'll reiterate a few examples :
>>   - no PCH (in decades)
>>   - no iOS (it seems we need to wait for 3.15 to have *some* support, let's
>>  not forget that iOS it's over a decade old)
>>   - no multi ABIs builds in one go (needed for msvc and useful also for
>>  Android).
>
> I'm not claiming those existed or discounting the value of having those. And
> in the case of iOS builds, the absolute necessity thereof, before 6.0 is out.
>
> What I'm saying is that once we've got all the necessary pieces and we're
> trying to build it, we will still have problems and my post was about ensuring
> we had a robust enough tool and community to help us out. We will have
> problems, whichever tool it is. My objective was to figure out how to solve
> them afterwards.
>
> Granted, the iOS support being so new to the tool does not inspire
> confidence...
>
>>    My *hunch* is that 3.15 won't be enough to build all Qt platforms and
>>  we'll probably needs to wait a little bit more. IMHO cmake superiority it's
>>  just a myth, because, obviously, in *this moment* qmake is a superior
>>  buildsystem *for Qt*.
>
> Again, my post was not about technical superiority. It was about community and
> robustness.
>
>>    Again, I want to highlight the fact that I don't want to change TQC
>>  decision regarding Qt6 and CMake, my comments are only for the sake of the
>>  truth.
>
> And I will point out that this is not a TQtC decision, but a Qt Project
> decision, although heavily influenced by the TQtC developers supporting the
> company's position and that company's decision to cut development of the other
> contender solution.
>
> BTW, the Meson developers contacted me after I posted my email last time and
> asked if we were willing to investigate changing to it. But they didn't offer
> and I didn't see anyone else stepping up to help us in the actual migration.
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel System Software Products
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development

-- 
Regards,
Konstantin




More information about the Development mailing list